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 00:52:42 GMT
+1  For the current build.

Although I still think we need to investigate a modular build, to enable 
compiling our proxy codebases to be compatible with JDK 1.4, for 
compatibility with earlier Jini releases running on earlier Java 
platforms.  I still would like to do a separate Java CDC release using a 
jini platform subset.  Doing either will only be possible if we make our 
build more modular.

Java CDC (Blue Ray & TV) looks to become a significantly larger client 
platform than Java SE, unless Java SE Embedded can break into the mobile 
phone market.

I've seen many OS / architectures become marginalised by neglecting the 
client.  Java is at risk here too.

We've got the benefit of infinite client flexibility with Jini, since 
the ServiceUI can be different for each client, even while utilising the 
same service.


Christopher Dolan wrote:
> I had previous advocated for 1.5 support.  But now that I've learned
> that Thread.interrupt() breaks classloading in 1.5 and that there's no
> feasible workaround for River, I'm eager to abandon that JRE version.
> So I vote for 1.6 only.
> Chris
> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org] 
> Sent: Tuesday, November 23, 2010 10:35 AM
> To: river-dev@incubator.apache.org
> Subject: JVM version policy Was: Re: Build failed in Hudson:
> River-trunk-jdk1.5 #3
> Sim IJskes - QCG wrote:
> ...
>> In order to make a decision/think of a fix i need a clear version 
>> support policy. Not something i need to trawl the mailing list
> archives 
>> for. Anybody else having the same opinion?
> ...
> +1 on the need for a clear version support policy without depending on 
> trawling the mailing list archives. We should discuss and vote on a 
> policy, and then document it on the web site.
> I am strongly opposed to attempting to support any version that we do 
> not routinely regression test. In practice, that means supporting at 
> most two releases. If we think we can handle two, I suggest 1.5 and 1.6.
> If not, I think 1.6 only.
> Patricia

View raw message