-
I am beginning the process of updating and evaluating whether our RCP products can be updated to use Java 21. However, not all the other tools we (and QA) use support the handling of Java 21 class files. One of our QA tools may well be quite slow in getting to supporting Java 21, but we don't really want that to be a blocker to updating. I thought then that perhaps we can go down the route of running our products on Java 21 (we force the JRE used by our users for our products anyway), but compile for Java 17 classes which our other tools will happily be able to read. Within Eclipse I can:
And this works well within Eclipse and exported products running on Java 21. However, when running Maven with Java 21, the following example code won't compile with Tycho (4.0.6):
I've update the Pom (maven.compiler.* properties) files with various combinations of Is this even possible? I was hoping to get further than just updating the installed JDK and temporarily adding |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
These are two contradictory settings (even though it theoretically works) as you say your bundle requires Java 21 bytecode but you compile to Java 17 ... You can run any BREE 17 bundle on Java 21 so why enforce it if you want be compatible with Java 17? So at a first sight there is some chance to confuse the tools by giving different configurations, so what benefit do you expect from requiring Java 21 as BREE? Technically without special configuration, Tycho (4.0.6) is not able to compile Java 21 you need at least use ECJ 3.37 but the error you are seeing here is most likely because the
I must confess that it works in the IDE seems like a bug to me, even though its hard to tell without the exact configuration, but if you really have a |
Beta Was this translation helpful? Give feedback.
-
Fair enough, I've left those alone, and indeed I now get Java 17 classes from Tycho when building using Java 21 without errors or warnings generated by Maven.
Hmm, well it does seem to be. Comparing the bytes in the classes generated by Eclipse before and after a change to a Java 21 API, both have "3D" in the version byte. Perhaps this is really more an issue for the Problems view in Eclipse not picking up the fact we're running "--release 17", i.e.: We don't care as we're targeting Java 17, so it's an unnecessary warning really. |
Beta Was this translation helpful? Give feedback.
These are two contradictory settings (even though it theoretically works) as you say your bundle requires Java 21 bytecode but you compile to Java 17 ... You can run any BREE 17 bundle on Java 21 so why enforce it if you want be compatible with Java 17?
So at a first sight there is some chance to confuse the tools by giving different configurations, so what benefit do you expect from requiring Java 21 as BREE?
Technically without special configuration, Tych…