In my opinion, the simple fact of the matter is that the existing user base of Jini is really tiny, and generally what can be considered "legacy". There is precious little new Jini development occurring - and probably all 10 of us worldwide are on this list :-)
I have to agree with Peter's sentiments - Jini in it's entirety, both
spec and river implementation - needs to evolve organically based on a
changing environment.
I am all in favour of improving and making the specification more
relevant to modern development, over being tied to an old, fixed
specification that is not evolving.
The fact that Jini standards are static, and there is no process in
place to evolve them, is actually really concerning. I think they *must*
evolve.
And given the vision, experience and efforts of people like Peter, it
would almost be criminal to not break free from an old standard, to miss
the potential of what may be.
For practical reasons, and the sanity of all involved, I think it's a
good idea to release River 3.0 without stirring the standards, just to
have a more modern,
massively fixed implementation available - it's been a long time since a
release.
But after that, I really think the Jini standards will, and have to,
evolve to a changing world, or become totally irrelevant. In the
open-source model, nobody is going to bother with an irrelevant
standard, they will just badly re-invent it.
Every day that I see some half-baked "micro services" or "distributed
computing" framework written in ECMAScript, which are invariably poor,
un-researched attempts at what OSGi or Jini already thought about, I
cringe. Yet, these frameworks get much more attention. The only way to
get Jini back into the space, is to find a killer app (and I firmly
believe that, and I hate this term, "Internet of things" is, and always
has been, it), and to get some real dynamics going with the community.
The last thing that process wants is to be burdened by some "standard"
from 1998 which is, actually, not widely used at all. I'm all for evolution.
regards,
Dawid
On 04/09/2015 10:40, Peter wrote:
> Threats to development and collaboration (as I see it):
>
> 1. The Jini standards are sacrosanct.
> 2. River is an implementation of the Jini Standards.
> 3. River has no public api other than the Jini standards.
> 4. Although public API can be improved in a backward compatible
> manner, the mandatory Jini Standards should not be.
> 5. The Jini standards are static; there is, at present, no process
> for standards review or replacement.
>
> This is the message I’m receiving, is this the message we want to send
> would be River developers?
>
> Sun Labs was isolated from the rest of Sun, to ensure developers were
> able to innovate, how can River innovate now?
>
> Here’s an example of a problem with the Jini public api, there are
> many as such, I’d like to fix, but for the sake of harmony on
> river-dev, I don't discuss them, instead I document and work around
> them if I can, I only discuss issues I can't work around:
>
> The following is an implementation comment from
> org/apache/river/impl/lease/AbstractLeaseMap.java
> /**
> * AbstractLeaseMap is intended to work around some minor design warts
> in the
> * {@link Lease} interface:
> *
> * In the real world, when a Lease is renewed, a new Lease contract
> document
> * is issued, however when an electronic Lease is renewed the Lease expiry
> * date is changed and the record of the previous Lease is lost.
> Ideally the
> * renew method would return a new Lease.
> *
> * Current Lease implementations rely on a {@link Uuid} to represents
> the lease,
> * the expiry date is not included the equals or hashCode calculations.
> For this
> * reason, two Lease objects, one expired and one valid, may be equal,
> this
> * is undesirable.
> *
> * The Lease interface doesn't specify a contract for equals or hashCode,
> * all Lease implementations are also mutable, previous implementations
> * of {@link LeaseMap} used Leases as keys.
> *
> * AbstractLeaseMap uses only the {@link ID}, usually a {@link Uuid}
> * provided by a Lease for internal map keys, if {@link ID} is not
> implemented
> * then the Lease itself is used as the key.
> *
> * Both Lease keys and Long values are actually stored internally as
> values
> * referred to by ID keys, allowing Lease implementations to either not
> override
> * hashCode and equals object methods or allow implementations that more
> * accurately model reality.
>
> Documentation from the Map interface states:
>
> Note: great care must be exercised if mutable objects are used as
> map keys. The behavior of a map is not specified if the value of an
> object is changed in a manner that affects equals comparisons while
> the object is a key in the map. A special case of this prohibition
> is that it is not permissible for a map to contain itself as a key.
> While it is permissible for a map to contain itself as a value,
> extreme caution is advised: the equals and hashCode methods are no
> longer well defined on such a map.
>
> You can't tell me this is well designed, it might be standardised, but
> it's also flawed.
>
> The first issue is, if I make an attempt to address this issue, there
> will be strong resistance to doing so. Who remembers what happened
> when I tried to create a Startable interface for starting services?
> It's now only an implementation detail? It was a very frustrating
> discussion, one developer hasn’t returned, yes I didn’t handle it
> well, at the time, I deliberately drove that developer away out of
> frustration.
>
> But the outcome has not been beneficial, there were no winners, not
> only did we lose a community member, even experienced developers are
> still exporting from constructors, new users will read our examples
> and unsafely export their services from within constructors and if
> they're using River 3.0, they're going to experience problems, how's
> this going to help adoption? River 3.0 can hammer a service with
> multiple threads, running at native socket speeds, if there's a
> concurrency bug, River 3.0 will expose it. With River 3.0, all
> hotspots are native methods.
>
> I think with River 3.0, we need a statement in the README file that
> says, River 3.0 does not support exporting services from object
> constructors.
>
> It's not so much a question of is River 3.0 ready for release, but is
> the world ready for River 3.0?
>
> Too much time is consumed debating and analysing, too little on
> development, we are suffering from standards concensus paralysis. It's
> fair to say that this has a negative effect on developer motivation.
> We spend days arguing about something that takes 20 minutes to
> implement, meanwhile development stalls and people complain of
> slipping release dates.
>
> During project incubation, we had a philosophy of doers decide, so if
> you wanted to veto something you needed to implement something else
> that solved the original issue. But now we have returned to a
> concensus model and we lack the ability to make progress when we
> cannot achieve concensus.
>
> It sounds like Git could help us a lot with our development
> collaboration problem.
>
> With Git, we could have an “Official Jini Standards release branch.”
> For those of us that bump into the limitations of the Jini Standards
> API, we need another branch: “Jini standards with extensions”.
>
> In this extensions branch, we can have innovation... If parts of this
> branch gain concensus, we then integrate these stable components into
> the Jini Standards, without requiring a namespace change that breaks
> compatibility.
>
> So think of one branch as the concensus branch and the other is the
> doer's decide branch.
>
> Those of us who want to further River aren't a threat to the existance
> of existing implementations. Git will enable us to maintain a shared
> codebase.
>
> For example the Lease interface could contain a default method:
>
> public interface Lease {
>
> final long FOREVER = Long.MAX_VALUE;
> final long ANY = -1;
> final int DURATION = 1;
> final int ABSOLUTE = 2;
> long getExpiration();
> void cancel() throws UnknownLeaseException, RemoteException;
> void renew(long duration)
> throws LeaseDeniedException, UnknownLeaseException, RemoteException;
> void setSerialFormat(int format);
> int getSerialFormat();
> LeaseMap<? extends Lease, Long> createLeaseMap(long duration);
> boolean canBatch(Lease lease);
>
> default Lease renewal(long duration) throws LeaseDeniedException,
> UnknownLeaseException, RemoteException
> {
> renew(duration);
> return this;
> }
>
> }
>
> The next thing would be to write a contract for Lease equals and
> hashcode methods.
>
> Q: How does this help?
> A: It reduces maintenance, simplifies debugging, reduces mutable state
> and clarifies ambiguity in implementing the existing interface.
>
> All River’s Lease implementations in the Jini standards extended
> edition, would be immutable and override the new method and return a
> new copy, the renew method would be implemented so the Lease would
> replace itself in the LeaseMap. LeaseMap implementations would replace
> the existing Lease with the renewed Lease. The implications are
> subtle, but it simplifies the implementation of Leases greatly.
>
> For those that remain sceptical, existing third party Lease
> implementations and the strict Jini standards edition would still be
> interoperable, although less defined, this would be an example of
> stable backward compatible api evolution. If there was concensus, this
> change could be incorporated into the Jini standards. The Jini
> standards extended edition would be fertile ground for developers to
> innovate without threatening the existing user base.
>
> An example of hampered development is my recent research into River
> service security. I found that River still depends on Serialization
> for security.
>
> No other software today relies on Serialization for security? Do we
> really want this?
>
> The results of my investigation indicated that the serialization
> protocol wasn’t at fault, but the input stream needed to be filtered
> much like a web server filters input. Securing serialization by
> filtering input, would allow bootstrap proxy’s to be securely obtained
> from lookup services by clients.
>
> Unfortunately due to ObjectInputStream's api, it isn't possible to
> have pluggable input filters like a web server, but it was possible to
> use the existing protocol and remain serial form compliant.
>
> Now this atomic serialization was an implementation fix, relevant only
> to Entry’s and bootstrap proxy’s, it's selection would have been by
> configuration and security constraints. No users had to implement it;
> it wasn’t part of the api, but it would provide them with secure
> bootstrap proxy’s. If users wanted to use this in their own services,
> they could have done so, with significant performance, evolution and
> security benefits.
>
> The consensus on river-dev was that we should limit the amount of data
> that could be downloaded through an input stream, but serialization
> wasn’t a River project concern. The sad reality is that you can’t
> limit the amount of data through the input stream, because it breaks
> once you hit that limit. The recommendation can’t be implemented, but
> I figured the odds of acceptance were low and let it go. It was shut
> down before I had opportunity to present the code for peer review.
>
> Why isn't the message: "Ok, lets have a look at the code, can you
> explain more?" This was how the OpenJDK project responded. Due to
> other constraints, it couldn’t be fully adopted by OpenJDK, but at
> least they listened and implemented some of the functionality.
>
> So now we live with a legacy; we have this broken proxy trust model
> that burdens users. I would still like to fix it.
>
> As a River developer, I’m being boxed in by Jini Specifications, I can
> only fiddle with the implementation and fix bugs. I can build software
> around it, but I’m prohibited from fixing fundamental design flaws.
>
> I had to pause and think before sending this email, I don't want to
> stir up arguments on the list, but then I also feel the need to talk
> about it.
>
> I thank you for your honesty and hope you'll respect me for mine,
> perhaps we can reach a compromise that has mutual benefits, I
> understand we can't all agree, but we need to find a way to make
> progress when we don't.
>
> Thank you,
>
> Peter.
>
>
signature.asc
Description: OpenPGP digital signature
