river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3
Date Thu, 02 Dec 2010 00:53:36 GMT
I would encourage that as you move along your roadmap, once the namespace is changed to org.apache.river,
that River mandates 1.6 as a baseline. Migration guides and/or utilities can be provided to
assist in the transition from legacy Jini to River. I dont think it's unreasonable to draw
this line in the sand.

From my point of view backwards (pre 1.6) compatibility is required for client's that are
not running on a 1.6 JVM. Service implementation does not seem to be the issue. If a wholesale
replacement of the distribution is required, the requirements of the new distribution (River)
must be met by those wanting to use the technology. Going forward, perhaps River should consider
providing semantics for obtaining proxies that support specific versions of not only direct
dependencies but also transitive dependencies (including JVM version requirements). In this
way service producers can ensure that they support legacy clients that require outdated platform

Some of the discussion has referenced Java CDC on BlueRay. Should these platforms have an
overriding influence on whether River moves forward and adopts 1.6 as a baseline? I'm not
so sure at this point.



On Dec 1, 2010, at 707PM, Patricia Shanahan wrote:

> Peter Firmstone wrote:
> ...
>> The use of concurrent language features should be part of implementation rather than
our public API, so in theory at least, the
>> jvm local components can utilise the latest language features and
>> run on the latest java platform while remaining network compatible
>> with older platforms and releases.
> If everyone where running the current Java version, then whether we used
> particular API classes or not would indeed be implementation. The
> problem is getting the current Java version installed and available to
> us on *every* River-running system. Until we can do that, we can't use
> its features.
> I'm scared that we are not QA testing with 1.4, and so may have
> accidentally introduced things that don't work with 1.4, but have not
> made a decision to abandon it.
> ...
>> Concurrency is the future, at some point we've got a bullet to bite.
> ...
> From my point of view concurrency is also the present and the past.
> I remember my delight, in about 1983, when I switched from working on a
> multi-processor operating system to a compiler, and found I could do
> things like single stepping through code with the program doing exactly
> what it would have done at full speed, with no interrupts, timeouts, or
> other asynchronous changes in state. Amazingly, delightfully convenient.
> But, yes, concurrency is spreading, and is not just for servers and
> professional workstations any more.
> Patricia

View raw message