river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3
Date Sat, 04 Dec 2010 20:54:52 GMT

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.



> 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 <tvhobbs@googlemail.com> 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 <jini@zeus.net.au> 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
>>>>>>> forward and adopts 1.6 as a baseline? I'm not so sure at this
>>>>>> Is the relevant Java dialect identical to 1.4? If not, we would need
>>>>>> 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
>>>>> Java 1.4 Security, JSSE and JCE.  It lacks Swing, has some AWT and a
>>>>> suited to television. It has networking, dynamic ClassLoading and
>>>>> Serialization but most of RMI is missing.  To gain adequate privileges,
>>>>> 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
>>>>> 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
>>>> 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
>>>> 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
>>>>> 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
>>>>> 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.

View raw message