Hi all, I asked the question on jdk6-dev list, and Joe Darcy said here's a better place to ask, so here I go.
According the the JVM spec, 2nd edition, 5.3.3 Creating Array Classes, both the bootstrap class loader and user-defined class loaders can load array classes, and the corresponding class loaders involved are recorded as initiating class loaders. But starting from JDK 6, Sun's JDK by default doesn't allow array syntax in ClassLoader.loadClass()/ClassLoader.findSystemClass(); array classes couldn't be created by calling defineClass() anyway, so this effectively bans user-defined class loaders to be initiating class loaders for array classes. Calling Class.forName(className, initialize, classLoader) won't record classLoader as an initiating class loader for an array class either. Is this an intended behavior? I'm expecting a call to Class.forName() would mark the loader as an initiating one, for all classes (including array classes). That way I won't have to keep a cache of my own in my custom class loader to keep track of what's been loaded already. I read Bug 6500212 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500212) and know that I shouldn't call ClassLoader.loadClass() with array syntax, so I switched to Class.forName(). But then when my class loader is asked to load the same array class again, it calls findLoadedClass() and gets a null back. That's pretty bad because I don't won't to get down to SystemDictionary::resolve_array_class_or_null() every time I load an array class. That'll force me to use my own cache to record just about the same info as what the VM already has, plus the array classes loaded, which looks like a bad smell to me. And, is it possible for future JDK releases to include more "default operations" in the reflection API? I mean, something like .NET's Binder (http://msdn.microsoft.com/en-us/library/system.reflection.binder.aspx ), or just increasing overloads of Class.getMethod()/getMethods() would be great. The project I'm working on requires lots of reflective calls, some of which only the receiver type, the target methods name, the number of arguments, and the exact type of each argument (not parameter) is known; overload resolution would have to be done at runtime, where I need to find a best matching overload to invoke. In .NET, a default Binder provided by the Base Class Library (fetched via System.Type.DefaultBinder property), and it'll do the overload resolution for users. I guess it might be more efficient to implement this kind of feature in the core library, and I wonder what you guys think. My scenario here is pretty much something like what Fredrik Ohrstrom's proposed version of MethodHandle's generic invocation support implements, and if that kind of binding feature exists in the VM already, exposing it in public API for general consumption should be easy, I suppose. Greetings, Raven
