> #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 JP

> #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.