+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.
Peter.
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:p...@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
