I'm not sure how much JEP 411 will impact River. I agree with the overall direction that it proposes in removing the security manager. However, I am worried that removing security features is going to cause some other problems in the Java ecosystem. Beyond the potential impact of River.
I do think what affect it will have on Apache River should be explored. I am of the opinion that Apache River should look beyond just being a Java only project and that we may need to rethink the way that we approach building distributed systems. On Thu, Apr 29, 2021 at 1:10 PM Simon Roberts < si...@dancingcloudservices.com> wrote: > 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 > -- Jeremy R. Easton-Marks "être fort pour être utile"
