Revert removal of JRE-1.1 execution environment profile and add its system-packages #596
Conversation
This reverts commit dee9f0f.
The packages are read from ancient Java-1.1 JREs. Fixes eclipse-equinox#571 Part of eclipse-pde/eclipse.pde#1231
There was a problem hiding this comment.
In the end adding the JRE-1.1 is the simple thing to do. But I really wish PDE and others could somehow just use the "next best" EE when the one requested isn't available. After all the JavaSE-1.2 profile claims to provide:
osgi.ee; osgi.ee="JRE"; version:List<Version>="1.0, 1.1"
It would probably be possible somehow. But for now I agree that reverting is the simplest thing to do. |
This reverts commit 0cd092a because corresponding equinox change was reverted. See discussion on eclipse-equinox/equinox#571 See eclipse-pde/eclipse.pde#1231 See eclipse-equinox/equinox#596
This reverts commit 0cd092a because corresponding equinox change was reverted. See discussion on eclipse-equinox/equinox#571 See eclipse-pde/eclipse.pde#1231 See eclipse-equinox/equinox#596
I disagree it would be great :) One thing that concerns me with the "support" objectives of PDE and other tools is I don't think there is a possibility to use Java 21 to compile down to Java 1.1. In fact, I would not be surprised if Java 11 doesn't let you compile to Java 1.1. Even ECJ will be dropping the ability to compile to really old Java versions. With these kinds of support conflicts it is hard for me to sympathize with scenarios where some project/product has a build with a set of bundles where the build infrastructure wants to keep building the exact same bundle, over and over, with no code modifications what so ever and they want to be able to continually update their tooling versions to keep building that bundle (targeting Java 1.1) over and over. I fail to sympathize with the desire to keep building a bundle that doesn't change, ever, while also desiring to keep up to date with the very latest Eclipse release to build such a bundle. If the bundle does change, then surely the maintainers of the project/product would want to at least compile down to a version of Java that still has support in some context. If the bundle never changes, then what is the reason it has to keep being built, over and over, just to produce the exact same artifact? |
|
I’m not asking for sympathy. If you want some background about one specific case, this is one such case |
I saw that, but I do not understand why we need to keep building that particular bundle if it will never have real source code changes. |
|
I could change it and will do that if/when the signature expires. There has never been any suggestion that something was wrong, bad, or otherwise. Also, projects depend on really old maven crap and those might contain such things or when wrapped by bnd might produce such things. I’d rather such old crap were not used. It would make my life easier. |
|
@tjwatson that's why I initially though it is "safe" to remove but in the end its just a random text file that literally never changes so any more effort here seems wasted time compared to the rumors this has already produced. |
At least what I can say from the top of my head in PDE the main 'issue' is that the EEs provided in the PDE TP state and their system packages are the ExecutionEnvironment defined by JDT, which get the system-packages from the embedded Equinox profiles. So it is possible just (probably) needs more planning/investigations. |
With [1] the JRE-1.1 profile embedded in Equinox was updated to have the expected system-packages. Therefore the hard-coded ones in PDE can be removed. [1] - eclipse-equinox/equinox#596
|
I already mentioned it in the past that I think the behavior of PDE is wrong in this regard. It is matching each (target) bundle against the exact matching profile this does not happens in a runtime and therefore produces all this kind of strange errors sometimes. Instead PDE should use the target platforms EE as this is what is "targeting" and will be used at runtime, especially for bundles from the target platform the user can't influence the EE anyways in any other way. |
|
It seems to me that each project is bound to a JRE too and when it doubt, that would be used instead. Also, looking closely here, I'm surprised that the information jar produced by Tycho is not really what I would expect based on the BREE in the MANIFEST.MF:
In any case, note that the source MANIFEST.MF makes no mention on JRE 1.1. That detail is produced elsewhere. |
With [1] the JRE-1.1 profile embedded in Equinox was updated to have the expected system-packages. Therefore the hard-coded ones in PDE can be removed. [1] - eclipse-equinox/equinox#596
The fundamental problem here is that a workspace is not the runtime and the eventual runtime JVM is not known with certainty. Furthermore bundles in the TP are different from the one in the workspace. But no solution for that problem and there are always possibilities for false positive or negative errors. But we have discussed that in length in eclipse-pde/eclipse.pde#429 and I actually don't want to start that discussion again. The solution chosen there is in my onion a good trade-off. Nevertheless this issue in combination of the discussed removal of support for ancient java version made we wonder if these EEs should be removed from JDT, which would in the end also allow to remove the profiles from Equinox when PDE is adapted: |
This reverts #572 and instead instead adds the system-packages for the JRE-1.1 execution environment profile that where derived from ancient Java-1.1 JREs as described in eclipse-pde/eclipse.pde#693 (comment).
Fixes #571
Part of eclipse-pde/eclipse.pde#1231 (fixing that completely requires the reversion of eclipse-jdt/eclipse.jdt.debug#425)
Once this is merged, we can remove the hard-coded system-packages from PDE:
https://github.com/eclipse-pde/eclipse.pde/blob/860100e5b0d57bca42cbe26078ea5c3093828c60/build/org.eclipse.pde.build/src/org/eclipse/pde/internal/build/site/PDEState.java#L580-L603