Migrate to Java 2 Standard Edition (J2SE) 5

 

+

Search Tips   |   Advanced Search

 

Overview

WAS 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 added by J2SE 5, adjust the JIT mode if necessary, and begin the transition from deprecated functions.

For an introduction to J2SE 5, see the "J2SE 5 in a Nutshell" article on the Sun site.

The following JSRs are new in J2SE 5:

• JSR 003: The JMX 1.2 specification. Packages: javax.management.*
• JSR 013: Additions to java.math for improved arithmetic operations using BigDecimal
• JSR 028: The Java SASL packages: javax.security.sasl
• JSR 114: JDBC Rowset implementations that specify rowset more completely
• JSR 133: Java Memory Model and Thread Specification Revision
• JSR 160: JMX remote API, V1.0
• JSR 163: Java Platform Profiling Architecture, JVMTI (replaces JVMPI)
• JSR 166: Concurrency utilities. Packages: java.util.concurrent.*
• JSR 174: Monitoring and Management Specification for the Java Virtual Machine
• JSR 1.5: A Metadata Facility for the Java Programming Language
• JSR 200: Network Transfer Format for Java Archives
• JSR 201: Extending the Java Programming Language with Enumerations, Autoboxing, Enhanced for Loops and Static Import
• JSR 206: Java API for XML Processing (JAXP) 1.3
• JSR 204: Unicode Supplementary Character Support

The new virtual machine specification adds 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, see the J2SE 5 application programming interface documentation on the Sun site.

See also http://java.sun.com/j2se/1.5.0/docs/index.html.

 

Procedure

• Determine whether to use the default JIT mode.

  For J2SE 5, the default JIT mode for the Solaris virtual machine depends on the hardware configuration. It is no longer always 'client.' With J2SE 5, for server class hardware (meaning 2+ CPU and greater than 2 GB RAM), the virtual machine automatically switches to 'server' JIT mode.

  To configure the -server or -client parameter to your liking, set the generic Java virtual machine arguments of the server process definition.

• Decide whether to take advantage of new J2SE 5 capabilities in your applications.

  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.

• Compile J2SE 5 applications to run on older Java virtual machine levels by setting the compiler modes.

  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.

• Address incompatibilities in previously compiled J2SE 1.4 based applications.

  Java 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.

  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
  • http://java.sun.com/j2se/1.5.0/docs/api/index.html

  Here are the most notable source compatibility problems.

  • Variables named 'enum.' The word 'enum' has become a language keyword. It now will cause a compiler fault if used as a variable name. Consider specifying '-source 1.4' for compilations with J2SE 5 until you can correct the variable names. While using -source 1.4, all new JDK 5 language constructs are disabled and cannot be used in the source code.

  • Ambiguous references to classes with base names of 'Proxy,' 'Queue,' or 'Formatter.' You might encounter compile-time errors if you import java.net.* and then use other classes with a base name of Proxy without fully qualifying the latter class names. The errors are because java.net.* now contains java.net.Proxy.

    In similar circumstances, you might encounter errors importing...

    java.lang.reflect.*

    Note also that a new class...

    java.utils.Queue

    ...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.

• Start the transition from deprecated JVMDI and JVMPI functions to JVMTI.

  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.

• Update your use of the Java command line interface. The command-line interfaces for the J2SE 5 level have not changed extensively from J2SE 1.4, although they vary among virtual machine vendors. You can find them in the JAVA_HOME/bin directory. Here are some notable command line options that are standard to all J2SE 5 implementations.

  • For JVMTI, use -agentlib to load a native agent library specified.

  • For JVMTI, use -agentpath to load the native agent library by the full path name

  • For JVMTI, use -javaagent to load the Java programming language agent (see java.lang.instrument for details)

  • See apt -help for information about this new command line supporting the annotations capability.

  • See javac -help for information and updates to that command line.

• Update ANT tasks.

  If you have created ANT tasks based on the idltojava ANT task shipped with prior versions of WAS, 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.

---

J2EE specification

 

Related information

http://java.sun.com/developer/technicalArticles/releases/j2se15/
http://java.sun.com/j2se/1.5.0/docs/api/index.html
http://java.sun.com/j2se/1.5.0/docs/index.html
http://java.sun.com/j2se/1.4.2/docs/api/index.html
http://java.sun.com/j2se/1.5.0/compatibility.html
http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/index.html
http://java.sun.com/j2se/1.5.0/docs/guide/xml/jaxp/JAXP-Compatibility_150.html