[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tycho-dev] Prefer currently running Java as ExecutionEnvironment version instead of BREE ?
|
I think that things are interleaved a bit here for convenience that are
a good guess but not always the same.
===== Bundle Execution Environment + Class Comptibility =====
1) First of all, the Bundle Execution Environment of a _Bundle_ was
solely introduced because OSGi does not allows to import packages from
the java.* namespace but wanted to express what java packages it needs.
2) Then there is the source/target level of compiled classes that could
but does not requires to match the Bundles-EE.
3) And there is the JDK/JRE a class is compiled against.
4) Even without OSGi, it is possible to compile with JDK 8 a class with
source-level JDK 6 that fails on a true Java 6!
So the only way to ensure a class can really be executed on (and is not
only binary compatible) is and was to have a true jdk to compile
against. At least the Eclipse-Compiler support having different JRE
installations configured for a given JRE System-libary for this purpose.
===== javax.* and alike =====
It always was and is an error to not import so called "java extension
packages" (that is everything except java.*) and from java 9 on even
these java.* packages should be imported, sad enough PDE has a long
standing unresolved bug and does not support this, and eclipse still has
this "compatibility-classloading" as its default mode.
So it is a complete Eclipse-Specific extension that bundles not
importing the package has ever worked. Weather or not this import could
be resolved against the target is just a matter of the target (see below).
===== What should be exposed to the build =====
1) What JRE to use? If nothing is specified the build JRE must be used,
if a JRE is specfied by either a concrete jre[1] or a execution env
[2]) there must actually be an alternative JRE be configured somewhere
(don't know if tycho supports this)
2) The packages of the chosen JRE must then be determined and exposed as
implicitly be available for resolution
3) now the desired target (I assume there is only one for not make
things more complex as required) must be resolved to get a list of all
packages explicitly exposed by target bundles.
3) If a bundle specifies an EE, the profile for this must be loaded and
all packages must be resolved against the target (implicit jre packages
and explicit target bundle packages)
3*) Special case: in fact a bundle can configure a different JRE System
Library in its .classpath file!
4) Then we have two possible outcomes:
4a) not all packages could be resolved --> The EE cannot resolve against
the current target -> the bundle can't be resolved/compiled/...
4b) all packages can be resolved and we can now proceed to resolve the
bundles other requirements
I hope my explanation was not to confusing, the key-point is that an EE
itself must be resolved against the target that is constituted of a JRE
and a set of extra packages.
[1]
org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/zulu11.37.19-ca-fx-jdk11.0.6-linux_x64
for example
[2]
org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-11
for example
Am 10.07.20 um 18:25 schrieb Mickael Istria:
Hi all,
We're having a lot of fun with target platform resolution and execution
environments lately. I'm confident we're doing a great job that will
result in way less confusion for users and for maintainers in Tycho, and
in easier adoption of .target, pom-less and newer Java versions.
However, there is still 1 big topic, which I'd like to discuss here
before we change the behavior, as it's not really backward compatible:
Up to now, the BREE is used to derive the execution environment if not
overridden explicitly somewhere else.
The reason behind it seems to be solely that the EE used to be consumed
in order to derive the compiler source/target levels; so passing a newer
EE to a bundle resulted in compiling classes that weren't compatible
with its BREE. That was a clear bug, and it was fixed recently: the BREE
is used by the compiler to decide on the source/target levels
independently of the "resolution" EE.
But this EE derived from BREE can cause issues in simple cases: imagine
there is a bundle with BREE=JavaSE-1.8 and requiring the
javax.annotation package, the environment only has Java 11
(javax.annotation not included). Tycho currently resolves the
javax.annotation package as being part of JavaSE-1.8 and does *not* add
it to the target definition (which is later used as classpath). As a
result, resolution succeeds, but compilation and test will fail later
complaining that javax.annotation package is not found.
This is IMO a bug.
My proposal is that we simply abandon anything that reads the BREE to
derive an EE, and in case no hint about EE is given anywhere, Tycho
should use the current Java runtime as EE.
What do you think? Any strong opinion against that?
--
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
_______________________________________________
tycho-dev mailing list
tycho-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tycho-dev
