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