Hi Martin,
thanks for testing! All your remarks make sense. I changed the code
accordingly and checked it in.
Regards Michael
Michael,
I tested your JDO1 patch with JDK 1.4 in a clean workspace, and
all security manager tests run fine.
I mostly looked at the code additions to RuntimeJavaModel.java,
which are well documented (no further questions on the code).
Also, the getJavaModel() and getDeclaringJavaModelFactory()
changes look good. I was surprised about the amount of changes,
but to me the classloading code has gained clarity.
Only true cosmetics:
- 'instacne' misspelled twice in RuntimeJavaModel
- "class instance" might be ambiguous, consider "Class instance"
since the comments refer to an instance of java.lang.Class
- The 'true' value passed to the two invocations of forNamePrivileged()
leaves one guessing, though the code comments explain the intent.
Consider:
final boolean initialize = true;
RuntimeJavaModelFactory.forNamePrivileged(..., initialize,...)
- In getJavaType(Class), somewhere after
if (javaType == null) { ...
I'd expected a comment (or assertion) about the special handling
of pre-defined types, i.e., that 'javaType' cannot be a PreDefined
type. Correct? The javadoc on that class already has it, so it's
not a real lack of information there, just redundancy.
Martin
Michael Bouschen wrote:
I have implemented the JavaModel changes as we discussed. Now the
Class.forName is called in a doPrivileged block to avoid the
SecurityException.
The other change is that I moved all the code that checks for the
right class loader to the RuntimeJavaModel. A JavaType lookup by name
first gets the class instance using the class loader bound to the
model instance. Then it gets the class loader from the class instance
and delegates to JavaModel bound to this class loader. This makes
sure that a JavaModel handles only classes that are loaded by th
class loader bound to the JavaModel. There is one exception: all
JavaModel instances know about all the PredefinedType instances
(JavaType instances for primitive types, Java wrapper class,
java.util classes etc.).
Attached find two patches created from the trunk(!) directory:
- JDO1-JavaModel.patch: ri11 changes. I tested this running the ri11
tests and tck11 in a jdk1.5 environment (I'm using the enhancer
changes you send over).
- JDO2-JavaModel.patch: the corresponding changes for JDO2. This
changes classes in core20, enhancer20, runtime20 and fostore20. I run
the fostore20 tests with jdk 1.4.
Please let me know what you think.
--
Michael Bouschen [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
