Hi River Team I am an occasional user/developer of JINI and River. Here are my thoughts on this project. Since last summer I am using River to educate my seminar students to learn the concept of distributed computing by using River. A couple of students are already working to integrate River with other technologies to cross the NAT and other limitations of private network. For example, you can use the technique of UDP hole punching integrating with STUN server to address that problem as Peter mentioned. We already have the clear solution for that River is facing on which we are working now. I am even thinking to introduce the River from next year as a formal course for my seminar students (as a sub project) seeing the potential of this project. I think it is too early to decide to move it to Attic as there are some users as of me and my students. Instead of moving this project to the corner, why not some of us introduce a working example/or a killer application so that a lots of users will have attention on it. Users have difficulties to understand the architecture and how to integrated this architecture to other technology. Once we clearly show it, more users will come to the River. We need more publications regarding this project. In order to do that students are the great source. Recently, we published a discussion paper from Japan that utilize River. I attach here for your reference. There was great feedback on it. I hope you will consider to keep it for the time being and see the progress. I am ready to contribute to promote this project. For your reference, here is the paper that we published. We are preparing next paper that shows the potential of River to integrate with other technologies so that more users will understand how to utilize this technology.
Bishnu Prasad Gautam ________________________________ From: Peter Firmstone <peter.firmst...@zeus.net.au> Sent: Thursday, February 10, 2022 12:12 AM To: dev@river.apache.org <dev@river.apache.org> Subject: Re: [DISCUSS] Moving Apache River to the Attic Even in the Attic, River will remain a valuable resource of information. When OpenJDK published JEP411 in April 2021, they believed what we were already doing with River was impossible, which succinctly sums up a number of River's features. https://mail.openjdk.java.net/pipermail/security-dev/2021-May/thread.html > >/Lets be clear Java will no longer be able to finely control access to > sensitive data with the removal of SecurityManager. I'm sure it will > be a great bonus for OpenJDK dev's not to have to think about, but it > will impact some developers significantly, who would like to do so > with the least suffering possible. / > I wouldn’t say Java (or anything else, for that matter) is “able" to do it > now, except in the sense that people (scientists) are > able (in a billion-dollar particle accelerator) to transmute lead into gold > (a few atoms). We’ve had twenty five years to convince the world this could > work, the world isn’t buying, and our job isn’t to sell ideas but to serve > millions of developers by giving them > what we believe they need now, not what we wished they wanted. OpenJDK's arguments around SMs poor scalability, poor performance etc, only applied to the unloved provider code shipped with OpenJDK, (hardly changed since Java 1.4), they were proven wrong on every account, except for development cost; maintaining Security had a cost, they were right about that, and OpenJDK no longer wished to bear that cost for a small uptake. For example we are not vulnerable to the recent Log4j vulnerability, even when using the logger, provided SecurityManager is enabled with tool generated principle of least privilege policy files. Parts of OpenJDK didn't make use of SecurityManager, eg data parsing (deserialization) and OpenJDKs trusted codebase became too large, when it should have been restricted to the Java core language features (too much Java platform code has AllPermission). While OpenJDK might have learned from River, they chose not to, perhaps things might have been different had some of the original team remained. Perhaps Jini's original vision might be commercially viable today had Oracle reconsidered it and the role Java was intended for. The challenges River as a project faced: * Challenges for new developers: o The large monolithic build, new developers struggled to understand how River worked under the hood, they couldn't see the forest for the trees. River / Jini also had many layers of indirection, a result of its well designed architecture. o Classdepandjar - a unique dependency based build that, while innovative in its time, was confusing to new developers and modern modular frameworks provided better solutions. * Technical challenges for users: o Codebase annotation loss and ClassLoader resolution problems, relating to flaws in the design of Java Serialization, that River / Jini was forced to plaster over. o IPv4 network address translation had relegated River / Jini to private networks, limiting its appeal in the age of the internet. o TLS, HTTPS & Kerberos transport layers were configurable replacements, but event notifications stopped working. Events are a pretty important feature. o How to integrate with modular frameworks, eg Maven or OSGi. o These historical technical challenges were solved outside of the project. * Disagreements on technical solutions, no doubt due to different understandings or experiences and complexity (OSGi integration caused a lot of contention). * Many developers maintained their own forks of Jini / River, to solve problems they needed to make something work, but it was never standardized or agreed upon and it was difficult the merge the changes back, even when in agreement, it was a big undertaking due to River's use of SVN and large monolithic build. River's complexity came from making the impossible, possible. When your process involves turning lead into gold in your billion dollar particle accelerator, you have to accept there will be some difficulties and disagreements among the boffins. Maybe cat herding might have been easier. But hey, it was fun. Cheers, Peter. On 10/02/2022 1:34 am, Dan Rollo wrote: > I agree it is time. > > Well said Jeremy! Thanks for sharing. > I have fond memories of Jini conferences in Chicago and Brussels (even if all > I remember is the Delirium Cafe). > > Dan Rollo > > >> On Feb 9, 2022, at 10:03 AM, Jeremy R. >> Easton-Marks<j.r.eastonma...@gmail.com> wrote: >> >> I, sadly, agree that it is time to move this project to the Attic. While I >> hoped to work on this as a side project, I have not been able to carve out >> time for it. While I do think this project has a lot of potential, without >> some type of sponsorship in time and resources I don't see it moving >> forward. Thank you Roy for stepping up as the chair as well as the rest of >> the River team for contributing to this project over the years. It has been >> great watching the discussions in these threads. >> >> On a personal note, seeing this project move into the Attic while sad, it >> will hopefully be cathartic. My father, Peter C. Marks, was one of the >> original developers at Sun who worked on Jini. I remember him being very >> excited about the potential for the technology and he enjoyed demoing it. I >> even remember accompanying him to Amsterdam to demo it at a conference when >> I was younger. I have some of the original Jini books sitting in my office >> right now that have been signed by some of the original team members. >> >> I had hoped to see the project keep going, maybe with it moving into the >> Attic River can move forward in a different way. >> >> On Mon, Feb 7, 2022 at 6:41 PM Roy T. Fielding<field...@gbiv.com> wrote: >> >>> Hello everyone, >>> >>> It's that time of year when I try to figure out what I am doing and >>> what I am not, and try to cut back on the stuff that seems unlikely >>> to succeed. I suspect the same is true of others. >>> >>> I had hoped that more new people at River would result in more activity, >>> but that hasn't occurred over the past 9 months and doesn't seem likely >>> in the future. Aside from ASF echoes and Infra-driven website replacement, >>> there has been nothing to report about River the entire time that I have >>> been the chair pro tem, and there hasn't been any chatter by users either. >>> >>> Please feel free to let me know if I am missing something. >>> >>> If not, I'd like us to accept the reality of this situation and move the >>> River project to the Attic. The code will still be available there, and >>> folks are welcome to copy it under the license, move it to Github, or >>> otherwise seek to re-mold it into a collaborative project wherever is >>> most convenient for them. >>> >>> Cheers, >>> >>> ....Roy >>> >>> >> -- >> Jeremy R. Easton-Marks >> >> "être fort pour être utile"
