review request (L): 7030453: JSR 292 ClassValue.get method is too slow

Rémi Forax forax at
Mon Dec 5 01:03:13 UTC 2011

On 12/05/2011 01:27 AM, Joe Darcy wrote:
> On 12/4/2011 2:13 PM, Rémi Forax wrote:
>> On 12/04/2011 08:38 PM, Joe Darcy wrote:
>>> Hi John,
>>> Are there alternatives to adding two new fields to java.lang.Class?  
>>> I assume most Class'es won't have ClassValue information associated 
>>> with them.
>>> -Joe
>> If you use Groovy, JRuby or Nashorn in your code, all visible classes 
>> will use this two fields.
>> Any alternative will slow down the access to the class value.
> In the mean time, all the non-Groovy, non-JRuby, non-Nashorn, etc. 
> uses of class Class and all the classes not visible in those 
> environments when they are being used will be larger.
> Adding the fields may be the right time/space trade-off, but I think 
> the point merits some discussion given how many Class objects get 
> created and the relative proportion of Java executions where 
> ClassValue is currently used.
> The more reasonable time/space trade-off can change over time of course.
> -Joe

I agree but as I said, in that case, I think it's better to take a look 
to the big picture
and see if not only class values fields but also annotations related 
fields or reflection related fields
can be moved.

Also, if we don't provide a fast ClassValue, people will create their 
own concurrent weak hash map
using class as key that will be worst because it seems that only few 
people knows
how to do that right. Personally, I don't.


More information about the core-libs-dev mailing list