[releng] Codegen Templates Build failure for Java 21 post 2024-12

[ewillink]

The platform moves to Java 21 for 2025-03 causing a variety of failures. Some are trivially fixed -

• use Java 21 for Jenkins / launches
• use Java 21 aware Tycho (refresh all versions and use latest Maven)
• eliminate StringTemplate ambiguity in Impact Analyzer code
• eliminate duplicate inheritance of conflicting default reversed() Compator/AbstractList

and one hard one: The autogenerated ValidationProblemFactory/Package in a variety of UsageTests is empty.

Initial debugging reveals that the method for e.g. PackageClass.javajet is null when lazily resolved during generateJava. EAger loading of PackageClass seemingly enables the same ClassLoader to provide the required class.

It would appear that class loading now differs as to the resolution of

/org.eclipse.emf.codegen.ecore/bin/org/eclipse/emf/codegen/ecore/templates/model/PackageClass.class
/org.eclipse.ocl.examples.codegen/bin/org/eclipse/emf/codegen/ecore/templates/model/PackageClass.class

The latter is exported x-internal:=true to avoid infecting non-OCL template users.

Is this adequate? Is there an ordering hazard with the OCL template class being loaded first and now occluding the non-OCL template usage. (The failing tests were not declared to use the OCL templates.)

[ewillink]

The code comments are insightful

/**

• OCLGenModelGeneratorAdapterFactory is a hopefully temporary facility awaiting a fix for EMF Bug 543870.
  /
  @deprecated / @deprecated temporary workaround for Bug 543870 */
  public class OCLGenModelGeneratorAdapterFactory extends GenModelGeneratorAdapterFactory

//
// Overridden to allow static templates to be invoked standalone.
//
@deprecated /* @deprecated temporary workaround for Bug 543870 */
public class OCLGenClassGeneratorAdapter extends GenClassGeneratorAdapter

Unfortunately Bug 543870 was WONTFIX so the temporary workaround is still in place and it appears to be the setStaticTemplateClass override with its careful ClassLoader logic that is now failing.

[ewillink]

Evolving the changes step-wise, everything (code tweaks, maven plugin versions, Java 21) seems ok; only Tycho 4.0.10 (or 4.0.4) is a problem. Tycho 3.0.5 is ok. Tycho 4.0.0 has other problems.

Eagerly loading PackageClass.class etc changes the failure so that ValidationProblemPackage is no longer empty, rather it is generated by the OCL-style template which was not requested. References from the embedded OCL2Java in e.g FarmElementImpl use EMF-style symbolic references that now fail since for consistency they should have been OCL-style Literals.

Clearly there is a class loading problem. maven-surefire is operating standalone so the tweak to x-internal or even packageExport makes no difference. Surely a standalone class loader just finds **/*.class regardless of the MANIFEST.MF? So the real bug is why did it work before. Did the 'old' class loader provide a fortuitous class path ordering? Is the null class load return the consequence of an ambiguity?

[ewillink]

eclipse-tycho/tycho#4555 raised.

Tycho 3.0.5 provides a broadly bottom up dependency ordering for maven-surefire.

Tycho 4.0.4 puts project dependencies ahead of plugins and so puts org.eclipse.ocl.examples.codegen's variant of org.eclipse.emf.codegen.ecore.templates.model ahead of org.eclipse.emf.codegen.ecore's.

For now we can only move to Tycho 3.0.5 which at least supports Java 21.

[ewillink]

/Attempting to workaround the problem moving the duplicate classes from "bin" to e.g. "temples-bin" and it all gets a bit weird. TemplateClassLoader (the derived URLClassLoader that loads the overriding class) has an alphabetical canonical classpath sort so the classpath order should be irrelevant. Once sorted, it chooses the longest prefix classpath match to the user templates. Debugging 4.0.4/3.0.5 the paths used by TemplateClassLoader are identical, except 3.0.5 handles a CNFE for not-overridden classes whereas 4.0.4 return null directly. 3.0.5 finds the overridden classes and 4.0.4 doesn't. It is as if 4.0.4 has managed to change the behavior of the inherited Java 17 URLClassLoader.

The problem only occurs for Maven Surefire, since Tycho Surefire/JUnit Plugin can use the proper Eclipse path. Standalone uses class files directly. So is there something special about jars? The URLClasspath ends "jar!/template" which is wierd since the "template" does not match the jar content. Why does it ever work? How does the proper Eclipse path work once the overrides are not exported?

[ewillink]

It is as if 4.0.4 has managed to change the behavior of the inherited Java 17 URLClassLoader.

Try instrumenting the code to see whether the ClassLoader classes are as expected, or to detect a magic Tycho irregularity.