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
jgr...@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" <nic...@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, <jgr...@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
