On 12/3/2010 11:29 PM, Peter Firmstone wrote:
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.
There are a couple of different places that a client can get "code" from. We
know about how ClassLoading can be controlled, remotely, using the annotation on
any MarshalledObject that a client receives. One of the interesting thing about
Entry use in the ServiceUI mechanisms is that the client is in control of when
the unmarshalling occurs. Therefore, it is possible for there to be multiple
service UIs with platform specific versioning contained in the associated
MarshalledObject. So, there could be a JDK1.4 marshalled UIDescriptor in
addition to others.
The current situation with how lookup returns an unmarshalled object limits a
client choice to much earlier "binding". That is, instead of being able to look
at multiple service matches and say "this one is not for me", it needs to,
instead, be connected with the service deployments via an Entry which might
indicate what "platform" the server can support. This is not always a problem
and I don't want to undervalue how Entry can be used to do this.
Deferred unmarshalling in lookup could provide some more powerful decision
opportunities for the client by allowing it to better manage when that occurs.
Gregg Wonderly
