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

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

For (3) below, I specifically mentioned running tests locally. I think it is still a good practice to at least occasionally do that.

 

For the rest of the points, everything comes with a cost – the question is what is the right trade off.

 

See my point about stack map generation and exception handling in the other group.

 

Srikanth

 

From: jdt-dev <jdt-dev-bounces@xxxxxxxxxxx> On Behalf Of Manoj Nalledathu Palat via jdt-dev
Sent: Friday, March 29, 2024 10:00 AM
To: Eclipse JDT general developers list. <jdt-dev@xxxxxxxxxxx>
Cc: Manoj Nalledathu Palat <manoj.palat@xxxxxxxxxx>
Subject: Re: [jdt-dev] RFC - Withdrawing compiler support for older versions of Java levels

 

CAUTION: This email was sent from outside of Advantest.

 

Hi Srikanth,

 

 I would argue against removing the code actively; the arguments listed below:

 

1. As I see in one of the threads, able to support older versions is an advantage over the javac – agree with this point.
2. Since IDE is tied with ecj, whoever wanting to use compiler-agnostic features of the IDE can continue to upgrade to the latest Eclipse
3. Tests are not run for all supported versions automatically in Jenkins when we submit a PR, its run only from 1.8. I believe Stephan made this change a few years back. So that burden is not there for the PRs unless we test explicitly.
4. Also, in case someone wants to fix an issue on an older version, we can expect him/her to contribute rather than expecting the team to work on a priority basis.

 

 

One issue I see, from JEP 182, rt.jar could have some issues, [“when a -source N option older than the source level of rt.jar is specified, it is not clear how newer-than-release-N language artifacts in the platform libraries should be modeled to the code being compiled.”] – but given that we can give a warning for older releases we can atleast notify the user of the risk and hence I don’t think this is a blocker for keeping the ancient code.

 

Regards,

Manoj

 

 

From: jdt-dev <jdt-dev-bounces@xxxxxxxxxxx> on behalf of Stephan Herrmann via jdt-dev <jdt-dev@xxxxxxxxxxx>
Date: Thursday, 28 March 2024 at 7:47 PM
To: jdt-dev@xxxxxxxxxxx <jdt-dev@xxxxxxxxxxx>
Cc: Stephan Herrmann <stephan.herrmann@xxxxxxxxx>
Subject: [EXTERNAL] Re: [jdt-dev] RFC - Withdrawing compiler support for older versions of Java levels

Have you seen https: //github. com/eclipse-jdt/eclipse. jdt. core/discussions/820 ? On 28. 03. 24 11: 25, Sankaran, Srikanth via jdt-dev wrote: Hello! Greetings. I am a committer on the JDT/Core project – specifically focussed on the Eclipse Compiler

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

 

ZjQcmQRYFpfptBannerEnd

Have you seen https://github.com/eclipse-jdt/eclipse.jdt.core/discussions/820 ?

On 28.03.24 11:25, Sankaran, Srikanth via jdt-dev wrote:

Hello!

 

Greetings.

 

I am a committer on the JDT/Core project – specifically focussed on the Eclipse Compiler for Java.

 

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

 

1. Compiler compliance level : Currently supports all the way back to 1.3
2. Source compatibility: Currently supports all the way back to 1.3
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.

 

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

 

 

 

_______________________________________________

jdt-dev mailing list

jdt-dev@xxxxxxxxxxx

To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev