FWIW, I don't see any reason to think that JEP-411 means the end of River. My reason for saying that is two-fold:
1. My use cases for River are mostly in the context of a trusted environment where one entity controls all the code end to end and the SecurityManager stuff isn't all that important. 2. I am not convinced that we can't implement a sufficient level of security at the application level anyway, without needing a SecurityManager mechanism built into the JVM. It might mean something that's a lot different from the way River works today, but as a relative new-comer, I don't feel particularly bound by "the way it's always been done" to begin with. But to be fair, I haven't spent a lot of time thinking about the subject either (mainly because of (1) above). Phil On Mon, May 10, 2021 at 12:28 PM Phillip Rhodes <motley.crue....@gmail.com> wrote: > > > > On Thu, Apr 29, 2021 at 10:43 PM 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. >> > > > +1 > > > >