I have currently enabled -pedantic:true to see what “pedantic” warnings we have and try to clean them up.
There is one warning, where I am not sure what is the best strategy to solve it:
Imports that lack version ranges: [javax.net.ssl]
My bundle has a class that has imports like:
import javax.net.ssl.SSLSessionContext;
import javax.net.ssl.SSLSocket;
my bnd.bnd is simple:
Import-Package: *
The Manifest.mf contains (among other stuff):
Import-Package: javax.net.ssl, java.lang
etc. without versions .
So since these packages come from Java itself and probably do not have an OSGi version, I wonder: What is the proper way to get rid of this warning? (I know about-fixupmessages)
There is an interesting idea that this is similar what -contracts tries to solve.
master ← chrisrueger:pedantic-warning-Imports-that-lack-version-ranges-should-ignore-java-packages
I think we might be able to do something better here.
> This reduces warning … noise with pedantic:true regarding the warning "Imports that lack version ranges". This warning is not useful for packages from the JDK like java. , javax.net. , javax.security. (and maybe more), because JDK packges have no version. we did not add "javax." because it would be too broad, as there are packages out there not coming from the JDK (e.g. javax.xml.bind)
>
I had a high-level idea for a different approach to this that I wanted to float: I'm not an expert on contracts (see https://docs.osgi.org/reference/portable-java-contracts.html), but to me this seems identical to problem to what contracts are designed to solve.
A contract is a set of packages where the version number applies to the entire set (ie, the "contract") rather than to the individual packages. My understanding is that Bnd doesn't (or at least shouldn't) complain about missing versions on packages that are known to be part of a contract, because the version is effectively set by the contract version that those packages are a part of. Instead, it creates a `Req-Cap` for the contract with the proper contract version.
Is there perhaps some way we can leverage this functionality to solve the same problem here, by treating the set of packages provided by the JDK as a contract? Bnd already does the hard work to calculate the minimum osgi.ee level required for a bundle and insert this as a `Req-Cap` header. This requirement could be internally mapped to a set of available packages and treated as a contract. Then (assuming that we internally define in bndlib somewhere all of the correct contract definitions) this will automatically be handled by the core contract handling code - which would include not warning about missing version ranges on imports.
I can foresee situations where there are multiple solutions to a missing version range, where packages have moved out of the JDK and "into the wild" (eg, for `javax.xml.bind`). I think that this could be handled by clearly separating the code that 1. calculates the minimum EE requirement, and 2. calculates the missing imports based on contract, which always uses the highest allowed contract version based on the bundle's EE req-cap. That way you can resolve conflicts by manually specifying an upper bound on your bundle's EE requirement if necessary. Eg, if I want to use an unversioned `javax.xml.bind` import, I can specify the maximum supported version of my bundle is EE JavaSE 1.8. Bnd will then use the 1.8 contract definition to see that `javax.xml.bind` is part of the Java 8 contract and so it will not generate the warning. I note that this problem (ie, packages moving in-and-out of the contract) is not specific to the JDK but also applies to contracts in general.
The advantage of this approach is that it provides a natural evolution path as packages move in-and-out of the JDK across different JDK versions.
Thoughts? Or is this overkill?
See also
Let’s see what happens with this PR.