Drop support of older Java releases in ecj

[iloveeclipse]

Stephan asked good question, I'm not sure we've discussed that before.

The question is:

• Did we discuss dropping support for some ancient Java versions? What's the status there?

and my take on this is: if we can make our life easier, we should follow what javac does, and it does what was proposed in JEP-182: with each Java LTS release they seem to drop support for one of previous releases.

See

• https://openjdk.org/jeps/182
• https://bugs.openjdk.org/browse/JDK-8046172
• https://bugs.openjdk.org/browse/JDK-8173605

Current state in Java 17 (still same in 19):

/usr/lib/jvm/java-17/bin/javac --help | grep release
        Enable preview language features. To be used in conjunction with either -source or --release.
  --release <release>
        Compile for the specified Java SE release. Supported releases: 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17
  --source <release>, -source <release>
        Provide source compatibility with the specified Java SE release. Supported releases: 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17
  --target <release>, -target <release>
        Generate class files suitable for the specified Java SE release. Supported releases: 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

WDYT?

[stephan-herrmann]

To clarify: I would be happy to drop specific sections of ancient code, when they interact with code being actively worked on.

I would, however, caution against actively discarding big amounts of code without further scrutiny :)

Still the message to users could well be along the lines of JEP 182, since "not supported" doesn't necessarily imply "has been removed from our code base completely". Such leeway between user expectation and implementation would be great.

[iloveeclipse]

@stephan-herrmann : with "if we can make our life easier" I meant that if some old code that added to support Java 1.0 hinders us to implement some bug of feature that is needed for Java 42, we should not hesitate to remove that and declare that 1.0 is not supported anymore.

[iloveeclipse]

See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=536194

[martinlippert]

Just wanted to mention a subtle difference between the javac support strategy and what ecj might apply: if you need to compile against an older java version (for whatever reason), you could always just grab the older version of javac. You can't do the same with ecj within the Eclipse IDE. You could use an older version of the IDE that contains the older ecj version, but you would loose everything that happened to the IDE since then as well. Whether that makes a big difference or not, I can't judge (probably depends), but maybe worth to keep in mind.

This is not meant as an argument to keep support for older Java versions in ecj, just wanted to mention that there is a somewhat tight relationship between ecj and the IDE.

[guw]

Martin, I think this work is a potential solution to the problem. Thus, if someone really wants to use an old ECJ and an up-to-date JDT, they should fund some developers to help accelerate the abstraction and implement and "old ECJ" plug-in. Thoughts?

[iloveeclipse]

ecj does not require IDE, old ecj compiler can be used in same way as javac. So I see here no problem saying "use ecj from Eclipse 3.8 if you want to compile with Java 1.0 target".

The work started here has no direct relationship to the problem of "compiling to old target" - actually it is exact the opposite of this, and it is far from being complete.

The only common is that both questions - dropping support for old targets and adding support for new Java versions - is the limited resources we have in the project.

So the existing resources should be spent in most effizient way and for most urgent goals. And that means, if someone can save time by dropping support for older Java compilation targets, it is what will happen.

[martinlippert]

@guw I am not sure if the work that you mentioned aims at having the javac part of this being replaceable. I don't think that is a goal of this work - at least from my poor perspective. But I don't know whether this piece of the puzzle has already been discussed (directly embed and use javac within JDT vs. use an "external" javac installation from somewhere and dynamically load that into JDT).

But independent of whether the javac/JDT work will allow this or not, I totally agree to the point of: when someone has this concrete need (to have up-to-date JDT/Java tooling + support for very old Java versions), that person/organization should step up and contribute - no question about that... :-)

I actually think this is a very niche situation, just wanted to mention it to avoid ecj adopting the javac support strategy without at least having this IDE relationship in mind.

[guw]

You are right. I missed that the focus is on parsing side only but not generating class files.

[HannesWell]

A point related to Java versions supported by ECJ, might be the supported Execution-Environments:
eclipse-jdt/eclipse.jdt.debug#433.

[iloveeclipse]

A point related to Java versions supported by ECJ, might be the supported Execution-Environments:

This is kind of unrelated, as running something with Java 1.6 doesn't mean it has to be compiled in the IDE with Java 1.6 JLS. So one could debug application on Java 1.6 if it is compiled by old ecj / javac on command line.

What constantly makes troubles for developers is that running full tests coverage for all "supported" versions takes too long, so we run only subset on jenkins / in the IDE and see later errors during SDK build (like in #2234 (comment)). And of course supporting older JLS doesn't make the code simpler after the fix...

It simply constantly steals our time urgently needed elsewhere to support "modern" Java versions.

[iloveeclipse]

@merks, @scottslewis: assuming ECJ (Eclipse batch compiler) would discard Java 1.5 compilation target, would it be a blocker for EMF / ECF projects that still have set 1.5 JLS as target?

I'm coming from #2434 (comment) where the compiler has a bug compiling projects targeting 1.5 JLS. Of course we will fix that for now, but it is not the first time where we need spend more time as we could afford for supporting ancient Java language specifications.

So my proposal would be to drop support for all JLS specifications below 1.6 in Eclipse compiler in the next 4.33 SDK (or even below 1.7, in the same way how javac it does).

This would mean, EMF & ECF would need to go at least to Java 1.6 (or even to 1.7 or as far as you can go).

[merks]

Yes, it would be best to make such a change at the beginning of a release cycle. I've opened this issue to put it on the radar screen:

eclipse-emf/org.eclipse.emf#32

[scottslewis]

ECF will move to 1.8, but next release cycle is much preferred. Seems like that's the plan.

[iloveeclipse]

Thanks. Scott! 1.8 is a good target :-)

Seems like that's the plan.

Yes, assuming other JDT committers will not disagree, this would be on my list for 4.33.

[mpalat]

Andrey : +1 for this initiative.

[iloveeclipse]

ECF will move to 1.8, but next release cycle is much preferred. Seems like that's the plan.

@scottslewis : we are in a new release cycle now, so can ECF move? Do you need some help?

[iloveeclipse]

I've created #2536 and plan to work on it next week.

[tjwatson]

Removing Java 7 and older support may not be that disruptive since there is no supported Java 7 runtime available anywhere to run on. Unfortunately Java 8 is here for many years to come (all the way to 2030). Much needs to be considered before removing Java 8 release support from ECJ.