Re: [jdt-dev] [eclipse-dev] RFC - Withdrawing compiler support for older

["Sankaran, Srikanth" <srikanth.sankaran@xxxxxxxxxxxxx>]

It is hard to quantify - so I can't claim it will significantly speed up the development.

We rarely get defects specifically against very old versions, so no, this doesn't consume significant amount of maintenance work.

I would say, borrowing your words, " it is rather a matter of scrolling over lots of legacy code" - particularly legacy code in highly
complex parts of the compiler. Such as exception handling.

Quoting from my discussion with another JDT committer:

// ---
I am planning to undertake some interesting and ambitious work for switch expressions.
An early task is https://github.com/eclipse-jdt/eclipse.jdt.core/issues/2234 

If successful, it could mean (a) we report verify errors at compile time itself (b) eliminate the separate pass (ambitious) for generating StackMapTable and (c) clean up a significant part of the implementation of switch expressions (d) shake out a whole slew of bugs in switch expressions
Blah, blah, blah …

Now StackMapTable is a 1.6+ thing.

From a puritanic pov, all such stack tracking code should happen in StackMapFrameCodeStream and not in CodeStream : this would require a ton of overrides in the subclass.

Of course I can ditch puritanism and break/blur abstraction and make all the changes in CodeStream itself – perhaps conditionally on 1.6+ levels – or perhaps just unconditionally

Just that I feel it will be cleaner if we can just say StackMapTable will always be emitted : i.e., minimum 1.6 level

It is also the case that exception handling has special treatment for 1.4- levels with jsr instruction. EH being one of the most complex topics, I would prefer that we are dealing with just one flavor and not three.
// ---

Srikanth




-----Original Message-----
From: eclipse-dev <eclipse-dev-bounces@xxxxxxxxxxx> On Behalf Of Alexander Kriegisch via eclipse-dev
Sent: Thursday, March 28, 2024 5:18 PM
To: jdt-dev@xxxxxxxxxxx; eclipse-dev@xxxxxxxxxxx
Cc: Alexander Kriegisch <alexander@xxxxxxxxxxxxxx>
Subject: Re: [eclipse-dev] [jdt-dev] RFC - Withdrawing compiler support for older versions of Java levels

CAUTION: This email was sent from outside of Advantest.


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
>
>

_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-dev