Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: 209.147.113.130 is neither permitted
 nor denied by domain of mmcgrady@topiatechnology.com)
References: <862502422.8331290517859184.JavaMail.hudson@aegis>
 <4CEBDFC0.90506@qcg.nl>
 <AANLkTi=x13MS-gUsXMEWyrsm8UjCY-ghpTmO1WnQ+yjt@mail.gmail.com>
 <4CEBE8B0.2020806@qcg.nl> <4CEBED3F.3080504@acm.org>
 <77F1E32F67C8D5479858C0C7E93EB46503E19BB8@WAL-MAIL.global.avidww.com>
 <4CEC61DA.3030702@zeus.net.au> <4CECC1A5.7070804@qcg.nl>
 <4CED1D08.3030101@acm.org> <4CED23EA.1020208@qcg.nl>
 <4CF6688A.7070201@wonderly.org> <4CF685DA.3080000@acm.org>
 <4CF6D8B8.6090006@zeus.net.au> <4CF6E337.4050402@acm.org>
 <F5422BBB-9F0C-4936-AAF6-A90969644E3B@gmail.com> <4CF6F077.7030704@acm.org>
 <84380CFD-746A-4F3C-9F53-E1B2493CF71F@topiatechnology.com>
 <1291266017.16266.3373.camel@cameron>
 <75124B2C-1116-4A35-A186-FDA769E0BC52@topiatechnology.com>
 <EDBE9047-7BA9-4B1C-82F9-AE955428F5AE@gmail.com>
 <4CF88A67.5000606@zeus.net.au>
 <ED0F22E9-E5B3-416A-AECC-DE08A5FAB25C@topiatechnology.com>
 <4CF8932A.3030401@zeus.net.au> <4CF89E67.3080407@acm.org>
 <1A3CC0B1-CC23-459D-9274-2FAB74DEB662@topiatechnology.com> <4
 CF9AB64.3070609@zeus.net.au>
In-Reply-To: <4CF9AB64.3070609@zeus.net.au>
Mime-Version: 1.0 (iPhone Mail 8C148a)
Content-Type: text/plain;
	charset=us-ascii
Message-Id: <D9FC2202-966F-4924-9BB3-44076D76CF7F@topiatechnology.com>
Content-Transfer-Encoding: quoted-printable
From: Mike McGrady <mmcgrady@topiatechnology.com>
Subject: Re: JVM version policy Was: Re: Build failed in Hudson:
 River-trunk-jdk1.5 #3
Date: Sat, 4 Dec 2010 07:22:48 -0800
To: "river-dev@incubator.apache.org" <river-dev@incubator.apache.org>

We could not tolerate JavaSpaces running on Java 1.6.  That is for sure.  Th=
is is a mistaken conclusion if you think this is a corollary or implication o=
f what I said.=20

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 3, 2010, at 6:45 PM, Peter Firmstone <jini@zeus.net.au> wrote:

> As I suspected the suggestion would reveal Michael's needs for RTSJ.
>=20
> We've established no one needs a real time server PLATFORM service, this m=
eans that the existing service implementations don't need to run on RTSJ, on=
ly the proxy's and a core platform for producing application services.
>=20
> If we make River modular, Patricia can work on the Javaspace server implem=
entation so it can utilise the latest platform concurrency features.  Theref=
ore to run a Javaspace server, it must be installed the Java 1.6 platform.  T=
he same can apply for Reggie, Mahalo and all the other service servers.
>=20
> You can still use a Javaspace service on a RTSJ client, to produce informa=
tion for the Javaspace cloud, where it can be processed using the producer c=
onsumer pattern.
>=20
> Modularity is the Solution to multi platform support.
>=20
> Where earlier Java platforms can participate, but don't provide platform s=
ervices, only consume them.
>=20
> The Service Implementations need to be separated from the River Jini Platf=
orm codebase.
>=20
> This massively reduces the maintenance required to support earlier platfor=
ms.
>=20
> I don't need to run any Platform service on BlueRay either.
>=20
> Even if we don't call it modularity, River should be broken up, all the se=
rvices can be subprojects, they can evolve at their own pace and needs, with=
out being held back by earlier Java platform support requirements.
>=20
> Cheers,
>=20
> Peter.
>=20
> MICHAEL MCGRADY wrote:
>> That is correct.  I do not think that River would be interested at this t=
ime in real-time constraints.  It is too big a jump for this place in the hi=
story and I am just asking for an incremental move to Java 1.5 from Java 1.4=
 to remain consistent with real-time JVMs.
