[External] : Re: JEP draft: Integrity and Strong Encapsulation

[Ron Pressler]

> On 11 May 2023, at 12:04, Dan Heidinga <heidinga at redhat.com> wrote:
> 
> I had read this JEP as a position statement on future directions given it refers to the preventing dynamic loading of agents (a future action) and restricting JNI (future) while also talking about strong encapsulation (past).

Restricting FFM/JNI is new, but disallowing the dynamic loading of agents by default was already in JEP 261 in 2017.

> Integrity is good and brings benefits - we agree.  Libraries grovelling through internals makes upgrading challenging but as a broad OpenJDK community, we are also claiming that upgrades from 9+ are generally easy (and I'd like to believe that uptake of JDK11 & 17 is proving that to be true).  Locking the platform down further may be a benefit but our current state surely isn't preventing the platform's evolution.


I agree that upgrades from 9+ are generally easy because all the implementation changes in the JDK (and the resulting breakage of non-portable JDK-hacking libraries) delivered a shock to the ecosystem that unstuck it from its off-spec dependence on JDK 8 implementation details. Then 17 delivered most of what’s discussed in the JEP and made it harder for the ecosystem to silently get stuck in a similar way to JDK implementation details ever again.

The few additional restrictions mentioned in the last section of the JEP don’t serve evolution as much as they serve the other motivations (performance, security). Closing down the last few corner-case loopholes will allow the platform and anyone using it to truly trust strong encapsulation, while not imposing additional significant pain on the vast majority of applications. If we thought that disallowing dynamically loaded agents or restricting JNI would cause significant pain to even a minority of applications, we would not propose those changes. 


> 
> Quite frankly, then those applications should break.  Application developers will then need to decide if the benefits from those libraries outweigh the upgrade difficulties introduced.
> ...
> They kind of did when they *chose* those libraries.


As we say in the JEP, it has become customary for Java applications to use many levels of dependencies, and many developers never understood how deep the tree was. Even those application developers who knew what purpose their third- or fourth-level dependencies served couldn't know that those dependencies made the application non-portable. 

Applications need a way to know that a library exposes them to such a risk (ideally, by the library documentation spelling out the --add-opens needed by the library). This knowledge is communicated by an opt-out mechanism rather than opt-in for the reasons explained in this section of the JEP: https://openjdk.org/jeps/8305968#Strong-Encapsulation-by-Default

> 
> Most production applications are migrations - they previously accessed internals and now need --add-opens to allow their previous use of deep reflection (and setAccessible(true)) to continue to work.  If you classify "modern Java applications" as those greenfield applications written without existing libraries, then I might agree with the "no need.... to require --add-opens".

The use of deep reflection does not require --add-opens. Only the use of deep reflection across module boundaries that choose to forbid it does. In practice, that means JDK internals, and most code that uses JDK internals is in libraries, not applications. Libraries that aren’t maintained will probably require their applications to give them access to JDK internals until those libraries break, but those that are maintained can (and should) reduce their use of internals, as they already have been doing.

> 
> As to the relationship between modularisation and --add-opens, as applications (or libraries) adopt modularity, the number of --add-opens *increases* at the boundaries between the newly made modules and the existing classpath libraries.  Once everything is modularized, the usage will hopefully decrease (or disappear!).
>  
> 
> As for agents, not only are they perfectly supported as ever, it may be interesting to run them at link time in certain future Leyden modes. The use of agents for tooling is more than just acceptable — it’s wonderful! It’s their use by libraries that’s somewhat concerning, but in the long term we may want to offer libraries some of the power of agents, only restricted by encapsulation boundaries.
> 
> This - and some of the Leyden-related statements - hint at a larger vision.  Could you share some of that vision (or roadmap) with the broader community?  It makes it much easier to get on board with where you're going if we can also see the intended destination. 

Sure: https://openjdk.org/projects/leyden/notes/02-shift-and-constrain

— Ron