Migration from JDK 1.4.2 to JDK 6

XSLT Transformations

Problem

You experience problems with XSLT transformations.

Reason

There is a known change in behavior between JDK 5 and JDK 6 regarding the handling of keys in XML documents. With JDK 5, the xsl key() function would return all matching nodes with a particular key value or else return all the nodes with the same ID value in the same table, regardless of the source document.

This was seen as a bug by Apache developers and changed in the Xalan version that is in JDK 6. With this version, the key() function will only return those nodes that match the document from the current context node.

This change will break scenarios where keys are used to reference elements in other documents loaded via the document() function by a unique ID.

Solution

At the moment, there is no solution to this problem, as the new behavior is considered to be the expected behavior. The XSLT 2.0 specification introduces a new optional argument to the key() function that allows the user to specify the subtree that is searched for matching nodes. If this optional argument is missing, only the document of the current context node is used, which is the behavior of JDK 6.

Unfortunately, the Xalan version in JDK 6 implements XSLT 1.0 only, so the additional argument is not available and there is no way for the user to include other documents in the search.

The only workaround is to implement referencing to other documents by normal searching, which might impact performance.

Exceptions in the SAX Parser

Problem

You get exceptions as shown below:

                  org.xml.sax.SAXNotRecognizedException: Property 'http://xml.org/sax/features/namespaces' is not recognized.
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.getProperty(AbstractSAXParser.java:2060)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.setProperty(SAXParserImpl.java:467)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.setProperty(SAXParserImpl.java:263)
at .....

               

This exception means that some code tried to set a property of a SAXParser instance, but the given name ( http://xml.org/sax/features/namespaces in this case) is not a recognized property. The same code worked in SAP JVM 5.

Reason

Looking at the prefix http://xml.org/sax/features/ you can see that this is actually a feature, not a property. In JDK 5, a feature could be set using the SAXParser.setProperty() method, so this code worked:

                  SAXParser parser = SAXParserFactory.newInstance().newSAXParser();
parser.setProperty("http://xml.org/sax/features/namespaces",true);
               

With JDK 6, there is a much stricter distinction between features and properties, setting a feature using the setProperty method is no longer possible and will result in an org.xml.sax.SAXNotRecognizedException .

Solution

A slight modification of the code is necessary to set the feature. The above example could be changed to look like this:

                  SAXParserFactory parserFactory = SAXParserFactory.newInstance();
parserFactory.setFeature("http://xml.org/sax/features/namespaces",true);
SAXParser parser = parserFactory.newSAXParser();

               

Notice that the SAXParser interface has no setFeature() method, so the feature is set for the parser factory before creating the parser instance. This code change is compatible with JDK 5, so the modified code will run on both, JDK 5 and JDK 6.

Changed Element Order in Unsorted Collections

Problem

When iterating over elements of a Set, the order of elements has changed compared to the order that was returned in JDK 5.

Reason

As stated in the documentation, a Set is a Collection that provides no guarantee about the elements' order. In JDK 6, the implementation of the hash function has changed for some classes resulting in a different element iteration order.

Solution

If the element order is of importance, an ordered Collection like a List has to be used. Otherwise, if code worked in JDK 5 but it no longer works because it unintentionally relies on the previous implementation specific element order, then this is a bug that needs to be fixed in this code.

Class Loading Errors with Array Syntax

Problem

ClassLoader.loadClass() throws java.lang.ClassNotFoundException: [Ljava.lang.String;

Note in particular the [ character in the class name, referring to an array (of strings, in this case).

Reason

This problem can easily reproduced with a simple test program:

                  public class test {
      public static void main(String[] args) throws Exception {

          String[] s = new String[] { "123" };
          String clName = s.getClass().getName();
          test.class.getClassLoader().loadClass(clName);
      }
  }

               

The program runs without any problems on JDK 5, but throws this exception on JDK 6:

                  Exception in thread "main" java.lang.ClassNotFoundException: [Ljava.lang.String;
        at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at test.main(test.java:7)


               

This happens because the class name in clName is in array syntax (with a leading [ ). According to Sun documentation, it was not intentional that this syntax worked before and there were cases, where it failed even in older releases. For JDK 6 the array syntax was disallowed on purpose.

Solution

The recommended solution is to fix the custom class loading code so it depend not on the array syntax. If this is not possible, or as a short-time workaround, the following system property can be set to enable the old behavior without checks for array syntax:

                  sun.lang.ClassLoader.allowArraySyntax=true