[cg] Provide more efficient Ecore API

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 563865 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Jun 02, 2020 15:40 EDT | | Modified | Feb 22, 2021 13:27 EDT | | See also | 549476, 570995 | | Reporter | Ed Willink |

Description

All generated Ecore methods comply with the Ecore API requiring the Executor to be rediscovered by each call.

The code could be much improved by augmenting e.g.

boolean OCLExpression.isNonNull();

with

    boolean OCLExpression.isNonNull(@NonNull Executor executor);

so that OCL usage is much better anf Ecore usage only incurs one discovery.

[eclipse-ocl-bot]

By Ed Willink on Feb 10, 2021 13:25

But when can the new API be used?

• within the same CG session, no problem

• to external models?

could test for some run-time support version assuming that what is available at genmodel-time will be available at run-time

could use a ThreadLocal so that a speculative call can provide something that a compatible callee can exploit

probably safest to incur the slow API between CG sessions.

Maybe we should have an OCL CG Runtime Compatibility Level per usedGenPackage.

[eclipse-ocl-bot]

By Ed Willink on Feb 10, 2021 13:34

(In reply to Ed Willink from comment #1)

Maybe we should have an OCL CG Runtime Compatibility Level per usedGenPackage.

For the hopefully relatively few inter-session calls we can catch the NoSuchMethodException and fall back.

---

Adding the doubled API means that the in-memory representation will have to be tweaked to inject the extra operations for GenModel, which does at least mean that they will be in the interface avoiding Impl castdowns, but presumably also cluttering up eInvoke,.

[eclipse-ocl-bot]

By Ed Willink on Feb 22, 2021 13:27

(In reply to Ed Willink from comment #1)

could use a ThreadLocal so that a speculative call can provide something that a compatible callee can exploit

This is done for 6.14.0M3. => FIXED

(In reply to Ed Willink from comment #2)

Adding the doubled API means that the in-memory representation will have to be tweaked to inject the extra operations for GenModel, which does at least mean that they will be in the interface avoiding Impl castdowns, but presumably also cluttering up eInvoke,.

This still has attractions and difficulties. The benefits are reduced since the ThreadLocal is surely much faster that an eResource() recursion. => WONTFIX