Patricia Shanahan wrote:
On 9/14/2010 2:55 AM, Peter Firmstone wrote:
Tom Hobbs wrote:
In my mind, it's an attractive proposition to drop support for the
older
JVMs and go straight into 1.5 - however I'm only one user and I
wouldn't
have a problem if River did that.
I think this question should be asked on the River Users list as
well. If
there are active users out there who monitor River updates and the
lists
then getting their feedback might make our decision easier.
That's a good point Tom, this project does need more focus on users.
I think we should also ask users whether to do a smaller release soon
or wait until we have more content. In the longer term, I am a
believer in basing performance work on measurement. My current
TaskManager scalability mission cries out for access to a real
workload that exhibits scalability problems.
In this case it would be about offering the user less and asking if it's
ok.
The only thing that Java 1.5 offers in Proxy code and Service API are
some additional classes, not much good for API, but useful for some
smart proxy's needing concurrency perhaps. But this is already possible.
Once we take the users mind away from supporting Java 1.4 in Service
API, however, we have to explain the difficulties of using Generics in
Service API. For example you can use Specific generics List<Apple>, but
not bounded wildcards, like List<? extends Fruit>, or List<T>
We will have to solve those problems anyway to go to 1.6, the current
Java release. I am currently having to work around the lack of the 1.6
features in java.util.TreeSet.
When making changes, it's important to understand the impacts of the
change before making the decision. We must consider the distributed
environmental impacts, not just the local jvm impacts.
I propose we go to Java 6 now and drop support for older jvm's as
proposed, but continue to compile platform smart proxy's and Service API
with target = 1.4
The kind of backward compatibility I'm talking about is, I have 200 nice
shiny new racks units, with Java 6, Apache River 2.2.0 and it's going to
play nicely with my other 400 Java 1.4 RU with Jini 2.1 and 600 Java 5
RU with Jini 2.1.
I'm not proposing we support new installations of Java 1.4 or 5 with
this release, just that we don't cause issues with existing
installations. Lets keep our users on the upgrade path, I'm not sure
we've convinced the big corporate users to migrate to Apache River from
Jini 2.1 yet, in fact Orbitz migrated away. Gigaspaces has a large user
pool, lets ask them? If users plug in Apache River 2.2.0 and
incompatibility issues arise, they're not going to replace their Jini
2.1 boxes, in which they've gained confidence, they're going to pull the
plug on Apache River.
The failure I experienced with the RemoteEvent and the Java CDC
experiment, was caused by trying to retain Serialized form compatibility
with previous releases, while changing object fields. If were going to
have islands of compatibility, it doesn't bode well for an internet
based River.
Adopting a mindset of Service compatibility by honoring existing
platform Service API still allows a great deal of flexibility and change.
We can change the back end implementation, we can change the proxy
implementation, if we migrate away from a monolithic build, we can have
multiple service implementations for multiple platforms.
At the absolute minimum, we should compile Reggie's Proxy and API with
target=1.4, the reason is, ServiceRegistrar and ServiceItem allow
services to fail to unmarshall, it's in their contract, in which case
incompatible Services are simply not used by older clients.
I don't want to have to answer user queries like: "I've set up a new
djinn group for my new Apache River nodes, but my existing Jini nodes
can't discover the new group. The new nodes are using my existing
programs and they work among themselves, but the new Registrars aren't
working with my older nodes. The new nodes services work with my old
clients only if they register with existing Registrars. Reggie seems
broken in Apache River 2.2.0?"
If MarshalledObject's serialized form remains the same, but the bytecode
becomes incompatible, you still discover the service, you just can't use it.
These are the classes in the Reggie proxy, I'll do a ClassDep run and
find the platform dependents:
$ tail -100 reggie-dl.deps
com/sun/jini/action/GetBooleanAction.class
com/sun/jini/logging/Levels.class
com/sun/jini/logging/Levels$ClassReplacingObjectOutputStream.class
com/sun/jini/logging/Levels$LevelData.class
com/sun/jini/logging/LogUtil.class
com/sun/jini/reggie/AdminProxy.class
com/sun/jini/reggie/ClassMapper.class
com/sun/jini/reggie/ClassMapper$EntryField.class
com/sun/jini/reggie/ClassMapper$FieldComparator.class
com/sun/jini/reggie/ConstrainableAdminProxy.class
com/sun/jini/reggie/ConstrainableEventLease.class
com/sun/jini/reggie/ConstrainableRegistrarLeaseMap.class
com/sun/jini/reggie/ConstrainableRegistrarProxy.class
com/sun/jini/reggie/ConstrainableRegistration.class
com/sun/jini/reggie/ConstrainableServiceLease.class
com/sun/jini/reggie/EntryClass.class
com/sun/jini/reggie/EntryClassBase.class
com/sun/jini/reggie/EntryRep.class
com/sun/jini/reggie/EventLease.class
com/sun/jini/reggie/Item.class
com/sun/jini/reggie/Matches.class
com/sun/jini/reggie/ProxyVerifier.class
com/sun/jini/reggie/Registrar.class
com/sun/jini/reggie/RegistrarEvent.class
com/sun/jini/reggie/RegistrarImpl_Stub.class
com/sun/jini/reggie/RegistrarLease.class
com/sun/jini/reggie/RegistrarLeaseMap.class
com/sun/jini/reggie/RegistrarPermission.class
com/sun/jini/reggie/RegistrarProxy.class
com/sun/jini/reggie/Registration.class
com/sun/jini/reggie/RenewResults.class
com/sun/jini/reggie/ServiceLease.class
com/sun/jini/reggie/ServiceType.class
com/sun/jini/reggie/ServiceTypeBase.class
com/sun/jini/reggie/Template.class
com/sun/jini/reggie/Util.class
Peter.
