[External] : Re: Inconsistency with service loading by layer or by class loader

[Ron Pressler]

> On 16 Dec 2024, at 15:45, David Lloyd <david.lloyd at redhat.com> wrote:
> 
> 
> Modules are, in fact, a chore. They are an extra burden compared to the status quo, which (like it or not) is for most users building things with Maven or Gradle and not caring one way or another about modules. Modularity in the JDK adds restrictions, not additional capabilities. Sure you can argue that the restrictions are a "feature" but that is a subjective interpretation. The fact is that if you want modules, you do have to do some extra work, and you have to deal with additional rules that did not previously exist. There is simply no logical way around that conclusion.


Modules are no more a chore than any other feature (putting aside some known difficulties with build tools that we are very much aware of). *If* you want your server to offer higher throughput through higher concurrency, then you’ll have the “chore” of adapting your code to virtual threads (or the bigger chore of asynchronous programming). *If* you want to interact with native libraries then you’ll have the “chore” of using FFM (or the bigger chore of JNI). Similarly, *if* you want the benefits of strong encapsulation, then you’ll have the “chore” of authoring modules (or the bigger, though now irrelevant chore of configuring SecutityManager).

All these features are an extra burden compared to the status quo of not using them, and they’re there to offer benefits that can’t be obtained otherwise (or are more difficult).

The benefits of the modules feature are significant, but like FFM and virtual threads, they don’t apply to all programs (once modules gain more benefits, the feature will become more relevant to more programs). For example, if you want to improve maintainability/portability by blocking clients from becoming dependent on internal classes, then modules are the mechanism the JDK offers for doing that; it offers no other. If you want to make sure that some security-sensitive mechanism is more robust in the face of vulnerabilities in third-party libraries (especially once integrity by default is complete) then, again, modules are the mechanism for achieving that; there is no other.

These benefits come through a powerful new capability — the capability to trust that a private method or an internal class do not become dependencies and cannot be accidentally used in a vulnerable way. They are crucial needs of the JDK itself, as we’ve all seen the portability pains of the pre-strong-encapsulation era due to code relying on internal classes and the improvement in backward compatibility since. Maintainability and security became almost crippling burdens on the JDK, but it’s certainly possible that they’re of little concern to many other projects. How important they are for other projects is for each project to decide.

Since you’re attempting to use this feature, I naturally assume it’s because you want its benefits. Andrew suggested that perhaps you’re not interested in the feature for the maintainability and security benefits it offers today but that you may be anticipating future benefits, like performance and deployment improvements for modules. You’d be correct to do so. Either way, you’d be using the feature to offer (future) value to your users. That’s not a chore, that's just the work needed to adopt a feature.

— Ron