On Thu, Apr 29, 2021 at 11:40 AM Roy T. Fielding <field...@gbiv.com> wrote:
> > On Apr 28, 2021, at 9:24 PM, Michał Kłeczek <mic...@kleczek.org> wrote: > > > > Hi All, > > > > I’ve just learned JEP 411 (https://openjdk.java.net/jeps/411 < > https://openjdk.java.net/jeps/411>) moved to Candidate status. > > > > Does this JEP mean end of mobile code and hence Apache River? > > No, it's just code. If the code needs to be replaced, it can be replaced. > > ....Roy > > I'm not sure how you reach that conclusion Roy (which is not an attempt to claim that I'm qualified to disagree with you, though I *believe* I understand the core functioning of this stuff at a reasonable level). On the one hand, I'm not sure how many people run River systems in entirely trusted infrastructures, and for those that do, perhaps they won't care if the security manager goes away anyway. On the other hand, if the security manager and everything that goes with it disappears, I don't see how you can simply "replace" that from a library. We're not talking about "capabilities" we're talking about built-in restrictions in the core libraries for Java SE that are essential to the behavior of the security manager. If that all goes away, the only way I can see to put the functionality back is to provide a replacement implementation of core libraries. That's effectively distributing an alternate version of Java (though the actual JVM, and the platform specific binaries can be retained.) Can you explain how you see adding back security from a library level? Or is your assertion just that you don't see people caring? Of course, that only matters if people want the security manager, which I admit is not something I've witnessed in 26 years of trying to persuade them that they do! And it's long been clear that Oracle doesn't see sufficient value in mobile code for them to bother trying to make it secure. Frankly I've been struggling to explain the value to people for the same 26 years. -- Simon Roberts (303) 249 3613
