Java Platform Modules System - what's the point of protection?

Question

I read one of the advantages of JPMS is better encapsulation (all is restricted unless explicitly opened).

But I have a question: what prevents a programmer from replacing module-info.class in third-party module JAR and export all packages, or even making open module, so everything is accessible via reflection (including private members).

Is the JPMS something which can really can help to hide inner code, or it's just like with Java 8 and earlier: all is accessible via Reflection API, even private members (just extra step needed as of Java 9 to open a module)?

Answer 1

There is a fundamental difference between patching a stored module and using Reflection to access private members without modifying the stored classes.

Generally, there is no absolute security. Security is always about how hard an attacker’s work is. In best case, a successful attack needs far more work than whatever the attacker may gain from it.

If you have access to the code, including the possibility to alter it or create a modified copy, all bets are off anyway.

But the main focus is not about that kind of security, but to guide developers to use a library correctly. Before the module system, any public class and its public or protected members were accessible and even suggested by IDEs, e.g. on code completion, automatically and it required extra effort to tell the IDE that certain classes or members are not part of the API and therefore should not be suggested or even rejected when compiling code referencing them.

Nowadays, with a module, it requires extra effort to make non-API artifacts accessible again, which changes the game significantly. Now, making a non-API artifact accessible again, is equally hard, regardless of its access modifiers, so you can’t mistakenly think that something is part of the API, just because it’s public.

Likewise, you can not expect a library developer to maintain backwards compatibility to Reflection hacks into its internals. You can’t prevent such accesses completely. But the more effort a developer needs to create such code, the better they will know that they are off the track and can’t expect the result to continue to work in the next version.

Answer 2

I think it's fair to say that protection in the sense of security / tamper-proof code is not a primary goal of JPMS.

If tampering is still possible, there still is great value in being able to detect, whether or not a given application plays by the rules (or, to which exact extent the rules have been relaxed).

One obvious motivation being to more or less gently push developers towards producing "good, modular" code. Gradually "better" code is still "better" than "bad" code. Needing to take additional measures will be reason in some cases to resist the temptation.

A less obvious motivation is supporting advanced modular flow-analysis at runtime, which will benefit what optimizations a JIT can safely perform.

Many years ago I coined the term "gradual encapsulation" to denote a method and technology that enforces "as much encapsulation as you can afford", not less but importantly also not more than you can afford (establishing perfect encapsulation has its price). The set of JPMS command line options for tweaking modularity can be seen as a toolset to precisely declare the exceptions where you cannot afford perfect encapsulation (for one of various possible reasons). Forging jar files is of course possible, but it is also detectable if the original is signed. In all this, there is great value in being "honest" even if you can't be "perfect".

(All terms in quotes obviously being a matter of p.o.v.).