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"
