What about using a standard html param that indicates the java version? Would this allow those that support this different version to be transparent for those services that support it, whilst allowing ensuring non-breaking compatibility with those services that don't provide multiple versions? How much work would need to be done to ClassServer to be able to support this?
--Calum On 13 February 2011 23:31, Peter Firmstone <j...@zeus.net.au> wrote: > 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 <j...@zeus.net.au> >>> 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. > > > > > >
