Re: [eclipselink-dev] Reason behind ClassConstants (org.eclipse.persiste

[Blaise Doughan <blaise.doughan@xxxxxxxxxx>]

There easily could be a class constants for JRE classes.

We could have more fine grained ClassConstants classes (i.e. one per  
bundle, or refactored bundle).  The problem is ClassConstants is  
currently making this refactoring difficult.

-Blaise


On 2010-05-31, at 12:01 PM, Gordon Yorke <gordon.yorke@xxxxxxxxxx>  
wrote:

> This was added as a performance improvement.  ArrayList.class was  
> translated to Class.forName("ArrayList") by the compiler.  We could  
> add static attributes to the EclipseLink types but there are quite a  
> few references to non-EclipseLink types.
> What if we created multiple class constants files?
> --Gordon
>
> Blaise Doughan wrote:
> > Hello All,
> >
> > I am currently investigating the possibility of moving the OXM  
> > classes into there own bundle separate from core.  Before this can  
> > happen there are some class dependencies that need to be reworked.
> >
> > The first problem area discovered is  
> > org.eclipse.persistence.internal.helper.ClassConstants which has a  
> > transitive dependency on 797 classes
> >
> > Presumably ClassConstants was introduced as a performance  
> > improvement, is ClassConstants.IndirectMap_Class faster than  
> > IndirectMap.class?
> >
> > If so how about changing:
> > From:  ClassConstants.IndirectMap_Class
> > To:  IndirectMap.CLASS (assuming this is faster than  
> > IndirectMap.class)
> >
> > -Blaise
> > _______________________________________________
> > eclipselink-dev mailing list
> > eclipselink-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev