On Dec 4, 2010, at 1051AM, Mike McGrady wrote: > The multiple-tier architecture and the modular architecture need to be kept > separate. There is a problem scaling modules that are based on tiers. This > will not work for us. Essentially this says we do not need the Java version > to be consistent with Java 1.5, but we do.
The comments below refer to having a modular build; being able to build River in such a way that you can specify different target sources (for one), so for example if Mahalo or Outrigger needed to be built with a source of 1.4 or 1.5 it could be accomplished, as opposed to having a singular monolithic build. This is really a completely different thing from a multi-tier architecture. One doesnt have anything to do with the other. > Modules except in architectures that do not have quality control criteria > (QCC) are inadequate to solve this problem will not work for real-world > problems. I'm not sure what this means. Regards Dennis > > Sent from my iPhone > > Michael McGrady > Principal investigator AF081_028 SBIR > Chief Architect > Topia Technology, Inc > Work 1.253.572.9712 > Cel 1.253.720.3365 > > On Dec 4, 2010, at 5:49 AM, Tom Hobbs <[email protected]> wrote: > >> Peter is right, with a modular build we could do absolutely anything. >> Which is why I believe that our next release should just use whatever >> JDK version we used for the last one. The let's go down the roadmap >> and talk about this again when we start to do something about it (but >> after we've modularised the build, I would guess.) >> >> I know that supporting many multiple JDKs has been briefly discussed >> and rejected, personally, I am kind of warming to that idea though. >> Yes it is; >> >> - additional work to add functionality >> - additional work to fix bugs >> - additional work for the modular build stuff >> >> Consider the following directory structure; >> >> $RIVER_HOME/component/src/org.apache.river.component.Thing >> $RIVER_HOME/component/jdk1.4/src/org.apache.river.component.Thing >> >> The first line signifies the River-recommended and most up-to-date >> version, later (and still supported) version then appear in >> subdirectories. Bugs would be raised against versions and >> bug-exposing tests need only be written in the most up-to-date (and >> supported) JDK; which can then be run across all versions and as long >> as we have sensibly named JAR files runtime confusion can be kept to a >> minimum. >> >> Also, with a modular build we need only add this complexity when we >> come across a component that would be improved by using a >> non-previous-JDK feature. And when that happens, the developer >> creates the "component/jdk1.4/src/..." directory duplicates the >> *affected classes only*, modifies the build accordingly and carries >> on. >> >> As long as we ensure that the build is satisfactory and that tests are >> run against all the supported JDKs we should be good to go. I accept >> that this is additional work and effort, for each additional >> enhancement and bug fix, but I wonder if it is worth paying that cost >> in order to keep supporting users who are locked (for whatever reason) >> into other JDK versions. >> >> Just my thoughts. >> >> On Sat, Dec 4, 2010 at 5:29 AM, Peter Firmstone <[email protected]> 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. >>> >>> >>>
