Greg Trasuk wrote:
On Sat, 2011-02-12 at 04:51, Niclas Hedhman wrote:
On Sat, Feb 12, 2011 at 8:57 AM, Peter Firmstone <[email protected]> wrote:
Note that I too develop using Java 5 language features, so I'm not placing
any constraints on where River's headed, I accept recent developments,
people have their goals and dropping 1.4 compatibility seems the easiest way
to achieve them.
I would encourage people to open their minds to the investigation of modular
development, Java 7 and 8 are around the corner and the same thing will have
to happen for Java 5 at some point.
Doesn't these paragraphs capture the need for a new specification? A
standardized way to specify the "Minimum Runtime Requirement" for the
Service Proxy, so that lookup operations can ensure that clients only
find compatible proxies...
Not only would JRE variant be needed, but potentially also OS, network
features, and if you envision Android client deployment down the line,
you would probably also like to include incl/excl of GPS, camera,
compass and other physical devices and their respective properties
(e.g. resolution, accuracy,...)
(Forgive me if I have missed this and this is already part of the core specs.)
I'm pretty sure you could cover most of this with registration entries.
e.g. have an RuntimeEnvironment Entry with two fields, 'attribute' and
'value', then the service can include 'JDK1_5_COMPATIBLE'='true' or
something similar. I'm not sure if you can have multiple entries of the
same type with different values (got to check the spec), but you could
certainly filter the entries prior to using the service, or make it part
of proxy preparation.
I suspect it needs to be part of the codebase annotation, the future
will probably bring more fragmentation for the Java platform rather than
less. Right now, we're tied to the Sun implementation of Java 5 or 6.
The potential is there to provide 2 or more codebases for a Service and
let the client choose which to download, based on what's most
compatible, that will let you use Java 7 features as well as support
Java 5. I think people are still used to the forklift upgrade approach,
where everything is upgraded at the same time, leading to a period where
information has to be transferred between incompatible systems. If
we're serious about doing migration properly, it would be more like
natural attrition.
Remember it's not the Jini platform API that will require later language
features when they arrive, there are even caveats to using some Java 5
language features in Service API now, like generics, annotations are
ok. Pretending platform variations don't exist won't help people deal
with the issues when they arise.
Regards,
Peter.
