[MDSAL-550] Consider further specializing AugmentableCodecDataObject Created: 04/May/20 Updated: 01/Feb/22 |
|
| Status: | Open |
| Project: | mdsal |
| Component/s: | Binding runtime |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Medium |
| Reporter: | Robert Varga | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Keyed lists end up being implemented with a combination of AugmentableCodecDataObject and interface-specific implementation of Identifiable.key(), which routes back to CodecDataObject.codecKey(). As a keyed list is always augmentable, it would probably end up being advantageous to have another base class specialization, which would provide the implementation of key, i.e.: public abstract IdenfiableAugmentableCodecDataObject<I extends Identifier<T>, T extends DataObject & Augmentable<T> & Identifiable<I>> extends AugmentableCodecDataObject<T> implements Identifiable<I> { private static final VarHandle CACHED_KEY; static { try { CACHED_KEY = MethodHandles.lookup().findVarHandle(IdenfiableAugmentableCodecDataObject.class, "cachedKey", Identifier.class); } catch (ReflectiveOperationException e) { throw new ExceptionInInitializerError(e); } } // Used via VarHandle @SuppressWarnings("unused") private volatile I cachedKey; @Override public final I key() { return (I) codecKey(CACHED_KEY); } } Hence we end up generating a bit less code, as well as make the class layout a bit more normalized. The number of implementations of Identifiable.key() should also go down (as low as two with MDSAL-549), potentially helping JIT. |