You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If classes from the same package appear in Maven artifacts with different group IDs or different artifact IDs, it is easy to construct a classpath that splits packages. This is a problem even if individual classes do not overlap. For example, the google-cloud-vision Java API client places protobufs in com.google.api.grpc:proto-google-cloud-vision-v1 and gRPC stubs in com.google.api.grpc:grpc-google-cloud-vision-v1. Since both artifacts contain classes in the com.google.cloud.vision.v1 package, these two artifacts cannot be used together after Java 8.
If users choose to place these split-package libraries in class path rather than module path, they can use the libraries in Java 11.
I came up with an example. Let's say you have a module "com.greetings" that depends on an automatic module "proto.google.cloud.vision.v1". The module-info.java would look like this:
The automatic module comes from Java 8's JAR file "proto-google-cloud-vision-v1-1.100.10.jar" in module path. The JAR file uses classes from protobuf. We can use protobuf-java in the class path:
Now this command uses both module path and class path. In JPMS the packages (and classes) in the JAR files in the class path are in the "unnamed module". In this case, the classes in protobuf-java are in the unnamed module. Classes in a normal module cannot reference classes in unnamed modules. Classes in automatic module can reference it.
com.greetings.Main (in com.greetings module) depends on the automatic module proto.google.cloud.vision.v1.
The automatic module proto.google.cloud.vision.v1 depends on unnamed module, which contains protobuf classes.
(Note that com.greetings.Main does not directly reference classes in protobuf-java)
https://jlbp.dev/JLBP-19 says
If users choose to place these split-package libraries in class path rather than module path, they can use the libraries in Java 11.
ref https://blog.joda.org/2018/03/jpms-negative-benefits.html
The text was updated successfully, but these errors were encountered: