0N/A<!
DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
2362N/A Copyright (c) 2001, Oracle and/or its affiliates. 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 2362N/A published by the Free Software Foundation. Oracle designates this 0N/A particular file as subject to the "Classpath" exception as provided 2362N/A by Oracle 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 0N/A accompanied this code). 0N/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. 2362N/A Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 0N/A<
BODY BGCOLOR="white">
0N/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
0N/Awhich generates bytecodes, and is therefore portable. If licensees
0N/Adesire to port it, the following JVM changes are required:
0N/A<
LI> The following four new JVM entry points must be added:
0N/A <
LI> JVM_GetClassDeclaredConstructors
0N/A <
LI> JVM_GetClassDeclaredFields
0N/A <
LI> JVM_GetClassDeclaredMethods
0N/A <
LI> JVM_GetClassAccessFlags
0N/AThe first three return the declared constructors, fields, and methods
0N/Afor a given class, with an option to return only the public ones. They
0N/Aare similar in functionality to the earlier GetClassConstructors,
0N/AGetClassFields, and GetClassMethods. JVM_GetClassDeclaredFields and
0N/AJVM_GetClassDeclaredMethods must intern the Strings for the names of
0N/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
0N/ASerializationConstructorAccessorImpl; see 4486457 for a case where
0N/A<
LI> The stack walker for security checks must be modified to skip not
0N/A<
LI> The JVM entry points JVM_InvokeMethod and
0N/AJVM_NewInstanceFromConstructor are currently still used because the
0N/Afirst invocation of the bytecode-based reflection is currently slower
0N/Athan the original native code. The security checks they perform can,
0N/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
0N/Aframework) must skip reflection-related frames in its stack walk:
0N/Aspecifically all frames associated with subclasses of
0N/A<
LI> The new reflection implementation can cause class loading to
0N/Aoccur in previously-unexpected places (namely during reflective
0N/Acalls). This can cause class loaders which contain subtle bugs to
0N/Abreak. In general it is not possible to guarantee complete backward
0N/Abug compatibility, but one kind of bug has been observed more than
0N/Aonce: the inability of a user-defined loader to handle delegation to
0N/Ait for a class it has already loaded. The new reflection
0N/Aimplementation is predicated on delegation working properly, as it
0N/Aloads stub classes into newly-fabricated class loaders of type
0N/Aunloading of the stub classes to occur more quickly. To handle this
0N/Akind of bug, the JVM's internal class lookup mechanism must be
0N/Aslightly modified to check for instances of
0N/Asilently traverse the "parent" field once for such loaders before
0N/Aentering the bulk of the resolution code. This avoids an upcall to
0N/AJava programming language code which certain loaders can not handle.
0N/AThe following JVM entry points may be deleted:
0N/A<
LI> JVM_GetClassFields
0N/A<
LI> JVM_GetClassMethods
0N/A<
LI> JVM_GetClassConstructors
0N/A<
LI> JVM_GetClassField
0N/A<
LI> JVM_GetClassMethod
0N/A<
LI> JVM_GetClassConstructor
0N/A<
LI> JVM_GetPrimitiveField
0N/A<
LI> JVM_SetPrimitiveField
0N/ATo keep using the previous reflection implementation, licensees should
0N/Anot take changes from Sun's JDK 1.4 relating specifically to the
0N/Aany associated native code: