search

eclipse-jdt / eclipse.jdt.core

Eclipse Public License 2.0
161 stars 130 forks source link

Drop support of older Java releases in ecj #2536

Closed iloveeclipse closed 3 months ago

iloveeclipse commented 4 months ago

Discussed in https://github.com/eclipse-jdt/eclipse.jdt.core/discussions/820

Originally posted by **iloveeclipse** March 9, 2023 Stephan [asked good question](https://github.com/eclipse-jdt/eclipse.jdt.core/issues/809#issuecomment-1461692502), 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](https://openjdk.org/jeps/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 Compile for the specified Java SE release. Supported releases: 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17 --source , -source Provide source compatibility with the specified Java SE release. Supported releases: 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17 --target , -target 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 Compile for the specified Java SE release. Supported releases: 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21 -s Specify where to place generated source files --source , -source 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 , -sourcepath Specify where to find input source files --system |none Override location of system modules --target , -target 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 commented 4 months ago

@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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 https://github.com/eclipse-pde/eclipse.pde/pull/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 commented 4 months ago

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 https://github.com/eclipse-jdt/eclipse.jdt.ui/issues/1465 to track that.

iloveeclipse commented 4 months ago

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: https://github.com/eclipse-jdt/eclipse.jdt.debug/issues/451

testforstephen commented 2 months ago

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 commented 2 months ago

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.