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, 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?
Peter.
