Sim IJskes - QCG wrote:
On 11/24/2010 01:52 AM, Peter Firmstone wrote:
+1 For the current build.
Voting does not allow for an extra qualification. Does this mean that
you will only vote +1 if a terminating clause is included?
Gr. Sim
No just thinking out loud.
The last release is was compiled with Java 1.4, we need to get this
release out, Patricia needed Java 1.5 language features for her new
TaskManager implementation and I needed them for my concurrent policy
implementation, but neither are being included in this release. Perhaps
our newest release too could be a Java 1.4 compiled release?
Java CDC on BlueRay and TV (these are networkable and support Java 1.4
Security features) will be around as Java 1.4 compatible for some time
to come, I'd like to enable interaction between our River Java SE
release and with a subset River release for the Java CDC platform.
But we can make this release Java 1.6 only, we could still come up with
a new way of defining codebase URL's, perhaps there might be a way of a
service making platform specific codebases available. One service, two
proxy codebases. Service implementations running on Java SE 1.6,
servicing clients running on a Blue Ray Disk Player. If this is
possible and I think it is, we can simply use the previous release proxy
codebases for such a thing, because nothing within them has changed.
In fact I think I like the latter option better, so assuming we can come
up with a new URL scheme I would still vote +1 without conditions.
In a distributed environment there are multiple levels of compatibility:
* Serialization - object serial form is transmitted separately,
different codebases can share the same serial form.
* Service API - Prefer Interface extension or encapsulation and
replacement over interface evolution. We have no mechanisms to
handle Interface evolution and neither does Java. (Patricia
mentioned that this is in the pipeline for Java).
* Proxy Binary compatibility is important, more so than compile time
compatibility, because Codebases are compiled separately.
* Generics cannot be supported across compile time boundaries,
unless the Generic is specific eg: List<String> can be supported
in Service API, but List<T> or List<? extends Fruit> cannot.
Jini has only the Discovery Protocols (and Codebase URL's), all other
communications are across Service API boundaries, hence the end of
protocols.
Cheers,
Peter.
