Enable workspace blackboxes to import classes from required plug-ins

[eclipse-qvt-oml-bot]

| --- | --- | | Bugzilla Link | 564434 | | Status | NEW | | Importance | P3 normal | | Reported | Jun 18, 2020 10:49 EDT | | Modified | Jun 19, 2020 08:05 EDT |

[eclipse-qvt-oml-bot]

By Christopher Gerking on Jun 18, 2020 11:13

Even if a Java blackbox can be resolved inside the workspace (cf. bug 472482), the blackbox will not be executable if it imports another class from a required plug-in. The reason is obvious: a ProjectClassLoader only scans required plug-ins that correspond to other workspace projects. By contrast, classes must also be scanned if they reside in a required bundle.

A fix is trivial, just use the required bundles' class loaders as additional parents. However, this will increase the search space for blackboxes, thereby extending the compilation time.

[eclipse-qvt-oml-bot]

By Ed Willink on Jun 18, 2020 12:34

Shouldn't do.

The existing hits are unchnaged (earlier)

The later hits are fixes not slower.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Jun 18, 2020 13:11

(In reply to Ed Willink from comment #2)

The existing hits are unchnaged (earlier)

Not if the new hits are due to a parent ClassLoader, which will always take top priority. So if a plugin project requires a number of plugins, the class loaders of the corresponding bundles would always be consulted first, even for the existing hits.

But maybe it is a good idea to take a look at how Equinox handles such cases.

[eclipse-qvt-oml-bot]

By Ed Willink on Jun 18, 2020 15:05

But I do exactly what you need in org.eclipse.ocl.examples.codegen.dynamic.ExplicitClassLoader which takes first bite at the cherry to ensure that the wanted class and all its nested classes are oaded first then misses fall back to a standard loader.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Jun 19, 2020 03:32

(In reply to Ed Willink from comment #4)

But I do exactly what you need in org.eclipse.ocl.examples.codegen.dynamic.ExplicitClassLoader which takes first bite at the cherry to ensure that the wanted class and all its nested classes are oaded first then misses fall back to a standard loader.

Right, seems as if this one could replace QVTo's ProjectClassLoader. I just wonder if it violates the "parent first" contract of ClassLoader, and which repercussions this might have. Surely it enables clients to override classes like java.lang.Object.

[eclipse-qvt-oml-bot]

By Ed Willink on Jun 19, 2020 08:05

Potentially, but if a user is so determined to have a variant Object class loaded they will find a way anyway. But I think ExplicitClassLoader is limited to the class and its nested classes.