When does the Bundle task consider a private reference to have been "exported"?

[Chris Rankin]

Hi,

So I've been dutifully fixing the warnings from the Bundle task:

warning: Export a.b.blob,  has 2,  private references [a.b.blob.impl, a.b.clob.impl]

But these impl packages are very small, and their references from the a.b.blob package are few. In fact, the only possible candidate for these warnings would seem to be as parameters to a private constructor.for a single exported class.

That seems a bit extreme to me. Is Bundle being over-zealous please, or would a private constructor really cause OSGi problems?

Cheers,

Chris

[BJ Hargrave]

Bnd is seeing that your API (exported packages) has non-exported packages in its API signature. This could mean super types, implemented interfaces, method parameter types, return types. That is, Bnd is telling you that you have a potential error in your API that would prevent a user of your API from being able to fully use it since the user would have no visibility to the non-exported packages.

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/7e121f98-7c0f-42fe-a895-82c78151d01cn%40googlegroups.com.

--

BJ

[Chris Rankin]

On Monday, 31 August 2020 at 15:00:38 UTC+1 BJ Hargrave wrote:

Bnd is seeing that your API (exported packages) has non-exported packages in its API signature. This could mean super types, implemented interfaces, method parameter types, return types. That is, Bnd is telling you that you have a potential error in your API that would prevent a user of your API from being able to fully use it since the user would have no visibility to the non-exported packages.

Yes, I understand that. My point is that warnings about private constructors would seem to be "false positives", because Java itself prevents them from being visible outside of the class. And similarly for "package private" scope too.

Cheers,

Chris

 

[BJ Hargrave]

You will need to provide specific examples.

Bnd should not care about private or default ("package private") access constructors. It will care about public and protected classes using non-public and non-protected super types or interfaces (all the way up the hierarchy) and public and protected members referencing non-public and non-protected types.

--

You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/4a04e4f8-1de2-401d-9e40-c21c42ebc711n%40googlegroups.com.

--

BJ

[Chris Rankin]

On Mon, 31 Aug 2020 at 17:51, BJ Hargrave <b...@bjhargrave.com> wrote:
> Bnd should not care about private or default ("package private") access constructors. It will care about public and protected classes using non-public and non-protected super types or interfaces (all the way up the hierarchy) and public and protected members referencing non-public and non-protected types.

OK, thanks. I've just disassembled the class concerned and am now
suspecting that the problem is being caused by certain "public static
final" "accessXXX()" methods that the compiler has helpfully generated
for me. And public synthetic constructor too!

Cheers,
Chris