Add JPMS module-info.java

[kurtostfeld]

The newest version 5.0.0 of microprofile-metrics-api doesn't include a module-info.java descriptor, so it's not a proper JPMS module. I see that the published jar uses bytecode version 55.0 (Java 11), so the project doesn't support older versions of Java, so adding a module-info.java should be very simple

jlink packaging, and the Maven jlink plugin in particular, requires all transitive dependencies have module-info.java descriptors, so if I add microprofile-metrics-api to my projects, I get the jlink error:

[ERROR] Error: automatic module cannot be used with jlink: microprofile.metrics.api from file:///Users/admin/.m2/repository/org/eclipse/microprofile/metrics/microprofile-metrics-api/5.0.0/microprofile-metrics-api-5.0.0.jar

[xazap]

I had a look at this issue and found that adding a module-info.java is not straightforward. The problem is that the microprofile-metrics-api has a lot of OSGi dependencies that don't have proper module descriptors themselves. There is a Maven plugin to generate module info for non-JPMS JARs, but it would be better if the OSGi people made their releases properly modular. Maybe they won't since OSGi sort of competes (or partially overlaps) with the goals of the JPMS.

Now for some irony: as of commit 12044ea the microprofile-metrics-api POM puts both org.osgi.annotation.versioning-1.1.0.jar and osgi.annotation-8.0.1.jar on the classpath. Both these JARs contain package org.osgi.annotation.versioning with the same classes. Who knows which version is actually used to compile and run tests against....

This is exactly one of the use cases where JPMS is beneficial: to prevent duplicate classes and packages in dependencies.

[Emily-Jiang]

I had a look at this issue and found that adding a module-info.java is not straightforward. The problem is that the microprofile-metrics-api has a lot of OSGi dependencies that don't have proper module descriptors themselves. There is a Maven plugin to generate module info for non-JPMS JARs, but it would be better if the OSGi people made their releases properly modular. Maybe they won't since OSGi sort of competes (or partially overlaps) with the goals of the JPMS.

Now for some irony: as of commit 12044ea the microprofile-metrics-api POM puts both org.osgi.annotation.versioning-1.1.0.jar and osgi.annotation-8.0.1.jar on the classpath. Both these JARs contain package org.osgi.annotation.versioning with the same classes. Who knows which version is actually used to compile and run tests against....

This is exactly one of the use cases where JPMS is beneficial: to prevent duplicate classes and packages in dependencies.

It looks like the osgi.annotation-8.0.1.jar contains the versioning APIs. In this case, the correct fix is to remove the dependency on org.osgi.annotation.versioning-1.1.0.jar. Can you upgrade to the latest release of osgi.annotation-8.1.0?

[xazap]

It looks like the osgi.annotation-8.0.1.jar contains the versioning APIs. In this case, the correct fix is to remove the dependency on org.osgi.annotation.versioning-1.1.0.jar. Can you upgrade to the latest release of osgi.annotation-8.1.0?

Yes, that will fix the classpath issue I mentioned to illustrate the value of JPMS, but it doesn't address the subject this issue is about. The problem stems from the fact that the MicroProfile project uses OSGi dependencies and the OSGi implementers are dragging their feet by not including a proper module-info in their artifacts. I had hoped that the body that governs the JVM eventually would deprecate and remove the classpath in favor of the module path. I mean, JPMS has been there since 2017 with the release of Java 9. Deprecating the classpath in the next LTS release would force the OSGi implementers to finally add the coveted JPMS descriptor.

Opinions aside, to fix this issue, I would call for removal of all OSGi dependencies so that container implementers using the MicroProfile such as Payara can eventually move to JPMS.