-
-
Notifications
You must be signed in to change notification settings - Fork 305
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OSGi Java 9 support: Multi-release JAR #2227
Comments
Some more detail on what "support" for multi release jars would look like in OSGi is needed here. Bnd could certain stop objecting to classes in This topic was discussed in a recent OSGi expert group call and the OSGi "way" here would be to use a fragment to supply the types for a java version with the host bundle carving out a space in the Bundle-Classpath. But if Bnd is being fed a |
Also, if classes in |
How do JPMS modules and multi-release jars interact? I assume they are mutually exclusive since JPMS modules would have the same issues with varying requires/exports depending upon the runtime version of Java. Yes, this is not a practical issue yet for JPMS since it is only Java 9 for now. But with Java 10, then what? |
Unfortunately the version-specific part under |
You can have |
We don't need a fragment for pre-Java 9 code. The host bundle would have all the pre-9 code and |
Okay nice idea with |
Hmm, so bnd could put different manifests under META-INF/versions and the framework would pick a manifest at runtime? (sigh)
|
The problem with the bundle classpath is that it needs to be conditional. So you would need an entry for each existing java version. |
Yes I think that might need to be the way forward... runtime support for fragments nested inside a bundle. That way projects like log4j can just release a single JAR, which is what they want to do. |
No. There will be multiple fragments which only resolve for the specific java version. |
But they need to override each other. |
I think there are many issues here. Like how does Bundle.getEntry/getEntries treat this? |
No. At most one of the fragments is attached and it supplies classes in the versioned folder. |
So you would duplicate all classes from the other versions that are not overriden in this version in each fragment in the chain? |
Could we add some new "effective"-ness' which map to Java version X?
Import-Package: \
com.foo,\
com.bar;effective=resolve-java9
Plus the Bundle-ClassPath?
…On Wed, Dec 6, 2017 at 6:09 PM, BJ Hargrave ***@***.***> wrote:
You can have module-info.class under META-INF/versions. So you could have
entirely different dependencies for Java 9, 10, etc.
Hmm, so bnd could put different manifests under META-INF/versions and the
framework would pick a manifest at runtime? (sigh)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2227 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAI9TKR4CisE1GdlTDIRmODvyhf5jsqbks5s9x6ngaJpZM4Q4tuA>
.
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
|
the thing is you can have: /A.class |
Why would you need to do that? Does multi release jars stack up all the versions? So that on Java 11, you search 11, then 10, then 9, then the base jar for a class? |
Yes |
That is in insane design. Good luck building such a jar and keeping it operational in all the versions of java... And how do you build all the module-infos for all these versions of java (if you use JPMS)? |
At least that is what I think http://openjdk.java.net/jeps/238 is saying |
So i would say yes, they stack. |
I think the structure would look like this:
A smaller problem is that the fragment for Java 9 would resolve on Java 10 because EEs include every previous EE. We would have to express a dependency on the EE of "exactly Java 9". |
Part of me wonders if the solution is to really make them fragments inside the bundle. I.e., if a dir on the bundle-classpath has a META-INF/MANIFEST.mf we should just handle it like a fragment. |
No, I think we want exactely that. |
Bundle-Classpath: META-INF/versions/10,META-INF/versions/9,. and then what you just proposed as layout. |
I think we need to stop fixing this in this bug. This is sounding more than Bnd can address alone. Changes are need in the Core spec to address this. And then Bnd can support the Core changes. |
This is what I told David last week and what made him bring it up in your call (and because I had the feeling that wasn't the conclusion of the call I pinged Neil about it today :-) |
Yes I think this works, and bnd can generate that. It becomes tricky when the user wants to use Agree with BJ that bnd should follow CPEG. |
Just want to let you know that I started adding MultiRelese support similar to @rotty3000 idea see but going a step further:
Based on this, it would be possible to have a "release" flag on the analyzer set, that then analyzes the jar as it would be viewed for the given release (everything else will be hidden, including the versions folder) one can e.g. pass in the BND file, or e.g. like it is done by the maven-compile plugin, put together one multi-release jar (this would then require one invocation for each declared release compiled). This is of course just a first step, but that way one not needs to make everything aware of the multirelease in BND (e.g. a AnalyzerPlugin will not notice anything here). |
Setting a If we ignore the layout issues (e.g. how I get stuff into
in the bnd file. This has the advantage of matching the normal Java header, and being minimal effort for the "happy path" scenario. The things to clear up would then be stuff like:
|
I don't think that's really "true" as e.g. BND delegates to bnd instructions of the "parent" already, so there could also be one bnd file == no bundle or even one bnd file = many bundles (if I use the same for many bundles)...
But what if I don't want a multi-release jar? I just want a single manifest but for java 11 as a target release. I think this is a conceptual misunderstanding that a user want to build some Multi-Release stuff at all. Still I want BND to discover the same things that java would discover at runtime that is https://docs.oracle.com/javase/9/docs/api/java/util/jar/JarFile.html#getJarEntry-java.lang.String- So the very first goal (for me) would be that BND could correctly handle Jars like they would be handled in a real executed JVM run, generatinga MR-Bundle is just the second step.
Now I'm confused, didn't you just said one bnd file == one bundle ;-) |
This really isn't the case. You may be misunderstanding things if you have only ever used the
If this is what you want then bnd does not need to change because you're not using multi-release. To get this result don't have a
Seriously? I'm trying to help you here. It is important not to pre-judge the outcome of the discussions about how we do this. I'm open to some pretty significant changes to make this work, including having subsidiary bnd files, but the changes need to make sense and they need to be discussed more widely. |
The
You mean, it does not work ... whenever I use a MR-bundle as a dependency BND will currently not read it correctly (e.g see #5327) and if the dependency contains different packages annotations on the versioned classes variants, or even contains additional classes, BND will not work correctly.
I'm just pointing out that previously you said multiple BND files "seem bad" and then you say we better should use a alternative approach that might require multiple bnd files :-)
At least allow using multiple BND instructions (you are not forced to use them, see previous example where my bundle itself is not MR-Jar) does not limit anything here and you seem to indicate that this is even a speific thing of the bnd-maven-plugin, so why I should it be forbidden to do so, especially when one talks about the
All this does not introduce anything "new" and it is not forbidden right now, so I really curious why this should "not make sense", given that the
That's why I think BND needs a |
@pkriens Could you please post a reference to the commit that introduced the fix? |
@jonatan-ivanov the current bnd snapshots contain the handling of MRJs. |
@laeubi I think you are ignoring the all important fact that MRJs mandate that an MRJ must not cause public API differences when run on different VM releases. (This is the main reason why I think MRJs are such a stupid idea; they require this humongous restriction to not fall flat on your face but they have not even the tiniest mechanisms in place to enforce this immense constraint. Ergo, another sun.misc they can fix in Java 42)
No public API changes implies that the only differences that running on different releases can cause are the runtime dependencies. Ergo, bnd should be able to read the public API for any supported version and then the base release is sufficient. This is what we do today. The spec also says:
I do not think we should try to guess what they're going to do in Java 42 ... Tends to end up badly. |
I'm not sure this answers my question. I did not ask if bnd supports it or not, I asked if you could post a reference to the commit/PR that introduced the fix. Like this one? #5346 |
This were the primary commits
|
and update to a newer version of bnd for multi-release jar support, see bndtools/bnd#2227.
I know this is an old issue, but i read this thread and the felix issue tracker, but cannot find if this is or isn't fixed in the maven bundle plugin. I ran into this when upgrading to Jersey 3.1.7, which is a multi release jar now. |
At least the release notes of bnd version 7.0.0. mention "Supports Multi release JARs" @paulrutter Don't know how this behaves with other plugins you mention in your question. |
You need felix-plugin with latest bnd if felix has not yet updated there is quite a good chance you can simply add bnd-7 to the dependency section of the plugin. Beside that |
Thanks, would just adding the dependency be enough or do i need additional instructions? |
If you don't build a MR jar no additional instructions are required. |
Thanks, i will try it out and file an issue to the felix issue tracker to get bnd upgraded in the maven bundle plugin if it works. EDIT Adding this to the maven-bundle-plugin section indeed solves the build issue with consuming MR jars as compile dependency of the OSGi bundle.
I will file a PR for the felix project to get it upgraded, although it will be a breaking change due to the java 17 requirement. |
This issue was raised against Felix (maven-bundle-plugin) but it needs to be addressed in bnd: https://issues.apache.org/jira/browse/FELIX-5592
The text was updated successfully, but these errors were encountered: