| Re: [epp-dev] Moving a package to Java 11 as requirement |
Mickael,
Keep in mind though that p2 will happily install something with a
higher BREE than the actual Java version being used by the IDE,
but those plugins will just fail to start.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=483383
Also this situation is trickier for the director application (and the Oomph p2 director task) where the running Java version is not related to the Java version that will be used in the target, which might not be known (e.g., in the director application). This will be further complicated if the JRE itself is available as an installable unit.
All this is to say that while you can ensure that the Rust
package consistently required Java 11, you can be sure that users
installing Corrosion elsewhere are likely to have problems with
the bundles not starting.
Regards,
Ed
Hi all,
Today I've faced a couple of issues where Java 8 is noticeable less productive that Java 11 and some of its sugar. I'm willing to start adopting Java 11 in some projects to write better code faster.The first "safe" example that comes to my mind is Corrosion.Let's imagine that a future (post-2020-03) release of Corrosion wants to switch to Java 11 as BREE, would it be fine for EPP to have the Rust package requiring Java 11 while others require Java 8? If not, what would be the possible alternatives that wouldn't block Corrosion from adopting Java 11?
Also, I'm curious, are there any other package maintainers out there who are eager to move to a newer Java as BREE?
Cheers,
--
_______________________________________________ epp-dev mailing list epp-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/epp-dev