Given the (significant) benefits of moving to 1.5 and the (relative) lack of opposition, could we agree to:
1) do our little current release 2) graduate 3) do a new release with package renames and move to 1.5 4) revisit the roadmap to prioritize 1.6 and the more significant changes we've been putting off I see a code restructuring as being possible with either step 3 or 4. I know all of these things have been said, I'm just gauging whether we're converging on agreement... -jeff On Thu, Dec 2, 2010 at 11:38 PM, Patricia Shanahan <[email protected]> wrote: > I think we may be getting distracted from the key objective if this thread, > nailing down our JVM version policy for the next few releases. > > 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. > > Patricia > > > On 12/2/2010 10:50 PM, Peter Firmstone wrote: >> >> 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 that >> require it while others may not require it in the same environment. >> >> Currently constraints are used to enforce: >> >> 1. Confidentiality >> 2. Integrity >> 3. Authentication >> 4. Authorization >> >> If we supported RTSJ we could add: >> >> 5. Real Time >> >> Just a thought. >> >> >> >> Mike McGrady wrote: >>> >>> 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] >>>>>> >>>>>> >>>>>> >>>>> >>> >> >> > >
