Problem with Java-9+

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with Java-9+

Uri Blumenthal

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`

Reply | Threaded
Open this post in threaded view
|

Re: Problem with Java-9+

Uri Blumenthal
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 <[hidden email]> 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 (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Java-9+

David Hook-3

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.

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.

You might want to use the  *jdk15to18* jars instead. 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.

Apologies,

David

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 <[hidden email]> 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`


Reply | Threaded
Open this post in threaded view
|

Re: Problem with Java-9+

Uri Blumenthal
On Sep 16, 2019, at 1:38 , David Hook <[hidden email]> 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 <[hidden email]> 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 (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Java-9+

Uri Blumenthal
Any comment regarding my proposal/request?  Can you change the module names to match JAR names (which, AFAICT, would address the problem I described)?

Uri Blumenthal



On Sep 16, 2019, at 8:26 AM, Uri Blumenthal <[hidden email]> wrote:

On Sep 16, 2019, at 1:38 , David Hook <[hidden email]> 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 <[hidden email]> 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 (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Java-9+

David Hook-3

Still thinking.

I'll admit it's a compelling case. It's a bit of an odd one though...

The jdk15t018 jars are on maven as well.

Regards,

David

On 24/9/19 8:16 am, Uri Blumenthal wrote:
Any comment regarding my proposal/request?  Can you change the module names to match JAR names (which, AFAICT, would address the problem I described)?

Uri Blumenthal



On Sep 16, 2019, at 8:26 AM, Uri Blumenthal <[hidden email]> wrote:

On Sep 16, 2019, at 1:38 , David Hook <[hidden email]> 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 <[hidden email]> 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`





Reply | Threaded
Open this post in threaded view
|

Re: Problem with Java-9+

Uri Blumenthal
On Sep 24, 2019, at 8:50 AM, David Hook <[hidden email]> wrote:

Still thinking.

I'll admit it's a compelling case. It's a bit of an odd one though...

IMHO, nothing to think about, really. You have these options:
  • Remove explicit module definitions - unattractive for Java-9+, but likely to remain compatible across all the JDKs, as automatic module names would be assigned;
  • Change module names to match the  names of their corresponding JAR files - IMHO the best overall, as it both provides what’s necessary for utilizing modules in Java-9+, and remains compatible across all the JDKs;
  • Rename JAR files to match the new module names - breaks compatibility with the old projects, but the names would better match what they represent.

I don’t think the status-quo is acceptable, as it’s incompatible whichever way you look - the projects now must be aware of both what JDK you use, and what BC version you pull (the latter one is especially bad).


The jdk15t018 jars are on maven as well.

Thanks!


On 24/9/19 8:16 am, Uri Blumenthal wrote:
Any comment regarding my proposal/request?  Can you change the module names to match JAR names (which, AFAICT, would address the problem I described)?

Uri Blumenthal



On Sep 16, 2019, at 8:26 AM, Uri Blumenthal <[hidden email]> wrote:

On Sep 16, 2019, at 1:38 , David Hook <[hidden email]> 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 <[hidden email]> 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 (5K) Download Attachment