Well this is a tough one, here are some ideas:
1. Branch what we have now for release and simply reset the compiler
flag, to jsr14, which buys time until we have a more modular
build, then based on what we know then, decide if ongoing support
for remote clients using Java 1.4 is feasible. For this release,
test on Java 1.4, 5 and 6. We could adopt a policy that if a bug
exists on Java 1.4 or 5, but not on 6, then the fix is to upgrade
to Java 6. Users would of course be free to submit a patch, but
we wouldn't actively support the earlier platforms.
2. Compile on JDK 1.6 and support only Java 5 and 6, drop support for
communicating with remote Java 1.4 clients. If we find that it is
later possible to support Java 1.4 clients with the modular build,
users can skip the current release. Users can work around the
Java 1.4 communication issue if they need to, by using proxy
codebases from the previous release only.
Patricia's right, just because Sun didn't do it, doesn't mean we can't.
Jini didn't succeed because it was maligned, J2EE was corporate Java,
Jini wasn't marketed to the corporate environment and wouldn't gain much
foothold now anyway, the toaster marketing didn't succeed either.
The one market that has captured the imagination of so many programmers
when it comes to Jini's and now River's promise is that of Ubiquitous
computing, the internet, has never been targeted, although Jini started
moving in that direction with Jini 2.1. Private networks are corporate
environments, although River / Jini has some niche markets in
specialized areas, River's true hope for success is the internet and the
internet developer community, who seem happy to try almost anything.
Don't forget the embedded market, Java SE Embedded (Java 1.6) is MVM and
has the Isolates API, in some ways, it's superior to Java SE, River can
still shine here too.
It is true that I'm not currently working on an implementation for Java
CDC, this would be a subset platform, because it's missing much of RMI,
it can still use Discovery V2, since that is based on
MarshalledInstance, not MarshalledObject. Dropping support for
communication with Java 1.4 based platforms long term means any Java CDC
implementation would have to play in its own universe, there would still
be other communications means available, like plain old serialization
and Surrogate. It would limit the possibility of creating interactive
ServiceUI, because there would be no current compatible Server platform
for SE. If the consensus is to go Java 5 and 6, and Drop 1.4, it will be
unlikely that I'll do anything with Java CDC for the above reasons, but
this wont dampen my spirit for River, were forging ahead in leaps and
bounds. We can't all agree all the time, but it's important we have the
discussion.
I think you touched on something earlier, it's important we address ease
of deployment.
Cheers,
Peter.
Patricia Shanahan wrote:
Sim IJskes - QCG wrote:
...
We are not going to create a communication universe where every
machine talks jini to every other machine. This was a goal Sun had.
They did not succeed. Are we going to?
...
There is nothing magic about Sun.
The question of whether we can achieve something Sun didn't depends on
why they didn't. Obviously, Sun had more programmers than we have. On
the other hand, those programmers were always limited by conflicting
demands on their time and energy.
I used to work for Sun - nothing to do with Jini, I was performance
architect for a couple of Sun's large servers - but I worked with a
lot of Sun programmers. They were capable, but no more so than the
current River team.
Sometimes a small group operating without management interference can
achieve things that would be impossible for a large organized team.
I think we should look at the usability and migration consequences of
the various options, and do the best we can with reasonable effort. In
particular, I would like to see a migration path that does not require
all communicating systems to change JVM version simultaneously.
Patricia
