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

[Oliver Zeigermann]

Right. Generally, I think the use case of a compiled template for
highest performance would be an edge case anyway.

2011/2/6 Eric B <ebatzdor at gmail.com>:
> I think, like Spring, the compiled-to-bytecode feature could be
> optional.  Those who can't go with dynamic classes for whatever
> reason, can go with an "interpreted mode" that is basically how the
> templates are resolved today.
>
> Eric
>
> On 2/6/11, Johan Stuyts <j.stuyts at javathinker.com> wrote:
>>> 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
>> _______________________________________________
>> stringtemplate-interest mailing list
>> stringtemplate-interest at antlr.org
>> http://www.antlr.org/mailman/listinfo/stringtemplate-interest
>>
>
> --
> Sent from my mobile device
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org/mailman/listinfo/stringtemplate-interest
>