Sorry, I disagree. I think, I'm not sure what your (Peter) "+1" was for.
Whether River continues to support this version or that version or
neither needs to be more considered. I also don't want it to hold up
graduation. This is what I propose;
1. Lets do this bug-fix release, using whatever versions we used for
the previous release
2. Come up with a roadmap, something like:
A: Define JVM compatability policy and confirm on user list
B: Modularise build and migrate namespaces
C: Complete build/release mechanism on required JDKs
D: First build after graduation
E: Help users to migrate
F: Cool stuff
2. Grind the graduation wheels
3. Start knocking tasks off the roadmap, discussing, voting and
agreeing (or not) on each step
Sorry, something in one of Sim's post earlier struck a nerve. We seem
to be a bit paralyzed and don't seem to be getting anywhere. Let's
clear our plates of stuff, finish the minimum we need for graduation,
graduate, and then launch into these discussions and so on.
Let's make the priority graduation, until that's achieved everything
else just feels a bit like procrastination.
Obviously the above is my opinion and subject to change without warning... :-)
On Wed, Nov 24, 2010 at 8:32 AM, Peter Firmstone <j...@zeus.net.au> wrote:
> 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.
>
