專利名稱：一種Java應用程序的更新方法及裝置的制作方法
技術領域：
本申請涉及計算機領域，特別涉及一種應用程序的更新方法及裝置。
背景技術：
在Java軟件開發過程中，開發人員每次修改代碼后需要重新編譯，并封裝為應用程序，然后重新啟動應用程序，才能看到修改后的最終執行效果；某些應用程序重新編譯后，重新啟動需要較長時間，例如，無法分割成模塊開發的應用程序(如，WEB應用的TOB層開發)，對于此種應用程序，每次即使修改很少量的代碼，都需要重新編譯封裝整個應用程序，并且關閉再重新啟動WEB應用服務器(如，Jboss)。在企業級的開發中，一般情況下，修改普通的應用程序，從修改代碼到關閉并重新啟動WEB服務器，這一過程需要5分鐘左右的時間，對于較大的應用程序，這一過程可能需要10多分鐘的時間；而在程序編寫過程中，開發人員需要定期查看當前代碼的運行結果并作相應修改，以保證代碼按照了開發人員的意愿呈現相應效果，因此需要不斷地關閉并重新啟動WEB服務器，這樣，便令無謂花在代碼編譯、重啟應用程序上的時間大大提升，尤其是當修復代碼錯誤時，這種消耗更為明顯，從而嚴重降低了代碼研發的效率。另外，對于大型服務性應用程序來說，在升級過程中，往往需要重新啟動應用程序，重新編譯部署，并重新發布應用程序，在重啟服務過程中，往往需要中斷對外的服務，從而影響系統的服務質量。針對上述問題，現有技術下提供了兩種解決方案第一種解決方案為直接使用WEB服務器(如，tomcat，Jboss)的熱部署功能。即 WEB服務器監控文件改變，如果某個文件被修改，WEB服務器便重新加載該文件所屬模塊； 從而實現熱部署。但是采用此種解決方案，存在以下缺點A.WEB服務器通過監控文件改變，重新加載整個模塊，僅能針對sevlet ( 一種服務器端的Java應用程序)進行熱加載；對于使用了框架的應用程序，無法加載框架內的內容， 如果通過servlet熱加載來實現框架代碼的更新，需要再次初始化框架，速度非常緩慢.B、每次修改文件后，WEB服務器會自動進行熱部署，這會使內存需求增加，同時，由于要重新初始化相應模塊，所以會占用大量CPU資源；多次熱部署后，系統資源會被大量占用，從而不得不停止熱部署，重新編譯應用程序和重新啟動服務。第二種解決方案為采用hotswap的方法，通過Java虛擬機(Jvm)提供的接口 (Jpda或者Jvmti)，來改變Java虛擬機的狀態，將修改過的類文件(.class文件)替換Jvm 中原有的.class文件。采用上述解決方案可以實現對運行狀態中能夠到達的區域進行修改，采用的調式工具可以是debug，具有一定的熱部署能力。然而，采用此種解決方案，存在以下缺點A、僅能針對運行狀態可以到達的區域進行修改，而不能增加新的區域。如，僅支持對方法body的修改，不支持增加方法，修改方法名，方法參數等操作。對于熱部署來說，無法做到全部代碼的熱部署，特別是經常性的操作，比如增加方法，增加內部類，修改方法名等等；會嚴重影響熱部署方法的應用范圍，具有一定的局限性。B、Hotswap提供的熱部署比較復雜，使用時會產生不穩定的現象，有時會發生崩潰。C、通過此種解決方案實現熱部署時采用的工具的開發量極大，會增加開發復雜度。綜上所述，現有的解決方案均無法實現理想的Java應用程序的熱部署，需要提供一種新的方案以克服現有方案的缺陷。
發明內容
本申請提供一種Java應用程序的修改方法及裝置，用以在對Java應用程序進行修改的過程中，降低操作流程的復雜度，提高其執行效率。本申請提供的具體技術方案如下一種Java應用程序的更新方法，包括確定存在至少一個編譯生成的目標類文件；在指定存儲位置獲取所述至少一個目標類文件；針對獲取的至少一個目標類文件建立相應的類加載程序，采用所述類加載程序將所述至少一個目標類文件加載至運行狀態的Java應用程序中；其中，所述類加載程序繼承當前的環境加載程序。一種用于Java應用程序更新的裝置，包括掃描單元，用于確定存在至少一個編譯生成的目標類文件；獲取單元，用于在指定存儲位置獲取所述至少一個目標類文件；處理單元，用于針對獲取的至少一個目標類文件建立相應的類加載程序，采用所述類加載程序將所述至少一個目標類文件加載至運行狀態的Java應用程序中；其中，所述類加載程序繼承當前的環境加載程序。本申請實施例中，開發了新的熱部署工具，通過新建的繼承當前環境classloader 的eas於tartClassLoader，在指定存儲位置加載目標類文件，并將其加載至運行狀態的 Java應用程序中，從而完成Java應用程序的更新，這樣，只需加載重新編譯的目標類文件， 便實現了 Java應用程序的熱部署，從而提高了 Java應用程序的更新效率。
圖1為本申請實施例中TOB服務器工作原理示意圖；圖2為本申請實施例中WEB服務器功能結構圖；圖3為本申請實施例中WEB服務器對運行狀態的Java應用程序進行更新流程圖。
具體實施例方式參閱圖1所示，在對Java應用程序進行修改的過程中，為了降低操作流程的復雜度，提高其執行效率，本申請實施例中，研發了一種新的熱部署工具，較佳的，該熱部分工具在運行時所采用的WEB服務器為Jboss，采用的代碼開發環境(即代碼編輯器)為 eclipse，而本申請實施例不限于Jboss和eclipse兩種實現方式，此處僅為舉例，這里只是示例性的說明如圖1所示，現有技術下，當開發人員編寫完源代碼，會使用antx/maven等編譯工具對源代碼進行編譯封裝，并最終生成軟件產品(如，一個可運行的Java應用程序)；接著，開發人員將該軟件產品部署到Jboss上，再啟動JvmCJavaVirtual Machine, Java虛擬機)，由Jvm啟動Jboss，再由Jboss啟動軟件產品(包括啟動應用框架，由應用框架啟動軟件產品的應用代碼)；此時，開發人員向Jboss發送一個執行命令，可以看到相應的執行效果。如果根據執行效果發現需要對源代碼進行修改，那么開發人員需要關閉Jboss，并重復上述源代碼修改、編譯封裝過程，將根據修改后的源代碼生成的軟件產品再次部署到Jboss 上，再重新啟動Jboss以運行修改后的軟件產品。這一過程需要較長時間，會降低Java應用程序的修改效率，從而影響整個服務系統的性能。與普通程序不同，Java程序(.class文件)并不是本地的可執行程序。當需要運行.class文件時，首先應運行JvmCJava虛擬機)，然后再把.class文件加載到Jvm中運行，負責加載.class文件的工具就叫做classloader，而Jvm在加載過程中使用的接口稱為 Jvmti接口。本申請實施例中，重新設計的熱部署工具中，重新定義了 Jvmti接口的功能，替換了 Jvm中原有的框架代碼，這樣，啟動Jvm時，Jvm根據改變后的框架代碼會自動重新創建一個classloader (稱為fes於tartClassLoader)，直接在指定存儲位置獲取最新編譯生成的.class文件，其中，Jvmti接口 如圖1所示，在原有框架(也可以稱為應用框架)運行時，Jboss—般通過運行環境中的classLoader去獲取本地軟件產品中包含的應用代碼，而本申請實施例中，通過重新定義Jvmti接口，改變了原有框架的行為，使Jboss每次調用目標.class文件時，到指定存儲位置獲取最新編譯生成的目標.class文件，所謂指定存儲位置，可以是開發人員指定的代碼編輯器中的編譯目標文件夾。實際應用中，也可以不從代碼編輯器中獲取目標.class文件，例如，通過命令行調用Jvm指令直接編譯生成一個目標.class文件，或者，從其它指定位置拷貝一個編譯生成的新的目標.class等等，其目的在于獲取一個目標.class文件并熱部署到運行狀態的 Java應用程序中，并不限制目標.class文件的來源。以下實施例中，以在代碼編輯器中的指定存儲裝置獲取目標.class文件為例進行說明。EasyStartClassLoader : gfe · classclassloader,
施例中，在創建fesyMartClassLoader時，顛倒了 classLoader的常規的雙親委派的機制 (classLoader 力口i，#由〒 classLoader ^ ) ,^Μτ^ EasyStartClassLoader 加載，再由EasyStartClassLoader的父classLoader加載的方式，同時將該父classLoader 設成環境classLoader，并通過限定EasyMartClassLoader只能加載目標.class文件，來保證與目標.class文件相關的其他.class文件或者.class文件庫由環境classLoader加載。其中，所謂環境classLoader即是當前環境的創建者，所謂環境，即是指當前的運行狀態，即一組代碼運行的狀態，加載這一組代碼的classLoader即是當前環境classLoader。在加載過程中，一般通過Java中的接口或者Java反射機制的方式，來使外部環境可以正常使用easyMartClassLoader加載的目標.class文件，從而實現在運行態，自動調用最新加載的目標.class文件來運行，并得到即時結果。以代碼編輯器是eclipse為例，開發人員修改部分代碼后，eclipse會把修改部分的代碼文件編譯成新的.class文件，即目標.class文件；由于是編譯單個文件，因此速度極快，可以忽略編譯時間；接著，通過使用被JVM的jvmti接口處理過的框架(即重新定義的框架)，定期進行文件掃描，確定eclipse中指定的文件夾內存在重新編譯生成的目標.class文件時，便在該指定的文件夾內獲取新生成的目標.class文件，這個過程速度也很快，可以忽略時間。下面結合附圖對本申請優選的實施方式進行詳細說明。參閱圖2所示，本申請實施例中，用于對Java應用程序進行更新的裝置(如，WEB 服務器)包括掃描單元10、獲取單元11和處理單元12，其中掃描單元10，用于在指定存儲位置進行掃描，確定生成了重新編譯的目標類文件， 即目標.class文件；本發明實施例中，由于在代碼編輯器中獲取目標.class文件，因此，需要采用掃描單元10定期進行文件掃描，以確定存在目標.class文件，實際應用中，若是根據Jvm命令直接編譯生成目標.class文件，或者根據指示從其他位置拷貝目標.class文件，則也可以不采用掃描單元10，在此不再贅述；獲取單元11，用于獲取至少一個目標類文件，即目標.class文件；本實施例中，獲取單元11在指定存儲位置獲取目標.class文件，其原因是Jvm采用的框架使用的是重新設計的Jvmti接口，框架行為發生了改變。處理單元12，用于針對獲取的至少一個目標類文件建立相應的類加載程序，即eas於tartClassLoader，并采用該類加載程序將獲取的至少一個目標類文件加載至運行狀態的Java應用程序中；其中，類加載程序繼承當前的環境加載程序，即 easyStartClassLoader 7 C^ IU"W^F^ classloder。本實例中，掃描單元10獲取單元11和處理單元12，是通過Jvm的重新設計的 Jvmti接口，在不改變原框架代碼的情況下，嵌入原有框架邏輯，并且生效運行的。上述TOB服務器中需支持Jvm，較佳的，上述TOB服務器為Jboss，或者為tomcat。基于上述系統架構，參閱圖3所示，本申請實施例中，以在eclipse中編譯目標.class文件為例，介紹TOB服務器對運行狀態的Java應用程序進行更新的詳細流程如下步驟300 確定代碼編輯器(如，eclipse)中存在至少一個編譯生成的目標類文件，即目標.class文件。步驟310 在代碼編輯器內的指定存儲位置獲取上述至少一個目標類文件。本申請實施例中，在執行步驟310時，WEB服務器支持的Jvm通過新定義的Jvmti 接口改變了 Jvm中運行的原有框架的行為，令改變后的框架可以在eclipse的指定存儲位置(如，eclipse默認將目標.class文件編譯到文件夾target/classes/目錄下)，獲取開發人員新編譯的目標.class文件，目標.class文件的數目可以是一個，也可以是多個。現有技術下，Jvm在配置使用jvmti接口后，Jvm在加載每個· class文件時，均會通過Jvmti接口調用，并且可以通過Jvmti接口對.class文件的字節碼進行修改，現有的 Jvmti接口的實現代碼如下byte []transform(ClassLoader loader,
Stringc IassName，Class< ？ >cIassBeingRedefined,ProtectionDomain protectionDomain,byte[]classf ileBuffer)throws IllegalClassFormatException ；現有技術下通過Jvmti接口調用.class文件是從框架的代碼中獲取，在上述代碼中，loader為裝載被調用的.class文件的classloader，className為被調用的.class文件的名稱，classBeingRedf ined為被調用的.class文件的類型，protectionDomain為被調用的.class文件的作用域，classfileBuffer為Jvm讀取到的字節碼。通常情況下，可以根據classfileBuffer讀取到的字節碼來進行分析，然后改變字節碼的內容，并返回給Jvm， Jvm將運行改變后的字節碼，從而達到改變框架行為的目的，而實際上原先使用的代碼并沒有改變，于是在不改變原先使用的代碼，即在無侵入的情況下，改變了框架的原有運行方式。但是分析并改變字節碼，需要開發人員對Java編譯類文件的機制非常了解，對.class 文件的機制非常了解，因此，按照上述方式即使達到了改變Jvm調用.class文件的原有方式的目的，也需要相當的工作量。本申請實施例中，為了減少實現上述目的的工作量，將需要改變的.class文件導入代碼編輯器(如，eclipse)中，按照實際需求自定義改變類的運行方式，保存后，代碼編輯器自動編譯生成目標.class文件，相應地，Jvm通過jvmti接口，只需檢驗代碼編輯器中的className，確定是需要替換的.class文件時，就直接獲取編譯完成的目標.class文件的字節碼，而不用去分析并修改classfileBuffer中的字節碼，這樣，便大大降低了采用原有Jvmti接口的使用方式所需的工作量。本申請實施例中，實現Jvmti接口調用的執行代碼如下String targetName = "targetClass，，；if(className. equals(targetName)){return Transformer. getBytesFromFile(targetName)；}return null ；其中，getBytesFromFile (targetName所定義的方法只是返回目標.class的文件流而已，步驟320 針對獲取的至少一個.class文件建立相應的easyMartClassLoader， 采用該easyMartClassLoader將獲取的至少一個.class文件加載至運行狀態的Java應用程序中，其中，上述easyStartClassLoader繼承當前環境classLoader。本申請實施例中，上述easyMartClassLoader的功能是加載代碼編輯器中編碼生成的指定的目標.class文件，較佳的，針對重新編譯生成的目標.class 文件可建立至少一個easyStartClassLoader,如，針對每一個目標· class文件分別建立一個easyMartClassLoader，也可以針對多個目標.class文件建立一個 easyMartClassLoader，并且要將加載的目標.class文件返回給Jvm中的運行狀態的Java 應用程序，令Java應用程序可以采用新加載的目標.class文件進行運作。本申請實施例中，要實現上述功能，存在以下難點
首先，一個classLoader加載了某個.class文件后，就不能再重新加載這個.class文件，必須重新建立一個classLoader才能重新加載這個.class文件；其次，不同的classLoader加載的.class文件是不能相互使用的，即使新建了 easyMartClassLoader，加載了目標.class文件，該.class文件也無法讓之前已建立的 classLoader iJM ；再次，easyStartClassLoader加載的.class文件大量依賴當前的環境類和類庫， 這些需要由環境classLoader加載,而不能由easyStartClassLoader加載。針對上述問題，本申請實施例中采用了以下方式加以解決每次都創建新的 easyStartClassLoader，新創建的 eas於tartClassLoader 繼 ^ IU" ^F M classLoader (艮口 {乍為 easyStartLoader 的義 classLoader) ； # i 真頁 flj J
ClassLoader的雙親委派的機制，即先由eas於tartClassLoader加載目標· class文件， 再交由其繼承的環境classLoader處理；同時通過限定加載項的辦法，保證安全，即限定 easyStartClassLoader只能加載指定存儲位置的目標.class文件，其它相關的.class文件全部交由其繼承的環境classLoader加載。其中，所謂環境classLoader即是當前環境的創建者，所謂環境，即是指當前的運行狀態，即一組代碼運行的狀態，加載這一組代碼的 classLoader 艮口是當前環境 classLoader。具體為現有技術下，classLoader的實現代碼舉例如下protected synchronized Class< ？ >loadClass (String name, boolean resolve)throws ClassNotFoundException{//First, check if the class has already been loadedClass c = findLoadedClass(name)；if (c == null) {try {if (parent ！ = null) {c = parent. IoadClass (name, false)；}else{c = findBootstrapClassO(name)；}}catch(ClassNotFoundException e){//If still not found, then invoke findClass in order//to find the class.c = f indClass (name)；}}if (resolve) {resolveClass (c)；
}return c ；}從上述代碼中可以看出，classloader存在兩個特性第一個特性為一旦加載了一個.class文件(稱為類A)，就不再去讀取其字節碼。因此，本實施例中，針對類A進行重新編譯生成類A’后，必須新建一個 easyStartClassLoader 去讀取并力口載類 A，。第二個特性為優先讓父classLoader加載.class文件，如果父classLoader可以加載這個.class文件，就不再由子classLoader加載這個.class文件。因此，本實施例中，需要顛倒雙親委派機制，針對重新編碼生成的類A’，先由新建的 easyStartClassLoader 力口classLoader (艮口 easyStartClassLoader
環境classLoader)加載其他相關的.class文件。與現有技術不同，本申請實施例中，easyStartLoader實現代碼舉例如下public synchronized Class< ？ >loadClass(String name)throwsClassNotFoundException{Class< ？ >c = findLoadedClass(name)；if (c ! = null) {return c ；}try {if (name. indexOf (targetClass) = = -1) {throw new Exception(" easyStartClassLoader escaped:" +name)；}c = this, f indClass (name)；System, out. println( " easyStartClassLoader loaded:" +name)；} catch (Exception e) {c = super. IoadClass (name)；}return c ；} 從上述代碼可以看出，easyStartClassLoader只需要繼承當前環境classLoader，
成為當前環境classLoader的子classLoader，這樣，目標.class文件(即重新編譯后的至少一個.class文件)所依賴的其他相關的.class文件則均可由環境classLoader加載， 并且環境classLoader無法加載目標.class文件，即在限定加載項(即目標.class文件) 的前提下，顛倒雙親委派的機制，讓子classLoader (即easyMartLoader)先加載，再由環境classLoader加載,但easyMartLoader只加載目標.class文件,其他相關的.class文件還是由環境classLoader加載。基于上述實施例，在將目標.class文件加載至運行狀態的Java應用程序的過程中，一般通過java中的接口或者Java反射機制的方式，來令外部環境可以調用新加載的目標.class文件。所謂Java中的接口是一系列方法的聲明，是一些方法特征的集合，一個Java中的接口只有方法的特征沒有方法的實現，因此這些方法可以在不同的地方被不同的類實現， 而這些實現可以具有不同的行為(即功能)。Java中的接口事實上由環境classLoader 加載，但easyMartClassLoader因為繼承環境classLoader所以也可以訪問到，由于 easyStartClassLoader加載的一個或一組目標.class文件也是繼承Java中的接口的，所以在外部環境中，被加載的一個或一組目標.class文件在被實例化后，通過強轉成java中的接口來被使用。本實施例中，在外部環境中使用被easyMartClassLoader加載的一個或一組.class文件的實現代碼舉例如下ClassLoader classloader = newEasyStartClassLoader (new URL [] {url}, moduleClassName)；moduleClass =classloader. IoadClass(moduleClassName)；module = (Module) moduleClass. newlnstance ()；通過上述代碼可以看出，本實施例中，被easyMartLoader加載的一個或一組目標.class文件(以下稱為被加載的模塊)實現了使用Java中的接口，同時，還保證 T Java Φ StJii π # ^ easyStartClassLoader classLoader ^^F^ classLoader 加載，而非easyMartClassLoader加載，這是為了讓環境classLoader可以使用 easyStartClassLoader加載的模塊，因為一般情況下，不同classLaoder加載的模塊是不能通用的。這樣，easyStartClassLoader繼承上述環境classLoader，便可以令自身加載的模塊訪問到環境classLoader加載的Java中的接口，從而令外部環境可以通過上述Java 中的接口來調用eas於tartClassLoader加載的模塊。其中，所謂外部環境，即是指相對于 easyStartClassLoader加載的環境，調用easyMartClassLoader加載的環境的環境稱之為外部環境。另一方面，所謂的Java反射機制(稱為Reflection)，即是在Java應用程序運行時，允許加載、探知、使用編譯期間完全未知的.class文件，換句話說，Java應用程序可以加載一個運行時才得知名稱的.class文件，獲悉其完整構造，并生成其對象實體。例如， Java反射機制為Class. getMethod (). invoke ()，采用Java反射機制，對于任意一個.class 文件，都能夠知道其所有屬性和方法；對于任意一個對象，都能夠調用它的任意一個方法； 因此，采用Java反射機制，可以在Java應用程序加載目標.class文件后，令外部環境也能夠調用該目標.class文件。最后，Jvm按照重新加載的.class文件執行Java應用程序，便可以使用新加載的.class文件具有的功能。本申請實施例中，開發了新的熱部署工具，通過新建的繼承當前環境classloader 的eas於tartClassLoader，在指定存儲位置加載目標類文件，并將其加載至運行狀態的Java應用程序中，從而完成Java應用程序的更新，這樣，只需加載重新編譯的目標類文件，便實現了 Java應用程序的熱部署，提高了 Java應用程序的更新效率；而且， easyStartClassLoader的原理結構簡單，具有很高的穩定性，也不會增加內存消耗和額外的系統消耗，可以無限次快速無代價實現熱部署，具有很高的實用性；進一步地，新的熱部署工具的核心代碼可以根據Java應用框架和應用狀態，以極少的開發量作出擴展，可以做到全代碼全操作的熱部署，具有廣泛的應用范圍。 顯然，本領域的技術人員可以對本申請進行各種改動和變型而不脫離本發明的精神和范圍。這樣，倘若本申請的這些修改和變型屬于本申請權利要求及其等同技術的范圍之內，則本申請也意圖包含這些改動和變型在內。
權利要求
1.一種Java應用程序的更新方法，其特征在于，包括獲取至少一個編譯生成的目標類文件；針對獲取的至少一個目標類文件建立相應的類加載程序，采用所述類加載程序將所述至少一個目標類文件加載至運行狀態的Java應用程序中；其中，所述類加載程序繼承當前的環境加載程序。
2.如權利要求1所述的方法，其特征在于，針對獲取的至少一個目標類文件建立相應的類加載程序，包括若獲取的目標類文件的數目為一個，則對應該目標類文件建立相應的類加載程序；若獲取的目標類文件的數目為一個以上，則對應各目標類文件建立至少一個類加載程序。
3.如權利要求1或2所述的方法，其特征在于，采用所述類加載程序將所述至少一個目標類文件加載至運行狀態的Java應用程序中，包括先采用所述類加載程序對所述至少一個目標類文件進行加載；再采用所述環境加載程序對與所述目標類文件相關的其他類文件進行加載。
4.如權利要求3所述的方法，其特征在于，采用所述類加載程序將所述至少一個目標類文件加載至運行狀態的Java應用程序中，進一步，包括采用所述類加載程序繼承所述環境加載程序加載的全部Java中的接口，令外部環境能夠通過所述Java中的接口調用所述至少一個目標類文件。
5.如權利要求3所述的方法，其特征在于，采用所述類加載程序將所述至少一個目標類文件加載至運行狀態的Java應用程序中，進一步，包括采用Java反射機制，令外部環境能夠調用所述至少一個目標類文件。
6.一種用于Java應用程序更新的裝置，其特征在于，包括獲取單元，用于獲取至少一個編譯生成的目標類文件；處理單元，用于針對獲取的至少一個目標類文件建立相應的類加載程序，采用所述類加載程序將所述至少一個目標類文件加載至運行狀態的Java應用程序中；其中，所述類加載程序繼承當前的環境加載程序。
7.如權利要求6所述的裝置，其特征在于，所述處理單元針對獲取的至少一個目標類文件建立相應的類加載程序，包括若獲取的目標類文件的數目為一個，則所述處理單元對應該目標類文件建立相應的類加載程序；若獲取的目標類文件的數目為一個以上，則所述處理單元對應各目標類文件建立至少一個類加載程序。
8.如權利要求6或7所述的裝置，其特征在于，所述處理單元采用所述類加載程序將所述至少一個目標類文件加載至運行狀態的Java應用程序中，包括先采用所述類加載程序對所述至少一個目標類文件進行加載；再采用所述環境加載程序對與所述目標類文件相關的其他類文件進行加載。
9.如權利要求7所述的裝置，其特征在于，所述處理單元采用所述類加載程序將所述至少一個目標類文件加載至運行狀態的Java應用程序中，進一步，包括采用所述類加載程序繼承所述環境加載程序加載的全部Java中的接口，令外部環境能夠通過所述Java中的接口調用所述至少一個目標類文件。
10.如權利要求6所述的裝置，其特征在于，所述處理單元采用所述類加載程序將所述至少一個目標類文件加載至Java應用程序中，進一步，包括采用Java反射機制，令外部環境能夠調用所述至少一個目標類文件。
全文摘要
本申請公開了一種Java應用程序的更新方法及裝置，用于提高Java應用程序的更新效率。該方法為獲取至少一個目標類文件，并針對獲取的至少一個目標類文件建立相應的類加載程序，在Java應用程序運行過程中，采用所述類加載程序將所述至少一個目標類文件加載至運行狀態的Java應用程序中；其中，所述類加載程序繼承當前的環境加載程序。這樣，只需加載重新編譯的目標類文件，便實現了Java應用程序的熱部署，從而提高了Java應用程序的更新效率。本發明同時提供了相應的裝置。
文檔編號G06F9/445GK102402427SQ20101027995
公開日2012年4月4日 申請日期2010年9月9日 優先權日2010年9月9日
發明者楊航 申請人:阿里巴巴集團控股有限公司