search

eclipse-equinox / equinox

equinox
Eclipse Public License 2.0
31 stars 65 forks source link

Revert removal of JRE-1.1 execution environment profile and add its system-packages #596

Closed HannesWell closed 5 months ago

HannesWell commented 5 months ago

This reverts https://github.com/eclipse-equinox/equinox/pull/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 https://github.com/eclipse-pde/eclipse.pde/pull/693#issuecomment-1673903650.

Fixes https://github.com/eclipse-equinox/equinox/issues/571 Part of https://github.com/eclipse-pde/eclipse.pde/issues/1231 (fixing that completely requires the reversion of https://github.com/eclipse-jdt/eclipse.jdt.debug/pull/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

github-actions[bot] commented 5 months ago

Test Results

   78 files  ±0     78 suites  ±0   37m 25s :stopwatch: -14s 2 170 tests ±0  2 125 :white_check_mark: ±0   45 :zzz: ±0  0 :x: ±0  6 642 runs  ±0  6 505 :white_check_mark: ±0  137 :zzz: ±0  0 :x: ±0 

Results for commit f5ee3b81. ± Comparison against base commit 9fd42b02.

HannesWell commented 5 months ago

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.

It would probably be possible somehow. But for now I agree that reverting is the simplest thing to do. If someone has the time and interest to investigate it in depth and all details it can be removed again, which would be great.

tjwatson commented 5 months ago

If someone has the time and interest to investigate it in depth and all details it can be removed again, which would be great.

I disagree it would be great :) To me it seems to be a waste of precious resources.

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?

merks commented 5 months ago

I’m not asking for sympathy. If you want some background about one specific case, this is one such case

https://github.com/eclipse-pde/eclipse.pde/issues/1231#issuecomment-2056841517

tjwatson commented 5 months ago

I’m not asking for sympathy. If you want some background about one specific case, this is one such case

eclipse-pde/eclipse.pde#1231 (comment)

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.

merks commented 5 months ago

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.

laeubi commented 5 months ago

@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.

HannesWell commented 5 months ago

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.

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. If JDT removes some of the EEs in the future that mechanism has to be changed in PDE to be the JDT-EEs plus the ancient EE that are still required in some old existing manifests. We then probably have hard-code the system-packages in PDE (again).

So it is possible just (probably) needs more planning/investigations. But since only bundles in the TP can then require the removed EEs it is probably save to just reuse the system-packages of the next supported EE and only maintain a map of EE name to Java-Version.

laeubi commented 5 months ago

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.

merks commented 5 months ago

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:

image

In any case, note that the source MANIFEST.MF makes no mention on JRE 1.1. That detail is produced elsewhere.

HannesWell commented 5 months ago

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.

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 https://github.com/eclipse-pde/eclipse.pde/issues/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: