Add module-info.java

[chad.preisler]

I’m wondering if you would consider adding module-info.java? That would allow jose4j to be used with jlink. I’m willing to do the work, but only if you’re interested. If you want me to make these changes, I need the following information.

• Do you still want to support Java 7? If you do, the build can be changed to a multi-release jar, if not what minimum version of Java do you want to support moving forward? In my opinion, JDK 11 and above would be best.
• My preference would be to just add the module-info.java class to the project. Are you okay with that? Some projects are fancy and try to generate it at build time. In this case, and many cases, I don’t see an upside to that.
• If you want to move to a newer version of the JDK, do you want me to remove some of the deprecated methods from jose4j? (obviously not necessary, but since moving the JDK is a pretty big change, I thought why not take out the deprecated methods).
• Do you want me to clean up some unnecessary boxed types?

Let me know if yow want this change. My main motivation is to get module-info added.

‌

[Brian Campbell]

Hi Chad, I’m not opposed to adding a module-info.java, however, my priority is not breaking things for folks using the library (and costing them and me time). And I have to admit that I’ve not done much work with the module system so am largely ignorant and also cautious about unindexed impacts. I've been considering dropping support for Java 7 so that would be okay but I think I still need to support Java 8 for a good while. While there is kinda an implied public API for jose4j, it’s not strict or documented and I don’t know what methods/classes people use in practice. So pretty much everything would need to be exposed. I’d prefer to deal with deprecated stuff and boxing separately.

‌

[chad.preisler]

Thanks for getting back to me on this. I started working on this and noticed that org.jose4j.jws.EdDsaAlgorithm uses java.security.interfaces.EdECPrivateKey. The EdECPrivateKey was introduced in JDK 15. Looks like EdDsaAlgorithm is loaded in AlgorithmFactoryFactory. I haven’t tried, but it seems like the latest version jose might not work on JDKs prior to 15. JDK 15 was a non-lts release. The next LTS after 15 is 17. Do you want to reconsider supporting JDK 8? If you want to support JDK prior to 17 it might make sense to move EdDsaAlgorithm to only be available on JDK 17 and above. I think with multi-release jar I can make it happen. Let me know what you think.

[Brian Campbell]

but it seems like the latest version jose might not work on JDKs prior to 15

It works. RFC8037 functionality like the EdDSA alg and OKP kty won't be available at runtime. But it does work and “exposes” the JOSE functionality supported by the underlying runtime and security providers.

‌

Do you want to reconsider supporting JDK 8?

No, Java 8 support is necessary for the time being.

‌

I think with multi-release jar I can make it happen.

That would be a much more invasive change than I’d be willing to consider incorporating.

[Brian Campbell]

It might not always be pretty but a decent amount of effort has been put into allowing the library to work on many different runtimes and with different security providers - including but not limited to older java versions, android, HSMs, etc. It looks at what’s available from the installed security providers and runtime java APIs and only makes the corresponding JOSE features available. It’s not perfect but seems to work pretty well. And while it’s far from the most popular library in the world, it is widely used in large scale mission-critical production applications. As such, I am very risk averse with respect to changes. I maybe should have been more direct about that upfront.

‌

[chad.preisler]

I’ve forked the project and checked my changes in here. I created a project using the code from the RFC 7797 JSON Web Signature example. I ran it on JDK 1.8, and it worked fine. Also included the JAR in a modular project and was able to run jlink to create a custom JDK. Everything worked as expected.

Please let me know if you want changes, have a specific project you would like me to test with, or want me to create a pull request.

[Brian Campbell]

I’m sorry Chad, I appreciate the offer and effort you’ve put in but I’m not currently inclined to incorporate these changes or pursue this further. I hope you can use the work in your fork to meet your needs.

[chad.preisler]

Okay, no problem. Do you have a gut feel for when you will release version 0.9.5?

[Brian Campbell]

No imminent plans for 0.9.5. There aren’t particularly significant changes from 0.9.4 currently.

[Gili]

I think with multi-release jar I can make it happen.

That would be a much more invasive change than I’d be willing to consider incorporating.

Hi Brian,

Can you please clarify what is invasive about using a multirelease JAR? It is literally the same JAR file you have now, but with one file added into the META-INF/versions/9/ directory. It is fully backwards compatible with older versions of Java.

If you go to https://medium.com/@ankitagrahari.rkgit/multi-release-functionality-8fc423b6c94e and jump to section “Add execution for Java 11” you’ll see the code you need to add into the pom.xml file:

<execution>
    <id>java11</id>
    <goals><goal>compile</goal></goals>
    <configuration>
        <release>11</release>
        <compileSourceRoots>${project.basedir}/src/main/java11</compileSourceRoots>
        <multiReleaseOutput>true</multiReleaseOutput>
    </configuration>
</execution>

Easy peasy! :)