Community
Participate
Working Groups
Move compliance level to Java 11, in order to use newer APIs.
(In reply to Jörg Kubitz from comment #0) > Move compliance level to Java 11, in order to use newer APIs. Which concrete new API's are needed for which use case? See previous discussion on bug 569235 for 4.19. JDT core is also used as standalone Java compiler (ecj), so this might affect users that run compilation with ecj on Java 8. Note: differently to bug 569235 time we now have resources bundle switched to Java 11 (without any change/reason requiring that), and JDT depends on resources bundle if running in the IDE (but not running standalone).
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/178486
> Which concrete new API's are needed for which use case? I would "need" InputStream::readAllBytes() for bug 572372. So "only" for performance reasons. > JDT core is also used as standalone Java compiler (ecj), so this might > affect users that run compilation with ecj on Java 8. Is that still a usecase for anybody? > Note: differently to bug 569235 time we now have resources bundle switched > to Java 11 (without any change/reason requiring that), and JDT depends on > resources bundle if running in the IDE (but not running standalone). Would there be any pattern to use JDK11 API running in the IDE while using JDK8 API in standalone?
(In reply to Jörg Kubitz from comment #3) > > JDT core is also used as standalone Java compiler (ecj), so this might > > affect users that run compilation with ecj on Java 8. > > Is that still a usecase for anybody? This bug is hardly seen by those folks whose answer you need. ecj is used far and wide on the globe, not only "standalone" as Andrey mentioned but also embedded into various other components. I don't think there is a suitable platform for asking all of them. So conservatively, my answer would be: yes it *probably* still is a relevant use case. I could, however, see a compromise: if all JDT/Core developers have project org.eclipse.jdt.core.ecj.validation checked out in their workspace, and pay attention to possible compile errors there, then we *could* declare that the restriction to 1.8 applies only to ecj, while *the rest of JDT/Core* could leverage Java 11. But that won't help for bug 572372 which affects the ecj part.
So far i read only vague comments that "someone" (who?) might (realy?) need 1.8 compliance. But no one (not even on jdt-dev mailinglist) gave any concrete demand for that. Would you please add information who specific should be asked? 1.8 already reached its public end of live. 11 LTS is already available and for free. Why does someone still need 1.8 compliance? Till when? How would JDT ever announce a new required version for ecj? I did not find any public requirement documentation. I ask the jdt community to give a upgrade plan. And if no one realy requires 1.8 compliance anymore i ask to upgrade ASAP.
(In reply to Jörg Kubitz from comment #5) > So far i read only vague comments that "someone" (who?) might (realy?) need > 1.8 compliance. But no one (not even on jdt-dev mailinglist) gave any > concrete demand for that. I made a fairly random sample and came up with these: Dependency on ecj: https://sourceforge.net/p/jasperreports/code/ci/master/tree/jasperreports/pom.xml Settings configured for 1.8: https://sourceforge.net/p/jasperreports/code/ci/master/tree/jasperreports/.settings/org.eclipse.jdt.core.prefs It's quite tricky to get a picture of what dependencies exist out there in the wild, and jdt-dev certainly isn't the global forum to get that information, but you may actually get a first idea by scanning through this: https://mvnrepository.com/artifact/org.eclipse.jdt/ecj/usages Those are only the maven dependencies against ecj. What JRE requirements they have and why I have no idea. To be perfectly clear, I never intended to imply that this situation completely blocks JDT's evolution, but specifically for the ecj part I would raise the bar, i.e., incur potential trouble for downstream projects only if there's a substantial benefit to balance it. In particular InputStream::readAllBytes looks like smth we can easily do on our side even on 1.8, no?
(In reply to Jörg Kubitz from comment #5) > So far i read only vague comments that "someone" (who?) might (realy?) need > 1.8 compliance. But no one (not even on jdt-dev mailinglist) gave any > concrete demand for that. See https://mvnrepository.com/artifact/org.eclipse.jdt.core.compiler/ecj/usages with some "maven only" users (282), you may try to research if all of them are moved to Java 11 already - those didn't updated after 25.09.2018 are probably not Java 11 ready, but it is just a guess... > Would you please add information who specific should be asked? You could ask on cross-projects mailing list (cross-project-issues-dev@eclipse.org) & general developers list (eclipse-dev@eclipse.org), but it is mostly lists for developers and not users. You only know if you broke someone's workflow *after* the release :-) > 1.8 already reached its public end of live. 11 LTS is already available and > for free. > Why does someone still need 1.8 compliance? Till when? This is probably more philosophical question. If I would say my company still builds software versions based on Java 8 and does not plan to switch for some of the products to Java 11 till 2030 (where Java 8 extended support probably ends, see https://www.oracle.com/java/technologies/java-se-support-roadmap.html), would it mean, we should wait for 2030? Sure not. Why do we do that? It is very simple. The software builds & runs just fine on Java 8 & our customers value the platform stability / support of the old releases up and over 10th of years. Even more, some of the customers explicitly don't want to change *anything* in the environment for 10th of years, so we often ship only the updated product on a platform (OS/Java/libc etc) that was "frozen" years ago. But please don't take this above as a request to keep JDT on Java 8 till 2030. We (Advantest) are fine with moving JDT to 11, *if* the JDT project decided to do so. > How would JDT ever announce a new required version for ecj? I did not find > any public requirement documentation. The plan for the entire platform is here, but it doesn't mention ecj explicitly: https://www.eclipse.org/projects/project-plan.php?planurl=https://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_20.xml. I have no idea if JDT has some official statement "we support Java XYZ version" somewhere except the MANIFEST itself. > I ask the jdt community to give a upgrade plan. > > And if no one realy requires 1.8 compliance anymore i ask to upgrade ASAP. As said, there will be no answer if "someone" requires ecj to support Java 8, even if that is the case, it doesn't mean we won't update because of that. I personally think that people that use ecj, but want run on Java 8 for some reason, do not need to jump on the latest greatest Eclipse platform, which is known to move forward faster now, and simply use older ecj/platform versions. @Jay, @Manoj: can we decide about the switch to Java 11 for JDT for 4.20 M2, or is it too late? I think *if* we decide to move we should announce that early enough on cross-project / general mailing list.
(In reply to Stephan Herrmann from comment #6) > https://mvnrepository.com/artifact/org.eclipse.jdt/ecj/usages Thats interesting! Thanks for the link. > InputStream::readAllBytes looks like smth we can easily do on our side I dont know how: Technically we could copy&paste that impl from jdk (which is prohibitetd by licence) but we cannot copy&paste all its overloads (for example in ByteArrayInputStream). Thus we can not take the real advantage of the enhanced interface. (In reply to Andrey Loskutov from comment #7) > https://mvnrepository.com/artifact/org.eclipse.jdt.core.compiler/ecj/usages Well thats the OLD ecj. And its interesting that the new ECJ (see Stephans link) is used much less (39). Means that majority of projects did not update to recent versions of ecj for years. I looked in some dependend projects and some look dead, some use ecj only for testing - and some are still on java 1.8 and active. However i doubt such a project that runs on 1.8 will need the new features of recent ecj (like to compile java 16 code). Bugfixes would be a valid reason but i see very little commits that fix old bugs. > "we support Java XYZ version" somewhere except the MANIFEST itself As far as i know the required java version is not exported to the MANIFEST.MF but only to the individual .class files. Or do you mean the current "Build-Jdk-Spec: 11"? Please note 11!
(In reply to Jörg Kubitz from comment #8) > > "we support Java XYZ version" somewhere except the MANIFEST itself > As far as i know the required java version is not exported to the > MANIFEST.MF but only to the individual .class files. > Or do you mean the current "Build-Jdk-Spec: 11"? Please note 11! I meant "Bundle-RequiredExecutionEnvironment: JavaSE-1.8" in jdt core.
(In reply to Jörg Kubitz from comment #8) > > InputStream::readAllBytes looks like smth we can easily do on our side > > I dont know how: > Technically we could copy&paste that impl from jdk (which is prohibitetd by > licence) but we cannot copy&paste all its overloads (for example in > ByteArrayInputStream). Thus we can not take the real advantage of the > enhanced interface. If you show us affected locations in JDT maybe we can help? > I looked in some dependend projects and some look dead, some use ecj only > for testing - and some are still on java 1.8 and active. However i doubt > such a project that runs on 1.8 will need the new features of recent ecj > (like to compile java 16 code). doubt is not proof :) But you're right regarding newer versions of Java, since they would again require new libraries anyway. > Bugfixes would be a valid reason but i see very little commits that fix old bugs. If you mean bugs in ecj, then this is a big problem in itself, because there's no shortage in old bugs in the compiler ... In the sample of jasper I happened to see that they updated the ecj version a year ago. You might ask them if this is an annual routine or what's their plan. > As far as i know the required java version is not exported to the > MANIFEST.MF but only to the individual .class files. For OSGi contexts we have BREE as Andrey mentioned, for ecj there is no such place where we can possibly declare this (other than the classfiles), right? But it would perhaps be a good idea to add the specific requirements of ecj into plan or readme (https://www.eclipse.org/eclipse/development/readme_eclipse_4.19.php), even though it would be quite late and you can never know who reads it :)
(In reply to Andrey Loskutov from comment #7) > still builds software versions based on Java 8 and does not plan to switch > for some of the products to Java 11 till 2030 (where Java 8 extended support > probably ends, see > https://www.oracle.com/java/technologies/java-se-support-roadmap.html), > would it mean, we should wait for 2030? Sure not. Why do we do that? It is Interestingly Java 8 support (2030) is longer than 11 (2026) and 17 (2029). And many people in conferences/discussions do say that they are still at Java 8 - well, that's only a data that can change over time - so I will leave it at that. > @Jay, @Manoj: can we decide about the switch to Java 11 for JDT for 4.20 M2, > or is it too late? > I think *if* we decide to move we should announce that early enough on > cross-project / general mailing list. M2 is too late for switching over - I would prefer an early mail being sent across to various mailing lists (in the hope of *everyone* will see this) much before. Traditionally, ecj was always behind the current release - and now in the 6 month release cadence, I would consider only LTS as the major release. Given that the LTS is 11 at this point, I think it is fine as long as ecj continues to be on the previous LTS version which is 8 prior to the current LTS (11) unless there is a pressing need. If we agree to this, then we can think of moving ecj to 11 when the next LTS version is supported by ecj source, ie after Java 17 support is into ecj. 4.21 (Sep 2021) will have Java 17 support as a patch build only, so we are looking at 4.22 ie the December 2021 release for the ecj upgrade to Java 11 - ie, if there is a consensus to upgrade to Java 11. my 2 cents.
For now i rebased bug 572372 on bug 573239 which avoids InputStream::readAllBytes(). Therefore i do not have any current need for Java 11 anymore. However i suggest that JDT has a plan. Manoj suggested a plan that looks good to me. Would be nice if we all could agree on that.
On the mailing list, Jörg asked me to comment here. AspectJ forks two modules of JDT Core and still builds to Java 8 target level. Because of a single JAR in JDT Core, we already have to build using Java 14, not just Java 11. For details, see my ML message: https://www.eclipse.org/lists/eclipse-dev/msg11669.html I cannot speak for the maintainer Andy Clement, but I know he would like to keep the option to also build on Java 8. As for myself, as long as I can still use target 8, I would not mind having to build on a more recent JDK. I am just wondering why presently there already is a dependency with Java 14 (58.0) class files in it.
What I found confusing on all this "should we update topics" really is: If people need support for older <place your favorite thing here> why don't they simply stick to the last release that support this? That's one point of releases so you have a safe checkpoint (otherwise we could just do rolling releases and only increment build qualifiers...). Especially here on the java8 topic, there are not updates/new features for java8 why one would expect a compiler to support *running* on an older jdk (you can still compile j8 *code* on newer jdk with recent compiler version) ... So even though I was hit by the problem in the past (a lib/dep I liked to update requires more recent java) I can fully understand that maintainers of such a project don't like to take extra effort just because I/the company/whatever is unable for whatever reason to upgrade. Especially on open-source, there is always the option to backport required bugfixes to older releases if it *really* hurts...
(In reply to Manoj Palat from comment #11) > > @Jay, @Manoj: can we decide about the switch to Java 11 for JDT for 4.20 M2, > > or is it too late? > > I think *if* we decide to move we should announce that early enough on > > cross-project / general mailing list. > > M2 is too late for switching over - I would prefer an early mail being sent > across to various mailing lists (in the hope of *everyone* will see this) > much before. Is 4.21 M1 OK? > Traditionally, ecj was always behind the current release - and now in the 6 > month release cadence, I would consider only LTS as the major release. > Given that the LTS is 11 at this point, I think it is fine as long as ecj > continues to be on the previous LTS version which is 8 prior to the current > LTS (11) unless there is a pressing need. > > If we agree to this, then we can think of moving ecj to 11 when the next LTS > version is supported by ecj source, ie after Java 17 support is into ecj. > 4.21 (Sep 2021) will have Java 17 support as a patch build only, so we are > looking at 4.22 ie the December 2021 release for the ecj upgrade to Java 11 > - ie, if there is a consensus to upgrade to Java 11. my 2 cents. Manoj: I think 4.22 is too late. There is not much of platform supporting Java 8 left, and our "official" Eclipse support for Java 8 terminated already year ago with 4.17 (see https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_17.xml). Sure, that doesn't mean we *must* move, but to be honest: we can't afford to support running on Java 8 anymore. We simply have no resources doing that. Such bugs like bug 574229 will appear and will steal the time from few people trying to keep up with Java 17+ support, regular compiler bugs etc. I would propose to move JDT to Java 11 for 4.21 release and stop support for running ecj on older Java releases. We should announce that and honestly say that we are unable to continue supporting running ecj on Java 8 release because of limited resources, not because we have fun doing so. The downstream consumers can keep on using old ecj versions or move to Java 11 too.
How can we make sure that Java 11 is sufficient while having a JDK15+ API in the classpath?
(In reply to Jörg Kubitz from comment #16) > How can we make sure that Java 11 is sufficient while having a JDK15+ API in > the classpath? Through code review & tests. We run 3x tests on Java 11 (Mac/Win/Linux), but we do not run *any* tests on Java 8, neither use it for building etc. From this point of view, we aren't supporting Java 8 anymore, because no one knows what quality Java 8 support in ecj has.
(In reply to Andrey Loskutov from comment #17) > We run 3x tests on Java 11 (Mac/Win/Linux), but we do not run *any* tests on > Java 8, neither use it for building etc. > > From this point of view, we aren't supporting Java 8 anymore, because no one > knows what quality Java 8 support in ecj has. From that point of view JDT must stick to the version of the eclipse infrastructure or afford an own infrastructure (unlikely).
+1 from PMC member to move to Java 11
-1 for doing this right now. In any case generating code for a Java 8 target must still be supported and work correctly in all cases. Which it doesn't with 3.26.0 if the JSR-199 EclipseCompiler entry point is used; see bug 574181.
(In reply to Thomas Wolf from comment #20) > -1 for doing this right now. > > In any case generating code for a Java 8 target must still be supported and > work correctly in all cases. Which it doesn't with 3.26.0 if the JSR-199 > EclipseCompiler entry point is used; see bug 574181. Thomas, you misunderstand this. We stop support for *running* ecj on Java 8, *not* the support for compilation with Java 8 target. These are two completely different issues.
(In reply to Andrey Loskutov from comment #21) > (In reply to Thomas Wolf from comment #20) > > -1 for doing this right now. > > > > In any case generating code for a Java 8 target must still be supported and > > work correctly in all cases. Which it doesn't with 3.26.0 if the JSR-199 > > EclipseCompiler entry point is used; see bug 574181. > > Thomas, you misunderstand this. We stop support for *running* ecj on Java 8, > *not* the support for compilation with Java 8 target. These are two > completely different issues. Currently I can only generate correct Java 8 code in a maven build with ECJ if I run ECJ on Java 8. If I run ECJ in a maven build through plexus-compiler-eclipse, which is the "standard" way to configure maven-compiler-plugin to use ECJ in the first place and which uses the JSR-199 entry point, and ECJ is executed on Java 11, the generated code is not correct for a Java 8 target even with --release 8. So what exactly am I missing?
(In reply to Thomas Wolf from comment #22) > If I run ECJ in a maven build through plexus-compiler-eclipse, which is the > "standard" way to configure maven-compiler-plugin to use ECJ in the first > place and which uses the JSR-199 entry point, and ECJ is executed on Java > 11, the generated code is not correct for a Java 8 target even with > --release 8. > > So what exactly am I missing? Either the ECJ is not getting the correct source levels through the JSR-199 interface or something is broken around that part. Can't comment without seeing the failing scenario. The default compliance is always the latest supported version and one has to pass the compliance explicitly if an older version is desired.
(In reply to Thomas Wolf from comment #22) > Currently I can only generate correct Java 8 code in a maven build with ECJ > if I run ECJ on Java 8. Thats only a bug but not the plan. The plan is that you can still compile to 8 running on 11. You needs to have a jdk 8 API in the projects classpath though to get not only bytecode for 8 but also calling java 8 APIs. At least the UI warns about that if you don't.
(In reply to Jay Arthanareeswaran from comment #23) > Either the ECJ is not getting the correct source levels through the JSR-199 > interface or something is broken around that part. Can't comment without > seeing the failing scenario. Jay, in case it got lost in the flurry of posts: it's bug 574181, which has some technical discussion and a failing test case on Gerrit. My point regarding the move to Java 11 was simply: do that only if it is guaranteed that generating for a Java 8 target still works in all cases if ECJ itself is run on Java 11.
(In reply to Thomas Wolf from comment #22) > Currently I can only generate correct Java 8 code in a maven build with ECJ > if I run ECJ on Java 8. Perfect. Just continue to use this exact ecj version. > If I run ECJ in a maven build through plexus-compiler-eclipse, which is the > "standard" way to configure maven-compiler-plugin to use ECJ in the first > place and which uses the JSR-199 entry point, and ECJ is executed on Java > 11, the generated code is not correct for a Java 8 target even with > --release 8. This is bug 574181 and it has to be fixed, and waits in the queue until one from few JDT maintainers have time to look into. > So what exactly am I missing? Few things: 1) you *can* continue use ecj on Java 8 with whatever ecj version is used. No one forces you to use *latest* ecj that would be released with 4.21 release. 2) The bug 574181 need to be fixed by same people that are supposed to continue ecj maintenance on Java 8, and since those people can't clone themselves they have to decide if they want to fix your bug or to continue Java 8 support and fix bug 574229 or to provide Java 17 support and work on bug 571398 and all linked issues. 3) Tomorrow someone will report a bug that ecj doesn't work on Java 17+ or doesn't support some fancy new Java 17+ feature. Again, that bug goes to the same small JDT team and has to be fixed ASAP etc. With the current setup we have an extremely small team of people that are supposed to do all the work on an extremely complicated code base. Running compiler on Java 8 release requires extra work / code / fixes / tests. Someone must do this work / code / fixes / tests. There is no one free. All who could do that job work already 24 hours at day on other JDT issues with higher priority. That's all. So while I would like to say "let support Java 8 till 2030 or longer", it is simply unrealistic to expect that this will happen without serious *additional* investment. Therefore we should give JDT team freedom to work on ecj without thinking about "ecj running on Java 8" problem, and we should honestly say to the "ecj on Java 8" consumers, that there is no free beer and that if someone wants ecj to continue to run on Java 8, this someone could go and fork JDT code and try to build a version that runs on java 8.
(In reply to Andrey Loskutov from comment #15) > > Manoj: I think 4.22 is too late. @Andrey: hmm.. so the issue is up again :). From my earlier comment 11:... " Given that the LTS is 11 at this point, I think it is fine as long as ecj continues to be on the previous LTS version which is 8 prior to the current LTS (11) unless there is a pressing need. " So let me re-iterate my stand here albeit with a modification. If it feels that there is a pressing need to move to 11 in 4.21, let us announce it in the cross-project/eclipse general mailing lists which Andrey has already gone ahead. And then lets wait for a few days (a week?) in M1 time frame. However, I would like to make sure that this is a repeatable process and we stick to a particular mode. In this case, the mode will be "let us move to the last stable release just before the BETA support for the next stable version is expected" instead of "let us move to the last stable release along with the BETA support of the next stable version". If we announce this also, then the customers are not taken by surprise for the move and they can always plan for the same. I will reply to the message in the mailing list and let us see whether we can elicit any response.
(In reply to Thomas Wolf from comment #22) > Currently I can only generate correct Java 8 code in a maven build with ECJ > if I run ECJ on Java 8. The OCL TYcho builds have been generating correct Java 8 and Java 5 JARs to comply with no-need-to-change legacy practices for many years. Additional Jenkins jobs conform that they really are that version. IIRC I did have some trouble setting the execution environment and do not really understand my solution, but it works. See https://git.eclipse.org/r/plugins/gitiles/ocl/org.eclipse.ocl/+/refs/heads/master/releng/org.eclipse.ocl.releng.tycho/pom.xml Reviewing the embeddded comments it appears that the difficulties were caused by a Jetty side effect and went away once Java 11 has used for the tooling JVM. Now the generated clas code is what the plugin BREE specifies.
https://www.eclipse.org/forums/index.php/t/1108263/ People are already complaining about JDT Core at level 8 having dependency on other plugin with Java 11.
(In reply to Sarika Sinha from comment #29) > https://www.eclipse.org/forums/index.php/t/1108263/ > > People are already complaining about JDT Core at level 8 having dependency > on other plugin with Java 11. That was hopefully clear for everyone, that keeping JDT alone on Java 8 doesn't mean JDT would run on Java 8? We've switched almost everything of JDT dependencies to Java 11, only compiler that is dependency-free is kind of working on Java 8 (if not bug 574229).
(In reply to Andrey Loskutov from comment #30) > That was hopefully clear for everyone, that keeping JDT alone on Java 8 > doesn't mean JDT would run on Java 8? We've switched almost everything of > JDT dependencies to Java 11, only compiler that is dependency-free is kind > of working on Java 8 (if not bug 574229). I was one of those wanting to keep JDT at 8. The reason has always been about the standalone ECJ rather than JDT. Having said that, as has been proven by myriad of incoming issues, JDT should move forward to 11.
(In reply to Jay Arthanareeswaran from comment #31) > (In reply to Andrey Loskutov from comment #30) > > JDT dependencies to Java 11, only compiler that is dependency-free is kind > > of working on Java 8 (if not bug 574229). > > proven by myriad of incoming issues, JDT should move forward to 11. @Jay: Thanks for the agreement. Andrey and I had an offline discussion as well now. Initially, I was thinking about keeping ecj (implying the command line compiler) sacrosanct with 1.8 but that would mean further pressure for our already time-constrained team, either be it while coding or probably more so while checking for this item in the reviews (@Stephan - I hear you about ecj validation - yet the onus will be upon the reviewers to make sure that this is adhered to). And anyway, this would have been only be a stop gap arrangement until the next release. Hence +1 for moving to 11 in 4.21 itself. Marking this as a plan bug for 4.21 [@Andrey: marking you as QA.] Also we agreed that we should be explicit about ecj at: https://www.eclipse.org/projects/project-plan.php?planurl=https://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_21.xml
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/182165
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/182172
*** Bug 574303 has been marked as a duplicate of this bug. ***
Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/182172 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=32abdfb9c5100e8c2ff7669768b7d7fcc83c7e23
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/182266
Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/182266 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=fcd7d32b4b0760b4834d8f22f4b1bc53b940ea02
There are 3 ways we use JDT compiler 1. As part of IDE. 2. As part of Maven build a. Using Tycho - already moved to java11 b.Using org.codehaus.plexus:plexus-compiler-eclipse plugin 3. as commandline using java -jar <ecj.jar> As part of IDE, the build will not work unless we use java 11 because of dependencies unrelated to JDT core as IDE itself requires Java 11 as minimum requirement. Since Tycho already mandates java 11, there will be no impact on while using with Tycho. Regarding the plexus-compiler plugin we need to specify ecj version specifically. With this requirement I envisage minimal impact in this case as well. Among these the impact will come only with using as command line. As most of the distributions already moved to java 11 as default java this impact is quite minimal.
(In reply to Sravan Kumar Lakkimsetti from comment #39) > Among these the impact will come only with using as command line. As most of > the distributions already moved to java 11 as default java this impact is > quite minimal. As java can be downloaded and run even without installation so even if this particular distribution does not offer J11 its still not a major blocker (and even on command line one can use a previous release).
Let declare this as fixed, after bug 574347 is resolved. Functional improvements that could be made for throwing out code that was needed for Java 8 runtime support should get own tickets.
Raised Bug 574671 - Move jdt.core.binaries to Java 11 for the remaining parts
Verified in I20210705-1800
A lot to follow here, but just as a recap to ensure I understand properly - JDT/ECJ both move to Java 11 as the minimum runtime in version 4.21 (which is to be released in September) - ECJ still supports previous compilation targets: Java 1.1 through 16 (and additionally 17 which is targeted for 4.21) Is the above correct? Thank you.
(In reply to Volodymyr Siedlecki from comment #44) > A lot to follow here, but just as a recap to ensure I understand properly > > - JDT/ECJ both move to Java 11 as the minimum runtime in version 4.21 (which > is to be released in September) > > - ECJ still supports previous compilation targets: Java 1.1 through 16 (and > additionally 17 which is targeted for 4.21) > > Is the above correct? Thank you. Mostly yes. Just that 4.21 itself won't have Java 17 support out of the box. One will have to install the Java 17 patch from here on top of 4.21: https://marketplace.eclipse.org/content/java-17-support-eclipse-2021-09-421
