Idiom for forcing class loading?
in [Java Programming]
|
Prev: setJPEGEncodeParam method not found in JPEGImageEncoder jdk 1.5 and jdk 1.6
Next: HYDROCODONE SIDE EFFECTS INFORMATION
From: Tom Anderson on 19 Nov 2009 16:03 On Wed, 18 Nov 2009, Alessio Stalla wrote: > On 18 Nov, 20:06, Tom Anderson <t...(a)urchin.earth.li> wrote: > >> What's really happening is more like this: >> >> class FooMangler implements Mangler { >> � � � � static { >> � � � � � � � � ManglerRegistry.register("foo", FooMangler.class); >> � � � � } >> >> } > > If you have control on the source code of the mangler, I would do like > this: > > class FooMangler implements Mangler { > public static void autoregister() {} > ... > } > > and to initialize it, FooMangler.autoregister(); We have indeed done it like that in similar situations. I can't remember why we didn't do it like that here - i think someone didn't like the idea of having a method which 'did nothing'. I'll mention this to my colleagues when we next pass by this bit of code. tom -- Safety Not Guaranteed
From: Tom Anderson on 19 Nov 2009 16:05 On Wed, 18 Nov 2009, Arne Vajh?j wrote: > Tom Anderson wrote: > >> Am i right in thinking that all of these will force loading of Foo? Does >> anyone have any other idioms? How about any opinions on which idiom is >> best, or at least most idiomatic? > > I don't think the problem is common enough to make a solution idiomatic. It seems not. > I would without thinking twice: > - read class names from config file > - use Class.forName to initialize them The set of classes that need loading is very much static and code-like; it isn't the kind of thing that *needs* configuration at runtime. Given that, is reading a file really the right thing to do? How about putting the names in a string array? tom -- Safety Not Guaranteed
From: Tom Anderson on 19 Nov 2009 16:09 On Wed, 18 Nov 2009, Kevin McMurtrie wrote: > Self-registering classes are not the best design. Under extremely rare > circumstances, references from live classes to the registration > container might not exist during a GC - then it's suddenly empty. In a > web server or other application with multiple ClassLoaders, it might not > be clear where things are going. For the work I've done, there were > enough problems to justify not using JDBC driver self-registration with > DriverManager. > > Consider a configuration parameter that is a list of classes that your > registration container should load when it initializes. Sadly, the registration container is third-party, and i can't change it. Annoyingly, the system it's in has a dependency injection framework with a nice layering mechanism that lets modules we build add to the configuration of components defined by others. If the container was a component in this framework, adding classes to its to-do list would be as simple as putting their names in a file. But it isn't! tom -- Safety Not Guaranteed
From: Tom Anderson on 19 Nov 2009 16:11 On Thu, 19 Nov 2009, Jim Janney wrote: > Tom Anderson <twic(a)urchin.earth.li> writes: > >> class FooMangler implements Mangler { >> static { >> ManglerRegistry.register("foo", FooMangler.class); >> } >> } > > To me what smells here is that ManglerRegistry is using static methods. > I'd prefer creating an instance of ManglerRegistry, registering the > appropriate manglers with it, and keeping a reference to it in the > ManglingParser. This requires more coding, obviously, but gives you > more flexibility in that different parsers can use different registries. You're absolutely right, of course, and if i was in charge, that's how it would be done. Sadly, the ManglerRegistry is supplied by someone else, their parsing code depends on it, and we need their parsing code. All very annoying. tom -- Safety Not Guaranteed
From: Little Green Man on 19 Nov 2009 16:31
On Nov 19, 4:11 pm, Tom Anderson <t...(a)urchin.earth.li> wrote: > You're absolutely right, of course, and if i was in charge, that's how it > would be done. Sadly, the ManglerRegistry is supplied by someone else, > their parsing code depends on it, and we need their parsing code. All very > annoying. Consider shopping around for an alternative that does the same job. Preferably open source. |