Hi All, Based on the excelent work of (mainly) Peter Firmstone (et al) I am personally working on “River 4.0” right now and was planning to share my work with the community soon(tm).
1. Implementation of my old idea of making codebase annotations objects implementing a specific interface (instead of Strings containing space delimited list of URLs). One might think of it as “smart codebase annotations” being installers of software necessary to deserialise an object. 2. Refactoring of River codebase to make it modular (in terms of JPMS modules). 3. Some cleanup to modernise the codebase (ie. use generics instead of raw types, enums, records where possible/useful) What it gives us is: a) uniform representation of code and data: there is no need to have separate specifications for code metadata languages (manifests etc.). Examples: - module dependency graph is represented as serialised Java objects - Expressions specifying module compatibility (such as semantic version ranges) are provided as objects implementing a specific interface - in particular it is possible not to rely on version numbers but have “animal sniffers” that decide if local code is compatible with downloaded classes - installation packages can be provided as serialised objects (either with code serialised in-band or out-of-band depending on the needs) In other words: “everything is an object”. b) security To instantiate any class and deserialise an object - installer first makes sure code is verified before execution (the verification algorithm is pluggable as the installer can be any object implementing an interface). Installers are treated the same way - the code of the installer has to be verified first. The installer itself grants permissions to the code it installs and is constrained by any GrantPermissions it has. So no more unverified code execution - contrary to old Jini way of instantiating an unknown class to ask for a verifier. c) great flexibility of the way how code is downloaded and installed: - in particular it is possible to express a module dependency graph that can be instantiated in the client VM - since codebase annotations are objects that are also annotated - it is now possible to provide new protocols to download and verify software. d) since we can now express non-hierarchical module dependencies it is possible to implement scenarios not possible (or really cumbersome) to implement previously: - “adapter/wrapper services” - ie. smart proxies that wrap other services proxies. For example RemoteEventListener that pushes events to a JavaSpace. I am only doing it for fun and sentiment to Jini idea of mobile code. From reading the mailing list and taking part in some discussions here I can see there is almost no interest in moving River forward. And even if there is - there is no clear idea on what direction it should be. My own opinion on the matter is that the single DEFINING idea of Jini/River is mobile code. Without mobile code there is no reason for Jini to exist: - it is 2022 - there are so many excellent networking libraries on the market that River does not bring anything to the table - web protocols and new developments such as QUIC make River as a networking solution (even if excellent) less and less relevant. - River codebase is outdated and does not play well with the broad Java ecosystem (DI frameworks, pluggable logging, JFR etc.) - looks like “static linking” is the current buzz in the industry (either as executables or container images). On the other hand - having worked quite extensively with k8s/Helm/containers/Docker/microservices and what not - I still think there is still a (big) case for Jini style mobile code. But only if it is re-designed to be secure, robust and flexible. There is also Project Loom - it will make River scalable and - hopefully - relevant again. Michal > On 8 Feb 2022, at 01:41, 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 >
