Java

JavaTM Development Kit
Tools Changes

 JDK Tools
This document describes some of the changes made to the tools in the Java Development Kit since version 1.1, and summarizes the related issues arising from the new JDK 1.2 directory structure and class loading mechanism. This document applies to both Window and Solaris, although the directory separators are shown for Solaris. The contents are:

Tools Changes

  1. In version 1.2 of the Java Development Kit, 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.

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

  3. See the Java Development Kit 1.2 security documentation for descriptions of the new security-related tools.

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

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

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

  7. 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 version 1.2 of the Java Development Kit. Code signed using version 1.2 will be recognized as unsigned on 1.1.x versions.

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

  9. Beginning with version 1.2, the javadoc tool uses some new file name conventions:

    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

  1. Beginning with version 1.2, the JDK 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 JDK software; the directory structure of the reference Solaris JDK software is similarly changed.

    Class files formerly contained in the classes.zip archive of the JDK 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 JDK software.

    In the Win32 version of the JDK 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 JDK 1.2 software.

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

  2. In version 1.2 of the Java Development Kit, 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.

Copyright © 1995-98 Sun Microsystems, Inc. All Rights Reserved.

Feedback 		Sun

Java Software