[bndlib] Private references warning

[kriegfrj]

Has anyone else seen this warning?

warning: Export aQute.bnd.build,  has 1,  private references [aQute.libg.command]

Seems a bit odd - I can't figure out how that package has that reference?

[kriegfrj]

Sorry, should have said this happens during the build of the Bndtools workspace.

[chrisrueger]

Maybe related to this somehow? 6c0759e#diff-466b9847665ae417cb9470404a7672bdeb39d2404d8e0cc6df9ed8dba7104867R56-L74 as part of #6471

[kriegfrj]

Yes, that would do it.

Hmm, this is usually a problem. In ordinary circumstances it would make the feature impossible to use as the Command class (which is in the public API) won't be accessible outside of the bundle, so whoever (outside of the bundle) tries to load the ProjectLauncher class will get a NoClassDefFoundError. Classes in aQute.libg are usually not meant to be exposed in the public API of the bundle for this reason.

I think the reason we've gotten away with it so far is because ProjectLauncher is part of the infrastructure that is responsible for launching the OSGi framework - so it is normally running outside the context of the framework and its package visibility restrictions. But if anyone for whatever reason tried to use the ProjectLauncher from within a running framework, they would likely get a NCDFE.

Possible solutions:

• bndlib exports aQute.libg.command.
• ProjectLauncher goes in its own package (maybe even its own bundle?) that is not exported, to make it clear that it is not supposed to be used from within a framework.

Another issue is how this warning went unnoticed and unattended. We should consider using -fixupmessages to make "private references" warnings into errors so that they are a bit more noticeable.

[chrisrueger]

We should include @laeubi in the discussion who needed 6c0759e#diff-466b9847665ae417cb9470404a7672bdeb39d2404d8e0cc6df9ed8dba7104867R56-L74

[laeubi]

Whatever issue is there, it was there before as no "new" code was added. The difference is that now there is a public method and that's why bnd complains (what is kind of correct) but the launcher is/was not used that way as it seems.

This is similar to

• biz.aQute.launcher imports "impossible" packages #6476

[kriegfrj]

Whatever issue is there, it was there before as no "new" code was added. The difference is that now there is a public method and that's why bnd complains (what is kind of correct)

This is an important difference. It means that whereas Command was before previously an implementation detail (hidden from users of ProjectLauncher), now it is part of the public API of ProjectLauncher. All of the public API classes must be visible to users of the class or else users of the class in an OSGi context won't be able to load the class. This is the reason Bnd complains (and it's a good reason).

but the launcher is/was not used that way as it seems.

Well, to be fair, it seems that the Bnd workspace and none of its bleeding edge users use it that way - but what about out in the wild? This would be a backward-incompatible change the way it currently stands, the polite thing to do would be to make it backward-compatible somehow.

@pkriens , do you have a feel for this?

[laeubi]

I don't get what "backward compatible" you have in mind, the method was previously not there so no code can ever have referenced it, so any "old" code will never be affected.

If "in the wild" the code would have been executed before, and the bundle never imported that package, it would have lead to a CNF exception, the same way as it is now (just in case), so this is also completely "compatible" even if not maybe desirable.

Apart from that it won't hurt to import aQute.libg.command (maybe with optional).

[kriegfrj]

I don't get what "backward compatible" you have in mind, the method was previously not there so no code can ever have referenced it, so any "old" code will never be affected.

If "in the wild" the code would have been executed before, and the bundle never imported that package, it would have lead to a CNF exception, the same way as it is now (just in case), so this is also completely "compatible" even if not maybe desirable.

I'm sorry, I think you're mistaken. It wouldn't have caused a CNFE before, because Command was not part of the public API before but it is now, and now it will. That's what the Bnd warning means. This warning didn't happen before, and now it does because Command is now in the method signature of a public method whereas before it was simply in a local variable.

The fact that it wouldn't cause a CNFE before and now it will is what I mean about it not being backward compatible.

[laeubi]

The fact that it wouldn't cause a CNFE before and now it will is what I mean about it not being backward compatible.

Can you please proof this by an example project? A CNF exception will be thrown regardless of being used in a "public" API.

The warning only tells that no one will ever be able to use the return value (when running in OSGi), because the package is not exposed/imported so there will be a classspace incompatibility.

[kriegfrj]

Hmm, maybe you're right... I'll try and experiment tomorrow.