On 5/12/2011 11:03 AM, Rémi Forax wrote:
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:
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.
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.
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.
This is currently being looked at with a general aim of reducing the
size of Class instances. So adding back some size would need strong
justification.
David
-----
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.
Rémi
