0N/A<!
DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
0N/A Copyright 2001 Sun Microsystems, Inc. All Rights Reserved. 0N/A DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 0N/A This code is free software; you can redistribute it and/or modify it 0N/A under the terms of the GNU General Public License version 2 only, as 0N/A published by the Free Software Foundation. Sun designates this 0N/A particular file as subject to the "Classpath" exception as provided 0N/A by Sun in the LICENSE file that accompanied this code. 0N/A This code is distributed in the hope that it will be useful, but WITHOUT 0N/A ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 0N/A FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 0N/A version 2 for more details (a copy is included in the LICENSE file that 1472N/A You should have received a copy of the GNU General Public License version 0N/A 2 along with this work; if not, write to the Free Software Foundation, 0N/A Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 0N/A Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, 0N/A CA 95054 USA or visit www.sun.com if you need additional information or 0N/A<
BODY BGCOLOR="white">
1123N/A<
B> Licensee impact of JDK 1.4 reflection changes </
B>
0N/Aoffers substantially higher performance than previous JDKs' native
0N/Acode. Licensees can at their discretion port these changes. There are
0N/Ano public API or documentation changes associated with the new
0N/Areflection implementation aside from a few minor clarifications in the
0N/AThe bulk of the new implementation is Java programming language code
2790N/Awhich generates bytecodes, and is therefore portable. If licensees
2790N/Adesire to port it, the following JVM changes are required:
767N/A<
LI> The following four new JVM entry points must be added:
767N/A <
LI> JVM_GetClassDeclaredConstructors
0N/A <
LI> JVM_GetClassDeclaredFields
1601N/A <
LI> JVM_GetClassDeclaredMethods
0N/A <
LI> JVM_GetClassAccessFlags
1879N/AThe first three return the declared constructors, fields, and methods
1879N/Afor a given class, with an option to return only the public ones. They
1879N/Aare similar in functionality to the earlier GetClassConstructors,
1879N/AGetClassFields, and GetClassMethods. JVM_GetClassDeclaredFields and
0N/AJVM_GetClassDeclaredMethods must intern the Strings for the names of
757N/Athe Field and Method objects returned. The fouth returns the access
0N/Aflags for a given class as marked in the class file, as opposed to in
0N/Athe InnerClasses attribute if the class is an inner class, and
0N/Atherefore differs from JVM_GetClassModifiers for inner classes (most
0N/Aimportantly, protected inner classes; see 4471811.)
0N/A<
LI> The JVM's link resolver must be modified to allow all field and
0N/Aany other class (even to private members of other classes) to
0N/Asucceed. This allows setAccessible() and its associated checks to be
0N/A<
LI> The code which calls the verifier must skip verification for all
0N/Aintended that only a subset of the stub classes used for serialization
0N/Awould not pass the verifier, specifically, those subclassing
767N/ASerializationConstructorAccessorImpl; see 4486457 for a case where
1123N/A<
LI> The stack walker for security checks must be modified to skip not
2790N/A<
LI> The JVM entry points JVM_InvokeMethod and
2790N/AJVM_NewInstanceFromConstructor are currently still used because the
2790N/Afirst invocation of the bytecode-based reflection is currently slower
2790N/Athan the original native code. The security checks they perform can,
2790N/Ahowever, be disabled, as they are now performed by Java programming
0N/AThe following changes were discovered to be necessary for backward
0N/Acompatibility with certain applications (see bug 4474172):
0N/A<
LI> The existing JVM entry point JVM_LatestUserDefinedLoader
0N/A(typically used in applications which rely on the 1.1 security
1879N/Aframework) must skip reflection-related frames in its stack walk:
specifically all frames associated with subclasses of
<
LI> The new reflection implementation can cause class loading to
occur in previously-unexpected places (namely during reflective
calls). This can cause class loaders which contain subtle bugs to
break. In general it is not possible to guarantee complete backward
bug compatibility, but one kind of bug has been observed more than
once: the inability of a user-defined loader to handle delegation to
it for a class it has already loaded. The new reflection
implementation is predicated on delegation working properly, as it
loads stub classes into newly-fabricated class loaders of type
unloading of the stub classes to occur more quickly. To handle this
kind of bug, the JVM's internal class lookup mechanism must be
slightly modified to check for instances of
silently traverse the "parent" field once for such loaders before
entering the bulk of the resolution code. This avoids an upcall to
Java programming language code which certain loaders can not handle.
The following JVM entry points may be deleted:
<
LI> JVM_GetClassConstructors
<
LI> JVM_GetClassConstructor
<
LI> JVM_GetPrimitiveField
<
LI> JVM_SetPrimitiveField
To keep using the previous reflection implementation, licensees should
not take changes from Sun's JDK 1.4 relating specifically to the
any associated native code: