Drop support of older Java releases in ecj

[iloveeclipse]

Discussed in #820

^{Originally posted by iloveeclipse March 9, 2023}
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

for Java 21 we have

  --release <release>
        Compile for the specified Java SE release.
        Supported releases: 
            8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21
  -s <directory>               Specify where to place generated source files
  --source <release>, -source <release>
        Provide source compatibility with the specified Java SE release.
        Supported releases: 
            8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21
  --source-path <path>, -sourcepath <path>
        Specify where to find input source files
  --system <jdk>|none          Override location of system modules
  --target <release>, -target <release>
        Generate class files suitable for the specified Java SE release.
        Supported releases: 
            8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21

The proposal is for 4.33 to drop support for all Java releases older Java 8.

I plan to start working on this next week.

[mpalat]

@iloveeclipse - How about we take an approach something similar to deprecation in apis.- in a staggered manner - instead of throwing an error in 4.33, we issue a warning in 4.33 and then an error in 4.34?

[iloveeclipse]

The reason to start this initiative was reducing the effort for maintenance & focus on quality of new Java features.
Adding warnings will just postpone unavoidable for one release but not help with any of the goals.
Users will simply ignore the warning for now and complain on next release.
So I'm for a "clean" error solution.
Whoever needs to compile to an ancient Java can use any of previously released ecj/SDK versions.

[jarthana]

Are there issues in jdt.ui and jdt.debug that may be required for this? I don't yet know what we require to do there, but for starter, we will need to remove the compliance from the UI. Might be a good idea to start the discussions around the UI too.

[iloveeclipse]

Are there issues in jdt.ui and jdt.debug that may be required for this?

Code wise not yet (as I didn't removed JavaCore constants for old Java versions), but I guess there will be some.

we will need to remove the compliance from the UI.

This is for sure pending, we will need to change the "target" properties/preference pages in JDT UI and also "available execution environments" for PDE/Debug UI.

I will check that but of course would be nice if someone else could take it over while I'm looking into JDT test fixes.

I've just pushed eclipse-pde/eclipse.pde#1309 for PDE tests that moves their compilation level from 1.4/1.5 to 1.8. (most of the PDE tests were written at IBM times with Java 1.5 considered "modern" environment :-) )

Regarding JDT tests: as we can see, fails are now down to ~800 from initial ~2.500. I intentionally do not disable tests yet to see how far we can go preserving tests also written for old targets because many of them aren't JLS target specific.

[jarthana]

I will check that but of course would be nice if someone else could take it over while I'm looking into JDT test fixes.

Sorry, I didn't mean to check if you were going to work on it. I am sure (and hope) we have enough committers in UI to take care of that. I raised eclipse-jdt/eclipse.jdt.ui#1465 to track that.

[iloveeclipse]

I raised eclipse-jdt/eclipse.jdt.ui#1465 to track that.

I've created another ticket for debugger, as most of configuration pages are provided by debugger: eclipse-jdt/eclipse.jdt.debug#451

[testforstephen]

Sorry to raise a concern late for this issue. Dropping support for older Java versions in ECJ is fine when it is used as a standalone compiler. However, this may cause confusion when ECJ is integrated into IDEs such as Eclipse. Since Eclipse integrates the latest ECJ by default, it is not possible to specify an older ECJ version with the latest JDT. As a result, newer versions of Eclipse will no longer support Java 1.7 and lower, potentially confusing users working on legacy projects.

[iloveeclipse]

newer versions of Eclipse will no longer support Java 1.7 and lower, potentially confusing users working on legacy projects.

Not sure where confusion is coming from, as ecj is a part of JDT core / IDE, it was clear that dropping legacy Java versions support in ecj means exact same for the IDE.

• Users working on legacy projects could continue use legacy Eclipse releases as long as they will run on legacy Java versions and legacy operating systems. No one forces anyone to update Eclipse, Java or operating system.
• Users who want support for legacy Java versions in latest ecj/IDE should contribute to the project.
• With the current project resources we don't have the choice.