Projects, which use JSR292

[John Rose]

On Feb 15, 2011, at 7:51 AM, Jochen Theodorou wrote:

> Am 15.02.2011 15:50, schrieb Kirill Shirokov:
>> Hi All,
>> 
>> Oracle will make an one-day conference called "Java Tech Day" in St.
>> Petersburg, Russia. There will be a section called "ask the experts" for
>> a number of JDK7 features including JSR 292. I'm asked to be a live
>> emulator of JSR292 expert there.
>> 
>> I expect that people will ask about "real" projects where JSR292 is
>> used, so I'm trying to gather information about these projects on this list.
>> So far, I have heard of:
>> 
>> - JRuby by Charles Oliver Nutter
>> - PHP.reboot by Remi Forax
>> - Smalltalk implementation by Mark Roos (in progress)
>> 
>> Sorry, if I missed somebody.
>> 
>> And the main question to early adopters: is JSR292 really helping
>> you:
>> simplifies and clarifies your code, do you expect performance
>> improvements over the "old" code as soon as this will be addressed in
>> HotSpot?

Thanks, Jochen, for the useful summary.

> None of the JSR292 parts is in Groovy now, but we intend to make heavy 
> use of it if the JVM allows it. What we target with this is for example 
> that we no longer have to generate call sites at runtime. This is stress 
> on permgen and not every garbage collector behaves as it should in my 
> eyes. Another part that promises to be useful is ClassValue.

Yes, that helps any dynamic language that uses Object as a root type, as opposed to systems which define their own root type (MyLanguageObject).

> We would in fact need a InstanceValue,

This is hard, and probably amounts to a change-class operator.  I suppose you need this for arbitrary pre-existing objects from non-cooperating classes?

> but it will help already avoiding some big 
> internal structures, that tend to cause problems.

You mean the Class to metaclass mapping, right?  This is the main purpose (but not only purpose) for ClassValue.

> As for performance... 
> I think it can help here if the inlining really works.

Yes.  We can make inlining work "in the lab" right now, but the goal is to make it work from the beginning in a customer application.

> In the end it 
> very much depends on finding good guards here, which is part of the 
> process for Groovy 1.8, even though Groovy 1.8 will not yet make use of 
> JSR292. Since 1.8.0 will be release soon Groovy 1.9 will most probably 
> make use of JSR292.

Great!

-- John