You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: