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
