Abandoning Java RT is not in the cards for us. 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 2, 2010, at 10:12 PM, Peter Firmstone <[email protected]> wrote: > It may be possible to add real time constraints. > > For example, EtherCAT supports real time networking, a client and server > could set a real time constraint and communicate over EtherCAT. > > 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. > > 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. > > Cheers, > > Peter. > > > Dennis Reedy wrote: >> 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. >> >> What I'd like to find out from Michael here is what exactly are the RT >> requirements for River? >> >> Service Infrastructure (JoinManager and the like...) >> Services (Reggie, Mercury, Outrigger, etc...) >> >> Other? >> >> >> On Dec 2, 2010, at 104AM, MICHAEL MCGRADY wrote: >> >> >>> 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. >>> >>> MG >>> >>> On Dec 1, 2010, at 9:00 PM, Greg Trasuk wrote: >>> >>> >>>> On Wed, 2010-12-01 at 23:33, Mike McGrady wrote: >>>> >>>>> 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. >>>>> >>>>> >>>> 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 pass >>>> allowed plain Java (i.e. non-real-time) to be executed. Would River >>>> 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 without >>>> real-time guarantees? >>>> >>>> Also, what would be the impact if the RT system called services that >>>> 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? >>>> >>>> Cheers, >>>> >>>> Greg. >>>> >>>> >>>> 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 1, 2010, at 5:03 PM, Patricia Shanahan <[email protected]> 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 >>>>>> >>>> -- >>>> Greg Trasuk, President >>>> StratusCom Manufacturing Systems Inc. - We use information technology to >>>> solve business problems on your plant floor. >>>> http://stratuscom.com >>>> >>>> >>> Michael McGrady >>> Chief Architect >>> Topia Technology, Inc. >>> Cel 1.253.720.3365 >>> Work 1.253.572.9712 extension 2037 >>> [email protected] >>> >>> >>> >>> >> >> >> >
