当前页面:
在线文档首页 >
JDK 5 Documentation v1.2.2, Java 2 SDK 英文文档
SDK Tools Changes - JDK 5 Documentation v1.2.2, Java 2 SDK 英文文档
This document describes some of the changes made to the tools in the
Java
TM Development Kit since version 1.1, and summarizes the related
issues arising from the new Java 2 SDK directory structure and
class loading mechanism. This document applies to both Win32 and
Solaris
TM operating systems, although
the directory separators are shown for Solaris. The contents are:
Tools Changes
- The -noasyncgc option of the Java application launcher is
no longer supported.
- In the Java 2 SDK, the -O option for javac
has a different meaning, and
may have different performance effects on generated code, than earlier
compilers. Additionally, -O no longer implicitly turns on -depend,
so you will need to add -depend to the command line where
desired.
- You should use only versions of javac released later than version
1.1.4 to compile against 1.2 class files.
1.1 versions of javac sometimes generate
incorrect inner class attributes. In version 1.2, javac generates correct
attributes. The version 1.1.4 javac compiler and earlier compilers could crash
when encountering the correct form. Beginning with version 1.1.5,
javac will handle both old as well as the new corrected attributes.
This is only a compile-time problem. Class files generated by the 1.2
compiler will work on older VMs.
- See the
Java 2 SDK security documentation
for descriptions of the new security-related tools.
- In 1.1, "javap -verify" performed a partial verification of the class
file. This option was misleading because it did not perform many
portions of a full verification. The option has been removed in 1.2.
- The Java interpreter now has a set of standard command-line
options and a set of non-standard options. The standard set is supported
in version 1.2 and also will be supported in upcoming
versions of the virtual machine. The non-standard options are not guaranteed
to be supported in future virtual machines produced by Sun. See
descriptions of the two sets of options for java for
Solaris
and Windows.
- This is an incompatibility between version 1.2 of the Java
Develoment Kit and versions prior to 1.1.4. In releases prior to 1.1.4,
the Java
interpreter would allow the class file at /a/b/c.class to be invoked
from within the /a/b directory by the command "java c", even if the
class c was in package a.b.*. In version 1.1.4, and in version 1.2,
the fully qualified class name must be specified. For example, to invoke the
class a.b.c at a/b/c.class, the command "java a.b.c" could
be issued from the parent directory of directory /a.
- Due to bugs in versions 1.1.x, code that is signed using the 1.1.x
"javakey" tool (now obsolete) will be recognized as unsigned in the Java 2
SDK.
Code signed using version 1.2 will be recognized as unsigned on 1.1.x
versions.
- Prior to 1.2, javac permitted some inconsistent or redundant
combinations of command line options. For example, -classpath could be
specified multiple times with only the last usage taking effect. In
1.2 such usage is no longer allowed.
- Beginning with version 1.2,
the javadoc tool uses some new file name conventions:
- Generated pages are arranged in a directory hierarchy instead
of a single directory. Package names are indicated by directory
names, not in the file names.
- A frames-based root page, index.html, is created. To bypass
frames, use overview-summary.html, which replaces the old
packages.html.
Any hard-coded links in doc comments will be broken by these changes.
Doc comments should not contain hard-coded links -- use the
{@link} tag instead. For more information, see
Javadoc.
Directory Structure Changes
- Beginning with version 1.2, the SDK software has the
following directory structure (not comprehensive):
C:\jdk1.2
___________|________________
| | |
bin lib jre
| | _______|__________
java.exe tools.jar | |
javac.exe lib bin
javap.exe / \ / \
javah.exe ext rt.jar classic java.exe
javadoc.exe / i18n.jar / java.dll
iiimp.jar jvm.dll awt.dll
The structure shown is for the Windows SDK software; the directory
structure of the reference Solaris SDK software is similarly changed.
Class files formerly contained in the classes.zip archive of
the SDK software are now split among three files:
- rt.jar - contains the system classes of the platform's
core API.
- i18n.jar - contains character-conversion classes and
other files associated with internationalization and localization.
- tools.jar - contains non-core class files for support of the
tools and utilities in the SDK software.
In the Win32 version of the SDK software, the DLL file for
the Java virtual machine, jvm.dll, is in the
jre\bin\classic directory. The classic directory
has also been added to the directory structure in the Java 2 SDK.
The value of the java.home system property is the jre
directory rather than the directory where the JDK software is installed,
as previously.
The tools.jar archive is not in the default system classpath
used by the SDK tools. This means, for example, that
you'll need to put tools.jar on the classpath to
compile Javadoc doclets:
javac -classpath <path to tools.jar> MyDoclet.java
As another example, a command like
java sun.tools.javac.Main MyClass.java
won't work if the classpath isn't set, as it would have in previous versions of the JDK software. You'll first need to explicitly
put tools.jar on the
classpath, either by setting the CLASSPATH environment variable or by
using the -classpath option:
java -classpath <path to tools.jar> sun.tools.javac.Main MyClass.java
The SDK compiler (javac on Solaris, javac.exe on Win32)
takes care of this automatically, so there's no need to put
tools.jar on the classpath if you invoke the compiler directly:
javac MyClass.java
This is the recommended way to use the compiler.
For further information on these and related topics, see
Command Line Changes From
1.1 to 1.2.
-
In the Java 2 SDK, the Java virtual machine
implementation and runtime support ("runtime") are installed in a
shared library named "jvm.dll" (on Win32) and "libjvm.so" (on Solaris).
In version 1.1, the runtimes for Win32 and Solaris resided in
"javai.dll" and "libjava.so", respectively. The version 1.1 shared libraries
contained both the runtime and the native methods for some of the class
libraries. In version 1.2, we have isolated the runtime into a separate binary
product; the native methods of the class libraries have been moved to
"java.dll" and "libjava.so". This change is of significance to users who
have either,
- written non-JNI native methods with the old native method
interface (Old NMI) that was supported by version 1.0 of the
Java Development Kit, or,
- have embedded the runtime via the JNI Invocation Interface.
If you fall in either of the above categories, you must relink your native
libraries before they can used with version 1.2. On Solaris, you will have to
replace -ljava in your link command line with -ljvm. On
Win32 with the Microsoft VC++ Linker, the change would be from
link -dll -out:mylib.dll -libpath:%JAVA_HOME%\lib javai.lib
to
link -dll -out:mylib.dll -libpath:%JAVA_HOME%\lib jvm.lib
Note that this change does not affect JNI programmers implementing native
methods.
We strongly encourage you to migrate your native methods to
JNI. JNI is the standard way for making your native libraries
interoperate with the Java programming language, and JNI offers virtual
machine independence for any native code that you might write. In the
future, we will not support the old NMI.