test

Java 2 SDK for Solaris Developer's Guide

Runtime Incompatibilities

  1. In JDK 1.0 and 1.1, the runtime systems finalize objects (invoke their finalize methods) somewhat aggressively. Sometimes all eligible but unfinalized objects would be finalized at the end of nearly every garbage-collection cycle. Code written for such systems can unintentionally depend upon this prompt garbage collection-invoked finalization for correct operation, which can lead to complicated bugs and deadlocks.

    In Java 2 SDK for Solaris, finalization is not performed directly by the garbage collector. Instead, objects are finalized only by a high-priority thread. So, in a busy program, the time between the moment an object becomes eligible and the moment when it is finalized might be longer than in previous versions of the runtime system.

    In Java 2 SDK for Solaris, the runtime system properly implements the definition of finalization in the JLS, so this difference is not, strictly speaking, an incompatibility. This change might, however, cause programs to malfunction if they rely upon prompt finalization. Many such programs can be repaired by using reference objects instead of finalize methods. (Reference objects are implemented by the java.lang.ref.Reference class and its subclasses.) A less preferable workaround is to periodically invoke the System.runFinalization method at regular intervals.

  2. Virtual machines in releases prior to Java 2 SDK for Solaris accept some class files that should be rejected (according to the JLS). Typically, these class files have one or more of the following problems:

    1. Extra bytes are at the end of the class file.

    2. The class file contains method or field names that do not begin with a letter.

    3. The class attempts to access private members of another class.

    4. The class file has other format errors, including illegal constant pool indexes and illegal UTF-8 strings.

    Java 2 SDK for Solaris VM more closely implements the specification, so it can be stricter on all of these points.

    Until the RC2 release of Java 2 SDK for Solaris, this strict checking was the default behavior. However, final product testing revealed that many existing Java applications failed to run because of some of these checks. In particular, obfuscated code frequently suffers from problems a and b, while some inner-class code generated by previous compilers suffers from problem c. Java 2 SDK for Solaris relaxed some of these checks to make it as easy as possible for developers and end users to upgrade to Java 2 SDK for Solaris.

    The Java 2 SDK for Solaris -Xfuture option enables the strictest possible class file format checks, access checks, and verification policies. Developers should start using this option as soon as possible for all new development work. This ensures that new Java applets and applications are prepared for migration to strict behavior when it again becomes the default.

    The Java Plug-in always uses the strict class file checks (as if the -Xfuture flag is set). The appletviewer ignores the -Xfuture flag and uses the more relaxed set of default checks.

  3. In Java 2 SDK for Solaris, an unimplemented abstract method or interface method causes an AbstractMethodError to be raised at runtime when the method is invoked. In previous versions, the error occurred during link time.

  4. Prior to Java 2 SDK for Solaris, putting code on CLASSPATH could make it more privileged. For example, prior to Java 2 SDK for Solaris, VMs would sometimes not require that some trusted class files pass verification. Verification depended on the installed security manager. For example, if the following method was in a class on CLASSPATH, and was called by an applet, then it could read the user.name property: 


    String getUser() {
	return System.getProperty("user.name");
}

    In Java 2 SDK for Solaris, this kind of code requires a call to do Privileged (as in the following example). 


    String getUser(){
		return(String)
		java.security.AccessController.doPrivileged
																	(new PrivilegedAction(){
			public Object run() {
				return System.getProperty("username");
			}
		})
}

    • The security model in Java 2 SDK for Solaris changes the way in which resources are accessed. When a security manager is in force, resources must reside at a URL that has been granted appropriate security permissions by a policy file. The default policy file,java.policy, grants all security permissions to resources located in the lib/ext directory, where extensions are stored. The default policy file is located at /lib/security/java.policy.

      In addition, an invocation to access system resources, as for example by ClassLoader.getResource, must be enclosed within an AccessController.doPrivileged call. Attempts to access system resources without use of a doPrivileged statement will fail. This is true even if the resources that are granted security permissions by the policy file.

  5. Prior to JDK 1.1.6, the default ISO 8859-1 character encoding had the name "8859_1". With JDK 1.1.6, this name changed to "ISO8859_1". The old name works when passed as an argument to methods in the API, but does not work when used in font.properties files.

  6. Each of the following classes in package java.util.zip has a constructor that accepts an int parameter to specify the buffer size:

    • DeflaterOutputStream

    • InflaterInputStream

    • GZIPInputStream

    • GZIPOutputStream

    In Java 2 SDK for Solaris, an IllegalArgumentException is thrown if the input parameter for buffer size is less than or equal to 0. In the JDK 1.1 platform, these constructors do not throw IllegalArgumentException if the size parameter is less than or equal to 0.

  7. When the Java 2 SDK for Solaris VM attempts to load a class file that is not of the proper class file format, a java.lang.ClassFormatError is thrown. A java.lang.UnsupportedClassVersionError is thrown when the virtual machine attempts to load a class file which is not of a supported major or minor version. Earlier versions of the virtual machine threw java.lang.NoClassDefFoundError when either of the above class file problems was encountered.

  8. In Java 2 SDK for Solaris, application classes are loaded by an actual ClassLoader instance. This makes it possible for application classes to use installed extensions and also separates the application class path, which is specified by the user, from the bootstrap class path, which is fixed and normally should not be modified by the user. The -Xbootclasspath option can be used to override the bootstrap class path if necessary.

    However, this means that in Java 2 SDK for Solaris, application classes no longer have all permissions by default. Instead, they are granted permissions based on the system's configured security policy. This might cause some applications that write their own security code based on the original security model in JDK 1.0 and 1.1 to throw an exception and not start in Java 2 SDK for Solaris. To work around this problem, run these applications with the oldjava application launcher, which is documented on the reference page for the Java application launcher. See Chapter 4, Command-Line Differences Between the Java 2 SDK and JDK 1.1 for more information on using the oldjava utility.

    See the Extension Mechanism Specification at http://java.sun.com/products/jdk/1.2/docs/guide/extensions/spec.html for more information regarding the new extension mechanism and its effect on class loading. The document provides relevant information regarding the new class loader delegation model and class loader API changes.

    See the JDK security documentation at http://java.sun.com/products/jdk/1.2/docs/guide/security/index.html for information regarding the security model of Java 2 SDK for Solaris.

  9. In Java 2 SDK for Solaris, the constructors of some classes in package java.io check for null input parameters. Such checks were not performed in earlier versions of the platform.

    • The constructors PrintStream(OutputStream out) and PrintStream(OutputStream out, boolean autoFlush) throws a NullPointerException if parameter out is null.

    • Similar checks have also been added in Java 2 SDK for Solaris to constructors InputStreamReader(InputStream in) and InputStreamReader(InputStream in, String enc). These constructors throw NullPointerException if parameter in is null.

    • In Java 2 SDK for Solaris, the constructors Reader(Object lock) and Writer(Object lock) now throw NullPointerException if parameter lock is null.

  10. In JDK 1.1 software, Thread.stop is able to interrupt a thread blocked in Object.wait or Thread.sleep. However, in Java 2 SDK for Solaris software running on the Solaris 8 operating environment with native threads, Thread.stop cannot interrupt a blocked thread. Java 2 SDK for Solaris behaves the same as the JDK 1.1 release with respect to Thread.stop when running on other operating systems or on a Solaris 2.6 operating platform.

  11. Java 2 SDK for Solaris contains a revised class-loading mechanism. Under the new class loader, if any class file belonging to a package in a jar file is signed, all class files belonging to the same package must have been signed by the same signers. It is no longer possible to use a jar file in which some classes of a package are signed and others are unsigned or signed by a different signer. jar files can still contain packages that are unsigned. However, if any packages contain signed classes, all class files of that package must be signed by the same signer. Existing jar files that don't meet this criterion are not usable with Java 2 SDK for Solaris or Runtime Environment.

  12. Foreground and background colors of native components can be set explicitly using the setForeground() and setBackground() methods. If the colors are not set explicitly, default colors are used as follows:

    • In the Java 2 platform, default colors of native components are taken to be the colors defined by the underlying operating system.

    • Prior to Java 2 SDK for Solaris, default colors were pre-defined by the Java platform itself.

Code compiled with JDK 1.1 that relies on the default colors can exhibit different and sometimes undesirable component appearance when run on Java 2 SDK for Solaris. For example, if the JDK 1.1 code explicitly sets the foreground color to white for a component label but uses the default background color, the label is not visible when run on Java 2 SDK for Solaris if the underlying operating system's default background color is white.