The classloading interrupt issue is unrelated to real-time. Dennis, what about Patricia's point that the move from 1.5 to 1.6 is not that important and the move to 1.5 from 1.4 is? This seems to me to be powerful as well as the impact (inconvenience to you) difference (out of the game to me).
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 5:26 PM, Dennis Reedy <dennis.re...@gmail.com> wrote: > Patricia, > > There are many interested and active users. Michael is just one that has > expressed his opinions. I am also one, and have expressed mine (I urge others > on this list to also express their opinions). The systems that I currently > work with (in DoD and beyond) all use River, and all are based on 1.6. I dont > see how moving to a baseline that has its Java Technology End of Life (EOL) > transition period that ended October 8th, 2009 is a good plan for the future > of River. > > The JSR1 requirements are easily met by the current distribution of River. We > do not know the future of Oracle's plan with RTSJ. That combined with the > recent post that Thread.interrupt() breaks classloading in 1.5 and that > there's no feasible workaround for River seen, why baseline on a technology > that is not only EOL, but also has known issues? > > Dennis > > On Dec 2, 2010, at 749PM, Patricia Shanahan wrote: > >> The way I see it, the really big gain is going to 1.5. That gets us the >> initial implementation of the concurrent and atomic classes in java.util.*, >> and generics. >> >> Going to 1.6 adds some value, but not as big a step. For example, my >> TaskManager rewrite would be a bit simpler with the 1.6 version of >> java.util.TreeSet, but I can work around the missing methods. >> >> I would rather give up the 1.6 features that are not in 1.5, at least for >> now, than give up an interested, active user. >> >> Patricia >> >> >> On 12/2/2010 4:17 PM, MICHAEL MCGRADY wrote: >>> The status of Real Time Java is not a sentimental matter, but an >>> instructive fact of Sun culture. >>> >>> The first thing should be to see is where Java 1.6 might be a plus >>> for River. Can you list these areas? That would be very helpful. >>> >>> MG >>> >>> >>> On Dec 2, 2010, at 3:58 PM, Dennis Reedy wrote: >>> >>>> Well all sentimentality aside for JSR 1, I still stick with my >>>> earlier suggestion of: >>>> >>>> I would encourage that as River moves along it's roadmap, once the >>>> namespace is changed to org.apache.river, that River mandates 1.6 >>>> as a baseline. Migration guides and/or utilities can be provided to >>>> assist in the transition from legacy Jini to River. >>>> >>>> Regards >>>> >>>> Dennis >>>> >>>> On Dec 2, 2010, at 545PM, MICHAEL MCGRADY wrote: >>>> >>>>> If there is a way to move forward and keep River compatible with >>>>> Java 1.5, that would be ideal. We obviously cannot just stand >>>>> still even though Java RTS might for a time. It is hard to tell >>>>> at this stage what is happening because of the Oracle purchase of >>>>> Sun and speculation is not a thing I like to do. However, we do >>>>> know that Java RTS is the first Java Community Process, i.e. >>>>> literally No. 1, and I cannot believe that Java would abandon >>>>> this effort to the dustbin of history. That would not bode well >>>>> for Java as a platform. >>>>> >>>>> MG >>>>> >>>>> >>>>> On Dec 2, 2010, at 2:00 PM, Dennis Reedy wrote: >>>>> >>>>>> If you're fine with River 2.1.1 then you have a platform which >>>>>> you can move forward with right? That release is baselined at >>>>>> Java 1.4. >>>>>> >>>>>> As River moves forward with it's roadmap, changing the com.sun >>>>>> namespace to org.apache, and possibly moving to Java 1.6, you >>>>>> would still have a platform (2.1.1) that you could use. >>>>>> >>>>>> As RTJ (hopefully) moves forward with eventual 1.6+ >>>>>> interoperability at that point you could move to River, >>>>>> including product changes to account for the namespace change >>>>>> as well. >>>>>> >>>>>> Does that suffice? >>>>>> >>>>>> On Dec 2, 2010, at 337PM, MICHAEL MCGRADY wrote: >>>>>> >>>>>>> More on this later, but I am certainly aware that River >>>>>>> cannot stay stagnant at Java 1.5. We need to be realistic >>>>>>> but the real-time Java is going to "hit" in the near term, I >>>>>>> think. There might need to be options and tracks and >>>>>>> whatever makes sense to River. >>>>>>> >>>>>>> MG >>>>>>> >>>>>>> >>>>>>> On Dec 2, 2010, at 10:42 AM, Dennis Reedy wrote: >>>>>>> >>>>>>>> >>>>>>>> On Dec 2, 2010, at 127PM, MICHAEL MCGRADY wrote: >>>>>>>> >>>>>>>>> Perhaps this will help: on the generic question of going >>>>>>>>> to Java 1.6, and my plea not to do it. >>>>>>>>> >>>>>>>>> http://www.devx.com/Java/Article/33475 >>>>>>>> >>>>>>>> Michael, >>>>>>>> >>>>>>>> Thanks for the link. You may also find more information >>>>>>>> here: >>>>>>>> http://java.sun.com/javase/technologies/realtime/faq.jsp >>>>>>>> >>>>>>>> One thing on this topic that I am curious about is what >>>>>>>> Oracle's plan is for RTJ. We certainly cant answer that in >>>>>>>> this forum. But... will they keep it? If so, and if they >>>>>>>> are given a large enough business opportunity for it's use, >>>>>>>> will they move towards supporting 1.6? While this is a very >>>>>>>> interesting and compelling technical use of River, is it >>>>>>>> enough to prohibit River moving to 1.6 and beyond? >>>>>>>> >>>>>>>> Just asking ... >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Dennis >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Michael McGrady Chief Architect Topia Technology, Inc. Cel >>>>>>> 1.253.720.3365 Work 1.253.572.9712 extension 2037 >>>>>>> mmcgr...@topiatechnology.com >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> Michael McGrady Chief Architect Topia Technology, Inc. Cel >>>>> 1.253.720.3365 Work 1.253.572.9712 extension 2037 >>>>> mmcgr...@topiatechnology.com >>>>> >>>>> >>>>> >>>> >>> >>> Michael McGrady Chief Architect Topia Technology, Inc. Cel >>> 1.253.720.3365 Work 1.253.572.9712 extension 2037 >>> mmcgr...@topiatechnology.com >>> >>> >>> >>> >>> >>> >> >
