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.
