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 technology. 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. Regards Dennis 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
