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.
About this task
For an introduction to J2SE 5, see the "J2SE 5 in a Nutshell"
article on the Sun site at
http://java.sun.com/developer/technicalArticles/releases/j2se15/. 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 175: 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 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.)
The Java Monitoring and
Management Console (JConsole) is part of the Sun Java Development
Kit (JDK) and the IBM Software Development Kit (SDK) Version 5. Although
these development kits are shipped with WebSphere Application Server Version 6.1, WebSphere Application Server does
not support the JConsole tool.
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.
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.
See Java virtual machine settings.
- 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 Version 6.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 (TM) 2 Technology Edition,
Version 5.0 is upwards binary-compatible with Java (TM) 2 Technology
Edition, Version 1.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.
- 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 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.
- 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 that you specify.
- 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 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.