Re: Problem with Java-9+
David Hook <dgh-rTAZ0PM/[email protected]> Tue, 24 Sep 2019 22:50:21 +1000
| Newsgroups | gmane.comp.encryption.bouncy-castle.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------0D477287D8384DB6020FFDE9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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 > [email protected] <mailto:[email protected]> > > > >> On Sep 16, 2019, at 8:26 AM, Uri Blumenthal <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Sep 16, 2019, at 1:38 , David Hook <dgh-rTAZ0PM/[email protected] >> <mailto: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`/ >>>>> >>> >> > --------------0D477287D8384DB6020FFDE9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix"><br> </div> <div class="moz-cite-prefix">Still thinking.</div> <div class="moz-cite-prefix"><br> </div> <div class="moz-cite-prefix">I'll admit it's a compelling case. It's a bit of an odd one though... <br> </div> <div class="moz-cite-prefix"><br> </div> <div class="moz-cite-prefix">The jdk15t018 jars are on maven as well.</div> <div class="moz-cite-prefix"><br> </div> <div class="moz-cite-prefix">Regards,</div> <div class="moz-cite-prefix"><br> </div> <div class="moz-cite-prefix">David</div> <div class="moz-cite-prefix"><br> </div> <div class="moz-cite-prefix">On 24/9/19 8:16 am, Uri Blumenthal wrote:<br> </div> <blockquote type="cite" cite="mid:DC035E17-7556-4CD8-8174-791803EB1A64-3s7WtUTddSA@public.gmane.org"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> Any comment regarding my proposal/request? Can you change the module names to match JAR names (which, AFAICT, would address the problem I described)? <div class=""><br class=""> <div class=""> <div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;">Uri Blumenthal</div> <div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;"><a href="mailto:[email protected]" class="" moz-do-not-send="true">[email protected]</a></div> <div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""> </div> <br class="Apple-interchange-newline"> </div> <div><br class=""> <blockquote type="cite" class=""> <div class="">On Sep 16, 2019, at 8:26 AM, Uri Blumenthal <<a href="mailto:[email protected]" class="" moz-do-not-send="true">[email protected]</a>> wrote:</div> <br class="Apple-interchange-newline"> <div class=""> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class=""> <div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On Sep 16, 2019, at 1:38 , David Hook <<a href="mailto:dgh-rTAZ0PM/[email protected]" class="" moz-do-not-send="true">dgh-rTAZ0PM/[email protected]</a>> wrote:<br class=""> <div class=""> <blockquote type="cite" class=""> <div class=""> <div text="#000000" bgcolor="#FFFFFF" class=""> <div class="moz-cite-prefix"><br class=""> </div> <div class="moz-cite-prefix">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.</div> </div> </div> </blockquote> <div class=""><br class=""> </div> Well, yes - but I think there’s a way.</div> <div class=""><br class=""> <blockquote type="cite" class=""> <div class=""> <div text="#000000" bgcolor="#FFFFFF" class=""> <div class="moz-cite-prefix">If you look in bcprov-jdk15on for 1.60 you'll see:</div> <div class="moz-cite-prefix"><br class=""> </div> <div class="moz-cite-prefix">Automatic-Module-Name: org.bouncycastle.provider</div> </div> </div> </blockquote> <blockquote type="cite" class=""> <div class=""> <div text="#000000" bgcolor="#FFFFFF" class=""> <div class="moz-cite-prefix"><br class=""> </div> <div class="moz-cite-prefix">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.<br class=""> </div> </div> </div> </blockquote> <div class=""><br class=""> </div> <div class="">I don’t know why - but it appears that this statement is ignored, at least by Java-11 (or it’s added only to <b class="">bcprov-jdk15on</b>, and <b class="">not</b> to <b class="">bcprov-ext-jdk15on</b>). 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;"</div> <div class=""><br class=""> </div> <br class=""> <blockquote type="cite" class=""> <div class=""> <div text="#000000" bgcolor="#FFFFFF" class=""> <div class="moz-cite-prefix"> </div> <div class="moz-cite-prefix">You might want to use the *jdk15to18* jars instead. </div> </div> </div> </blockquote> <div class=""><br class=""> </div> <div class="">What are these? Are they on Maven? How do I refer to them?</div> <div class=""><br class=""> </div> <br class=""> <blockquote type="cite" class=""> <div class=""> <div text="#000000" bgcolor="#FFFFFF" class=""> <div class="moz-cite-prefix">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.</div> </div> </div> </blockquote> <div class=""><br class=""> </div> <div class="">Yes, I hear and understand you. I won’t say here what I think of the new Java module approach.</div> <div class=""><br class=""> </div> <div class="">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.</div> <br class=""> <blockquote type="cite" class=""> <div class=""> <div text="#000000" bgcolor="#FFFFFF" class=""> <div class="moz-cite-prefix">Apologies,</div> </div> </div> </blockquote> <div class=""><br class=""> </div> Accepted. ;)</div> <div class=""><br class=""> </div> <div class="">Could you please see if you can make module names match the JAR names?</div> <div class=""><br class=""> </div> <div class="">Thanks!</div> <div class=""><br class=""> </div> <div class=""> <blockquote type="cite" class=""> <div class=""> <div text="#000000" bgcolor="#FFFFFF" class=""> <div class="moz-cite-prefix">On 14/9/19 7:20 am, Uri Blumenthal wrote:<br class=""> </div> <blockquote type="cite" cite="mid:E927692E-67C8-4699-9A2B-2FE7B5B753F4-3s7WtUTddSA@public.gmane.org" class=""> 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.<br class=""> <br class=""> <div dir="ltr" class="">Sent from my test iPhone</div> <div dir="ltr" class=""><br class=""> On Sep 13, 2019, at 16:37, Uri the Great <<a href="mailto:[email protected]" moz-do-not-send="true" class="">[email protected]</a>> wrote:<br class=""> <br class=""> </div> <blockquote type="cite" class=""> <div dir="ltr" class=""> <p class="">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.</p> <p class="">Before 1.61, <i class="">module-info.class</i> 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.</p> <p class="">Now comes 1.61. Somebody decided that it's a good thing to give a special name to the bcprov module - <i class="">org.bouncycastle.provider</i>. So, the projects are no longer portable across different JDK and BC releases - because now they have to list dependency for <i class="">org.bouncycastle.provider</i> if they use BC 1.61+, or for <i class="">bcprov-ext-jdk15on</i> if they use BC 1.60 or earlier.</p> <p class="">I think the correct solution would be to set module name to <i class="">bcprov-ext-jdk15on</i> (or <i class="">bcprov-jdk15on</i> correspondingly), if you want to be backward-compatible.</p> <p class="">A nit: there's no JDK-1.9, so it might be better to rename your ...<i class="">jdk1.9... </i>to <i class="">...jdk-9...</i> or <i class="">...jdk9...</i></p> <p class="">P.S. Thanks for including <i class="">add_module.sh</i>. It's helpful. May I suggest changing <i class="">export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64</i> to something more dynamic, like <i class="">export JAVA_HOME=`/usr/libexec/java_home -v 11`</i><br class=""> </p> </div> </blockquote> </blockquote> <p class=""><br class=""> </p> </div> </div> </blockquote> </div> <br class=""> </div> </div> </blockquote> </div> <br class=""> </div> </blockquote> <p><br> </p> </body> </html> --------------0D477287D8384DB6020FFDE9--