System and method for providing a java code release infrastructure with granular code patching
A system and method for providing a code release infrastructure with granular code patching is described. Code patches, each including at least one resource unit are provided. Each resource unit includes metadata and file components. Code libraries, each including at least one resource unit, are patched. The metadata for each resource unit in the code patches is compared to the metadata for each such corresponding resource unit in the code libraries. Each resource unit in the code patches is merged into the code libraries for each such corresponding resource unit that is out-of-date as defined by merge rules. Archive files, as defined by archive file definitions, are created or updated using the resource units from the code libraries, or, optionally, are deleted. The archive files are digitally signed also as required. The system and method enables source and derived code and third party code to be patched granularly.
Latest Oracle Patents:
This patent application claims priority under 35 U.S.C. § 119(e) to provisional patent application Ser. No. 60/268,886, filed Feb. 14, 2001, the 10 disclosure of which is incorporated by reference.
FIELD OF THE INVENTIONThe present invention relates in general to maintaining applications developed using the JAVA programming language and, in particular, to a system and method for providing a JAVA code release infrastructure with granular code 15 patching.
BACKGROUND OF THE INVENTIONOver the last ten years, corporate computing environments have evolved from monolithic proprietary mainframe computer systems to networks of decentralized heterogeneous computer systems. These distributed systems 20 typically include personal computers and work stations that offer productivity solutions with higher flexibility at lower cost.
At the same time, the cost and complexity of support has drastically increased. For example, the operating systems and applications software require periodic updates. Moreover, every different system configuration can require a 25 separate reinstallation of software, an operation which can be costly and time-consuming for a large installed user base.
The JAVA programming language was developed to encourage low maintenance application development by providing a machine-independent and architecture-neutral programming language capable of operating on heterogeneous computer systems independent of machine-specific environment and configuration settings. An overview of the JAVA programming language is described in P. van der Linden, “Just JAVA,” Chapter 1, Sun Microsystems, Inc (1997 2d ed.), the disclosure of which is incorporated by reference. The most common JAVA programs are applications and applets. Applications are stand-alone programs. Applets are similar to applications, but adhere to a set of interface conventions and run only within the context of a JAVA-enabled container, such as a Web browser. During execution, the container downloads the byte code required to run the applet as needed.
The Java programming language provides a convenient means for disseminating software updates using Zip archives or Java Archive (JAR) files. These archives and files can be used to deliver and directly run Java applications and applets. The Zip archives and JAR files are packaged in a Zip format that allows multiple files to be bundled as a single archive file. In addition, JAR files include a manifest storing attributes for each of the bundled files and can include an optional digital signature. JAR files are described in D. Flanagan, “Java in a Nutshell,” Chapter 24, O'Reilly and Assocs. (1999 3d ed.), the disclosure of which is incorporated by reference.
Although offering a convenient way to deliver JAVA program updates, Zip archives and JAR files create a problem, known as the “high water mark” problem. The high water mark problem results from the inability to deliver specific updates or patches to individual component files using a JAR file. Rather, when JAVA program updates or patches are delivered using JAR files, an entire JAR file is delivered, instead of just a single updated component file. Moreover, to ensure that each JAR file is current, the JAR file must always include the latest version of each component file. A single updated component file cannot be delivered and a complete high water mark JAR file must be delivered instead. Delivering a complete high water mark JAR file results in delivering many other potentially undesirable changes, which can include unexpected behavioral changes, or other highly destabilizing changes to the product.
To avoid the high water mark problem, JAVA program updates can be delivered in the form of individual files stored within an operating system directory structure. Each separate update or patch can then be delivered to effect individual changes without unanticipated side effects. However, this approach poses difficulties with file naming conventions. The JAVA programming language supports long file and class names which are language features not supported on every operating system. JAVA source and class file names can contain special characters, such as the dollar sign, which can cause portability concerns. Similarly, the JAVA programming language uses the Unicode character set, an internationalized character set that may not be fully supported on all platforms, potentially causing further portability concerns.
These individual update or patch files also introduce directory nesting concerns. JAVA packages are implemented as directories in a hierarchical file structure. Packages can be stored in deeply nested directories. However, the nesting depth can exceed the maximum permissible depth on a given platform. Consequently, these JAVA programming language-specific file naming and directory storage conventions limit the operating systems that can directly support single file updating and patching.
JAR files lack integrity controls for ensuring the proper application of updates and patches. The order in which updates and patches are applied should not ordinarily determine the end result of the application. However, JAVA updates and patches can be generated and applied in any order. Moreover, neither JAR files nor individual patch and update files include a revision control mechanism to ensure that out-of-date class files do not overwrite the latest versions.
Inner classes further complicate JAVA program updating and patching. A single JAVA source file that uses the JAVA “inner class” construct can produce multiple JAVA class files. Inner classes make tracking out-of-date JAVA class files difficult.
Finally, other issues arise when patching and updating JAVA applets. Applets are generally loaded into a JAVA-enabled browser in a JAR file format. Some applets must be signed with a digital signature to work properly. Consequently, the JAR file in which applets are delivered must be signed. If a JAVA application being updated or patched requires a signature, either the signed high water mark JAR file must be delivered or the JAR file must be assembled and signed at the customer site. In addition to the problem inherent with delivering any high water mark file, delivering signed high water mark JAR files does not allow the integration of third-party code, that is, code not available when the JAR files are created.
Therefore, there is a need for an approach for providing a JAVA code release infrastructure. Preferably, such an approach would resolve the high water mark, patch integrity and revision control problems while supporting long file names, special characters, extended character sets, deeply nested packages, and inner classes.
There is a further need for an approach for providing granular patching of individual class files while maintaining the integrity of the source file to which the class belongs. Preferably, such an approach would include a facility to integrate third-party code into the patching process.
SUMMARY OF THE INVENTIONThe present invention provides a system and method for building and maintaining applications written in the JAVA programming language. Resource units are incorporated into a JAVA code release infrastructure. Each resource unit is created from a set of source or derived files, preferably written in the JAVA programming language and can include third-party code. The resource units include metadata that identifies and describes the contents. The version attribute of each resource unit can be derived from a revision string in the source file maintained by a revision control system. A set of JAVA code libraries, each including one or more resource units, is created and staged. Individual JAVA code patches, each made up of one or more resource units, are generated from JAVA code patch definitions. A patch tool compares the resource units in the JAVA code patches with those in JAVA code libraries and updates the resource units in JAVA code libraries as needed. If necessary, a set of JAVA archive (JAR) files, as defined by JAVA archive file definitions, are created or updated by extracting resource units from the JAVA code libraries. The JAR files are signed with a digital signature if required. In addition, obsolete JAR files are deleted.
An embodiment of the present invention is a system and method for providing a JAVA code release infrastructure with granular code patching. One or more JAVA code patches including at least one resource unit are provided. The JAVA code patch contains only those resource units that need to be updated but can optionally contain additional resource units. Each resource unit includes metadata and file components. The file components can include source JAVA files, derived JAVA files, and non-JAVA files. One or more JAVA code libraries, each including at least one resource unit, are patched. The metadata for each resource unit in the JAVA code patches is compared to the metadata for each such corresponding resource unit in the JAVA code libraries. The file components in each resource unit in the JAVA code patches are merged into the JAVA code libraries for each such corresponding resource unit that is out-of-date. If needed, only those JAVA archive files with resource units that are out-of-date when compared to corresponding resource units in JAVA code libraries are created or updated, and signed with a digital signature also if required.
A further embodiment is a system and method for patching staged code in a JAVA code release infrastructure. One or more staged JAVA code libraries are maintained in a staged code repository. Each JAVA code library includes at least one resource unit. Each resource unit includes metadata and file components. The JAVA code patches are stored in a patch repository and can be downloaded to the client to stage. One or more JAVA code patches in a staged patch repository are accessed. Each JAVA code patch includes at least one resource unit. The metadata for each resource unit in the staged JAVA code patches is compared to the metadata in the staged JAVA code libraries for each such corresponding resource unit. The file components in each resource unit in the staged JAVA code patches are merged into the staged JAVA code libraries for each such corresponding resource unit that is out-of-date. The JAVA code libraries can be implemented as a virtual file system and can be used directly by a JAVA Virtual Machine (JVM). If necessary, a set of JAVA archive (JAR) files, as defined by JAVA archive file definitions, are created or updated by extracting resource units from the JAVA code libraries. The JAR files are signed with a digital signature if required. In addition, obsolete JAR files are deleted.
A further embodiment is a system and method for generating JAVA code patches in a JAVA code release infrastructure. One or more JAVA code patch definitions describe the contents of JAVA code patches. A JAVA code patch definition identifies the set of resource units that must be included in the corresponding JAVA code patch. Each resource unit includes metadata and file components and is generated using files maintained in a source code repository. The resource units are packaged into JAVA code patches and staged. The staged JAVA code patches are stored into a staged patch repository from which the metadata for each resource unit is compared to the metadata for each such corresponding resource unit in the staged JAVA code libraries. The file components in each resource unit in the staged JAVA code patches are merged into the staged JAVA code libraries for each such corresponding resource unit that is out-of-date.
Still other embodiments of the present invention will become readily apparent to those skilled in the art from the following detailed description, wherein is described embodiments of the invention by way of illustrating the best mode contemplated for carrying out the invention. As will be realized, the invention is capable of other and different embodiments and its several details are capable of modifications in various obvious respects, all without departing from the spirit and the scope of the present invention. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.
The server 11 is used to build and maintain applications written in the JAVA programming language and other application programming languages. The applications are stored as source files 19 in the server storage device 18. As the applications are modified by updates and bug fixes, the patch generator 17 generates a set of JAVA code patches 20 that are downloaded by the client 12 and remote client 14. The patch tool 21 compares the contents of the JAVA code patch 20 to the contents of staged code 24 stored in the client storage device 22 or remote client storage device 23, respectively. The staged code 24 is updated by the patch tool 21 as needed.
The individual computer systems, including the server 11, client 12 and remote client 14, are general purpose, programmed digital computing devices consisting of a central processing unit (CPU), random access memory (RAM), non-volatile secondary storage, such as a hard drive or CD-ROM drive, network interfaces, and peripheral devices, including user-interfacing means, such as a keyboard and display. Program code, including software programs written in the JAVA programming language, and data, are loaded into the RAM for execution and processing by the CPU and results are generated for display, output, transmittal, or storage.
Individual JAVA applications (not shown) are executed by a JVM. Each JAVA application comprises byte code, which is a machine-independent form of binary code and interpretable by any JVM independent of architecture or operating system. The byte code is included in the resource units 38.
Resource units 38 form the basis of the JAVA code release infrastructure to enable granular code patching. A resource unit 38 is the smallest entity capable of being updated or patched. Resource units 38 are formed from metadata information (not shown) and file components stored in the source files 19, which include JAVA source code 33, JAVA derived code 34, non-JAVA source and derived code 35, and third party code 36. Metadata information is derived from the JAVA source code 33, JAVA derived code 34, non-JAVA source and derived code 35, and third party code 36, and includes attributes, such as a unique identifier, version and similar information. A set of JAVA code patch definitions 37 are used by the resource unit generator 31 to identify the versions of the resource units 38 to include in each JAVA code patch 20.
Each JAVA code library 41 includes one or more resource units 38 bundled in a JAVA archive (JAR) or cabinet archive (CAB) format. A JAVA code library in Zip format provides a portable virtual file system, which can be used directly by a JAVA virtual machine (JVM). The JAVA code libraries 41 can also be stored in an operating system directory structure or in a database (not shown).
The set of JAVA code libraries 41 need not be in the same format. JAVA code libraries 41 referenced by the patch tool 21 can be third-party code, which is maintained separately from the JAVA code release infrastructure.
The JAVA archive files 42 can be used by stand-alone JAVA applications or JAVA applets running in a browser application. Each JAVA archive file 42 includes one or more resource units 38 plus additional functionality for use by JAVA applets. Each JAVA archive file 42 also includes a manifest storing attributes describing the included resource units 38 and an optional digital signature.
Each JAVA archive file definition 43 describes the contents of an associated JAVA archive file 42 in terms of resource units 38. Similarly, the JAVA archive file definitions 43 can be used to describe an associated JAVA archive file that has become obsolete. The JAVA archive file definition 43 is extensible and allows customizations.
Thus, when creating or updating JAVA archive files 42, the patch tool 21 first references the set of JAVA archive file definitions 43. The patch tool 21 compares the resource units 38 from the JAVA code libraries 41 with the corresponding resource units 38 from the JAVA archive files 42. Resource units 38 required in a JAVA archive file 42 can be from third-party JAVA code libraries 41 which are maintained separately from the infrastructure. The patch tool 21 updates the JAVA archive files 42 by replacing out-of-date resource units 38 from the JAVA archive files 42 with newer resource units 38 from the JAVA code libraries 41 as needed.
Referring first to
Referring now to
Referring back to
Similarly, when multiple JAVA class files 34 are derived from a single JAVA source code file 33 such as required when updating JAVA inner classes, the prior art JAVA code patching system does not guarantee that all of the derived JAVA classes are updated as a unit. As well, the staged code in the directory structure 62 can place severe restrictions on the use of features supported by the JAVA programming language that may not be fully supported on all platforms. These features include long file names, deeply nested packages, extended character sets, and special characters included in file names.
During the first thread 99, JAVA source code files 33 are compiled 30 (transition 54) using a JAVA compiler (not shown) into JAVA derived code files 34. Resource units 38 are generated (transition 95) from the source 33 and JAVA derived code files 34, as further described below with reference to
During the second thread 100, non-JAVA source and derived code files 35 are used to generate (transition 95) resource units 38, as further described below with reference to
During the third thread 101, third party code files 36 are used to generate (transition 95) resource units 38, as further described below with reference to
During operation, the resource unit generator module 31 identifies the set of files required for each resource unit 38 using the JAVA code patch definitions 37 (shown in
When compiled, this JAVA source would result in multiple JAVA derived files 34, namely, A.class, A$1.class and A$Inner.class. These files must be packaged and updated as a unit.
Referring back to
The resource unit packager 123 bundles the JAVA source 33, JAVA derived code 34, non-JAVA source and derived code 35, third-party code 36, and metadata 124 into the resource units 38. In the described embodiment, resource units 38 are packaged as Zip archives, although other formats are feasible, as described above. Resource units 38 allow the use of JAVA-native features, including long file and class names, file names containing special characters, JAVA inner classes, and deeply nested packages implemented as directories.
The patch tool 21 includes four modules: compare 141, merge 142, extract 143, and sign 144. The compare module 141 compares resource units included in the set of JAVA code patches 20 to corresponding resource units included in the JAVA code libraries 41. The compare module 141 compares, for instance, the version attribute of corresponding resource units to determine if a resource unit in any JAVA code library 41 requires updating. The compare module uses a set of rules that allow a newer resource unit to be replaced by an older resource unit for the purposes of backing out a previously applied JAVA code patch.
The merge module 142 updates the JAVA code libraries 41 by removing obsolete resource units, adding any resource units that are missing and replacing 15 out-of-date resource units in the JAVA code libraries 41 with updated resource units from the JAVA code patches 20.
In the described embodiment, any resource unit included in a JAVA code library 41 that does not have a version attribute is replaced with a corresponding resource unit from a JAVA code patch 20. The set of rules used when comparing resource units and determining out-of-date resource units are flexible and provide the ability to back out changes made by a prior JAVA code patch, when required. Other merging rules can be applied to implement a resource unit updating policy, as would be recognized by one skilled in the art.
The extract module 143 uses the set of JAVA archive file definitions 43 to identify a set of JAVA archive files 42 in terms of included resource units. Each JAVA archive file 42 includes a set of resource units stored in a JAVA archive (JAR) file format. JAVA archive files 42 are primarily used by JAVA applets running in JAVA-enabled browser applications. If a required JAVA archive file 42 does not already exist as a staged code file 24 or requires an update, the extract module 143 extracts the required resource units from the JAVA code libraries 41 to create or update the JAVA archive file 42.
Finally, if required the sign module 144 digitally signs JAVA archive files 42 using a digital certificate 145. Digital signatures are used by JAVA applications and applets to authenticate the sources of JAVA code included in JAVA archive libraries.
In the initialize phase (block 161), JAVA code patches 20 (shown in
The set of resource units 38 to be generated is identified by referring to the JAVA code patch definitions 37 (block 171). Each identified resource unit 38 is processed in an iterative loop (blocks 172–178). During each iterative loop (block 172), the resource unit 38 definition is first checked for third-party code (block 173) and native JAVA source code (block 174). If the resource unit does not contain third-party code (block 173) but does contain native JAVA source code (block 174), the JAVA source code is compiled (block 175) using a JAVA compiler 121 (shown in
The set of JAVA code patch definitions 37 is referenced (block 181). Each resource unit 38 referenced in the JAVA code patch definitions 37 is processed in an iterative loop (blocks 182–184). During each iterative loop (block 182), resource units 38 are packaged into a JAVA code patch 20 (block 183) using the packager 32 of the patch generator 17 (shown in
Initially, the JAVA code patches 20 are identified for processing (block 25 191). The JAVA code patches 20 are then applied (block 192), as further described below with reference to
The routine merges a set of JAVA code patches 20 using a set of nested iterative processing loops (blocks 201–207 and 202–206). During each outer iterative loop (blocks 201–207), a JAVA code patch 20 is processed. During each inner iterative loop (blocks 202–206), a resource unit 38 included in the JAVA code patch 20 is processed. Resource units 38 in a JAVA code patch 20 are compared to corresponding resource units in JAVA code libraries 41 (block 203). If a JAVA code library 41 requires updating (block 204), the resource unit 38 in the JAVA code library 41 is updated (block 205). Processing continues with each subsequent resource unit 38 in the JAVA code patch 20 (block 206) and for each remaining JAVA code patch 20 (block 207). The routine then returns if JAVA archive files 42 are not required (block 208).
Otherwise, if JAVA archive files are required (block 208), the set of JAVA archive file definitions 43 (shown in
While the invention has been particularly shown and described as referenced to the embodiments thereof, those skilled in the art will understand that the foregoing and other changes in form and detail may be made therein without departing from the spirit and scope of the invention.
Claims
1. A system for providing a JAVA code release infrastructure with granular code patching, comprising:
- a computer readable storage medium holding one or more JAVA code patches, each comprising at least one resource unit, each resource unit comprising metadata and file components;
- a computer readable storage medium holding one or more to-be-patched JAVA code libraries, each comprising at least one such resource unit;
- a computer readable storage medium holding a patch tool, comprising:
- a compare module that determines which units in the to-be-patched JAVA code libraries are outdated by comparing the metadata for each such resource unit in the JAVA code patches to the metadata for each such corresponding resource unit in the to-be-patched JAVA code libraries; and
- a merge module merging each such resource unit in the JAVA code patches into the to-be-patched JAVA code libraries for each such corresponding resource unit that is out-of-date.
2. A system according to claim 1, further comprising:
- an extract module extracting at least one resource unit from the JAVA code libraries and modifying one or more JAVA archive files that are out-of-date with the at least one extracted resource unit.
3. A system according to claim 1, further comprising:
- a sign module signing the JAVA archive files using a digital certificate.
4. A system according to claim 1, wherein the one or more JAVA archive files are modified through at least one of creation, revision or deletion.
5. A system according to claim 1, further comprising:
- a source repository storing the source file components;
- a staged patch repository storing the one or more JAVA code patches; and
- a staged code repository organizing the one or more JAVA code libraries and the JAVA archive files.
6. A system according to claim 1, further comprising:
- a resource unit generator processing the file components into at least one such resource unit; and
- a packager packaging at least one such resource unit into one or more of the JAVA code patches.
7. A system according to claim 6, further comprising:
- stored JAVA source code provided as the file components.
8. A system according to claim 7, further comprising:
- a compiler compiling at least one JAVA source code file into one or more JAVA classes; and
- a resource unit packager module storing the JAVA classes into at least one such resource unit as the file components.
9. A system according to claim 6, further comprising:
- at least one of non-JAVA source and derived code provided as the file components.
10. A system according to claim 6, further comprising:
- third party code provided as the file components.
11. A system according to claim 6, further comprising:
- a metadata generator generating the metadata for each such resource unit; and
- a resource unit packager module storing the generated metadata into the resource unit.
12. A system according to claim 11, wherein the metadata comprises at least one of a unique identifier and a version attribute.
13. A system according to claim 1, further comprising:
- a compare module using a set of rules allowing one of an older resource unit to be replaced by a newer resource unit and a newer resource unit to be replaced by an older resource unit to back out a previously-applied JAVA code patch.
14. A system according to claim 1, further comprising:
- one or more JAVA archive files, each comprising at least one resource unit corresponding to one such resource unit in the JAVA code libraries; and
- a patch tool referencing JAVA archive file definitions which each correspond to one or more of the JAVA archive files.
15. A system according to claim 14, further comprising:
- an extract module extracting the resource units from the JAVA code libraries into the JAVA archive files for each such corresponding resource unit that is out-of-date.
16. A system according to claim 15, further comprising:
- an extract module referencing third party JAVA code libraries not maintained as part of the infrastructure.
17. A system according to claim 1, further comprising:
- JAVA code libraries implemented as a portable virtual file system which can be used directly by a JAVA Virtual Machine.
18. A system according to claim 1, further comprising:
- a machine portable infrastructure providing support for JAVA language features by encapsulating JAVA inner classes, nested directory structures, native class names, and native character set.
19. The system of claim 1, wherein the compare module resides on a client machine that is separate from a server machine on which resides a patch generator that generated the one or more JAVA code patches.
20. The system of claim 19, wherein the client machine downloads the one or more JAVA code patches from the server machine.
21. A method for providing a JAVA code release infrastructure with granular code patching, comprising:
- providing one or more JAVA code patches, each comprising at least one resource unit, each resource unit comprising metadata and file components;
- patching one or more to-be-patched JAVA code libraries, each comprising at least one such resource unit;
- comparing the metadata for each such resource unit in the JAVA code patches to the metadata for each such corresponding resource unit in the to-be-patched JAVA code libraries; and
- merging each such resource unit in the JAVA code patches into the to-be-patched JAVA code libraries for each such corresponding resource unit that is out-of-date.
22. A method according to claim 21, further comprising:
- extracting at least one resource unit from the JAVA code libraries and modifying one or more JAVA archive files that are out-of-date with the at least one extracted resource unit.
23. A method according to claim 21, further comprising:
- signing the JAVA archive files using a digital certificate.
24. A method according to claim 21, wherein the one or more JAVA archive files are modified through at least one of creating, updating or deleting.
25. A method according to claim 21, further comprising:
- storing source file components into a source repository;
- storing one or more JAVA code patches into a staged patch repository; and
- organizing one or more JAVA code libraries and the JAVA archive files into a staged code repository.
26. A method according to claim 21, further comprising:
- processing the file components into at least one such resource unit; and
- packaging at least one such resource unit into one or more of the JAVA code patches.
27. A method according to claim 26, further comprising:
- providing JAVA source code as the file components.
28. A method according to claim 25, further comprising:
- compiling at least one JAVA source code file into one or more JAVA classes; and
- storing the JAVA classes into at least one such resource unit as the file components.
29. A method according to claim 26, further comprising:
- providing at least one of non-JAVA source and derived code as the file components.
30. A method according to claim 26, further comprising:
- providing third party code as the file components.
31. A method according to claim 26, further comprising:
- generating the metadata for each such resource unit; and
- storing the generated metadata into the resource unit.
32. A method according to claim 31, wherein the metadata comprises at least one of a unique identifier and a version attribute.
33. A method according to claim 21, further comprising:
- using a set of rules to allow one of an older resource unit to be replaced by a newer resource unit and a newer resource unit to be replaced by an older 3 resource unit to back out a previously-applied JAVA code patch.
34. A method according to claim 21, further comprising:
- providing one or more JAVA archive files, each comprising at least one resource unit corresponding to one such resource unit in the JAVA code libraries; and
- referencing JAVA archive file definitions which each correspond to one or more of the JAVA archive files.
35. A method according to claim 34, further comprising:
- extracting the resource units from the JAVA code libraries for each such corresponding resource unit that is out-of-date.
36. A method according to claim 35, further comprising:
- referencing third party JAVA code libraries not maintained as part of the infrastructure.
37. A method according to claim 21, further comprising:
- implementing JAVA code libraries as a portable virtual file system which can be used directly by a JAVA Virtual Machine.
38. A method according to claim 21, further comprising:
- providing a machine portable infrastructure supporting JAVA language features by encapsulating JAVA inner classes, nested directory structures, native class names, and native character set.
39. A computer-readable storage medium holding code for performing the method of claim 21.
40. The method of claim 21, wherein the step of comparing is performed on a client machine that is separate from a server machine on which resides a patch generator that generated the one or more JAVA code patches.
41. The method of claim 40, further comprising downloading the one or more JAVA code patches from the server machine to the client machine.
42. A system for patching staged code in a staged JAVA code release infrastructure, comprising:
- a staged code repository maintaining one or more staged to-be-patched JAVA code libraries, each staged to-be-patched JAVA code library comprising at least one resource unit, each resource unit comprising metadata and file components;
- a staged patch repository storing one or more JAVA code patches, each JAVA code patch comprising at least one resource unit corresponding to one such resource unit specified in a JAVA code patch definition; and
- a patch tool accessing one or more JAVA code patches in the staged patch repository, comprising:
- a compare module comparing the metadata for each resource unit in the JAVA code patches to the metadata in the staged to-be-patched JAVA code libraries for each such corresponding resource unit; and
- a merge module merging each resource unit in the JAVA code patches into the staged to-be-patched JAVA code libraries for each such corresponding resource unit that is out-of-date.
43. A system according to claim 42, further comprising:
- an extract module referencing JAVA archive file definitions which each correspond to a staged JAVA archive file, each staged JAVA archive file comprising at least one resource unit corresponding to one such resource unit in the staged JAVA code libraries.
44. A system according to claim 43, further comprising:
- an extract module extracting one such resource unit from the staged JAVA code libraries into the staged JAVA archive files for each such corresponding resource unit that is out-of-date.
45. A system according to claim 44, further comprising:
- a sign module creating a digital signature for the staged JAVA archive files using a digital certificate.
46. The system of claim 42, wherein the compare module resides on a client machine that is separate from a server machine on which resides a patch generator that generated the JAVA code patches.
47. A method for patching staged code in a JAVA code release infrastructure, comprising:
- maintaining one or more staged to-be-patched JAVA code libraries in a staged code repository, each staged to-be-patched JAVA code library comprising at least one resource unit, each resource unit comprising metadata and file components;
- accessing one or more JAVA code patches in a staged patch repository, each JAVA code patch comprising at least one resource unit corresponding to one such resource unit specified in a JAVA code patch definition;
- comparing the metadata for each resource unit in the JAVA code patches to the metadata in the staged to-be-patched JAVA code libraries for each such corresponding resource unit; and
- merging each resource unit in the JAVA code patches into the staged to-be-patched JAVA code libraries for each such corresponding resource unit that is out-of-date.
48. A method according to claim 47, further comprising:
- referencing JAVA archive file definitions which each correspond to a staged JAVA archive file, each staged JAVA archive file comprising at least one resource unit corresponding to one such resource unit in the staged JAVA code libraries.
49. A method according to claim 48, further comprising:
- extracting one such resource unit from the staged JAVA code libraries into the staged JAVA archive files for each such corresponding resource unit that is out-of-date.
50. A method according to claim 49, further comprising:
- creating a digital signature for the staged JAVA archive files using a digital certificate.
51. A computer-readable storage medium holding code for performing the method of claim 47.
52. The method of claim 47, wherein the step of comparing is performed on a client machine that is separate from a server machine on which resides a patch generator that generated the JAVA code patches.
53. A computer-implemented method for patching code, the method comprising:
- downloading, to a client machine, from a server machine that is separate from the client machine, one or more patches that were generated on the server machine;
- comparing, at the client machine, (a) contents of the one or more patches to (b) code that is not resident on the server machine;
- based on the comparing, determining one or more out-of-date portions within the code; and
- applying at least a part of the one or more patches to the out-of-date portions without applying any part of the one or more patches to parts of the code other than the out-of-date portions.
5495610 | February 27, 1996 | Shing et al. |
6006034 | December 21, 1999 | Heath et al. |
6052531 | April 18, 2000 | Waldin et al. |
6349407 | February 19, 2002 | Towfiq |
6425126 | July 23, 2002 | Branson et al. |
6460055 | October 1, 2002 | Midgley et al. |
6535894 | March 18, 2003 | Schmidt et al. |
20020174139 | November 21, 2002 | Midgley et al. |
- TDB-ACC-NO: NNRD412102, Disclosure Title: “System for Service Level Identification in a Client/Server WWW/Java Environment”, Research Disclosure, Aug. 1998, UK. 6 pages, retrieved from EAST V 2.0.1.4. Nov. 22, 2004.
- Pugh, William; “Compressing Java Class Files”, p. 247-258, 1999 ACM, retrieved from ACM database Jan. 13, 2005.
- “Updating a JAR File”, 3 pages, retrieved from <URL http://java.sun.com/docs/books/tutorial/jar/basics/update.html>, retrieved Jan. 13, 2005.
- “Retrologic Systems RetroGuard Java Obfuscation”, retrieved from google.com search, □□<URL http://www.retrologic.com/rg-docs-patchadv.htnl>, Jan. 13, 2005.
Type: Grant
Filed: Feb 11, 2002
Date of Patent: Oct 24, 2006
Assignee: Oracle International Corporation (Redwood Shores, CA)
Inventors: Kenton E. Noble (Hillsborough, CA), Richard J. Lotero (San Mateo, CA), Subash Chadalavada (Fremont, CA), William Greene (Belmont, CA), Keith Swartz (Seattle, WA), Joseph H. Kent (Burlingame, CA), Joseph Epstein (San Bruno, CA)
Primary Examiner: Mary Steelman
Attorney: Hickman Palermo Truong & Becker LLP
Application Number: 10/073,669
International Classification: G06F 9/44 (20060101);