>>=20
>> MG
>>=20
>> On Dec 2, 2010, at 11:38 PM, Patricia Shanahan wrote:
>>=20
>> =20
>>> I think we may be getting distracted from the key objective if this thre=
ad, nailing down our JVM version policy for the next few releases.
>>>=20
>>> Do we have any indication of a need for real time constraints in River? I=
 don't think Michael has asked for anything beyond keeping River JVM version=
 compatible with Java RT.
>>>=20
>>> Patricia
>>>=20
>>>=20
>>> On 12/2/2010 10:50 PM, Peter Firmstone wrote:
>>>   =20
>>>> What I'm trying to say is, that a Service and Client each running on
>>>> RTSJ, could set real time constraints, as we now might set a
>>>> ServerMinPrincipal constraint, meaning that if real time was required
>>>> over EtherCAT, this could be supported by some services and clients tha=
t
>>>> require it while others may not require it in the same environment.
>>>>=20
>>>> Currently constraints are used to enforce:
>>>>=20
>>>> 1. Confidentiality
>>>> 2. Integrity
>>>> 3. Authentication
>>>> 4. Authorization
>>>>=20
>>>> If we supported RTSJ we could add:
>>>>=20
>>>> 5. Real Time
>>>>=20
>>>> Just a thought.
>>>>=20
>>>>=20
>>>>=20
>>>> Mike McGrady wrote:
>>>>     =20
>>>>> Abandoning Java RT is not in the cards for us.
>>>>>=20
>>>>> Sent from my iPhone
>>>>>=20
>>>>> Michael McGrady
>>>>> Principal investigator AF081_028 SBIR
>>>>> Chief Architect
>>>>> Topia Technology, Inc
>>>>> Work 1.253.572.9712
>>>>> Cel 1.253.720.3365
>>>>>=20
>>>>> On Dec 2, 2010, at 10:12 PM, Peter Firmstone <jini@zeus.net.au> wrote:=

>>>>>=20
>>>>>       =20
>>>>>> It may be possible to add real time constraints.
>>>>>>=20
>>>>>> For example, EtherCAT supports real time networking, a client and
>>>>>> server could set a real time constraint and communicate over EtherCAT=
.
>>>>>>=20
>>>>>> The question that Dennis has posed though is how much do you need?
>>>>>> This doesn't have to be decided now, perhaps you can set up an issue
>>>>>> on jira so we can track it.
>>>>>>=20
>>>>>> The current release still runs on Java 5. The next release due soon
>>>>>> will too, the following release may not, but time will help us decide=

>>>>>> how solve this problem.
>>>>>>=20
>>>>>> Cheers,
>>>>>>=20
>>>>>> Peter.
>>>>>>=20
>>>>>>=20
>>>>>> Dennis Reedy wrote:
>>>>>>         =20
>>>>>>> What boggles my mind here is adding real-time requirements in the
>>>>>>> same context of Jini. While you may have real-time threads, once you=

>>>>>>> touch the network your real-time QoS goes out the window. You may be=

>>>>>>> able to guarantee that the amount of time it takes to perform an
>>>>>>> operation will be done within a bounded time, but you will not be
>>>>>>> able to guarantee (in a real-time context) that the result of that
>>>>>>> operation will be transmitted over the media to a requesting client.=

>>>>>>>=20
>>>>>>> What I'd like to find out from Michael here is what exactly are the
>>>>>>> RT requirements for River?
>>>>>>>=20
>>>>>>> Service Infrastructure (JoinManager and the like...)
>>>>>>> Services (Reggie, Mercury, Outrigger, etc...)
>>>>>>>=20
>>>>>>> Other?
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Dec 2, 2010, at 104AM, MICHAEL MCGRADY wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>>           =20
>>>>>>>> We do this now with Java 1.5, Greg. Java RT 2.1 (64 bit) is
>>>>>>>> compatible with Java 1.5. http://preview.tinyurl.com/2bpjqfh There
>>>>>>>> would be no other test than works-with-Java-1.5. The simple answer
>>>>>>>> is that if River does not call real-time threads and uses Java 1.5
>>>>>>>> there is no issue. There are other things that impact real-time but=

