[stringtemplate-interest] it's 60% of time in ObjectModelAdaptor.getProperty()
j.stuyts at javathinker.com
Sun Feb 6 09:32:21 PST 2011
> Yes, classes are garbage collected, but as they have a reference to
> their class loader, they won't be garbage until the class loader is
> garbage. Which can only be when you have created it. Or am I missing
> anything here?
I think you mean the other way around: the class loaders have a reference
to their classes.
I am not familiar with the internals of class loaders, but if class
loaders use normal references to their classes then this would of course
prevent the classes from being collected. In that case you would need to
use more class loaders to make sure old classes are unloaded. Although I
feel that one class loader per class is a bit extreme. There must be other
'units' in StringTemplate to tie a class loader to.
I am fairly confident that class loaders don't hold on to their classes
indefintely, but I am not 100% sure. A simple test can show how (custom)
class loaders behave.
> When dynamically loading classes from byte arrays I do not know of any
> other way than creating your own class loader anyway.
> I sure know that
> the - know to be picky - Google App Engine allows you to do so - as I
> tried it :)
Cool. And like I said: custom class loaders are common practice so most
people won't have any problem with using them. But there might be
enthousiastic StringTemplate users who have to deploy to more restricted
environments. I guess these users would be disappointed if they cannot
migrate to version 4 of StringTemplate because of the additional security
restrictions. It's just something to keep in mind when the introduction of
a custom class loader comes up.
More information about the stringtemplate-interest