[stringtemplate-interest] it's 60% of time in ObjectModelAdaptor.getProperty()

[Johan Stuyts]

> 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.

Me neither.

> 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.

Johan