This product version supports the Java 2 Standard Edition (J2SE) 5 specification. Its Java virtual machine provides a Java language compiler and execution environment. Decide whether your new and existing applications will take advantage of the capabilities provided by J2SE 5, adjust the JIT mode if necessary, and begin the transition from deprecated functions.
The virtual machine specification provides several features and functions to benefit application developers, such as generics, auto-boxing of primitives, annotations (API documentation metadata for code generation), and support for enumerated types. This makes development quicker, easier, and less error prone. For example, generics should help eliminate issues with ClassCastExceptions from items like vectors, as generics based containers will allow compile-time catching of incorrect assignment or casting. (For developers familiar with the C++ language, generics are a new Java language function similar to C++ templates.)
For details on the specification, see the J2SE 5 application programming interface documentation on the Sun site at http://java.sun.com/j2se/1.5.0/docs/api/index.html. See also http://java.sun.com/j2se/1.5.0/docs/index.html.
Applications using the new language features and J2SE 5 can be deployed only to V6.1 nodes, as earlier product versions do not provide the J2SE 5 virtual machine.
The J2EE 1.4 specification does not take into account the new language features. Therefore, the usage of generics based types should not be used with public EJB interfaces that are exposed on the home, stubs, and so forth.
If the code being developed must run on multiple J2SE levels, use only the API specification for the minimum J2SE level, such as J2SE 1.4, to avoid inadvertent usage of classes and methods that are not part of all of the required J2SE levels. Failure to do so may cause application breakage on older J2SE implementations.
Applications that access classes and APIs internal to the Java virtual machine could have problems. These classes and APIs are not covered by the J2SE 5 specification and are therefore subject to change. Packages with prefixes such as 'com.sun.*' are considered internal. Additionally, direct use of implementations of XML and XSL parsers is strongly discouraged, such as direct use of Xerces and Xalan classes that provide the JAXP implementation for the virtual machine. The direct parser APIs also are considered internal and subject to change. Applications should rely only on the JAXP APIs defined in the J2SE 1.4 and J2SE 5 API documentation. If your application requires a specific version of Xerces or Xalan, or some other XML/XSL parser package, then embed the parser within your application's WEB-INF/lib directory and set the appropriate class loading mode in your application deployment so that for your application the XML parser APIs are loaded from the application class path, not the Java virtual machine bootstrap class path. Failure to follow this guideline can cause significant problems when trying to migrate to a new J2SE level.
When compiling applications that are built with J2SE 5 that are intended for running on older J2SE specifications, be sure to specify '-source' and '-target' modes for the J2SE 5 compiler. Doing so ensures that the bytecode generated is compatible with the earlier Java virtual machine.
For example, if the target Java virtual machine is at 1.4.2 level, when you compile applications with J2SE 5, you should specify '-source 1.4', and 'target 1.4' to generate bytecode compatible with 1.4.2. This does not handle the usage of packages, classes, or functions new to J2SE 5. It only addresses bytecode output. Developers must take care in what APIs they are using from the J2SE packages if they intend to run the application on multiple Java virtual machine specification levels.
Java (TM) 2 Technology Edition, V5.0 is upwards binary-compatible with Java (TM) 2 Technology Edition, V1.4.2, except for the incompatibilities documented by Sun Microsystems at http://java.sun.com/j2se/1.5.0/compatibility.html#binary. Most of the incompatibilities refer to compiling classes at a JDK 5 level using a target of 1.5. "Almost all existing programs should run on J2SE 5.0 without modification," to cite the Sun documentation. As a migration reference, the J2SE 1.4 and J2SE 5 application programming interface documentation is available on the Sun site at http://java.sun.com/j2se/1.4.2/docs/api/index.html and http://java.sun.com/j2se/1.5.0/docs/api/index.html, respectively. Here are the most notable source compatibility problems.
In similar circumstances, you might encounter errors importing java.lang.reflect.* Note also that a new java.utils.Queue class in J2SE 5 conflicts with other Queue package names, such as javax.jms.Queue.
You might encounter compile-time errors if you import java.util.* and then use other classes with a base name of Formatter, without fully qualifying the latter class names. The errors occur because java.util.* now contains java.util.Formatter, a class added in the J2SE 5 spec.
J2SE 5 deprecates some functions that were available for public usage in previous J2SE specifications. JVMDI and JVMPI are deprecated in J2SE 5 and might be removed in the next major release of the J2SE specification. Any new development and tool sets should begin moving to JVMTI. Migrate any of your native (JNI) performance profiling libraries to the new JVMTI API described at http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/index.html.
If you have created ANT tasks based on the idltojava ANT task shipped with prior versions of this product, you will need to ensure that it passes the proper parameters for J2SE 5 as it does for J2SE 1.4, to ensure the stubs/ties and skeletons it generates are compatible to earlier product releases.