Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Reason behind ClassConstants (org.eclipse.persistence.internal.helper)?

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


Back to the top