+1 for the current build I'm all for this, I think it's a good idea.
We need a clear definition of which classes/sources have to remain 1.4 compatible though. At the moment, I think that is mainly intrinsic knowledge held in people's (apart from mine) heads. Patricia's right though, we will also need appropriate regression tests for all supported JDKs. Ideally I'd like to see the build split up, the bulk of the code move up to JDK 1.6 and a clear definition of what must remain 1.4. On Wed, Nov 24, 2010 at 12:52 AM, Peter Firmstone <[email protected]> wrote: > +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:[email protected]] Sent: Tuesday, November 23, >> 2010 10:35 AM >> To: [email protected] >> 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 >> >> > >
