On Dec 4, 2010, at 12:54 PM, Dennis Reedy wrote: > > 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.
My mistake. I thought "modular" was being used in the traditional sense. > > >> 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. >>>> >>>> >>>> > Michael McGrady Chief Architect Topia Technology, Inc. Cel 1.253.720.3365 Work 1.253.572.9712 extension 2037 [email protected]
