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) Version 5. Although this JDK is shipped with WebSphere Application Server Version
6.1 on the Sun Solaris operating system, 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.