This subsection describes the notes common to OSs.

• Differences in the display of values of the java.math.BigDecimal class
  With JDK 5.0 and JDK 6, the value output format varies because exponent notations are now used for string conversion by the toString() method:
  

  (Example) To output the value of 1E-15 with the toString() method

  • In version JDK 1.4.2 or earlier: 0.000000000000001
  • In JDK 5.0 and JDK 6: 1E-15
  Note that to output the value in the JDK 1.4.2 or earlier format, use the toPlainString() method.
  
• Unicode version
  With JDK 6, the character processing is based on the default Unicode version 4.0. Therefore, take precautions when you reference and parse the character code individually.
  For details, see Supporting Supplementary Characters in Your Application on the relevant page (http://www.oracle.com/technetwork/articles/javase/supplementary-142654.html).
  
• Handling annotations in the java source program
  With JDK 6, you check the character code for the characters in the source program annotations. For example, if a source program, containing the Shift-JIS code in an annotation, is compiled in an environment where the default encoding is EUC, a warning is displayed. During compilation, specify the appropriate encoding in the -encoding option.
  
• Compiling the Java programs
  With the extension of the Java language specifications in J2SE 5.0, a caution or warning message is displayed and an error occurs if the syntax of the Java programs, which could be compiled by default with the javac command previously, violates the J2SE 5.0 Java language specifications. In the case of a caution or warning message, the programs that were being operated in the previous versions can be operated as they are. However, revising the Java code is preferable. Note that if you specify the -source option in the javac command, you can compile the programs by specifying the source code version 1.4 that is received by the javac command. With this, you can control the caution or warning message.
  
• Caution or warning messages output during the compilation of the Java programs
  With the extension of the Java language specifications in J2SE 5.0, source coding methods based on the new language specifications are recommended; therefore, the following caution messages might be output when the compilation ends:
  
  • Note: The AccountEJB.java operation is not checked or is not safe.
  • Note: For details, specify the -Xlint:unchecked option and re-compile the program.
  Also, when the -Xlint option is specified, the following warning message is output at the relevant location:
  
  • Warning: Unchecked invocation to add(E) as the member of [unchecked] raw type java.util.List.
  These warning and caution messages indicate that a check could not be performed during compilation. In the case of an actual error, a runtime exception occurs in JDK 1.4 as well. Therefore, if the program has operation results before migration, no action need be taken.
  
• Main compatibility items related to the language specifications in the change from JDK 1.4 to JDK 5.0
  With the extension of the Java language specifications in J2SE 5.0, the type-guaranteed enumeration type has been added to the Java language. Therefore, enum becomes a keyword and cannot be used as an identifier.
  
• Effect of the addition of the java.net.Proxy class
  With JDK 5.0, the java.net.Proxy class has been added in addition to the existing java.lang.reflect.Proxy class. Therefore, if you code Proxy in a class where an import declaration is specified, as shown in example of coding 1, a compilation error occurs because the package to which the Proxy class belongs is unclear.
  

  Example of coding 1

  import java.lang.reflect.*;

  import java.net.*;

  In this case, if you change the import declaration as shown in the example of coding 2, the compilation error can be avoided because the Proxy class of the java.lang.reflect package is clearly specified.
  

  Example of coding 2

  import java.lang.reflect.*;

  import java.net.*;

  import java.lang.reflect.Proxy;

• Change in the class initialization timing
  With JDK 5.0 or earlier versions, a class was initialized when a class literal (such as Foo.class) was referenced. However, the class is not initialized with JDK 5.0 or later. To initialize the class when a class literal is referenced, you must add the initialization code. An example of coding is as follows:
  

  Example of coding before the initialization code is added

  Class cl = Foo.class;

  Example of coding after the initialization code is added

  Class cl = forceInit(Foo.class);

  public static <T> Class<T> forceInit(Class<T> klass) {

  try {

  Class.forName(klass.getName(), true, klass.getClassLoader());

  } catch (ClassNotFoundException e) {

  throw new AssertionError(e); // Can't happen

  }

  return klass;

  }

• Changes in the java.lang.ClassLoader class
  According to the API specifications, you must specify a binary name delimited with a period (.) in the class name of the ClassLoader method with the String class name as the argument.
  With JDK 5.0 or earlier, operations are performed without a problem even with a name delimited with forward slashes (/) (for example, java/lang/String). However, with JDK 5.0 or later, java.lang.ClassNotFoundException occurs if you specify a class name that is not a binary name. Specify the binary name of the class according to the API specifications in the method of the ClassLoader class.
  
• Changes in java.util.logging.Level
  With JDK 5.0 or earlier, an exception does not occur even if you specify a null name argument in the constructor java.util.logging.Level(String name, int value, String resourceBundleName). However, with JDK 5.0 or later, NullPointerException occurs. Make sure you do not specify a null argument.
  
• Changes in java.sql.Timestamp.compareTo
  With JDK 5.0, java.sql.Timestamp.compareTo(java.util.Date) is added to the API. The accuracy of this API is different compared to java.util.Date.compareTo(java.util.Date) in JDK1.4.2, and is accurate up to nanoseconds. JDK 1.4.2 does not have this API, so java.util.Date.compareTo(java.util.Date) was invoked from an inheritance relationship, but with JDK 5.0 or later, java.sql.Timestamp.compareTo(java.util.Date) is invoked.
  When all the following conditions are satisfied, the comparison results might differ with JDK 1.4.2 and JDK 5.0 or later:
  
  • java.sql.Timestamp.compareTo(java.util.Date o) is invoked
  • There is a difference of nanoseconds in the time in the java.sql.Timestamp object and the time in the argument java.util.Date object
  To compare java.sql.Timestamp and java.util.Date with the same accuracy as JDK 1.4.2, you must use the compareTo(java.util.Date) method of java.util.Date, and pass java.sql.Timestamp to the argument.
  
• Serialized version UID
  If a method of the included class^# in a nested class (for example, class-name-including-nested-class.this. method-name-(argument);) is invoked, and if that included class is serializable, with JDK 5.0 or later, the value of the default serialized version UID of the included class varies from JDK 5.0 or earlier. This is because of the changes in the javac command implemented in JDK 5.0. If all of these conditions are satisfied, add the serialized version UID in the serializable class.
  

  # An included class is a class that includes a nested class.

  (Example of coding)

  import java.io.*;

  class A implements Serializable { // serializable included class

  void method1() {}

  class B { // nested class

  void method2() { A.this.method1(); }

  }

  }

• Effect on the method cancellation functionality (In Windows, AIX, and Linux)
  In Windows, AIX, and Linux, compared to Application Server 06-70, the method cancellation functionality fails easily with Application Server 07-00 or later.
  This is because of the addition of the protected area in Component Container 06-70-/G, and the upgrade from JDK 1.4.2 to JDK 5.0 in Application Server 07-00.
  
  • Addition of protected areas in Component Container 06-70-/G
    With Component Container 06-70-/G, multiple Java class library classes are added in a protected area. If method cancellation is executed with the Java class library classes added in the protected area, an inconsistency occurs in the internal status.
    Component Container 07-00 or later inherits the protected areas of Component Container 06-70-/G or later, so there are several protected areas compared to Component Container 06-70-/G or earlier. For details on the contents defined as the protected area, see Appendix C Contents of the Protected Area List in the uCosminexus Application Server Operation, Monitoring, and Linkage Guide.
    
  • Upgrading to JDK 5.0 in Application Server 07-00
    Method cancellation cannot be executed due to the restrictions in the Java specifications and JDK implementation. Such an area is assumed to be a special protected area without classes. The following table describes the differences in the specifications in Component Container 06-70 and 07-00 or later for handling the areas for which method cancellation cannot be executed due to the restrictions in the Java specifications and JDK implementation.
    

    Table 15-1 Handling the areas for which method cancellation cannot be executed

    Java program execution	Handling in Component Container 06-70	Handling in Component Container 07-00 or later
    Synchronized and lock allocation pending	Method cancellation can be executed	Method cancellation cannot be executed
    End of for and while loop	Method cancellation can be executed	Method cancellation cannot be executed
    Generating objects (new keyword)	Method cancellation can be executed
    A Java program other than above is being executed	Method cancellation cannot be executed (however, method cancellation can be executed during the execution by an interpreter)

    Note that if method cancellation cannot be executed due to the restrictions in the Java specifications and JDK implementation, the details for the KDJE52718-W message display the class name (JP.co.Hitachi.soft.jvm.CriticalClass.dummy(Native Method)).
    

This subsection describes notes for HP-UX.

• Initial value of the stack size (-Xss option)
  With JDK 1.4.2, the initial value of the Java thread stack size is 1 megabyte, but with JDK 6 or later, the initial value of the Java thread stack size is 4 megabytes.
  

This subsection describes notes for Linux.

• waitFor() and exitValue() methods of the java.lang.Process class
  The exit codes of the child processes that can be obtained with the waitFor() and exitValue() methods was changed to 0 or more and 255 or less. If a child process terminates with a negative exit code, that value is considered as an unsigned integer.