Sim IJskes - QCG wrote:
Peter Firmstone wrote:
Christopher Dolan wrote:
Honest question: considering that Sun end-of-lifed Java 1.5 back in
October 2009, what's the value in continuing to support the Java 1.4
platform in River?
Honest Answer: Just a few billion blue ray players, set top boxes and
multifunction network printers and any other device that run Java cdc.
Shall we go for a full use of JDK6 facilities, with a pre-processor to
create a (or multiple) minimal version?
Might as well, you might want to consider supporting 1.4 with any proxy
code, your choice though. Feel free to use generics. You can still use
@Override too. In other words, the server side service is free to use
those features.
We need to consider what the minimum requirements are to consume or
export a Jini service. (Protocols, classes) and make that the core
platform, that has to support Java 1.4.
From there it would be recommended to make smart proxy classes and
Service Interfaces Java 1.4 compliant, however use later Language
classes where it makes sense to do so. We need to annotate the class
version (bytecode) and Package version into MarshalledInstance to ensure
non compatible clients and servers aren't mixed.
Cheers,
Peter.
We can prototype this with a ant/sed/awk script, We could strip the
@overrides, selectively include JDK6 dependend facilities, etc.
Wouldn't worry about it just yet, lets see how we go first.
Retrotanslator can convert Java 5 Bytecode, however it needs custom
Object Marshallers Input Output Streams written for serialization
support. It does support Annotations, Generics and the Concurrent
Utilities.
JSR14 seems are more sensible option to begin with.
Really, i do sometimes miss something like the C preprocessor, in
order to postprocess for different deployment scenarios. A //#ifdef
maybe?
Gr. Sim
