Remove nolonger supported converterJclMin

[akurtakov]

Versions older than 1.8 are not supported and thus shouldn't be needed nor referenced anymore.

[akurtakov]

This looks like continuation of #3227 and I start with it as I figured converterJclMin1.8 lacks NoSuchFieldError while trying to enable ASTConververt15JLS8Test from #2758

[akurtakov]

@iloveeclipse @stephan-herrmann Do you see some fundamental reason to keep these? If not, I'll work on fixing the tests.

[iloveeclipse]

I don't, as long as tests are green, but only because I have no idea how it was designed. It just happened to me to stumble over the various jclMinXYZ jars which someone somehow built and the parallel exisring jclConverterXYZ jars.

[stephan-herrmann]

This looks like continuation of #3227 and I start with it as I figured converterJclMin1.8 lacks NoSuchFieldError while trying to enable ASTConververt15JLS8Test from #2758

Is removing old jars a prerequisite or otherwise related to fixing the test?

Do you see some fundamental reason to keep these? If not, I'll work on fixing the tests.

Nothing fundamental, I just suggest to look for a path that doesn't force changes in too many tests.

I have no idea how it was designed. It just happened to me to stumble over the various jclMinXYZ jars which someone somehow built and the parallel exisring jclConverterXYZ jars.

I cannot comment on the original motivation, but I can see that

• jars have different sizes, large to small: jclFull, converterJcl, jclMin
• small class libraries help keeping test execution time low
• class libraries that we control ensure that results don't unnecessarily change (see also my change of strategy in #3227).

... jars which someone somehow built ...

building is no longer a mystery since #2727 is it?

[akurtakov]

This looks like continuation of #3227 and I start with it as I figured converterJclMin1.8 lacks NoSuchFieldError while trying to enable ASTConververt15JLS8Test from #2758

Is removing old jars a prerequisite or otherwise related to fixing the test?

It is actually. As can be seen at

eclipse.jdt.core/org.eclipse.jdt.core.tests.model/JCL/build.xml

Line 34 in 6b53bf4

<antcall target="converterJclMin">

building converterJCLMin1.8 is commented out so changes to it have no effect.
And trying to use this build.xml file doesn't complete successfully with:

jclMin_notModular:
    [javac] /home/akurtakov/git/eclipse.jdt.core/org.eclipse.jdt.core.tests.model/JCL/build.xml:148: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
    [javac] Compiling 13 source files to /home/akurtakov/git/eclipse.jdt.core/JCL/jclMin1.8/bin
    [javac] /home/akurtakov/git/eclipse.jdt.core/JCL/jclMin1.8/src/java/lang/annotation/ElementType.java:2: error: cannot find symbol
    [javac] public enum ElementType {
    [javac]        ^
    [javac]   symbol:   method valueOf(Class,String)
    [javac]   location: class Enum<T>
    [javac]   where T is a type-variable:
    [javac]     T extends Enum<T> declared in class Enum
    [javac] 1 error
    [javac] Fatal Error: Unable to find method valueOf

BUILD FAILED
/home/akurtakov/git/eclipse.jdt.core/org.eclipse.jdt.core.tests.model/JCL/build.xml:94: The following error occurred while executing this line:
/home/akurtakov/git/eclipse.jdt.core/org.eclipse.jdt.core.tests.model/JCL/build.xml:148: Compile failed; see the compiler error output for details.

which is the next thing I plan to look at after this one and continuation to it no longer commenting 1.8 rebuild.

[stephan-herrmann]

@akurtakov I very much appreciate your efforts to fix ASTConververt15JLS8Test! I just wonder how we can avoid this to expand into a large moving target effort with limited benefit.

Regarding jclMin: the build has successfully run just recently (on my machine :) ). Have you seen https://www.eclipse.org/lists/jdt-dev/msg02453.html - not seeing any response there nor in #2727 I assumed everybody is happy with the status. If that is not the case please wait until next week when I will be able to help, to avoid unnecessary back and forth.

When I worked on #2727 actually my goal was to facilitate working on new / recent Java versions. Once #2758 is resolved I hope we will NEVER have to build any of the old version JCLs again. Those are intended to provide stability. No further changes intended.

So perhaps building all those jars always is actually a inappropriate approach. Possible steps:

• remove the default target from build.xml so we'll build only those jars where changes are definitely needed
• remove build.xml altogether and replace with a simple *.jardesc in each of the JCL projects

And, yes, building classes in java.lang et al is always a tricky issue, as the compiler assumes that these classes already exist before compilation starts, and ecj and javac seem to make different such assumptions. That's why an ant build using javac can indeed fail, despite ecj having successfully compiled everything.

[akurtakov]

@akurtakov I very much appreciate your efforts to fix ASTConververt15JLS8Test! I just wonder how we can avoid this to expand into a large moving target effort with limited benefit.

If it makes maintenance clearer for someone not involved daily (like me) it's worth it and I consider it time well spend.

Regarding jclMin: the build has successfully run just recently (on my machine :) ). Have you seen https://www.eclipse.org/lists/jdt-dev/msg02453.html - not seeing any response there nor in #2727 I assumed everybody is happy with the status. If that is not the case please wait until next week when I will be able to help, to avoid unnecessary back and forth.

I have to admit I haven't paid much attention to these changes and having others deal with it.

When I worked on #2727 actually my goal was to facilitate working on new / recent Java versions. Once #2758 is resolved I hope we will NEVER have to build any of the old version JCLs again. Those are intended to provide stability. No further changes intended.

Changes will have to happen when jdt min supported version moves up as tests on old versions will need updates.

So perhaps building all those jars always is actually a inappropriate approach.

I fully agree here, rebuilding when there is need should be possible though (like in this case).

[stephan-herrmann]

Changes will have to happen when jdt min supported version moves up as tests on old versions will need updates.

Once the current set of changes is done, all 1.8 jars should have reached their final state, as there will no longer be any tests at lower levels that will have to migrate to 1.8 😄

Additionally, I might do a general scan if any JCL X lacks feature present in JCL Y for Y<X, to avoid any such need to touch tests or JCL jars when any version goes EOL.

[akurtakov]

Changes will have to happen when jdt min supported version moves up as tests on old versions will need updates.

Once the current set of changes is done, all 1.8 jars should have reached their final state, as there will no longer be any tests at lower levels that will have to migrate to 1.8 😄

Additionally, I might do a general scan if any JCL X lacks feature present in JCL Y for Y<X, to avoid any such need to touch tests or JCL jars when any version goes EOL.

That would be very nice and would definetely minimize the changes needed whenever jdt.core moves to e.g. Java 11 as a min version.

[akurtakov]

Is there a reason not to merge this one in?

[stephan-herrmann]

Is there a reason not to merge this one in?

no :)