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 20 Nov 2009 12:20 On Thu, 19 Nov 2009, Little Green Man wrote: > 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. Believe me, i am constantly on the lookout for just that. The trouble is that this Mangler business is not a standalone thing. It's just one tentacle of a vast and terrifying tentacle-monster. There's no way to replace tentacles bit by bit - we'd have to replace the whole monster. tom -- If it ain't broke, open it up and see what makes it so bloody special.
From: Tom Anderson on 20 Nov 2009 18:18 On Thu, 19 Nov 2009, Jim Janney wrote: > Tom Anderson <twic(a)urchin.earth.li> writes: > >> 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. > > Ah. In that case, I'd probably just get rid of the static blocks and > do the registration directly in your initializer: that is, change > > void initialise() { > Class.forName(Foo.class.getName()); > } > > to > > void initialise() { > ManglerRegistry.register("foo", FooMangler.class); > } > > Since you have to reference each class in the initializer anyway, it > doesn't look as if the static blocks are buying you anything. What i'm not keen on there is that the initialiser class has to know about FooMangler's relationship with the ManglerRegistry. It doesn't seem like any of its business to me. tom -- Work alone does not suffice: the efforts must be intelligent. -- Charles B. Rogers
From: Филимон Лаковид on 24 Nov 2009 07:04 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. Also, it allows registering the same mangler more than once under different names, which can sometimes be useful.
From: Arne Vajhøj on 25 Nov 2009 22:42 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. Any detail son that? > Consider a configuration parameter that is a list of classes that your > registration container should load when it initializes. That was my suggestion as well. Arne
From: Kevin McMurtrie on 26 Nov 2009 02:25
In article <4b0df904$0$274$14726298(a)news.sunsite.dk>, Arne Vajh�j <arne(a)vajhoej.dk> wrote: > 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. > > Any detail son that? I witnessed it years ago in an early Java web server. There was about a 1 in 30 chance that the JDBC driver would initialize yet DriverManager didn't have it. It turned out that because Reflection was used to run startup components, there was a period of time with no reference to JDBC classes or DriverManager. Intentionally holding some references until after startup completed was the cure. Sure, that's an example of a very rare and obscure bug. Unfortunately they're the worst kind. > > > Consider a configuration parameter that is a list of classes that your > > registration container should load when it initializes. > > That was my suggestion as well. > > Arne -- I won't see Goolge Groups replies because I must filter them as spam |