Re: [jdt-dev] RFC - Withdrawing compiler support for older versions of J

["Alexander Kriegisch" <alexander@xxxxxxxxxxxxxx>]

I always thought that the ability to compile to older targets is a USP of ECJ. AspectJ leverages that, passing through the corresponding compiler options to its users. Many of our legacy integration tests compile to 1.5 or sometimes even lower targets, simply because they can. That is great.

OTOH, I am not sure how many users still actively use those older, pre-8 targets, and I have no easy way t find out. The JVM platform and Java language are evolving, which is a good thing. Backward compatibility is important, but I guess if that really would make JDT Core development significantly faster, it would be an acceptable trade-off. How much faster and when, I do not know. Maybe initially, it would cause extra work to weed out legacy distinction-of-cases code and configuration constructs from production and test code and maybe even some small parts of the Java grammar (probably not much, if any), before the JDT Core team can reap the benefits of increased productivity and better maintainability. The team probably knows best how fast it might reach the break-even point there.

Do you think, "significantly faster" would apply? I mean, does supporting the old source/target versions actually require significan amounts of maintenance work, or is it rather a matter of scrolling over lots of legacy code? The latter might already be reason enough to abandon it, I am just asking because I am curious.
-- 
Alexander Kriegisch
Eclipse AspectJ project lead


Sankaran, Srikanth via jdt-dev schrieb am 28.03.2024 11:25 (GMT +01:00):
> 
> 
> Hello!
> 
> 
> Greetings.
> 
> 
> I am a committer on the JDT/Core project – specifically focussed on the
> Eclipse Compiler for Java.
> 
> 
> 	I invite comments and objections with justifications to a hypothetical
> 	removal of support
> 
> 
> for compiling “ancient” Java code using the latest versions of ECJ or
> Eclipse IDE/SDK.
> 
> 
> Presently, using window/project preferences, you can configure the
> compiler to use
> 
> ancient versions of Java for
> 
> 
> 	Compiler compliance level : Currently supports all the way back to 1.3
> 	Source compatibility: Currently supports all the way back to 1.3
> 	Generated .class file compatibility : Currently supports all the way back
> 	to 1.1 and CLDC 1.1
> 
> 
> Eclipse compiler code can be modernized quite a bit by dropping support
> for ancient versions.
> 
> By reducing code clutter, we can also bring down the maintenance burden
> and flatten the learning curve.
> 
> Testing cycles will also come down. Currently when a JDT committer runs
> tests locally, tests are run at all
> 
> supported levels.
> 
> 
> As a comparison, javac from JDK22 does not support source levels below 8.
> I am proposing we do the same.
> 
> 
> 	Independently, I would also like to hear comments/objections with
> 	justifications for removing support
> 
> 
> for CLDC_1_1 as a target. Most folks I check with haven’t even heard of
> this configuration (embedded ??)
> 
> 
> Past versions of Eclipse SDK/IDE and ecj.jar’s will continue to be hosted
> at their usual habitat. We are only talking
> 
> about newer evolving version of Eclipse/ECJ
> 
> 
> Thanks!
> 
> Srikanth
> 
>