The IOT space is huge. It would be great to be relevant to more of it. Bryan
On Thu, Apr 29, 2021 at 19:44 Bryan Thompson <br...@blazegraph.com> wrote: > +1 > > On Thu, Apr 29, 2021 at 19:43 Jeremy R. Easton-Marks < > j.r.eastonma...@gmail.com> wrote: > >> 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" >> >
