river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3
Date Thu, 25 Nov 2010 14:01:46 GMT
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 

I think you touched on something earlier, it's important we address ease 
of deployment.



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

View raw message