jaxb-ri/docs/release-documentation/src/docbook/users-guide-deployment-runtime-errors.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--

    Copyright (c) 2012, 2021 Oracle and/or its affiliates. All rights reserved.

    This program and the accompanying materials are made available under the
    terms of the Eclipse Distribution License v. 1.0, which is available at
    http://www.eclipse.org/org/documents/edl-v10.php.

    SPDX-License-Identifier: BSD-3-Clause

-->

<!DOCTYPE book [
<!ENTITY % ents SYSTEM "docbook.ent">
%ents;
]>
<section version="5.0" xml:id="deployment-runtime-errors" xml:lang="en"
         xmlns="http://docbook.org/ns/docbook"
         xmlns:xlink="http://www.w3.org/1999/xlink"
         xmlns:ns5="http://www.w3.org/1999/xhtml"
         xmlns:ns3="http://www.w3.org/2000/svg"
         xmlns:ns="http://docbook.org/ns/docbook"
         xmlns:m="http://www.w3.org/1998/Math/MathML">
    <title>Runtime Errors</title>

    <section xml:id="Illegal_class_modifiers_for_package_info__0x1600">
        <title>Illegal class modifiers for package-info: 0x1600</title>

        <para>When you compile your sources files with JDK from Java6 and try
        to run it on Java5 JVMs, you may see a <literal>ClassFormatError</literal>
        at runtime like this:</para>

        <informalexample>
            <programlisting language=""><![CDATA[main" java.lang.ClassFormatError: Illegal class modifiers in class
com/alu/parentalcontrol/jaxb/package-info: 0x1600
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
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:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at java.lang.Package.getPackageInfo(Package.java:350)
at java.lang.Package.getAnnotation(Package.java:361)
at com.sun.xml.bind.v2.model.annotation.RuntimeInlineAnnotationReader.getPackageAnnotation(RuntimeInlineAnnotationReader.java:125)
at com.sun.xml.bind.v2.model.annotation.RuntimeInlineAnnotationReader.getPackageAnnotation(RuntimeInlineAnnotationReader.java:53)
at com.sun.xml.bind.v2.model.impl.TypeInfoImpl.parseElementName(TypeInfoImpl.java:122)
at com.sun.xml.bind.v2.model.impl.ClassInfoImpl.<init>(ClassInfoImpl.java:166)]]></programlisting>
        </informalexample>

        <para>This is due to a bug, and so far the only way to fix this is to
        compile your project with JavaSE 5.</para>

        <para>Here is what's happening. Java5 added a new class file modifier
        attribute called <literal>ACC_SYNTHETIC</literal>, whose bit value is
        0x1000. This attribute marks types and methods that are not present in
        the source file but generated by the compiler. When
        <filename>package-info.java</filename> is compiled into
        <filename>package-info.class</filename>, javac in Java5 apparently only put
        0x0600 (= <code>ACC_ABSTRACT|ACC_INTERFACE</code>.) Some time during
        Java6 development, someone filed <link
        xlink:href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6232928">a
        bug, saying it should also include <literal>ACC_SYNTHETIC</literal>
        bit</link>, since it was a synthesized class.</para>

        <para>Later <link
        xlink:href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6313196">it
        is discovered that the corresponding VM change needs to be made to
        allow this 0x1600 combination</link>, but apparently no one realized
        the real implication of this --- namely, 0x1600 will break all the
        past JVMs. Of course, this problem is <link
        xlink:href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6553734">eventually
        discovered</link>, but as of this writing there's still no fix for
        this.</para>

        <para>So as you see, this is why the only workaround is to use javac
        from Java5.</para>
    </section>
</section>