The first release candidate for bnd 7.0.0 has been released! This is the first release on Java 17.
This work was normally done by BJ but thankfully he left a good Release Description. Let me know if there is anything out of the ordinary.
2 Likes
Questions regarding “Supports Multi release JARs”.
-
Is it possible to add a short summary of what to expect? (or link the related PRs / issues in the changes section? I remember this was a heavily discussed topic.)
-
In the past we were using the following regarding some issues with MRJ:
-fixupmessages "Classes found in the wrong directory"; restrict:=error; is:=info
Is this something which is addressed with this? Could these fixup messages be removed one day with this work?
The RC1 works fine for me so far! 
Maybe it is also possible for PR #5773 to be added to the final release? 
1 Like
I will cherry pick it.
1 Like
The Multi release jars are now fully supported.
They work in the build as normal Jars since the root of the MRJ must be the public API, i.e. the versions directories are not allowed to add API. During the build they are (and were) more or less transparent. Since the MRJs can create specific requirements based on the VM version it runs on, which I consider not the smartest idea I’ve encountered, we needed a way to handle this in the resolver.
The discussion was about how to encode the MRJs in the resource model. This is (or should be) invisible for normal users. There is still a PR out with a second type of encoding but is is not yet switchable from the workspace yet.
We now ignore during analysis class files in the META-INF/versions directory so the warning should no longer be there.
1 Like
I can confirm this. Great
Thanks for the RC
Is Slow typing in "Add Bundle Requirement" dialog in Eclipse plugins · Issue #5699 · bndtools/bnd · GitHub included in this RC? Typing into the filter of the “Add Bundle Requirement” dialog still feels very sluggish.
It was a quick fix, there was a speedup available. But it should be in.
How many resources do you have loaded?
How do you find out that number?
In my case it feels fast.
We have:
- 60 local projects / bundles
- 280 revisions from central.maven (MavenBndRepository)
Something I noticed:
- When I have no .bndrun file opened, Eclipse’s CPU Usage is around 6%
- When I open a .bndrun file it goes up a little bit to around 8% (but I think the first time I noticed a short spike)
- But when I just open the “Add Bundle Requirements” dialog, CPU goes up to 30% ± (I would say stays around between 20-30% all the time, until I close the dialog)
Searching in this dialog does not make a difference in terms of CPU. It stays around the same.
Not sure if this is related or helpful.
I do not think this is related to the UI bug.
I did some forensics and noticed the refresh is called a lot. It turned out with almost any action, we refresh the whole workspace. This is a very expensive actions. Additionally, we had no optimization of the list of bundles did not change.
I made a PR to see if we can fix this.
1 Like
I counted the number of entries on the first page of the dialog and then used page-down to go through the rest, multiplying the number of pages with the number of entries on the first page.
That yields approx 1400 top-level entries in the tree, each of which may have multiple versions under it.
When I expand all items, I reach approx 3300 entries (top-level + version children).
Btw, the tree always shows Bundles and non-bundles (with an exclamation mark). It would be nice to be able to turn off the displaying of non-bundles - maybe even have them turned off by default.
Wow. You really need all of those? I don’t think i could sleep if I had a workspace with that many dependencies
Could you try the current snapshot? We were massively refreshing the workspace for this dialog and with thousands of dependencies I expect you will notice it.
If not,there is not much more we can do. We now use the standard solution for large lists.
About the filtering non-bundles, I’d always wanted to have a filter in this dialog like in the Repositories view. it would be easy to add :b for only bundles, like in the Bndtools explorer. However, though I like the idea, it is not high on my list and I’ve got lots of other things to do.
Could you please remind me if there is an update site for the current snapshot?
| Latest stable release | https://bndtools.jfrog.io/bndtools/update-latest |
|---|---|
| Latest release candidate | https://bndtools.jfrog.io/bndtools/update-rc |
| Latest build snapshot | https://bndtools.jfrog.io/bndtools/update-snapshot |
2 Likes
I have tried the latest snapshot. The search field remains slow with all these entries that I have. Interestingly, I do not see CPU time being spent in Java Threads when I watch my Eclipse using the VisualVM Sampling Profile while typing into the search field… I wonder if the filtering is delegated down to the native UI code layer in Eclipse… very strange.
Looks like I can no longer run BND Unit Tests in Eclipse if the project under test is Java 8 based:
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: aQute/launcher/pre/EmbeddedLauncher has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:419)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:352)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:601)
Note that in the respective run configuration, I have manually configured a Java 17 JDK.
Update: Changing the Java Library in the project from 8 to 17 also does not help… Eclipse itself is also running on Java 17.
Did you set your default VM to 17?
If yo mean which JDK is ticked in the Eclipse Preferences → Installed JREs, then yes. I’m not aware of another place to configure a default VM.
I still have this problem with
| Bndtools | 7.1.0.DEV-202309181444-g56772fd | bndtools.main.feature.feature.group | Bndtools |
|---|---|---|---|
| Bndtools m2e | 7.1.0.DEV-202309181444-g56772fd | bndtools.m2e.feature.feature.group | Bndtools |
| Bndtools PDE | 7.1.0.DEV-202309181444-g56772fd | bndtools.pde.feature.feature.group | Bndtools |
Basically, I cannot run tests because I get the java.lang.UnsupportedClassVersionError - is there any fix?
P.S.: I downgraded to BND 6.4.0 Eclipse Plugins now - now I can again run tests…
Maybe you can check if java -version on the command line shows that Java 17 is used by default?
$ java -version
openjdk version "17.0.8.1" 2023-08-24
OpenJDK Runtime Environment Temurin-17.0.8.1+1 (build 17.0.8.1+1)
OpenJDK 64-Bit Server VM Temurin-17.0.8.1+1 (build 17.0.8.1+1, mixed mode, sharing)
You can also check what Eclipse is using in Help -> About Eclipse IDE -> Installation Details -> Configuration:
