Re: Problem with Java-9+

Uri Blumenthal <[email protected]> Mon, 16 Sep 2019 12:26:38 +0000
Newsgroups gmane.comp.encryption.bouncy-castle.devel
Message-ID <[email protected]>
On Sep 16, 2019, at 1:38 , David Hook <dgh-rTAZ0PM/[email protected]> wrote:
> 
> I'm afraid this has really turned out to be one of those dammed if you do, dammed if you don't kind of things.

Well, yes - but I think there’s a way.

> If you look in bcprov-jdk15on for 1.60 you'll see:
> 
> Automatic-Module-Name: org.bouncycastle.provider
> 
> in the manifest, so the reality is module-info was actually introduced with backwards compatibility in mind. I think it was missing from the ext jar in that release.

I don’t know why - but it appears that this statement is ignored, at least by Java-11 (or it’s added only to bcprov-jdk15on, and not to bcprov-ext-jdk15on). I believe this because I can pull bcprov-ext-jdk15on-160 from Maven, and use it with my code that says “require bcprov.ext.jdk15on;"


> You might want to use the  *jdk15to18* jars instead.

What are these? Are they on Maven? How do I refer to them?


> I think originally the whole module/multi-release jar thing was envisioned as something that could just be slipped in without causing any unexpected side effects. It has turned out that nothing could have been further from the truth.

Yes, I hear and understand you. I won’t say here what I think of the new Java module approach.

Regardless, I think if you revert to module names matching their jar names (i.e., “bcprov.ext.jdk15on” for bcprov-ext-jdk15on-163.jar, and such), it would allow Java-11+ code to work with any version of BC jars - because in that case Automatic module name (determined from the JAR name) would match what the actual module name is.

> Apologies,

Accepted. ;)

Could you please see if you can make module names match the JAR names?

Thanks!

> On 14/9/19 7:20 am, Uri Blumenthal wrote:
>> Of course, I meant module name "bcprov.ext.jdk15on" - dots in the automatic module name and dashes in it's file name translate into each other.
>> 
>> Sent from my test iPhone
>> 
>> On Sep 13, 2019, at 16:37, Uri the Great <[email protected] <mailto:[email protected]>> wrote:
>> 
>>> As I resurrected one of my Maven-based projects that retrieve BouncyCastle jars from the Maven Central, I discovered that bcprov-ext jars for 1.61+ are incompatible with the previous releases, in a way that's both bad and unnecessary.
>>> 
>>> Before 1.61, module-info.class was not added, so for Java-1.8 (and before) it worked as expected - and for Java-9+ it took the name of the jar file as the module name. So far so good - it worked with all the JDK around.
>>> 
>>> Now comes 1.61. Somebody decided that it's a good thing to give a special name to the bcprov module - org.bouncycastle.provider. So, the projects are no longer portable across different JDK and BC releases - because now they have to list dependency for org.bouncycastle.provider if they use BC 1.61+, or for bcprov-ext-jdk15on if they use BC 1.60 or earlier.
>>> 
>>> I think the correct solution would be to set module name to bcprov-ext-jdk15on (or bcprov-jdk15on correspondingly), if you want to be backward-compatible.
>>> 
>>> A nit: there's no JDK-1.9, so it might be better to rename your ...jdk1.9... to ...jdk-9... or ...jdk9...
>>> 
>>> P.S. Thanks for including add_module.sh. It's helpful. May I suggest changing export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 to something more dynamic, like export JAVA_HOME=`/usr/libexec/java_home -v 11`
>>> 
>
smime.p7s (application/pkcs7-signature, 1.8 KB) - not displayed