At 09:53 10/5/01 +1000, Conor MacNeill wrote: >In the first approach, B's initializer does not run. The second approach >does run the initializer. The exception trace in the second run is just to >see a stacktrace of where the initializer is being run from. The results >are pretty surprising. When you use reflection on a class loaded by a >classloader (no AntClassLoader in sight), the static initializer is not >run. If you look at the comment "// try to get static initializers to run", >I have been trying various things in that block to get the static >initializers to run. The only thing which has worked has been to call >newInstance(). It doesn't matter if there is no zero-argument constructor, >the static initializers still get run.
It is by jdks design that this is done - I have run into it heaps in past (Avalon/Phoenix was historically littered with hacks to force static resolution and initialization). One of the reasons I wanted resolution of all classes at loading time - it removes this problem. The only way I know how to do it is to use Class.forName( "com.biz.Foo", true, null ); or Class.forName( "com.biz.Foo", true, myClassLoader ); Which was -1ed in the vote IIRC ... ;) Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
