Dennis Reedy wrote:
On Dec 2, 2010, at 618AM, Peter Firmstone wrote:
Patricia Shanahan wrote:
On 12/1/2010 4:53 PM, Dennis Reedy wrote:
...
Some of the discussion has referenced Java CDC on BlueRay. Should
these platforms have an overriding influence on whether River moves
forward and adopts 1.6 as a baseline? I'm not so sure at this point.
Is the relevant Java dialect identical to 1.4? If not, we would need a separate
project to make portions of River run on it.
Patricia
BDJ is a subset of Java 1.4, the bytecode is Java 1.4 compatible, it has Java
1.4 Security, JSSE and JCE. It lacks Swing, has some AWT and a UI suited to
television. It has networking, dynamic ClassLoading and Serialization but most
of RMI is missing. To gain adequate privileges, an application jar file must
be signed.
This would require a separate River release, (Brook?) It would have Service
API, but lack service implementations, it could be used as an application
client or provide services, but could never support the full Jini platform.
However this should not hold back the River Jini platform, which should take
advantage of newer Java language features.
The build we have now is monolithic, which means we can't compile proxy's
separately. To remain network compatible with Java 1.4 proxy's need to be
compiled with java 1.4 or a later platform using jsr14 to produce java 1.4
compatible byte code. However once we have a modular build,
I've been trying to carve out some weekend time to begin the creation of a
River maven project that would provide the level of decomposition required here
(this also would mean the removal of classdepandjar, and use straight forward
dependencies based on the conventions that we have discussed to resolve
intra-service dependencies). If we have api/proxy modules, they can be targeted
for a specific platform. My only excuse to not starting this is its just tough
to carve out the time. I know I should stop whining and just do it, hopefully
soon.
+1 Peter.
it may be feasible to introduce the latest version of river, which will require
a late version of Java to run on, to communicate with earlier existing Jini and
River installations which to date are still Java 1.4 compatible.
This does not mean that the River platform cannot utilise later java language
features, it doesn't need to run on Java 1.4, just communicate with it.
If the java 1.4 bytecode is too difficult to support for our proxy's, which may
be the case, then we'll need to decide which later platform will be the minimum
bytecode for our proxy's.
Dennis, do you have any thoughts on how to support platform transitive
dependency's?
Could it be as simple as a service specific attribute that clients can match on?
Perhaps, giving the client the opportunity to select the most suitable
codebase from a list?
I wonder about other services or exported objects passed to the service
though, they also need to download a suitable codebase.
