search

bndtools / bnd

Bnd/Bndtools. Tooling to build OSGi bundles including Eclipse, Maven, and Gradle plugins.
https://bndtools.org
Other
531 stars 304 forks source link

OSGi Java 9 support: Importing java.* packages #2507

Closed bjhargrave closed 4 years ago

bjhargrave commented 6 years ago

When building a Java 9 bundle, Bnd needs to import java.* packages.

bjhargrave commented 6 years ago

In OSGi Core R7, it mandates the framework export all java.* packages, so a bundle can safely import them. So in Bnd, we can build a bundle which imports java.* packages. But when it is safe to do that?

If the bundle imports org.osgi.framework;version=[1.9,2.0), then it is safe to import java.*.

If the bundle requires osgi.ee=Java SE 9, it may or may not be safe. Some R6 framework implementations have been taught to work on Java 9 (e.g. Eclipse Oxygen). So just because a bundle contains Java 9 class files, and thus requires Java 9, does not necessarily mean the bundle should import java.* packages. For this case, I propose the following:

Comments @bndtools/bnd-hackers, @njbartlett ?

timothyjward commented 6 years ago

I think that this set of rules may be too weak. It is reasonably common for implementation bundles not to need the core framework on the build path. For example if I use Declarative Services I can normally avoid the OSGi framework API completely.

I think I would be comfortable with putting the java.* imports in automatically if you have osgi.ee=Java SE 9, with an option to disable it if you want. If others disagree then I would still want us to have a threshold (say Java 10 or 11) where we start automatically including the java.* packages, otherwise we end up forcing an annoying bnd file into all of the implementation projects to do

Import-Package: java.*,*

when in reality that should be covered by the existing default *

bjhargrave commented 6 years ago

Well I propose Import-Package: java.*,* to avoid defining -yet-another-bnd-instruction to mean the same thing.

I can see the rule of osgi.ee=Java 10+ as useful too. This would only leave Java 9 as the odd-ball case.

Another choice is that we just leave Java 9 alone since it is already out of service.

So then you would get automatic imports of java.* package if either of these happens:

This would work well I think.

timothyjward commented 6 years ago

Another trigger I've just thought of - if your bundle makes use of the multi-release jar support then we should do it in the Java 9+ manifests (as R6 doesn't support MR Jars).

bjhargrave commented 6 years ago

Well MR jar support is R7 only, so that also be a trigger. But MR jar support will come after this issue.

I am now also thinking we will need to add a -nojavaimport=true instruction to disable importing java.* packages for project still using R6 frameworks but building code for Java 10+ (I am looking at you Open Liberty :-).

timothyjward commented 6 years ago

I am not also thinking we will need to add a -nojavaimport=true instruction to disable importing java.* packages for project still using R6 frameworks but building code for Java 10+ (I am looking at you Open Liberty :-).

Also Eclipse Oxygen will be around for a while yet, and I'm pretty sure that supports Java 10 development.

bjhargrave commented 6 years ago

So we seem to be converging on some triggers to turn on import of java. packages (import framework 1.9+, have class files for Java 10+) and an instruction to turn off import of java. packages if the triggers apply to you but you can't handle import of java.* packages.

timothyjward commented 6 years ago

So in the absence of the build path trigger I think this roughly equates to having the default for -nojavaimport be true on Java <= 9 and false on Java >= 10.

Would it therefore make sense to "turn on" java.* package imports on Java <=9 by setting -nojavaimport: false rather than Import-Package: java.*,*?

bjhargrave commented 6 years ago

Would it therefore make sense to "turn on" java.* package imports on Java <=9 by setting -nojavaimport: false rather than Import-Package: java.*,*?

No. You cannot turn it on manually. It is turned on only by the triggers but can be disabled by the -no instruction. We have many -no instruction which only disable things automatically done (like osgi.ee requirements can be disabled with -noee=true.)

timothyjward commented 6 years ago

No. You cannot turn it on manually.

Ok - we will need to doc this carefully!

njbartlett commented 6 years ago

I agree with the general conclusion that has been reached in this thread. However I think that the boundary version for triggering java. imports should be Java 11, not Java 10. Java 10 is the current Java version and is being used by some OSGi developers now... if we turn on java. imports for all bundles requiring Java 10 then it will break some current builds that use a pre-R7 Framework.

Java 11 is the first LTS version of Java after version 8. Most organisations I speak to are deferring any work on Java upgrade until 11. That would be a good time to make the switch IMHO.

Questions:

  1. If I want to turn on java. package imports for a whole project, can I set `Import-Package: java., *` in the top-level bnd instructions in a parent pom.xml?
  2. If a child module has a bnd.bnd with customised imports, it will have to be updated to use Import-Package: foobar; resolution:=optional, java.*, * instead of current Import-Package: foobar; resolution:=optional, *. Can we use merged properties, e.g. Import-Package.extra: foobar; resolution:=optional ??

Neil

On Fri, Sep 14, 2018 at 4:16 PM Tim Ward notifications@github.com wrote:

No. You cannot turn it on manually.

Ok - we will need to doc this carefully!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bndtools/bnd/issues/2507#issuecomment-421391627, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAY3tY3oXYtCJw2SExIt86OCqDfpHudks5ua8higaJpZM4U76kC .