Bugzilla – Full Text Bug Listing
| Summary: | Update JDT.core to Java 11 | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Lars Vogel <Lars.Vogel> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | carsten.hammer, christian.dietrich.opensource, Ed.Merks, jarthana, Lars.Vogel, loskutov, manoj.palat, sebastian.zarnekow |
| Version: | 4.18 | ||
| Target Milestone: | 4.21 M1 | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=566498 https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/172917 https://bugs.eclipse.org/bugs/show_bug.cgi?id=572389 |
||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 569069 | ||
|
Description
Lars Vogel
Jay, WDYT? Something for 4.19M1? @Christian: could you please give a feedback here regarding Xtext? How this will affect Xtext itself / Xtext ecosystem? @Lars: please send a similar question about possible JDT move to Java 11 to cross-project mailing list. Please note: JDT standalone Java compiler (ECJ) would be also affected and those who use it in the build process would implicitly need to move the build runtime to Java 11 too (even if target would be still Java 6). This can lead to many issues & lot of work. Do a little bit of expectation management: JEP 180 is only effective with very large maps that have a large number of hash collisions. Not sure if that is really necessary to improve the performance. In the past, it was already beneficial to move from the custom map implementations to java.util.HashMap to gain a lot. Also JEP 180 will be immediately effective if the runtime is Java 11. There won't be a need to change the BREE for *that* purpose. So I don't think the upgrade to Java 11 is related to the improvements. What I'm trying to say: If that is the *only* argument beyond "all the others are on Java11", I'm not sure it's a good reason to raise the BREE to Java11. (In reply to Andrey Loskutov from comment #2) > Please note: JDT standalone Java compiler (ECJ) would be also affected and > those who use it in the build process would implicitly need to move the > build runtime to Java 11 too (even if target would be still Java 6). This > can lead to many issues & lot of work. Yes, thanks for bringing it up, Andrey. I can straightaway say that not many people are going to like it and I am inclined against moving up. I am still fine with moving the tests bundles, though. New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/172917 I would also tend to avoid this unless there are compelling reasons. When I see a commit that changes on the BREE with nothing else to go with that, then I can't imaging the reason is compelling. Thanks for all the feedback. Lets move this to wontfix for now. (In reply to Lars Vogel from comment #7) > Thanks for all the feedback. Lets move this to wontfix for now. Why not update the test bundles as Jay suggested? Does not sound so bad for me and still preserves full backward compatibility on jdt.core itself, doesn't it? (In reply to Carsten Hammer from comment #8) > (In reply to Lars Vogel from comment #7) > > Thanks for all the feedback. Lets move this to wontfix for now. > > Why not update the test bundles as Jay suggested? > Does not sound so bad for me and still preserves full backward compatibility > on jdt.core itself, doesn't it? Not that I have a stake in this, but there's also the counter question: Why do that? "Does not sound too bad" is not exactly a ringing endorsement for doing something. Does there exist a very slightly good reason? (In reply to Ed Merks from comment #9) > Not that I have a stake in this, but there's also the counter question: > > Why do that? I can't think of a reason from an end user point of view. There was a time when, as a developer, I would want to code with latest language features. But then I came up with this (which is still not complete): [1] https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tree/org.eclipse.jdt.tests.latestBREE Bottom line, I am not particularly keen anymore. (In reply to Ed Merks from comment #9) > (In reply to Carsten Hammer from comment #8) > > (In reply to Lars Vogel from comment #7) > > > Thanks for all the feedback. Lets move this to wontfix for now. > > > > Why not update the test bundles as Jay suggested? > > Does not sound so bad for me and still preserves full backward compatibility > > on jdt.core itself, doesn't it? > > Not that I have a stake in this, but there's also the counter question: > > Why do that? > > "Does not sound too bad" is not exactly a ringing endorsement for doing > something. > Does there exist a very slightly good reason? I see two good reasons 1) use latest libraries and java versions to be able to write state of the art tests 2) use a realistically test scenario and stop using java versions behind its end of life for tests in gerrit and integration builds. You *have* to use the version of java your product is running with if you really want to make sure there are no issues. The first reason seems to be not important as Jay expressed no interest - core developers count here the most The second reason is still true imho. Theoretically you should have a copy of each test bundly for every long term release of java - that is Java 8, 11 and 14 at the time being. (In reply to Carsten Hammer from comment #11) > > I see two good reasons > > 1) use latest libraries and java versions to be able to write state of the > art tests So far I saw nothing in Java 11 API's that would be interesting for tests. > 2) use a realistically test scenario and stop using java versions behind its > end of life for tests in gerrit and integration builds. You *have* to use > the version of java your product is running with if you really want to make > sure there are no issues. I don't get this. Not sure you are aware of: we run tests on Java 11 since quite some time, this does *not* require to compile against Java 11. We also already run tests on Java 15, but this doesn't mean we will go to Java 15 in JDT any time soon. See https://download.eclipse.org/eclipse/downloads/drops4/I20201130-1800/testResults.php > The second reason is still true imho. Theoretically you should have a copy > of each test bundly for every long term release of java - that is Java 8, 11 > and 14 at the time being. I believe you mix runtime and compile time here. We do not need to have three copies of tests to run on Java X/Y/Z versions, as long as code compiled on X can run on Z. Sure, it would be cool to still run JDT tests on Java 8, but at some point in time we hit the limit on resources/time. That is where others contributions / 3rd party adopter tests are welcome. For the record: Verified for Eclipse Version: 2021-03 (4.19) M1 with Build id: I20210106-1800 [nothing to verify as this is just moving to verified -> wontfix] I think this was fixed somewhere else in 4.21. If you remember and care please mark as dup. |