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"