>>>>>>>> we can cover those.
>>>>>>>>=20
>>>>>>>> MG
>>>>>>>>=20
>>>>>>>> On Dec 1, 2010, at 9:00 PM, Greg Trasuk wrote:
>>>>>>>>=20
>>>>>>>>             =20
>>>>>>>>> On Wed, 2010-12-01 at 23:33, Mike McGrady wrote:
>>>>>>>>>               =20
>>>>>>>>>> Like I said, Java 1.6 is incompatible with Java RTS and that os
>>>>>>>>>> very serious in my neighborhood. We do QoS with Java RTS.
>>>>>>>>>>=20
>>>>>>>>>>                 =20
>>>>>>>>> That's certainly an interesting comment... I'm curious though: I
>>>>>>>>> haven't
>>>>>>>>> looked at RT Java for several years, but I recall that the first p=
ass
>>>>>>>>> allowed plain Java (i.e. non-real-time) to be executed. Would Rive=
r
>>>>>>>>> components need some other evaluation or testing to be accepted as=

>>>>>>>>> "real-time" (which I doubt would be an easy task), or would you
>>>>>>>>> just be
>>>>>>>>> looking for compatibility with the run-time environment, but witho=
ut
>>>>>>>>> real-time guarantees?
>>>>>>>>>=20
>>>>>>>>> Also, what would be the impact if the RT system called services th=
at
>>>>>>>>> were resident in a non-RT virtual machine? Specifically, would the=

>>>>>>>>> registrar and/or JavaSpaces implementation need to be hosted in a
>>>>>>>>> Java
>>>>>>>>> RTS virtual machine?
>>>>>>>>>=20
>>>>>>>>> Cheers,
>>>>>>>>>=20
>>>>>>>>> Greg.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Sent from my iPhone
>>>>>>>>>               =20
>>>>>>>>>> Michael McGrady
>>>>>>>>>> Principal investigator AF081_028 SBIR
>>>>>>>>>> Chief Architect
>>>>>>>>>> Topia Technology, Inc
>>>>>>>>>> Work 1.253.572.9712
>>>>>>>>>> Cel 1.253.720.3365
>>>>>>>>>>=20
>>>>>>>>>> On Dec 1, 2010, at 5:03 PM, Patricia Shanahan <pats@acm.org> wrot=
e:
>>>>>>>>>>=20
>>>>>>>>>>                 =20
>>>>>>>>>>> On 12/1/2010 4:53 PM, Dennis Reedy wrote:
>>>>>>>>>>> ...
>>>>>>>>>>>                   =20
>>>>>>>>>>>> Some of the discussion has referenced Java CDC on BlueRay. Shou=
ld
>>>>>>>>>>>> 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.
>>>>>>>>>>>>                     =20
>>>>>>>>>>> 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.
>>>>>>>>>>>=20
>>>>>>>>>>> Patricia
>>>>>>>>>>>                   =20
>>>>>>>>> --
>>>>>>>>> Greg Trasuk, President
>>>>>>>>> StratusCom Manufacturing Systems Inc. - We use information
>>>>>>>>> technology to
>>>>>>>>> solve business problems on your plant floor.
>>>>>>>>> http://stratuscom.com
>>>>>>>>>=20
>>>>>>>>>               =20
>>>>>>>> Michael McGrady
>>>>>>>> Chief Architect
>>>>>>>> Topia Technology, Inc.
>>>>>>>> Cel 1.253.720.3365
>>>>>>>> Work 1.253.572.9712 extension 2037
>>>>>>>> mmcgrady@topiatechnology.com
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>             =20
>>>>     =20
>>=20
>> Michael McGrady
>> Chief Architect
>> Topia Technology, Inc.
>> Cel 1.253.720.3365
>> Work 1.253.572.9712 extension 2037
>> mmcgrady@topiatechnology.com
>>=20
>>  ------------------------------------------------------------------------=

>>=20
>>=20
>>=20
>> =20
>=20