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 Wed, 24 Nov 2010 08:32:15 GMT
Sim IJskes - QCG wrote:
> On 11/24/2010 01:52 AM, Peter Firmstone wrote:
>> +1  For the current build.
> Voting does not allow for an extra qualification. Does this mean that 
> you will only vote +1 if a terminating clause is included?
> Gr. Sim
No just thinking out loud.

The last release is was compiled with Java 1.4, we need to get this 
release out, Patricia needed Java 1.5 language features for her new 
TaskManager implementation and I needed them for my concurrent policy 
implementation, but neither are being included in this release.  Perhaps 
our newest release too could be a Java 1.4 compiled release?

Java CDC on BlueRay and TV (these are networkable and support Java 1.4 
Security features) will be around as Java 1.4 compatible for some time 
to come, I'd like to enable interaction between our River Java SE 
release and with a subset River release for the Java CDC platform.

But we can make this release Java 1.6 only, we could still come up with 
a new way of defining codebase URL's, perhaps there might be a way of a 
service making platform specific codebases available.  One service, two 
proxy codebases.  Service implementations running on Java SE 1.6, 
servicing clients running on a Blue Ray Disk Player.  If this is 
possible and I think it is, we can simply use the previous release proxy 
codebases for such a thing, because nothing within them has changed.

In fact I think I like the latter option better, so assuming we can come 
up with a new URL scheme I would still vote +1 without conditions.

In a distributed environment there are multiple levels of compatibility:

    * Serialization - object serial form is transmitted separately,
      different codebases can share the same serial form.
    * Service API - Prefer Interface extension or encapsulation and
      replacement over interface evolution. We have no mechanisms to
      handle Interface evolution and neither does Java. (Patricia
      mentioned that this is in the pipeline for Java).
    * Proxy Binary compatibility is important, more so than compile time
      compatibility, because Codebases are compiled separately.
    * Generics cannot be supported across compile time boundaries,
      unless the Generic is specific eg: List<String> can be supported
      in Service API, but List<T> or List<? extends Fruit> cannot.

Jini has only the Discovery Protocols (and Codebase URL's), all other 
communications are across Service API boundaries, hence the end of 



View raw message