4 ms·

The JPMS represents what is probably the largest single change in Java's history. It significantly impacts the entire stack: language, libraries, and runtime/VM

The JPMS represents what is probably the largest single change in Java's history. It significantly impacts the entire stack: language, libraries, and runtime/VM. In my experience the host of incompatibilities resulting from modules are not worth the trouble -- there's not much to gain from using them. Generally the JPMS provide two benefits: 1. Since the JRE is restructured to use modules, it can be used piecemeal, which is great for embedded systems. 2. A module controls exposed packages -- only explicitly exported packages are accessible to dependent modules. With this in mind it's difficult to justify the JPMS fallout: Why should #1 impact the much larger market of Java SE? #2 is nice, however we already have this feature with IDEs like IntelliJ IDEA, which provide robust compile-time module systems. And the runtime aspect of JPMS access control is hardly worthwhile; it's not security (reflection can always bypass that), so what is it providing exactly? Surely it doesn't fix the notorious "JAR hell" issue, you still need to shade jars or use OSGi.

stingraycharles 7y ago
Does #2 mean that you could, say, for Google Cloud’s SDK which heavily relies on Netty, avoid it exports Netty to the rest of your application, avoiding dependency hell?
- mckinney 7y ago
  Essentially since the JPMS prohibits two modules from defining the same package (aka package splitting), you can't avoid any kind of package-related hell. So if a project depends on the Google Cloud SDK it can NOT have its own version of Netty due to the package splitting restriction.
kasperni 7y ago
> #2 is nice, however we already have this feature with IDEs like IntelliJ IDEA This hardly sounds like a standardized feature. > and the runtime aspect of JPMS access control is hardly worthwhile; it's not security (reflection can always bypass that) That is not true, access control is enforced both at compile time and at runtime. > so what is it providing exactly? Copied from the the Jigsaw requirements: * Reliable configuration, to replace the brittle, error-prone class-path mechanism with a means for program components to declare explicit dependences upon one another; * Strong encapsulation, to allow a component to declare which of its APIs are accessible by other components, and which are not; * A scalable Java SE Platform, whose components can be assembled by developers into custom configurations that contain only the functionality actually required by an application; * Greater platform integrity, to ensure that code that is internal to a platform implementation is not accessible from outside the implementation; and * Improved performance, by applying whole-program optimization techniques to complete configurations of platform, library, and application components.
- mckinney 7y ago
  > This hardly sounds like a standardized feature. IDE module systems reflect the standard module system used by standard build tooling such as Maven and Gradle. > That is not true, access control is enforced both at compile time and at runtime. Right... As I stated: the runtime aspect of JPMS access control is hardly worthwhile; it's not security (reflection can always bypass that). The compile-time module system already in place (maven/gradle) is already supported with IDEs. > Jigsaw requirements Reread my original comment.

stingraycharles 7y ago

Does #2 mean that you could, say, for Google Cloud’s SDK which heavily relies on Netty, avoid it exports Netty to the rest of your application, avoiding dependency hell?

mckinney 7y ago
Essentially since the JPMS prohibits two modules from defining the same package (aka package splitting), you can't avoid any kind of package-related hell. So if a project depends on the Google Cloud SDK it can NOT have its own version of Netty due to the package splitting restriction.

kasperni 7y ago

> #2 is nice, however we already have this feature with IDEs like IntelliJ IDEA This hardly sounds like a standardized feature. > and the runtime aspect of JPMS access control is hardly worthwhile; it's not security (reflection can always bypass that) That is not true, access control is enforced both at compile time and at runtime. > so what is it providing exactly? Copied from the the Jigsaw requirements: * Reliable configuration, to replace the brittle, error-prone class-path mechanism with a means for program components to declare explicit dependences upon one another; * Strong encapsulation, to allow a component to declare which of its APIs are accessible by other components, and which are not; * A scalable Java SE Platform, whose components can be assembled by developers into custom configurations that contain only the functionality actually required by an application; * Greater platform integrity, to ensure that code that is internal to a platform implementation is not accessible from outside the implementation; and * Improved performance, by applying whole-program optimization techniques to complete configurations of platform, library, and application components.

mckinney 7y ago
> This hardly sounds like a standardized feature. IDE module systems reflect the standard module system used by standard build tooling such as Maven and Gradle. > That is not true, access control is enforced both at compile time and at runtime. Right... As I stated: the runtime aspect of JPMS access control is hardly worthwhile; it's not security (reflection can always bypass that). The compile-time module system already in place (maven/gradle) is already supported with IDEs. > Jigsaw requirements Reread my original comment.