river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject [VOTE] Java Version for Jini Platform Service Servers
Date Wed, 29 Dec 2010 22:16:52 GMT
Java Minimum Version for Jini Platform Service Server side implementations:

Java 6:
+1 Peter Firmstone


Java 5:



Java 1.4:





Background:

Servers are the implementation side of Jini platform services, like 
Outrigger, Reggie et al, it has been proposed to take advantage of java 
concurrency features to fix issues that exist in current implementations. 

Using a modular build, planned for River after renaming com.sun.jini.* 
to org.apache.river.impl.*, the Service Server implementations can be 
built separately from the Jini Platform.  The Service API for these 
services would remain in the Jini Platform build.

The River Jini platform implementation would be similar to the existing 
release, minus the Service Server implementations.  This vote doesn't 
apply to the Jini Platform, which will still support earlier platforms 
for the time being, it only applies to the Service Server side 
implementations.

Requiring a later version of Java for Service Server side 
implementations won't affect clients on earlier platforms (proxy's will 
still be compiled as Java 1.4 compatible for now), this will only affect 
deployment of Services, not their clients.

Please add any additional reasons for requiring a particular platform below:

Christopher Dolan wrote:
> I would list bug fixes (specifically "no Thread.interrupt() classloader
> corruption") or maybe performance enhancements as the major reason for
> JDK 6 rather than newer features.  Outside of Swing and JAXB, there
> aren't very many compelling new features in JDK 6 that I'm aware of, and
> certainly not many that River would care about.
>
> Chris


Patricia Shanahan wrote:
> I am indeed working on the assumption of Java 5 for FastList. It is 
> going to be very difficult to get the combination of speed and solid 
> correctness without depending on the Java 5 memory model, specifically 
> the volatile guarantees, and on atomics.
>
> The current implementation is subject, under sufficient stress, to 
> intermittent dropped entries and NullPointerException failures. 
> Although these problems are easiest to reproduce by stress testing 
> FastList directly, the investigation was triggered by an isolated 
> failure of an Outrigger JavaSpaces QA stress test.
>
> I suggest a formal vote on Java 5 for servers ASAP, so that we know 
> where we are.
>
> Patricia
>
>
> jgrahn@simulexinc.com wrote:
>> My understanding was that we had decided to require Java 5 or 6 for 
>> servers (owing mostly to the concurrent packages), though the 
>> client-side requirements were left unresolved.   I thought Java 5+ 
>> items were being used in the ongoing FastList refactor.
>>
>> If I was mistaken, obviously some of what I did was invalid.
>>
>> jamesG
>>
>> -----Original Message-----
>> From: "Niclas Hedhman" <niclas@hedhman.org>
>> Sent: Wednesday, December 29, 2010 11:49am
>> To: river-dev@incubator.apache.org
>> Subject: Re: light refactoring
>>
>> On Wed, Dec 29, 2010 at 2:37 PM,  <jgrahn@simulexinc.com> wrote:
>>
>>> Replacing iterator usage with the enhanced for loop (for each).
>>> Added generic usage to internal methods/fields.  (Internal use 
>>> appeared to be non-controversial, and might ease future development.)
>>> Removed unused imports.
>>
>> I am curious; Has there been a "move to Java 5" decision already??
>>
>> Cheers
>
>


Mime
View raw message