Data processing: software development – installation – and managem – Software installation – Network
Reexamination Certificate
1999-04-27
2003-05-27
Morse, Gregory (Department: 2122)
Data processing: software development, installation, and managem
Software installation
Network
C717S176000, C709S241000, C709S242000
Reexamination Certificate
active
06571389
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a computer system, and deals more particularly with a method, system, and computer-readable code for improving the manageability and usability of a Java environment.
2. Description of the Related Art
Java is a robust, portable object-oriented programming language developed by Sun Microsystems, Inc., and which is gaining wide acceptance for writing code for the Internet and World Wide Web. While compilers for most programming languages generate code for a particular operating environment, Java enables writing programs using a “write once, run anywhere” paradigm. (“Java” and “Write Once, Run Anywhere” are trademarks of Sun Microsystems, Inc.)
Java attains its portability through use of a specially-designed virtual machine (“VM”). This virtual machine is also referred to as a “Java Virtual Machine”, or “JVM”. The virtual machine enables isolating the details of the underlying hardware from the compiler used to compile the Java programming instructions. Those details are supplied by the implementation of the virtual machine, and include such things as whether little Endian or big Endian format is used for storing compiled instructions, and the length of an instruction once it is compiled. Because these machine-dependent details are not reflected in the compiled code, the code can be transported to a different environment (a different hardware machine, a different operating system, etc.), and executed in that environment without requiring the code to be changed or recompiled—hence the phrase “write once, run anywhere”. The compiled code, referred to as Java “bytecode”, then runs on top of a JVM, where the JVM is tailored to that specific operating environment. As an example of this tailoring of the JVM, if the bytecode is created using little Endian format but is to run on a microprocessor expecting big Endian, then the JVM would be responsible for converting the instructions from the bytecode before passing them to the microprocessor.
Programs written in Java take two forms: applications and applets. Java applets are applications that are intended to be downloaded to a user's machine with a Web page, and run within the Web browser that displays the Web page. Since Java was introduced in 1995, it has gone through a number of dramatic changes in a very short period of time. During this evolution, number of advantages and disadvantages of using applications versus applets have come to light.
One of the areas of difference between applications and applets is in the Java runtime environment, as well as the affect of changes thereto. (The runtime environment includes the JVM, as well as a number of files and classes that are required to run Java application or applets. Hereinafter, the terms “JVM” and “runtime environment” will be used interchangeably unless otherwise noted.) For applets, only a single level of the JVM exists in a given version of a browser. In order to upgrade the JVM level to keep pace with changes to the language, a new version of the browser must be installed. And, as new levels of browsers are installed on client machines, developers must update and maintain the Java code, recompiling (and retesting) it to match the browser's JVM level. In addition, evolution of the Java language has in some cases resulted in functionality (such as specific application programming interfaces, or “APIs”) being deprecated between Java levels. This means that applets written in Java version 1.0.2, while they work in Java version 1.1, may not work when the browsers adopt the next version, Java 2. To continue using an applet written in an older Java version without changing the applet, an older JVM level (and therefore an older browser) must be used. While this approach solves the problem of running applets written in older Java versions, it typically does not enable deployment of new applets within this browser, because development tools typically cease supporting generation of code in the older levels. Furthermore, as defects in existing browser JVMs are identified, applet developers often create work-arounds while waiting for JVM developers to fix the problem. Once the fixes are applied, the work-arounds may cause defects in the applet. In addition, obtaining the latest release of a browser does not necessarily imply that it will provide the latest release of the JVM level, as the level of JVM within a browser tends to lag behind the currently released JVM level by 6 to 8 months. This may mean that applets under development, which will be created using a development toolkit, are created using a newer JVM level than is available in the new browser.
For applications, changes to the run-time environment are easier to deal with, as most Java applications ship bundled together with their own level of the Java runtime and those that don't state the required level of the Java runtime. However, shipping a runtime with the application means that multiple copies of the same JVM level may be installed on the client, leading to wasted storage space. When the application is not bundled with its runtime, on the other hand, the user is responsible for making sure that the correct JVM level is installed and the application is set up to use that level. Changing the runtime level so that a Java program can run, and making sure that all system settings are appropriate for the new level, is a difficult task for an end user to perform in today's environment. One solution to this problem is to write Java programs so that they will run correctly across multiple Java runtime levels. This, however, is a very difficult task for a developer, and is therefore not a viable solution.
A further issue in the run-time environment for applets is differences in how browsers from different vendors implement a particular JVM level. The browsers most commonly used today are Netscape Navigator and Internet Explorer. Because an applet developer typically has no way of predicting which browser (or browsers) will be used to run his application, good development practice calls for testing the applet with each potential browser. As will be readily apparent, the time spent testing an applet grows significantly when it is tested for multiple browsers, multiple JVM levels within each browser, etc. (as well as possibly testing implementations of the browsers on different operating system platforms). Sun Microsystems has attempted to address inter-browser differences (which also provides a way of making the latest run-time level available for applet execution) by providing a Java Plug-In which allows applets to be executed using a run-time environment provided by Sun, instead of the run-time provided by the browser. A JVM level can be selected from among those supported by the plug-in. However, this approach requires a user to understand which is the required JVM level and how to select it. In addition, the plug-in still provides a single level of a JVM until the user manually selects a different level, and therefore does not address the problems discussed above related to differences between JVM levels.
For applications, differences in JVM implementations manifest themselves differently. Typically, there is only one version of each JVM level per operating system platform. It may be easier for a developer to predict which operating system his applications will run on than it is to predict which browser will be used for executing applets. Thus, the test and support requirements are significantly simpler for applications than for applets. Synchronization between the JVM level used in application development and the JVM level used for executing the resulting application, as well as the synchronization problems related to fixing errors, are less likely to present a problem, compared to the situation for applets that was discussed above. This is because both the development and runtime environment for applications are likely to be provided by the same vendor. In addition, when it is desirable to run an application on an older JVM
Spyker Andrew W.
Walnock Matthew David
Doubet Marcia L.
Kendall Chuck
Ray-Yarletts Jeanine S.
LandOfFree
System and method for improving the manageability and... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for improving the manageability and..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for improving the manageability and... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3041296