river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MICHAEL MCGRADY <mmcgr...@topiatechnology.com>
Subject Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3
Date Thu, 02 Dec 2010 18:27:41 GMT
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

We use River and I meant that we will have to find a River substitute or fork the code, if
River goes to Java 1.6.

See within for more comments.

MG


On Dec 2, 2010, at 7:27 AM, Dennis Reedy wrote:

> 
> On Dec 2, 2010, at 958AM, MICHAEL MCGRADY wrote:
> 
>> There are no RT requirements for River.  
> 
> Ok, good.
> 
>> There is only the requirement that, if River wants to be compatible with Java RT
that it not go to Java 1.6 but stick at Java 1.5.  
> 
> Define compatible? In what specific areas must River be compatible with RTJ? Serialization?
Where? Can you be specific? Apologies, but I'm having a hard time parsing through your statements
since they are somewhat vague to me. Can you enumerate exactly what River capabilities need
to be 'compatible' with 1.5? The entire stack? Portions of it?

See cite above to the URL.

> 
>> Once you touch the network real-time QoS does not go out the window.  
> 
> How so? Are you saying that the network is reliable enough to deliver your request/response
in a guaranteed way? Have you developed a specific protocol that is part of the JERI stack
that ensure your transport has some real time context? Is River involved in this (other than
from a configuration point of view), or is it similar to whats described in this paper: http://www.cs.wustl.edu/~schmidt/PDF/RT-POA.pdf


We have a solution to this which has been highly vetted. and it is not appropriate to discuss
it here.  You are welcome to contact me offline.  I am behind on contacts to a number of people
on this list because I am so busy but I am interested in all these conversations offline.
 Thanks.

> 
>> 
>> We are bound to River-like functionality (JINI) and JavaSpaces and RT in a network
context.
> 
> This statement has a ton of hidden implications. River-like functionality? This implies
to me that you are doing River (Jini) like things but not using River. Is that right? 
> 
> JavaSpaces and RT in a network context? What does that mean?


There are really no hidden meanings.  We do use River.  Network contexts are a context in
which computers are networked.  ;-)  I think you are over thinking what I am saying, Dennis.
 Pay no attention to the man behind the curtain because he is not there. ;-)


> 

Michael McGrady
Chief Architect
Topia Technology, Inc.
Cel 1.253.720.3365
Work 1.253.572.9712 extension 2037
mmcgrady@topiatechnology.com


Mime
View raw message