OSGi Java 9 support: Importing java.* packages

[bjhargrave]

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

[bjhargrave]

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:

• If the Import-Package statement explicitly mentions java.* packages (e.g. Import-Package: java.*, *), then Bnd will generate imports for any referenced java.* packages.
• If the org.osgi.framework.package-info class is on the -buildpath, and its @Version annotation is version 1.9 or higher, then Bnd will generate imports for any referenced java.* packages. (This option basically includes the case where then bundle imports org.osgi.framework;version=[1.9,2.0) since that is the version of the org.osgi.framework package the bundle is being built against.)

Comments @bndtools/bnd-hackers, @njbartlett ?

[timothyjward]

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]

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:

• the bundle imports org.osgi.framework version 1.9+
• the bundle requires osgi.ee Java SE 10+

This would work well I think.

[timothyjward]

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]

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]

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]

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]

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]

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]

No. You cannot turn it on manually.

Ok - we will need to doc this carefully!

[njbartlett]

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 ***@***.***> 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 <#2507 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAY3tY3oXYtCJw2SExIt86OCqDfpHudks5ua8higaJpZM4U76kC> .