Closed iloveeclipse closed 3 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?
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.
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.
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.
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.
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
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.
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.
Discussed in https://github.com/eclipse-jdt/eclipse.jdt.core/discussions/820
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.