jclMin22.jar contains classes compiled against Java 21

[iloveeclipse]

Found while fixing tests in #2551.

jclMin22.jar contains classes compiled against Java 21. The expectation is that every such jar contains classes built for exact that Java API version it supposed to represent, so compiler tests can see / assert matching class file version if looking on classes from jclMin.jar's. Beside this, jclMin22.jar contains .classpath file that refers to JavaSE-14 which also looks wrong.

I see that there was an attempt made to provide some systematic approach for jclMin* & converterJclMin* jars (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=560658 and d925ea3), however I do not see any trace of actual automation for jclMin jars, nor I see any explanation what is expected content of those jars and what is the difference between jclMin and converterJclMin jars.

I would be very grateful if @stephan-herrmann or @jarthana would add something to the https://github.com/eclipse-jdt/eclipse.jdt.core/wiki/Adding-support-for-new-Java-version-and-Features-in-JDT page (or any other Wiki page that fits to the "jcl" jars).

Once I would know the expected procedure I could update jclMin22.jar with proper content (and may be fix other jars as I can see that jclMin17.jar contains .classpath file that refers to JavaSE-14).

PS.
In the changed code, it's org.eclipse.jdt.core.tests.model.ClasspathTests.test232816f() that found the problem

[stephan-herrmann]

I see that there was an attempt made to provide some systematic approach for jclMin* & converterJclMin* jars (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=560658 and d925ea3), however I do not see any trace of actual automation for jclMin jars ...

Right. Seems we ran out of steam before completing the task :(

[iloveeclipse]

Right. Seems we ran out of steam before completing the task :(

Could you just explain what is expected content of those jars and what is the difference between jclMin and converterJclMin jars, and how jclMin jars were created before?

[stephan-herrmann]

Right. Seems we ran out of steam before completing the task :(

Could you just explain what is expected content of those jars and what is the difference between jclMin and converterJclMin jars, and how jclMin jars were created before?

Guess what: I have no idea.

Both jclMin.jar and converterJclMin.jar where initially committed by Jerome Lanneluc on 2002-07-11, seperate commits, both without a commit comment. Both look like initial imports (into CVS) of some parts of the pre-existing code base.

All I can say is that converterJclMin* are used by DOM converter tests, and jclMin* by model tests.

So, when we need to do something about jclMin anyway, let's try to merge them and see what happens. Since converterJclMin* have sources in git and a build.xml, those should be the starting point for the merge.

The only rationale that I can provide is this: tests are supposed to run with much reduced class libraries to avoid performance problems and to make tests stable while the JDK evolves.

[iloveeclipse]

I see some really strange p1 packages artifacts in converterJclMin1.5.jar (which is of course causes extra fails after switching to converterJclMin1.8.jar because of course later one doesn't have that package).

@jarthana or @mpalat or @srikanth-sankaran : do you know what's the what is the difference between jclMin and converterJclMin jars, and how jclMin jars were created before?

[stephan-herrmann]

how jclMin jars were created before?

Unpack the corresponding jclMinSrc.zip, add stuff, compile and re-create the jar.

(no idea related to the difference between variants)

[iloveeclipse]

Unpack the corresponding jclMinSrc.zip, add stuff,

Which stuff? Where it is coming from? Is this something like CtSym?

[stephan-herrmann]

Unpack the corresponding jclMinSrc.zip, add stuff,

Which stuff? Where it is coming from? Is this something like CtSym?

Vaguely similar to CtSym as both are about stubbing JRE libraries.

All additions are manually crafted.

• some are obvious from language features being added (foreach loop needs Iterable, records need Record etc.)
• some are otherwise "standard" stuff to facilitate using almost-real-world examples in tests.

Still, for every type added, we go with a "minimal" set of members.

[merks]

After errors in my SDK workspace for months I wondered why this still hasn't been fixed.

The only recourse seems to be not to import them into the workspace. Or is there some plan here?

[iloveeclipse]

After errors in my SDK workspace for months

Which errors? This issue shouldn't produce any errors.

[merks]

Is this a different issue?

[iloveeclipse]

Is this a different issue?

Yes. Please remove projects inside JCL from Oomph setup, they shouldn't be used by most of developers. Even experienced ones don't know how to use them properly :-)