Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove Execution environments for unsupported Java versions? #433

Open
HannesWell opened this issue Apr 17, 2024 · 0 comments
Open

Remove Execution environments for unsupported Java versions? #433

HannesWell opened this issue Apr 17, 2024 · 0 comments

Comments

@HannesWell
Copy link
Contributor

HannesWell commented Apr 17, 2024

The recent discussion on the mailing list (or in eclipse-jdt/eclipse.jdt.core#820) about dropping support for ancient java version (it was discussed to drop everything below 1.6) as well the attempt to remove the JRE-1.1 profile from Equinox (eclipse-equinox/equinox#572 and eclipse-equinox/equinox#596) made we wonder if in JDT Debug Execution environments corresponding to unsupported Java versions should be removed as well as it was attempted for #425?

If JDT can't compile byte code down to a version is there then any point in being able to launch which such an EE (given the executing JRE is really of that version and not just a later one)?
The only scenario I can think of where this could still work is one launches an EE of an unsupported java version using only existing, or otherwise compiled jars. But one could still do that by selecting the corresponding ancient JRE for a launch.
At the same time the list of EE grows by two each year and it would maybe be good to prune it from time to time?

In PDE this would require a few adjustments to avoid issues like eclipse-pde/eclipse.pde#1231 because currently PDE supplies the EE defined by JDT as OSGi EE in its state to resolve the bundles in the target-platform. Because existing bundles that requires such ancient EEs exist and should continue to resolve as jars in the TP (they are even used in the SDK) PDE effectivly should maintain a list of such ancient EEs. Along with the EE only the most important system-properties would then be hard-coded in PDE. In that case it would probably be sufficient to assume the same system-packages as the lowest supported java-version for compiled bundles in the TP.
So PDE's would not to be a blocker for that, we would just need to know it, ideally in advance to make the transition smooth.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant