river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3
Date Fri, 03 Dec 2010 02:34:44 GMT
During this sort of discussion you may not be able to combine two or 
more of my messages, from several hours apart, and parse them together 
to get a single coherent position. That won't happen until we have 
finished discussing the subject and there is no more input that might 
change my mind.

I don't know exactly what you mean by "baseline". To me the key 
questions are what is our compilation target, and what versions do we 
test against. If we pick release N as compilation target, we should be 
able to test with JVM N, N+1, N+2, ... . On the other hand, if we don't 
routinely compile targeting N, we won't be able to run on JVM N, because 
N-incompatible source code changes will creep in.

I believe that, in order to use the most relevant features of 1.6 we 
would have to run with a 1.6 JVM and rt.jar. The question is whether the 
gains from going to 1.6, rather than 1.5, are worth the cost.

We know at least some of the cost of compiling to 1.6, abandoning anyone 
who is stuck on 1.5.

Now I'm trying to probe the cost of compiling to 1.5, but testing with 
both 1.5 and 1.6 JVMs. I understand the cost to River developers, 
especially the loss of the 1.6 java.util enhancements - and I think it 
is a manageable convenience cost.

Now I'm asking "Does compiling River to 1.5 impose a cost on 1.6 users, 
assuming we do QA test against JVM 1.6 as well as JVM 1.5?".


Dennis Reedy wrote:
> Trying to parse this correctly, let me make sure I understand what you are saying:
> Baseline River on Java 1.6 and have a compile target of 1.5?
> If so, how does this relate to your earlier post?
> On Dec 2, 2010, at 940AM, Patricia Shanahan wrote:
>> In my opinion, the differences between 1.5 and 1.6 that would most benefit River
are in java.util and its sub-packages. 1.5 added a good set of concurrency support. 1.6 improved
it based on experience.
>> The only way I know to get a 1.6 rt.jar is to run with a 1.6 JVM.
> IMO, as River moves through it's roadmap, move to JDK to 1.6 when you make the namespace
change. Branch the 2.1.2 version, keep it JDK 1.4. The 2.1.2 branch will still have the com.sun
namepsace. and provide legacy support for those that need it. If possible (and if needed),
make changes to that branch as changes and bug fixes are made to trunk. If those that are
interested and engaged want to help with that effort, they can certainly become engaged and
help make that happen.
> Regards
> Dennis
> On Dec 2, 2010, at 842PM, Patricia Shanahan wrote:
>> Would your use of River be adversely affected by a decision to limit River source
code to 1.5 compatible features, compile with target 1.5, and test it with both 1.5 and 1.6?
>> Patricia
>> On 12/2/2010 5:26 PM, Dennis Reedy 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
>>>>>> 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
>>>>>>> Sun and speculation is not a thing I like to do.  However, we
>>>>>>> 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
>>>>>>>> you can move forward with right? That release is baselined
>>>>>>>> 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,
>>>>>>>> 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
>>>>>>>>>> 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.
>>>>>>>>> 1.253.720.3365 Work 1.253.572.9712 extension 2037
>>>>>>>>> mmcgrady@topiatechnology.com
>>>>>>> Michael McGrady Chief Architect Topia Technology, Inc. Cel
>>>>>>> 1.253.720.3365 Work 1.253.572.9712 extension 2037
>>>>>>> mmcgrady@topiatechnology.com
>>>>> Michael McGrady Chief Architect Topia Technology, Inc. Cel
>>>>> 1.253.720.3365 Work 1.253.572.9712 extension 2037
>>>>> mmcgrady@topiatechnology.com

View raw message