JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Patricia Shanahan <pa...@acm.org>]

Sim IJskes - QCG wrote:
...
> In order to make a decision/think of a fix i need a clear version 
> support policy. Not something i need to trawl the mailing list archives 
> for. Anybody else having the same opinion?
...

+1 on the need for a clear version support policy without depending on 
trawling the mailing list archives. We should discuss and vote on a 
policy, and then document it on the web site.

I am strongly opposed to attempting to support any version that we do 
not routinely regression test. In practice, that means supporting at 
most two releases. If we think we can handle two, I suggest 1.5 and 1.6. 
If not, I think 1.6 only.

Patricia

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Peter Firmstone <ji...@zeus.net.au>]

Sim IJskes - QCG wrote:
> On 24-11-10 01:52, Peter Firmstone wrote:
>> +1  For the current build.
>>
>> Although I still think we need to investigate a modular build, to enable
>> compiling our proxy codebases to be compatible with JDK 1.4, for
>
> maybe you want to add a small line about binary compatibility?
>
> http://river.staging.apache.org/river/supported-platforms.html
>
> Gr. Sim
>
Ok, just need a little time to think about what to write.

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Sim IJskes - QCG <si...@qcg.nl>]

On 24-11-10 01:52, Peter Firmstone wrote:
> +1  For the current build.
>
> Although I still think we need to investigate a modular build, to enable
> compiling our proxy codebases to be compatible with JDK 1.4, for

maybe you want to add a small line about binary compatibility?

http://river.staging.apache.org/river/supported-platforms.html

Gr. Sim

-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Tom Hobbs <tv...@googlemail.com>]

+1 for the current build

I'm all for this, I think it's a good idea.

We need a clear definition of which classes/sources have to remain 1.4
compatible though. At the moment, I think that is mainly intrinsic
knowledge held in people's (apart from mine) heads.  Patricia's right
though, we will also need appropriate regression tests for all
supported JDKs.

Ideally I'd like to see the build split up, the bulk of the code move
up to JDK 1.6 and a clear definition of what must remain 1.4.

On Wed, Nov 24, 2010 at 12:52 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> +1  For the current build.
>
> Although I still think we need to investigate a modular build, to enable
> compiling our proxy codebases to be compatible with JDK 1.4, for
> compatibility with earlier Jini releases running on earlier Java platforms.
>  I still would like to do a separate Java CDC release using a jini platform
> subset.  Doing either will only be possible if we make our build more
> modular.
>
> Java CDC (Blue Ray & TV) looks to become a significantly larger client
> platform than Java SE, unless Java SE Embedded can break into the mobile
> phone market.
>
> I've seen many OS / architectures become marginalised by neglecting the
> client.  Java is at risk here too.
>
> We've got the benefit of infinite client flexibility with Jini, since the
> ServiceUI can be different for each client, even while utilising the same
> service.
>
> Peter.
>
> Christopher Dolan wrote:
>>
>> I had previous advocated for 1.5 support.  But now that I've learned
>> that Thread.interrupt() breaks classloading in 1.5 and that there's no
>> feasible workaround for River, I'm eager to abandon that JRE version.
>> So I vote for 1.6 only.
>>
>> Chris
>>
>> -----Original Message-----
>> From: Patricia Shanahan [mailto:pats@acm.org] Sent: Tuesday, November 23,
>> 2010 10:35 AM
>> To: river-dev@incubator.apache.org
>> Subject: JVM version policy Was: Re: Build failed in Hudson:
>> River-trunk-jdk1.5 #3
>>
>> Sim IJskes - QCG wrote:
>> ...
>>
>>>
>>> In order to make a decision/think of a fix i need a clear version support
>>> policy. Not something i need to trawl the mailing list
>>>
>>
>> archives
>>>
>>> for. Anybody else having the same opinion?
>>>
>>
>> ...
>>
>> +1 on the need for a clear version support policy without depending on
>> trawling the mailing list archives. We should discuss and vote on a policy,
>> and then document it on the web site.
>>
>> I am strongly opposed to attempting to support any version that we do not
>> routinely regression test. In practice, that means supporting at most two
>> releases. If we think we can handle two, I suggest 1.5 and 1.6.
>>
>> If not, I think 1.6 only.
>>
>> Patricia
>>
>>
>
>

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Tom Hobbs <tv...@googlemail.com>]

Sorry, I disagree.  I think, I'm not sure what your (Peter) "+1" was for.

Whether River continues to support this version or that version or
neither needs to be more considered.  I also don't want it to hold up
graduation.  This is what I propose;

1.  Lets do this bug-fix release, using whatever versions we used for
the previous release
2.  Come up with a roadmap, something like:
     A: Define JVM compatability policy and confirm on user list
     B: Modularise build and migrate namespaces
     C: Complete build/release mechanism on required JDKs
     D: First build after graduation
     E: Help users to migrate
     F: Cool stuff
2.  Grind the graduation wheels
3.  Start knocking tasks off the roadmap, discussing, voting and
agreeing (or not) on each step

Sorry, something in one of Sim's post earlier struck a nerve.  We seem
to be a bit paralyzed and don't seem to be getting anywhere.  Let's
clear our plates of stuff, finish the minimum we need for graduation,
graduate, and then launch into these discussions and so on.

Let's make the priority graduation, until that's achieved everything
else just feels a bit like procrastination.

Obviously the above is my opinion and subject to change without warning... :-)


On Wed, Nov 24, 2010 at 8:32 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> No just thinking out loud.
>
> The last release is was compiled with Java 1.4, we need to get this release
> out, Patricia needed Java 1.5 language features for her new TaskManager
> implementation and I needed them for my concurrent policy implementation,
> but neither are being included in this release.  Perhaps our newest release
> too could be a Java 1.4 compiled release?
>
> Java CDC on BlueRay and TV (these are networkable and support Java 1.4
> Security features) will be around as Java 1.4 compatible for some time to
> come, I'd like to enable interaction between our River Java SE release and
> with a subset River release for the Java CDC platform.
>
> But we can make this release Java 1.6 only, we could still come up with a
> new way of defining codebase URL's, perhaps there might be a way of a
> service making platform specific codebases available.  One service, two
> proxy codebases.  Service implementations running on Java SE 1.6, servicing
> clients running on a Blue Ray Disk Player.  If this is possible and I think
> it is, we can simply use the previous release proxy codebases for such a
> thing, because nothing within them has changed.
>
> In fact I think I like the latter option better, so assuming we can come up
> with a new URL scheme I would still vote +1 without conditions.
>
> In a distributed environment there are multiple levels of compatibility:
>
>   * Serialization - object serial form is transmitted separately,
>     different codebases can share the same serial form.
>   * Service API - Prefer Interface extension or encapsulation and
>     replacement over interface evolution. We have no mechanisms to
>     handle Interface evolution and neither does Java. (Patricia
>     mentioned that this is in the pipeline for Java).
>   * Proxy Binary compatibility is important, more so than compile time
>     compatibility, because Codebases are compiled separately.
>   * Generics cannot be supported across compile time boundaries,
>     unless the Generic is specific eg: List<String> can be supported
>     in Service API, but List<T> or List<? extends Fruit> cannot.
>
> Jini has only the Discovery Protocols (and Codebase URL's), all other
> communications are across Service API boundaries, hence the end of
> protocols.
>
> Cheers,
>
> Peter.
>

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Sim IJskes - QCG <si...@qcg.nl>]

On 11/24/2010 09:32 AM, Peter Firmstone wrote:

> The last release is was compiled with Java 1.4, we need to get this
> release out, Patricia needed Java 1.5 language features for her new
> TaskManager implementation and I needed them for my concurrent policy
> implementation, but neither are being included in this release. Perhaps
> our newest release too could be a Java 1.4 compiled release?
>
> Java CDC on BlueRay and TV (these are networkable and support Java 1.4
> Security features) will be around as Java 1.4 compatible for some time
> to come, I'd like to enable interaction between our River Java SE
> release and with a subset River release for the Java CDC platform.

So, in a nutshell: jdk1.6 source level compatibility, jdk1.4 object code 
compatibility. Possible?

How do we verify API dependencies? Is river already working on your 
blueray?

Gr. Sim

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Peter Firmstone <ji...@zeus.net.au>]

Sim IJskes - QCG wrote:
> On 11/24/2010 01:52 AM, Peter Firmstone wrote:
>> +1  For the current build.
>
> Voting does not allow for an extra qualification. Does this mean that 
> you will only vote +1 if a terminating clause is included?
>
> Gr. Sim
>
>
No just thinking out loud.

The last release is was compiled with Java 1.4, we need to get this 
release out, Patricia needed Java 1.5 language features for her new 
TaskManager implementation and I needed them for my concurrent policy 
implementation, but neither are being included in this release.  Perhaps 
our newest release too could be a Java 1.4 compiled release?

Java CDC on BlueRay and TV (these are networkable and support Java 1.4 
Security features) will be around as Java 1.4 compatible for some time 
to come, I'd like to enable interaction between our River Java SE 
release and with a subset River release for the Java CDC platform.

But we can make this release Java 1.6 only, we could still come up with 
a new way of defining codebase URL's, perhaps there might be a way of a 
service making platform specific codebases available.  One service, two 
proxy codebases.  Service implementations running on Java SE 1.6, 
servicing clients running on a Blue Ray Disk Player.  If this is 
possible and I think it is, we can simply use the previous release proxy 
codebases for such a thing, because nothing within them has changed.

In fact I think I like the latter option better, so assuming we can come 
up with a new URL scheme I would still vote +1 without conditions.

In a distributed environment there are multiple levels of compatibility:

    * Serialization - object serial form is transmitted separately,
      different codebases can share the same serial form.
    * Service API - Prefer Interface extension or encapsulation and
      replacement over interface evolution. We have no mechanisms to
      handle Interface evolution and neither does Java. (Patricia
      mentioned that this is in the pipeline for Java).
    * Proxy Binary compatibility is important, more so than compile time
      compatibility, because Codebases are compiled separately.
    * Generics cannot be supported across compile time boundaries,
      unless the Generic is specific eg: List<String> can be supported
      in Service API, but List<T> or List<? extends Fruit> cannot.

Jini has only the Discovery Protocols (and Codebase URL's), all other 
communications are across Service API boundaries, hence the end of 
protocols.

Cheers,

Peter.

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Peter Firmstone <ji...@zeus.net.au>]

Sim IJskes - QCG wrote:
> On 11/24/2010 03:11 PM, Patricia Shanahan wrote:
>
>> If we had started a formal vote, the qualification might indicate that
>> we had not yet done enough discussing. I suggest we continue discussing
>> a little longer, and then call a vote. We will probably be able to reach
>> a consensus proposal that will get a lot of definite positive votes.
>
> I'm aware off the differences between a formal and a informal vote. A 
> informal vote however is a clear indication how one will vote when a 
> formal vote is called.
>
> I can understand you want to go throught due process in determining 
> what we are going to do. But my personal impression from the mailing 
> list archives, is that the river project is completely gridlocked in 
> subtleties. I'm not saying that something agreed has a lifetime of 
> infinity, but we have to start somewhere. That means quick, decisive 
> action, while keeping our options open.
>
> Suppose we declare to support 1.4, 1.5, 1.6 and CDC. How do we 
> validate this? I don't see us building a compatibity verification on 
> short notice.

There are two types of compatibility:

Local Installation Platform.
Remote Distributed Environment Communication.

Jini is the end of protocols, the advantage of a protocol is, your not 
tied to different platforms, the disadvantage is your locked into your 
protocol.  With Jini / River, the bytecode our proxy is compiled with, 
is our protocol.

It looks like the easiest option for our current release is (users can 
skip this release if they need earlier remote platform support):

Local Installation Platform - Java 6
Remote Distributed Environment Clients - Java 6
Remote Distributed Environment Services - Anything that can a register a 
java proxy with a previous release lookup service, if available, or a 
Surrogate running on Java 6, or a Service running on Java 6.

With a modular build this will be possible:

Local Installation Platform - Java 6
Remote Distributed Environment Clients - Java 1.4, 5, 6, CDC
Remote Distributed Environment Services - Anything that can provide a 
java proxy.

In fact, if the Service API and proxy's are compiled to be Java 1.4 
compatible, then we simply unit test the proxy classes on Java 1.4, and 
check the serial form of our objects hasn't changed as part of testing 
that module.  We don't need to make it complicated.  The module jar 
files will be used in the qa integration tests for the supported 
platform, Java 6.

Each service will have at the minimum two modules, three for Services 
with smart proxy's:

   1. service_name-api.jar - Compile for / with Java 1.4
   2. impl_name-version-imp.jar - Compile for Java 6
   3. impl_name-version-proxy.jar Compile for / with Java 1.4

    * 2 and 3 depend on 1.
    * 2 depends on 3.

>
> If you want to go for river worlddomination, by keeping everything 
> compatible, you should bring a large suitcase of money. Then you can 
> checkout an older revision from the repo and build something with the 
> horde of programmers you are hiring.
>
> River has to grow from spurts from contributors, we are not going to 
> win a race by creating a swamp. I strongly believe that the current 
> failure of river is because of this longwinding process. We are not 
> going to attract more young eager bright committers if we keep on 
> discussing the future of river or the subtleties of compatibility.
As developers we need to understand the subtleties of compatibility, we 
can provide best practices for our users, so they don't have to 
understand the subtleties.

Don't forget the fallacies, we can't ignore the compatibility issues, we 
need to work out how to best handle them, then document for users, our 
best programming practices, so they can avoid the issues.

We need to be able to make it easy for user developers to utilise River, 
if we ignore the issues, we'll just make it harder.

I agree that we need to be careful about how we discuss the future of 
River and compatibility, but I don't agree that would should stop 
discussing it.  I'm not about holding up progress, I recognise we have 
limitations and cannot support everything, but we don't want to remove 
the possibilities either.

I don't see failure or gridlock, I see progress in leaps and bounds and 
some difficult things we haven't done yet, that we're working out how to do.

I also recognise the significant efforts you've all contributed has made 
graduation possible.

Cheers,

Peter.

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Peter Firmstone <ji...@zeus.net.au>]

Dennis Reedy wrote:
> On Dec 8, 2010, at 821AM, Gregg Wonderly wrote:
>   
>> The current situation with how lookup returns an unmarshalled object limits a client choice to much earlier "binding".  That is, instead of being able to look at multiple service matches and say "this one is not for me", it needs to, instead, be connected with the service deployments via an Entry which might indicate what "platform" the server can support.  This is not always a problem and I don't want to undervalue how Entry can be used to do this.
>>
>> Deferred unmarshalling in lookup could provide some more powerful decision opportunities for the client by allowing it to better manage when that occurs.
>>
>>     
>
> I agree, deferred marshaling and using lookup attributes can certainly aid in how this can be accomplished.
>
>
>   
I've got a Service API called StreamServiceRegistrar for just such a 
thing, in skunk/pepe, it was intended to maintain backward compatibility 
with ServiceRegistrar, by extending it.

So after discovery you can check if your ServiceRegistrar is an instance 
of StreamServiceRegistrar.  In older clients, it will only be a 
ServiceRegistrar, but be backward compatible.  It also has a powerful 
filter chaining interface, using the existing filters passed to 
ServiceDiscoveryManager so you can perform pre unmarshalling filtering 
(=) and post unmarshalling filtering (<><=>=), (Entry's are intended to 
be unmarshalled by default if they have local code).

This is intended to be an internet based service registrar, where the 
results may be infinitely streamed, and sent in small chunks and 
handled, where you can process more than your memory can contain, by 
discarding what you don't want, using filtering, then discarding the 
service after performing an operation on it, freeing up a service 
proxy's ClassLoader.

It's inspired by Gregg's work, although it isn't compatible.

I've been waiting for some feedback on the interface, since I know you 
can't change it once it's released.

Different but related topic:

As a totally separate concern, when you obtain a remote object, by means 
other than MarshalledInstance, which we can use to ensure trust, how do 
you ensure that MarshalInputStream will impose the right constraints?  
Eg you lookup a service and hand it an Exported Object or another service.

Because you have a trust relationship with the service already, it could 
reasonably expect that you won't perform an unmarshalling attack on it 
and it will apply suitable constraints at it's end.

Michal was working on preventing unmarshalling attacks using new Module 
implementations of MarshalInputStream and MarshalOutputStream, there are 
two drawbacks currently; it's not backward compatible with the existing 
implementations and it has to annotate a proxy with every object in the 
object stream.  On the plus side it can distinguish different service 
providers with the same codebase.

I've also wondered if we should create a URL handler that enables one to 
append a Subject's Certificate to the stream to ensure we don't have 
different Service proxy's with identical jar files sharing the same 
classloader.  The Certificate's Principal would somehow have to be one 
of the ServerMinPrincipal constraints set on the proxy also.

We could create a URL handler for URL's with the following information:

DNS-SRV domain path
jar filename
Message Digest
Subject unique Certificate.

This might enable redundant Codebase servers, discovered using DNS-SRV, 
message digest's to enable integrity, and a unique Certificate to ensure 
we keep separate identical services in separate ClassLoaders.  Note: 
Isolates would have been perfect for this to save on ClassLoaders and 
memory.  Java SE Embedded and JNode support the Isolates API.  Those 
platforms could use Isolates instead of separate ClassLoaders.


Cheers,

Peter.

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Dennis Reedy <de...@gmail.com>]

On Dec 8, 2010, at 821AM, Gregg Wonderly wrote:
> 
> The current situation with how lookup returns an unmarshalled object limits a client choice to much earlier "binding".  That is, instead of being able to look at multiple service matches and say "this one is not for me", it needs to, instead, be connected with the service deployments via an Entry which might indicate what "platform" the server can support.  This is not always a problem and I don't want to undervalue how Entry can be used to do this.
> 
> Deferred unmarshalling in lookup could provide some more powerful decision opportunities for the client by allowing it to better manage when that occurs.
> 

I agree, deferred marshaling and using lookup attributes can certainly aid in how this can be accomplished.

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Gregg Wonderly <gr...@wonderly.org>]

On 12/3/2010 11:29 PM, Peter Firmstone wrote:
> Dennis Reedy wrote:
>> On Dec 2, 2010, at 618AM, Peter Firmstone wrote:
>>
>>> Patricia Shanahan 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
>>>>
>>> BDJ is a subset of Java 1.4, the bytecode is Java 1.4 compatible, it has Java
>>> 1.4 Security, JSSE and JCE. It lacks Swing, has some AWT and a UI suited to
>>> television. It has networking, dynamic ClassLoading and Serialization but
>>> most of RMI is missing. To gain adequate privileges, an application jar file
>>> must be signed.
>>>
>>> This would require a separate River release, (Brook?) It would have Service
>>> API, but lack service implementations, it could be used as an application
>>> client or provide services, but could never support the full Jini platform.
>>>
>>> However this should not hold back the River Jini platform, which should take
>>> advantage of newer Java language features.
>>>
>>> The build we have now is monolithic, which means we can't compile proxy's
>>> separately. To remain network compatible with Java 1.4 proxy's need to be
>>> compiled with java 1.4 or a later platform using jsr14 to produce java 1.4
>>> compatible byte code. However once we have a modular build,
>>
>> I've been trying to carve out some weekend time to begin the creation of a
>> River maven project that would provide the level of decomposition required
>> here (this also would mean the removal of classdepandjar, and use straight
>> forward dependencies based on the conventions that we have discussed to
>> resolve intra-service dependencies). If we have api/proxy modules, they can be
>> targeted for a specific platform. My only excuse to not starting this is its
>> just tough to carve out the time. I know I should stop whining and just do it,
>> hopefully soon.
>>
>
> +1 Peter.
>
>>> it may be feasible to introduce the latest version of river, which will
>>> require a late version of Java to run on, to communicate with earlier
>>> existing Jini and River installations which to date are still Java 1.4
>>> compatible.
>>>
>>> This does not mean that the River platform cannot utilise later java language
>>> features, it doesn't need to run on Java 1.4, just communicate with it.
>>>
>>> If the java 1.4 bytecode is too difficult to support for our proxy's, which
>>> may be the case, then we'll need to decide which later platform will be the
>>> minimum bytecode for our proxy's.
>>>
>>> Dennis, do you have any thoughts on how to support platform transitive
>>> dependency's?
>>
>> Could it be as simple as a service specific attribute that clients can match on?
>>
>>
>
> Perhaps, giving the client the opportunity to select the most suitable codebase
> from a list?
>
> I wonder about other services or exported objects passed to the service though,
> they also need to download a suitable codebase.

There are a couple of different places that a client can get "code" from.  We 
know about how ClassLoading can be controlled, remotely, using the annotation on 
any MarshalledObject that a client receives.  One of the interesting thing about 
Entry use in the ServiceUI mechanisms is that the client is in control of when 
the unmarshalling occurs.  Therefore, it is possible for there to be multiple 
service UIs with platform specific versioning contained in the associated 
MarshalledObject.  So, there could be a JDK1.4 marshalled UIDescriptor in 
addition to others.

The current situation with how lookup returns an unmarshalled object limits a 
client choice to much earlier "binding".  That is, instead of being able to look 
at multiple service matches and say "this one is not for me", it needs to, 
instead, be connected with the service deployments via an Entry which might 
indicate what "platform" the server can support.  This is not always a problem 
and I don't want to undervalue how Entry can be used to do this.

Deferred unmarshalling in lookup could provide some more powerful decision 
opportunities for the client by allowing it to better manage when that occurs.

Gregg Wonderly

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[MICHAEL MCGRADY <mm...@topiatechnology.com>]

On Dec 4, 2010, at 12:54 PM, Dennis Reedy wrote:

> 
> On Dec 4, 2010, at 1051AM, Mike McGrady wrote:
> 
>> The multiple-tier architecture and the modular architecture need to be kept separate.  There is a problem scaling modules that are based on tiers.  This will not work for us.  Essentially this says we do not need the Java version to be consistent with Java 1.5, but we do.  
> 
> The comments below refer to having a modular build; being able to build River in such a way that you can specify different target sources (for one), so for example if Mahalo or Outrigger needed to be built with a source of 1.4 or 1.5 it could be accomplished, as opposed to having a singular monolithic build.
> 
> This is really a completely different thing from a multi-tier architecture. One doesnt have anything to do with the other.


My mistake.  I thought "modular" was being used in the traditional sense.  


> 
> 
>> Modules except in architectures that do not have quality control criteria (QCC) are inadequate to solve this problem will not work for real-world problems.
> 
> I'm not sure what this means.
> 
> Regards
> 
> Dennis
> 
> 
>> 
>> 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 4, 2010, at 5:49 AM, Tom Hobbs <tv...@googlemail.com> wrote:
>> 
>>> Peter is right, with a modular build we could do absolutely anything.
>>> Which is why I believe that our next release should just use whatever
>>> JDK version we used for the last one.  The let's go down the roadmap
>>> and talk about this again when we start to do something about it (but
>>> after we've modularised the build, I would guess.)
>>> 
>>> I know that supporting many multiple JDKs has been briefly discussed
>>> and rejected, personally, I am kind of warming to that idea though.
>>> Yes it is;
>>> 
>>> - additional work to add functionality
>>> - additional work to fix bugs
>>> - additional work for the modular build stuff
>>> 
>>> Consider the following directory structure;
>>> 
>>> $RIVER_HOME/component/src/org.apache.river.component.Thing
>>> $RIVER_HOME/component/jdk1.4/src/org.apache.river.component.Thing
>>> 
>>> The first line signifies the River-recommended and most up-to-date
>>> version, later (and still supported) version then appear in
>>> subdirectories.  Bugs would be raised against versions and
>>> bug-exposing tests need only be written in the most up-to-date (and
>>> supported) JDK; which can then be run across all versions and as long
>>> as we have sensibly named JAR files runtime confusion can be kept to a
>>> minimum.
>>> 
>>> Also, with a modular build we need only add this complexity when we
>>> come across a component that would be improved by using a
>>> non-previous-JDK feature.  And when that happens, the developer
>>> creates the "component/jdk1.4/src/..." directory duplicates the
>>> *affected classes only*, modifies the build accordingly and carries
>>> on.
>>> 
>>> As long as we ensure that the build is satisfactory and that tests are
>>> run against all the supported JDKs we should be good to go.  I accept
>>> that this is additional work and effort, for each additional
>>> enhancement and bug fix, but I wonder if it is worth paying that cost
>>> in order to keep supporting users who are locked (for whatever reason)
>>> into other JDK versions.
>>> 
>>> Just my thoughts.
>>> 
>>> On Sat, Dec 4, 2010 at 5:29 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
>>>> Dennis Reedy wrote:
>>>>> 
>>>>> On Dec 2, 2010, at 618AM, Peter Firmstone wrote:
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Patricia Shanahan 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
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> BDJ is a subset of Java 1.4, the bytecode is Java 1.4 compatible, it has
>>>>>> Java 1.4 Security, JSSE and JCE.  It lacks Swing, has some AWT and a UI
>>>>>> suited to television. It has networking, dynamic ClassLoading and
>>>>>> Serialization but most of RMI is missing.  To gain adequate privileges, an
>>>>>> application jar file must be signed.
>>>>>> 
>>>>>> This would require a separate River release, (Brook?)  It would have
>>>>>> Service API, but lack service implementations, it could be used as an
>>>>>> application client or provide services, but could never support the full
>>>>>> Jini platform.
>>>>>> 
>>>>>> However this should not hold back the River Jini platform, which should
>>>>>> take advantage of newer Java language features.
>>>>>> 
>>>>>> The build we have now is monolithic, which means we can't compile proxy's
>>>>>> separately.  To remain network compatible with Java 1.4 proxy's need to be
>>>>>> compiled with java 1.4 or a later platform using jsr14 to produce java 1.4
>>>>>> compatible byte code.  However once we have a modular build,
>>>>>> 
>>>>> 
>>>>> I've been trying to carve out some weekend time to begin the creation of a
>>>>> River maven project that would provide the level of decomposition required
>>>>> here (this also would mean the removal of classdepandjar, and use straight
>>>>> forward dependencies based on the conventions that we have discussed to
>>>>> resolve intra-service dependencies). If we have api/proxy modules, they can
>>>>> be targeted for a specific platform. My only excuse to not starting this is
>>>>> its just tough to carve out the time. I know I should stop whining and just
>>>>> do it, hopefully soon.
>>>>> 
>>>>> 
>>>> 
>>>> +1 Peter.
>>>> 
>>>>> 
>>>>>> 
>>>>>> it may be feasible to introduce the latest version of river, which will
>>>>>> require a late version of Java to run on, to communicate with earlier
>>>>>> existing Jini and River installations which to date are still Java 1.4
>>>>>> compatible.
>>>>>> 
>>>>>> This does not mean that the River platform cannot utilise later java
>>>>>> language features, it doesn't need to run on Java 1.4, just communicate with
>>>>>> it.
>>>>>> 
>>>>>> If the java 1.4 bytecode is too difficult to support for our proxy's,
>>>>>> which may be the case, then we'll need to decide which later platform will
>>>>>> be the minimum bytecode for our proxy's.
>>>>>> 
>>>>>> Dennis, do you have any thoughts on how to support platform transitive
>>>>>> dependency's?
>>>>>> 
>>>>> 
>>>>> Could it be as simple as a service specific attribute that clients can
>>>>> match on?
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> Perhaps, giving the client the opportunity to select the most suitable
>>>> codebase from a list?
>>>> 
>>>> I wonder about other services or exported objects passed to the service
>>>> though, they also need to download a suitable codebase.
>>>> 
>>>> 
>>>> 
> 

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

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Dennis Reedy <de...@gmail.com>]

On Dec 4, 2010, at 1051AM, Mike McGrady wrote:

> The multiple-tier architecture and the modular architecture need to be kept separate.  There is a problem scaling modules that are based on tiers.  This will not work for us.  Essentially this says we do not need the Java version to be consistent with Java 1.5, but we do.  

The comments below refer to having a modular build; being able to build River in such a way that you can specify different target sources (for one), so for example if Mahalo or Outrigger needed to be built with a source of 1.4 or 1.5 it could be accomplished, as opposed to having a singular monolithic build.

This is really a completely different thing from a multi-tier architecture. One doesnt have anything to do with the other.


> Modules except in architectures that do not have quality control criteria (QCC) are inadequate to solve this problem will not work for real-world problems.

I'm not sure what this means.

Regards

Dennis


> 
> 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 4, 2010, at 5:49 AM, Tom Hobbs <tv...@googlemail.com> wrote:
> 
>> Peter is right, with a modular build we could do absolutely anything.
>> Which is why I believe that our next release should just use whatever
>> JDK version we used for the last one.  The let's go down the roadmap
>> and talk about this again when we start to do something about it (but
>> after we've modularised the build, I would guess.)
>> 
>> I know that supporting many multiple JDKs has been briefly discussed
>> and rejected, personally, I am kind of warming to that idea though.
>> Yes it is;
>> 
>> - additional work to add functionality
>> - additional work to fix bugs
>> - additional work for the modular build stuff
>> 
>> Consider the following directory structure;
>> 
>> $RIVER_HOME/component/src/org.apache.river.component.Thing
>> $RIVER_HOME/component/jdk1.4/src/org.apache.river.component.Thing
>> 
>> The first line signifies the River-recommended and most up-to-date
>> version, later (and still supported) version then appear in
>> subdirectories.  Bugs would be raised against versions and
>> bug-exposing tests need only be written in the most up-to-date (and
>> supported) JDK; which can then be run across all versions and as long
>> as we have sensibly named JAR files runtime confusion can be kept to a
>> minimum.
>> 
>> Also, with a modular build we need only add this complexity when we
>> come across a component that would be improved by using a
>> non-previous-JDK feature.  And when that happens, the developer
>> creates the "component/jdk1.4/src/..." directory duplicates the
>> *affected classes only*, modifies the build accordingly and carries
>> on.
>> 
>> As long as we ensure that the build is satisfactory and that tests are
>> run against all the supported JDKs we should be good to go.  I accept
>> that this is additional work and effort, for each additional
>> enhancement and bug fix, but I wonder if it is worth paying that cost
>> in order to keep supporting users who are locked (for whatever reason)
>> into other JDK versions.
>> 
>> Just my thoughts.
>> 
>> On Sat, Dec 4, 2010 at 5:29 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
>>> Dennis Reedy wrote:
>>>> 
>>>> On Dec 2, 2010, at 618AM, Peter Firmstone wrote:
>>>> 
>>>> 
>>>>> 
>>>>> Patricia Shanahan 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
>>>>>> 
>>>>>> 
>>>>> 
>>>>> BDJ is a subset of Java 1.4, the bytecode is Java 1.4 compatible, it has
>>>>> Java 1.4 Security, JSSE and JCE.  It lacks Swing, has some AWT and a UI
>>>>> suited to television. It has networking, dynamic ClassLoading and
>>>>> Serialization but most of RMI is missing.  To gain adequate privileges, an
>>>>> application jar file must be signed.
>>>>> 
>>>>> This would require a separate River release, (Brook?)  It would have
>>>>> Service API, but lack service implementations, it could be used as an
>>>>> application client or provide services, but could never support the full
>>>>> Jini platform.
>>>>> 
>>>>> However this should not hold back the River Jini platform, which should
>>>>> take advantage of newer Java language features.
>>>>> 
>>>>> The build we have now is monolithic, which means we can't compile proxy's
>>>>> separately.  To remain network compatible with Java 1.4 proxy's need to be
>>>>> compiled with java 1.4 or a later platform using jsr14 to produce java 1.4
>>>>> compatible byte code.  However once we have a modular build,
>>>>> 
>>>> 
>>>> I've been trying to carve out some weekend time to begin the creation of a
>>>> River maven project that would provide the level of decomposition required
>>>> here (this also would mean the removal of classdepandjar, and use straight
>>>> forward dependencies based on the conventions that we have discussed to
>>>> resolve intra-service dependencies). If we have api/proxy modules, they can
>>>> be targeted for a specific platform. My only excuse to not starting this is
>>>> its just tough to carve out the time. I know I should stop whining and just
>>>> do it, hopefully soon.
>>>> 
>>>> 
>>> 
>>> +1 Peter.
>>> 
>>>> 
>>>>> 
>>>>> it may be feasible to introduce the latest version of river, which will
>>>>> require a late version of Java to run on, to communicate with earlier
>>>>> existing Jini and River installations which to date are still Java 1.4
>>>>> compatible.
>>>>> 
>>>>> This does not mean that the River platform cannot utilise later java
>>>>> language features, it doesn't need to run on Java 1.4, just communicate with
>>>>> it.
>>>>> 
>>>>> If the java 1.4 bytecode is too difficult to support for our proxy's,
>>>>> which may be the case, then we'll need to decide which later platform will
>>>>> be the minimum bytecode for our proxy's.
>>>>> 
>>>>> Dennis, do you have any thoughts on how to support platform transitive
>>>>> dependency's?
>>>>> 
>>>> 
>>>> Could it be as simple as a service specific attribute that clients can
>>>> match on?
>>>> 
>>>> 
>>>> 
>>> 
>>> Perhaps, giving the client the opportunity to select the most suitable
>>> codebase from a list?
>>> 
>>> I wonder about other services or exported objects passed to the service
>>> though, they also need to download a suitable codebase.
>>> 
>>> 
>>> 

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Mike McGrady <mm...@topiatechnology.com>]

The multiple-tier architecture and the modular architecture need to be kept separate.  There is a problem scaling modules that are based on tiers.  This will not work for us.  Essentially this says we do not need the Java version to be consistent with Java 1.5, but we do.  Modules except in architectures that do not have quality control criteria (QCC) are inadequate to solve this problem will not work for real-world problems.

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 4, 2010, at 5:49 AM, Tom Hobbs <tv...@googlemail.com> wrote:

> Peter is right, with a modular build we could do absolutely anything.
> Which is why I believe that our next release should just use whatever
> JDK version we used for the last one.  The let's go down the roadmap
> and talk about this again when we start to do something about it (but
> after we've modularised the build, I would guess.)
> 
> I know that supporting many multiple JDKs has been briefly discussed
> and rejected, personally, I am kind of warming to that idea though.
> Yes it is;
> 
> - additional work to add functionality
> - additional work to fix bugs
> - additional work for the modular build stuff
> 
> Consider the following directory structure;
> 
> $RIVER_HOME/component/src/org.apache.river.component.Thing
> $RIVER_HOME/component/jdk1.4/src/org.apache.river.component.Thing
> 
> The first line signifies the River-recommended and most up-to-date
> version, later (and still supported) version then appear in
> subdirectories.  Bugs would be raised against versions and
> bug-exposing tests need only be written in the most up-to-date (and
> supported) JDK; which can then be run across all versions and as long
> as we have sensibly named JAR files runtime confusion can be kept to a
> minimum.
> 
> Also, with a modular build we need only add this complexity when we
> come across a component that would be improved by using a
> non-previous-JDK feature.  And when that happens, the developer
> creates the "component/jdk1.4/src/..." directory duplicates the
> *affected classes only*, modifies the build accordingly and carries
> on.
> 
> As long as we ensure that the build is satisfactory and that tests are
> run against all the supported JDKs we should be good to go.  I accept
> that this is additional work and effort, for each additional
> enhancement and bug fix, but I wonder if it is worth paying that cost
> in order to keep supporting users who are locked (for whatever reason)
> into other JDK versions.
> 
> Just my thoughts.
> 
> On Sat, Dec 4, 2010 at 5:29 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
>> Dennis Reedy wrote:
>>> 
>>> On Dec 2, 2010, at 618AM, Peter Firmstone wrote:
>>> 
>>> 
>>>> 
>>>> Patricia Shanahan 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
>>>>> 
>>>>> 
>>>> 
>>>> BDJ is a subset of Java 1.4, the bytecode is Java 1.4 compatible, it has
>>>> Java 1.4 Security, JSSE and JCE.  It lacks Swing, has some AWT and a UI
>>>> suited to television. It has networking, dynamic ClassLoading and
>>>> Serialization but most of RMI is missing.  To gain adequate privileges, an
>>>> application jar file must be signed.
>>>> 
>>>> This would require a separate River release, (Brook?)  It would have
>>>> Service API, but lack service implementations, it could be used as an
>>>> application client or provide services, but could never support the full
>>>> Jini platform.
>>>> 
>>>> However this should not hold back the River Jini platform, which should
>>>> take advantage of newer Java language features.
>>>> 
>>>> The build we have now is monolithic, which means we can't compile proxy's
>>>> separately.  To remain network compatible with Java 1.4 proxy's need to be
>>>> compiled with java 1.4 or a later platform using jsr14 to produce java 1.4
>>>> compatible byte code.  However once we have a modular build,
>>>> 
>>> 
>>> I've been trying to carve out some weekend time to begin the creation of a
>>> River maven project that would provide the level of decomposition required
>>> here (this also would mean the removal of classdepandjar, and use straight
>>> forward dependencies based on the conventions that we have discussed to
>>> resolve intra-service dependencies). If we have api/proxy modules, they can
>>> be targeted for a specific platform. My only excuse to not starting this is
>>> its just tough to carve out the time. I know I should stop whining and just
>>> do it, hopefully soon.
>>> 
>>> 
>> 
>> +1 Peter.
>> 
>>> 
>>>> 
>>>> it may be feasible to introduce the latest version of river, which will
>>>> require a late version of Java to run on, to communicate with earlier
>>>> existing Jini and River installations which to date are still Java 1.4
>>>> compatible.
>>>> 
>>>> This does not mean that the River platform cannot utilise later java
>>>> language features, it doesn't need to run on Java 1.4, just communicate with
>>>> it.
>>>> 
>>>> If the java 1.4 bytecode is too difficult to support for our proxy's,
>>>> which may be the case, then we'll need to decide which later platform will
>>>> be the minimum bytecode for our proxy's.
>>>> 
>>>> Dennis, do you have any thoughts on how to support platform transitive
>>>> dependency's?
>>>> 
>>> 
>>> Could it be as simple as a service specific attribute that clients can
>>> match on?
>>> 
>>> 
>>> 
>> 
>> Perhaps, giving the client the opportunity to select the most suitable
>> codebase from a list?
>> 
>> I wonder about other services or exported objects passed to the service
>> though, they also need to download a suitable codebase.
>> 
>> 
>> 

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Tom Hobbs <tv...@googlemail.com>]

Peter is right, with a modular build we could do absolutely anything.
Which is why I believe that our next release should just use whatever
JDK version we used for the last one.  The let's go down the roadmap
and talk about this again when we start to do something about it (but
after we've modularised the build, I would guess.)

I know that supporting many multiple JDKs has been briefly discussed
and rejected, personally, I am kind of warming to that idea though.
Yes it is;

- additional work to add functionality
- additional work to fix bugs
- additional work for the modular build stuff

Consider the following directory structure;

$RIVER_HOME/component/src/org.apache.river.component.Thing
$RIVER_HOME/component/jdk1.4/src/org.apache.river.component.Thing

The first line signifies the River-recommended and most up-to-date
version, later (and still supported) version then appear in
subdirectories.  Bugs would be raised against versions and
bug-exposing tests need only be written in the most up-to-date (and
supported) JDK; which can then be run across all versions and as long
as we have sensibly named JAR files runtime confusion can be kept to a
minimum.

Also, with a modular build we need only add this complexity when we
come across a component that would be improved by using a
non-previous-JDK feature.  And when that happens, the developer
creates the "component/jdk1.4/src/..." directory duplicates the
*affected classes only*, modifies the build accordingly and carries
on.

As long as we ensure that the build is satisfactory and that tests are
run against all the supported JDKs we should be good to go.  I accept
that this is additional work and effort, for each additional
enhancement and bug fix, but I wonder if it is worth paying that cost
in order to keep supporting users who are locked (for whatever reason)
into other JDK versions.

Just my thoughts.

On Sat, Dec 4, 2010 at 5:29 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> Dennis Reedy wrote:
>>
>> On Dec 2, 2010, at 618AM, Peter Firmstone wrote:
>>
>>
>>>
>>> Patricia Shanahan 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
>>>>
>>>>
>>>
>>> BDJ is a subset of Java 1.4, the bytecode is Java 1.4 compatible, it has
>>> Java 1.4 Security, JSSE and JCE.  It lacks Swing, has some AWT and a UI
>>> suited to television. It has networking, dynamic ClassLoading and
>>> Serialization but most of RMI is missing.  To gain adequate privileges, an
>>> application jar file must be signed.
>>>
>>> This would require a separate River release, (Brook?)  It would have
>>> Service API, but lack service implementations, it could be used as an
>>> application client or provide services, but could never support the full
>>> Jini platform.
>>>
>>> However this should not hold back the River Jini platform, which should
>>> take advantage of newer Java language features.
>>>
>>> The build we have now is monolithic, which means we can't compile proxy's
>>> separately.  To remain network compatible with Java 1.4 proxy's need to be
>>> compiled with java 1.4 or a later platform using jsr14 to produce java 1.4
>>> compatible byte code.  However once we have a modular build,
>>>
>>
>> I've been trying to carve out some weekend time to begin the creation of a
>> River maven project that would provide the level of decomposition required
>> here (this also would mean the removal of classdepandjar, and use straight
>> forward dependencies based on the conventions that we have discussed to
>> resolve intra-service dependencies). If we have api/proxy modules, they can
>> be targeted for a specific platform. My only excuse to not starting this is
>> its just tough to carve out the time. I know I should stop whining and just
>> do it, hopefully soon.
>>
>>
>
> +1 Peter.
>
>>
>>>
>>> it may be feasible to introduce the latest version of river, which will
>>> require a late version of Java to run on, to communicate with earlier
>>> existing Jini and River installations which to date are still Java 1.4
>>> compatible.
>>>
>>> This does not mean that the River platform cannot utilise later java
>>> language features, it doesn't need to run on Java 1.4, just communicate with
>>> it.
>>>
>>> If the java 1.4 bytecode is too difficult to support for our proxy's,
>>> which may be the case, then we'll need to decide which later platform will
>>> be the minimum bytecode for our proxy's.
>>>
>>> Dennis, do you have any thoughts on how to support platform transitive
>>> dependency's?
>>>
>>
>> Could it be as simple as a service specific attribute that clients can
>> match on?
>>
>>
>>
>
> Perhaps, giving the client the opportunity to select the most suitable
> codebase from a list?
>
> I wonder about other services or exported objects passed to the service
> though, they also need to download a suitable codebase.
>
>
>

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Peter Firmstone <ji...@zeus.net.au>]

Dennis Reedy wrote:
> On Dec 2, 2010, at 618AM, Peter Firmstone wrote:
>
>   
>> Patricia Shanahan 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
>>>
>>>       
>> BDJ is a subset of Java 1.4, the bytecode is Java 1.4 compatible, it has Java 1.4 Security, JSSE and JCE.  It lacks Swing, has some AWT and a UI suited to television. It has networking, dynamic ClassLoading and Serialization but most of RMI is missing.  To gain adequate privileges, an application jar file must be signed.
>>
>> This would require a separate River release, (Brook?)  It would have Service API, but lack service implementations, it could be used as an application client or provide services, but could never support the full Jini platform.
>>
>> However this should not hold back the River Jini platform, which should take advantage of newer Java language features.
>>
>> The build we have now is monolithic, which means we can't compile proxy's separately.  To remain network compatible with Java 1.4 proxy's need to be compiled with java 1.4 or a later platform using jsr14 to produce java 1.4 compatible byte code.  However once we have a modular build,
>>     
>
> I've been trying to carve out some weekend time to begin the creation of a River maven project that would provide the level of decomposition required here (this also would mean the removal of classdepandjar, and use straight forward dependencies based on the conventions that we have discussed to resolve intra-service dependencies). If we have api/proxy modules, they can be targeted for a specific platform. My only excuse to not starting this is its just tough to carve out the time. I know I should stop whining and just do it, hopefully soon.
>
>   

+1 Peter.

>   
>> it may be feasible to introduce the latest version of river, which will require a late version of Java to run on, to communicate with earlier existing Jini and River installations which to date are still Java 1.4 compatible.
>>
>> This does not mean that the River platform cannot utilise later java language features, it doesn't need to run on Java 1.4, just communicate with it.
>>
>> If the java 1.4 bytecode is too difficult to support for our proxy's, which may be the case, then we'll need to decide which later platform will be the minimum bytecode for our proxy's.
>>
>> Dennis, do you have any thoughts on how to support platform transitive dependency's?
>>     
>
> Could it be as simple as a service specific attribute that clients can match on?
>
>
>   

Perhaps, giving the client the opportunity to select the most suitable 
codebase from a list?

I wonder about other services or exported objects passed to the service 
though, they also need to download a suitable codebase.

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Dennis Reedy <de...@gmail.com>]

On Dec 2, 2010, at 618AM, Peter Firmstone wrote:

> Patricia Shanahan 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
>> 
> BDJ is a subset of Java 1.4, the bytecode is Java 1.4 compatible, it has Java 1.4 Security, JSSE and JCE.  It lacks Swing, has some AWT and a UI suited to television. It has networking, dynamic ClassLoading and Serialization but most of RMI is missing.  To gain adequate privileges, an application jar file must be signed.
> 
> This would require a separate River release, (Brook?)  It would have Service API, but lack service implementations, it could be used as an application client or provide services, but could never support the full Jini platform.
> 
> However this should not hold back the River Jini platform, which should take advantage of newer Java language features.
> 
> The build we have now is monolithic, which means we can't compile proxy's separately.  To remain network compatible with Java 1.4 proxy's need to be compiled with java 1.4 or a later platform using jsr14 to produce java 1.4 compatible byte code.  However once we have a modular build,

I've been trying to carve out some weekend time to begin the creation of a River maven project that would provide the level of decomposition required here (this also would mean the removal of classdepandjar, and use straight forward dependencies based on the conventions that we have discussed to resolve intra-service dependencies). If we have api/proxy modules, they can be targeted for a specific platform. My only excuse to not starting this is its just tough to carve out the time. I know I should stop whining and just do it, hopefully soon.


> it may be feasible to introduce the latest version of river, which will require a late version of Java to run on, to communicate with earlier existing Jini and River installations which to date are still Java 1.4 compatible.
> 
> This does not mean that the River platform cannot utilise later java language features, it doesn't need to run on Java 1.4, just communicate with it.
> 
> If the java 1.4 bytecode is too difficult to support for our proxy's, which may be the case, then we'll need to decide which later platform will be the minimum bytecode for our proxy's.
> 
> Dennis, do you have any thoughts on how to support platform transitive dependency's?

Could it be as simple as a service specific attribute that clients can match on?

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Peter Firmstone <ji...@zeus.net.au>]

Patricia Shanahan 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
>
BDJ is a subset of Java 1.4, the bytecode is Java 1.4 compatible, it has 
Java 1.4 Security, JSSE and JCE.  It lacks Swing, has some AWT and a UI 
suited to television. It has networking, dynamic ClassLoading and 
Serialization but most of RMI is missing.  To gain adequate privileges, 
an application jar file must be signed.

This would require a separate River release, (Brook?)  It would have 
Service API, but lack service implementations, it could be used as an 
application client or provide services, but could never support the full 
Jini platform.

However this should not hold back the River Jini platform, which should 
take advantage of newer Java language features.

The build we have now is monolithic, which means we can't compile 
proxy's separately.  To remain network compatible with Java 1.4 proxy's 
need to be compiled with java 1.4 or a later platform using jsr14 to 
produce java 1.4 compatible byte code.  However once we have a modular 
build, it may be feasible to introduce the latest version of river, 
which will require a late version of Java to run on, to communicate with 
earlier existing Jini and River installations which to date are still 
Java 1.4 compatible.

This does not mean that the River platform cannot utilise later java 
language features, it doesn't need to run on Java 1.4, just communicate 
with it.

If the java 1.4 bytecode is too difficult to support for our proxy's, 
which may be the case, then we'll need to decide which later platform 
will be the minimum bytecode for our proxy's.

Dennis, do you have any thoughts on how to support platform transitive 
dependency's?

Peter.

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Dennis Reedy <de...@gmail.com>]

Apologies for getting wrapped around the axle here, I wanted to get some specifics on what River components were required in the RTSJ environment. I think it would be helpful to discuss that. 

Below, Greg asks an interesting question, I'd like to expand on it. Is it your requirement that all provided River services run in a RT Java VM? Even if they do not use any specific RTJ APIs? If so why?


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 <pa...@acm.org> 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
> mmcgrady@topiatechnology.com
> 
> 
> 

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[MICHAEL MCGRADY <mm...@topiatechnology.com>]

Thanks, Sim.

http://www.devx.com/Java/Article/33475

On Dec 2, 2010, at 7:03 AM, Sim IJskes - QCG wrote:

> On 02-12-10 15:58, MICHAEL MCGRADY wrote:
>> There are no RT requirements for River.  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.
> 
> No matter what the outcome is of the version debate, i would like to see/explained a way/method to verify the compatibility.
> 
> You cannot ask a developer to run on anything less then JDK6 nowadays. You can ask a developer to keep to certain compatibility conventions. In order to guard against mistakes, we need a (preferably) automated method of verifying if the code produced is still compatible.
> 
> When we argue for a certain version, shall we include the verification solution with it?
> 
> Gr. Sim
> 
> -- 
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

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

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Mike McGrady <mm...@topiatechnology.com>]

I know of no reason to think this is going to happen.  I think my friends in the industry would have notified me if this was imminent.

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 6:04 PM, Dennis Reedy <de...@gmail.com> wrote:

> 
> On Dec 2, 2010, at 840PM, Peter Firmstone wrote:
>>> 
>>> I Spoke to Greg Bollella over the phone about this some time ago, Oracle was quite keen on it, capable of generating lots of data see and well, Oracle have this database...
>>> 
>> Although I haven't heard anything, this problem might solve itself, given 6 months, perhaps there might be a 1.6 release of RTSJ, seeing as JSE 1.6 Embedded has also been released.
>> 
> 
> Interesting ... I saw that as well. Thanks for raising that issue Peter
> 
> Regards
> 
> Dennis
> 
> 
> 
> 

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Dennis Reedy <de...@gmail.com>]

On Dec 2, 2010, at 840PM, Peter Firmstone wrote:
>> 
>> I Spoke to Greg Bollella over the phone about this some time ago, Oracle was quite keen on it, capable of generating lots of data see and well, Oracle have this database...
>> 
> Although I haven't heard anything, this problem might solve itself, given 6 months, perhaps there might be a 1.6 release of RTSJ, seeing as JSE 1.6 Embedded has also been released.
> 

Interesting ... I saw that as well. Thanks for raising that issue Peter

Regards

Dennis

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Peter Firmstone <ji...@zeus.net.au>]

Peter Firmstone wrote:
> 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
>>
>>
>>
>>   
>
> I Spoke to Greg Bollella over the phone about this some time ago, 
> Oracle was quite keen on it, capable of generating lots of data see 
> and well, Oracle have this database...
>
Although I haven't heard anything, this problem might solve itself, 
given 6 months, perhaps there might be a 1.6 release of RTSJ, seeing as 
JSE 1.6 Embedded has also been released.

Cheers,

Peter.

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Peter Firmstone <ji...@zeus.net.au>]

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
>
>
>
>   

I Spoke to Greg Bollella over the phone about this some time ago, Oracle 
was quite keen on it, capable of generating lots of data see and well, 
Oracle have this database...

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Mike McGrady <mm...@topiatechnology.com>]

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 <de...@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
>>>>>>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Greg Trasuk <tr...@stratuscom.com>]

On Thu, 2010-12-02 at 21:34, Patricia Shanahan wrote:

> 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?".
> 
> Patricia

It's probably worth mentioning that int he J2EE world, there are many,
many folks out there on JDK 1.5 or earlier (for instance users of
Websphere Application Server 6).  There's no reason you can't call Jini
services from within a web layer (well, to be totally open I haven't
tried it under WAS6, but certainly have done it with no issues under
Tomcat).  So I can see some justification for not mandating JDK 1.6 just
yet.

Cheers,

Greg.
-- 
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.com

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Patricia Shanahan <pa...@acm.org>]

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?".

Patricia


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 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
>>>>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
> 
> 

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Dennis Reedy <de...@gmail.com>]

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 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
>>>>>>>> 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
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
> 

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Patricia Shanahan <pa...@acm.org>]

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 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
>>>>>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Dennis Reedy <de...@gmail.com>]

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
>>>>>> 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
>> 
>> 
>> 
>> 
>> 
>> 
> 

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Patricia Shanahan <pa...@acm.org>]

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
>>>>> 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
>
>
>
>
>
>

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[MICHAEL MCGRADY <mm...@topiatechnology.com>]

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
>>>> 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

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Dennis Reedy <de...@gmail.com>]

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
>>> 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
> 
> 
> 

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[MICHAEL MCGRADY <mm...@topiatechnology.com>]

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
>> 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

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Dennis Reedy <de...@gmail.com>]

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
> mmcgrady@topiatechnology.com
> 
> 
> 

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[MICHAEL MCGRADY <mm...@topiatechnology.com>]

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
mmcgrady@topiatechnology.com

Re: JVM version policy

[Gregg Wonderly <gr...@wonderly.org>]

In relation to "which JVMs are interesting", the article at

<http://terrencebarr.wordpress.com/2010/11/15/java-se-for-embedded-devices-new-release-new-features-better-performance/#comment-661>

has some information about more stuff brewing.  This type of environment could 
be a primary target for Jini enabled applications, and a ServiceUI based 
delivery mechanism.

Gregg Wonderly

On 12/2/2010 12:42 PM, 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
>
>
>

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Dennis Reedy <de...@gmail.com>]

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

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[MICHAEL MCGRADY <mm...@topiatechnology.com>]

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

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Dennis Reedy <de...@gmail.com>]

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?

> 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 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?

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Gerard Fulton <cg...@gmail.com>]

I think that Peter correct. River can potentially support both Java 1.5 and
1.6 in the future by implementing a modular build environment and using a
profile/API approach. In my opinion the fact that the Jini community refused
to address this issue was a serious black eye for the project.

Gerard



On Thu, Dec 2, 2010 at 7:03 AM, Sim IJskes - QCG <si...@qcg.nl> wrote:

> On 02-12-10 15:58, MICHAEL MCGRADY wrote:
>
>> There are no RT requirements for River.  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.
>>
>
> No matter what the outcome is of the version debate, i would like to
> see/explained a way/method to verify the compatibility.
>
> You cannot ask a developer to run on anything less then JDK6 nowadays. You
> can ask a developer to keep to certain compatibility conventions. In order
> to guard against mistakes, we need a (preferably) automated method of
> verifying if the code produced is still compatible.
>
> When we argue for a certain version, shall we include the verification
> solution with it?
>
> Gr. Sim
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Sim IJskes - QCG <si...@qcg.nl>]

On 02-12-10 15:58, MICHAEL MCGRADY wrote:
> There are no RT requirements for River.  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.

No matter what the outcome is of the version debate, i would like to 
see/explained a way/method to verify the compatibility.

You cannot ask a developer to run on anything less then JDK6 nowadays. 
You can ask a developer to keep to certain compatibility conventions. In 
order to guard against mistakes, we need a (preferably) automated method 
of verifying if the code produced is still compatible.

When we argue for a certain version, shall we include the verification 
solution with it?

Gr. Sim

-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[MICHAEL MCGRADY <mm...@topiatechnology.com>]

There are no RT requirements for River.  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.  

However, what boggles your mind is not accurate.  Once you touch the network real-time QoS does not go out the window.  And, your definition of the problem is one way to use real-time but it is not the way we use it and is irrelevant to what we do.  Essentially, and I cannot go into detail here, we use real-time functionality for converting various ways of structuring the importance of data to the ubiquitous standard of deadlines.  Believe me the government sees great value in what we do.  We are, among other things, a QoS solution for networking.

We are bound to River-like functionality (JINI) and JavaSpaces and RT in a network context.

MG


On Dec 2, 2010, at 5:15 AM, 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 <pa...@acm.org> 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
>> 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

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Patricia Shanahan <pa...@acm.org>]

On 12/4/2010 7:22 AM, Mike McGrady wrote:
> We could not tolerate JavaSpaces running on Java 1.6.  That is for
> sure.  This is a mistaken conclusion if you think this is a corollary
> or implication of what I said.

In any case, 1.6 does not really help JavaSpaces. The requirements for 
the main JavaSpaces data structure are unusual. It must allow rapid 
lookup by the combination of type and a template with some fields masked 
out, not just exact match.

The combination of performance requirements and special lookup rules 
calls for a custom data structure. There is no magic in 
ConcurrentHashMap, just fairly standard techniques that could also be 
applied in a custom data structure targeting JavaSpaces, as long as it 
can use the 1.5 memory model. A JavaSpaces data structure may also 
benefit from e.g. some of the atomic operations in 1.5, but I don't know 
for sure yet.

I need to do some reading, both to understand the current outrigger data 
structures, and to get up to date on the latest developments in 
concurrent data structures. The JavaSpaces lookup has some features in 
common with a relational database select operation, so I may look at 
some of the data structures used for that.

As far as I can tell, the only fully reliable technique for safe 
concurrent data access on 1.4 is synchronization, which could have very 
bad effects on performance.

Patricia

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Mike McGrady <mm...@topiatechnology.com>]

We could not tolerate JavaSpaces running on Java 1.6.  That is for sure.  This is a mistaken conclusion if you think this is a corollary or implication of what I said. 

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 3, 2010, at 6:45 PM, Peter Firmstone <ji...@zeus.net.au> wrote:

> As I suspected the suggestion would reveal Michael's needs for RTSJ.
> 
> We've established no one needs a real time server PLATFORM service, this means that the existing service implementations don't need to run on RTSJ, only the proxy's and a core platform for producing application services.
> 
> If we make River modular, Patricia can work on the Javaspace server implementation so it can utilise the latest platform concurrency features.  Therefore to run a Javaspace server, it must be installed the Java 1.6 platform.  The same can apply for Reggie, Mahalo and all the other service servers.
> 
> You can still use a Javaspace service on a RTSJ client, to produce information for the Javaspace cloud, where it can be processed using the producer consumer pattern.
> 
> Modularity is the Solution to multi platform support.
> 
> Where earlier Java platforms can participate, but don't provide platform services, only consume them.
> 
> The Service Implementations need to be separated from the River Jini Platform codebase.
> 
> This massively reduces the maintenance required to support earlier platforms.
> 
> I don't need to run any Platform service on BlueRay either.
> 
> Even if we don't call it modularity, River should be broken up, all the services can be subprojects, they can evolve at their own pace and needs, without being held back by earlier Java platform support requirements.
> 
> Cheers,
> 
> Peter.
> 
> MICHAEL MCGRADY wrote:
>> That is correct.  I do not think that River would be interested at this time in real-time constraints.  It is too big a jump for this place in the history and I am just asking for an incremental move to Java 1.5 from Java 1.4 to remain consistent with real-time JVMs.
>> 
>> MG
>> 
>> On Dec 2, 2010, at 11:38 PM, Patricia Shanahan 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 <ji...@zeus.net.au> 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 <pa...@acm.org> 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
>>>>>>>> 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
>> 
>>  ------------------------------------------------------------------------
>> 
>> 
>> 
>>  
> 

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Mike McGrady <mm...@topiatechnology.com>]

Peter, I think this is not the conclusion.  Let me think about what you are saying but one thing is clear that ultimately we cannot assume real-time applications processes are not separate from River services.

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 3, 2010, at 6:45 PM, Peter Firmstone <ji...@zeus.net.au> wrote:

> As I suspected the suggestion would reveal Michael's needs for RTSJ.
> 
> We've established no one needs a real time server PLATFORM service, this means that the existing service implementations don't need to run on RTSJ, only the proxy's and a core platform for producing application services.
> 
> If we make River modular, Patricia can work on the Javaspace server implementation so it can utilise the latest platform concurrency features.  Therefore to run a Javaspace server, it must be installed the Java 1.6 platform.  The same can apply for Reggie, Mahalo and all the other service servers.
> 
> You can still use a Javaspace service on a RTSJ client, to produce information for the Javaspace cloud, where it can be processed using the producer consumer pattern.
> 
> Modularity is the Solution to multi platform support.
> 
> Where earlier Java platforms can participate, but don't provide platform services, only consume them.
> 
> The Service Implementations need to be separated from the River Jini Platform codebase.
> 
> This massively reduces the maintenance required to support earlier platforms.
> 
> I don't need to run any Platform service on BlueRay either.
> 
> Even if we don't call it modularity, River should be broken up, all the services can be subprojects, they can evolve at their own pace and needs, without being held back by earlier Java platform support requirements.
> 
> Cheers,
> 
> Peter.
> 
> MICHAEL MCGRADY wrote:
>> That is correct.  I do not think that River would be interested at this time in real-time constraints.  It is too big a jump for this place in the history and I am just asking for an incremental move to Java 1.5 from Java 1.4 to remain consistent with real-time JVMs.
>> 
>> MG
>> 
>> On Dec 2, 2010, at 11:38 PM, Patricia Shanahan 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 <ji...@zeus.net.au> 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 <pa...@acm.org> 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
>>>>>>>> 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
>> 
>>  ------------------------------------------------------------------------
>> 
>> 
>> 
>>  
> 

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Dennis Reedy <de...@gmail.com>]

On Dec 4, 2010, at 1024AM, Mike McGrady wrote:

> We cannot throw our functionality into a client.  We are resident in the space.

I dont understand what you mean by "resident in the space". You move things through a JavaSpace, you dont execute things in a JavaSpace. Most likely I think you are mixing having a service in the same JVM as a JavaSpace (i.e. in a JVM that is hosting multiple services), as opposed to resident in the space.

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Mike McGrady <mm...@topiatechnology.com>]

We cannot throw our functionality into a client.  We are resident in the space.

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 3, 2010, at 6:45 PM, Peter Firmstone <ji...@zeus.net.au> wrote:

> As I suspected the suggestion would reveal Michael's needs for RTSJ.
> 
> We've established no one needs a real time server PLATFORM service, this means that the existing service implementations don't need to run on RTSJ, only the proxy's and a core platform for producing application services.
> 
> If we make River modular, Patricia can work on the Javaspace server implementation so it can utilise the latest platform concurrency features.  Therefore to run a Javaspace server, it must be installed the Java 1.6 platform.  The same can apply for Reggie, Mahalo and all the other service servers.
> 
> You can still use a Javaspace service on a RTSJ client, to produce information for the Javaspace cloud, where it can be processed using the producer consumer pattern.
> 
> Modularity is the Solution to multi platform support.
> 
> Where earlier Java platforms can participate, but don't provide platform services, only consume them.
> 
> The Service Implementations need to be separated from the River Jini Platform codebase.
> 
> This massively reduces the maintenance required to support earlier platforms.
> 
> I don't need to run any Platform service on BlueRay either.
> 
> Even if we don't call it modularity, River should be broken up, all the services can be subprojects, they can evolve at their own pace and needs, without being held back by earlier Java platform support requirements.
> 
> Cheers,
> 
> Peter.
> 
> MICHAEL MCGRADY wrote:
>> That is correct.  I do not think that River would be interested at this time in real-time constraints.  It is too big a jump for this place in the history and I am just asking for an incremental move to Java 1.5 from Java 1.4 to remain consistent with real-time JVMs.
>> 
>> MG
>> 
>> On Dec 2, 2010, at 11:38 PM, Patricia Shanahan 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 <ji...@zeus.net.au> 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 <pa...@acm.org> 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
>>>>>>>> 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
>> 
>>  ------------------------------------------------------------------------
>> 
>> 
>> 
>>  
> 

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Peter Firmstone <ji...@zeus.net.au>]

As I suspected the suggestion would reveal Michael's needs for RTSJ.

We've established no one needs a real time server PLATFORM service, this 
means that the existing service implementations don't need to run on 
RTSJ, only the proxy's and a core platform for producing application 
services.

If we make River modular, Patricia can work on the Javaspace server 
implementation so it can utilise the latest platform concurrency 
features.  Therefore to run a Javaspace server, it must be installed the 
Java 1.6 platform.  The same can apply for Reggie, Mahalo and all the 
other service servers.

You can still use a Javaspace service on a RTSJ client, to produce 
information for the Javaspace cloud, where it can be processed using the 
producer consumer pattern.

Modularity is the Solution to multi platform support.

Where earlier Java platforms can participate, but don't provide platform 
services, only consume them.

The Service Implementations need to be separated from the River Jini 
Platform codebase.

This massively reduces the maintenance required to support earlier 
platforms.

I don't need to run any Platform service on BlueRay either.

Even if we don't call it modularity, River should be broken up, all the 
services can be subprojects, they can evolve at their own pace and 
needs, without being held back by earlier Java platform support 
requirements.

Cheers,

Peter.

MICHAEL MCGRADY wrote:
> That is correct.  I do not think that River would be interested at this time in real-time constraints.  It is too big a jump for this place in the history and I am just asking for an incremental move to Java 1.5 from Java 1.4 to remain consistent with real-time JVMs.
>
> MG
>
> On Dec 2, 2010, at 11:38 PM, Patricia Shanahan 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 <ji...@zeus.net.au> 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 <pa...@acm.org> 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
>>>>>>> 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
>
>   
> ------------------------------------------------------------------------
>
>
>
>   

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[MICHAEL MCGRADY <mm...@topiatechnology.com>]

That is correct.  I do not think that River would be interested at this time in real-time constraints.  It is too big a jump for this place in the history and I am just asking for an incremental move to Java 1.5 from Java 1.4 to remain consistent with real-time JVMs.

MG

On Dec 2, 2010, at 11:38 PM, Patricia Shanahan 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 <ji...@zeus.net.au> 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 <pa...@acm.org> 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
>>>>>> 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

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Patricia Shanahan <pa...@acm.org>]

Those seem to me to be very good reasons to run with a 1.6 JVM if at all 
possible. I think that should be our strong recommendation, for the 
reasons you state.

Are there any negatives, other than not being able to use "Since 1.6" 
API features in the River source code, to keeping the code 1.5 
compatible, and compiling with 1.5? A 1.5 classfile can be used with a 
1.5 or 1.6 JVM.

Patricia


Christopher Dolan wrote:
> I would list bug fixes (specifically "no Thread.interrupt() classloader
> corruption") or maybe performance enhancements as the major reason for
> JDK 6 rather than newer features.  Outside of Swing and JAXB, there
> aren't very many compelling new features in JDK 6 that I'm aware of, and
> certainly not many that River would care about.
> 
> Chris
> 
> -----Original Message-----
> From: Sim IJskes - QCG [mailto:sim@qcg.nl] 
> Sent: Friday, December 03, 2010 2:33 AM
> To: river-dev@incubator.apache.org
> Subject: Re: JVM version policy Was: Re: Build failed in Hudson:
> River-trunk-jdk1.5 #3
> 
> On 03-12-10 09:25, Jeff Ramsdale wrote:
>> 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
> 
> Excellent! In order to make it possible for the discussion to resume 
> it's full amplitude at a later stage i've got the following condensed 
> version of the discussion:
> 
> # Compatibility requirements
> 
> JDK | Reason
> - | -
> 1.4 | CDC/BlueRay depends on it.
> 1.5 | RealTime Java (RTJ) depends on it.
> 6 | Newer features
> 
> I will document this on the website.
> 
> Gr. Sim
> 

RE: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Christopher Dolan <ch...@avid.com>]

I would list bug fixes (specifically "no Thread.interrupt() classloader
corruption") or maybe performance enhancements as the major reason for
JDK 6 rather than newer features.  Outside of Swing and JAXB, there
aren't very many compelling new features in JDK 6 that I'm aware of, and
certainly not many that River would care about.

Chris

-----Original Message-----
From: Sim IJskes - QCG [mailto:sim@qcg.nl] 
Sent: Friday, December 03, 2010 2:33 AM
To: river-dev@incubator.apache.org
Subject: Re: JVM version policy Was: Re: Build failed in Hudson:
River-trunk-jdk1.5 #3

On 03-12-10 09:25, Jeff Ramsdale wrote:
> 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

Excellent! In order to make it possible for the discussion to resume 
it's full amplitude at a later stage i've got the following condensed 
version of the discussion:

# Compatibility requirements

JDK | Reason
- | -
1.4 | CDC/BlueRay depends on it.
1.5 | RealTime Java (RTJ) depends on it.
6 | Newer features

I will document this on the website.

Gr. Sim

-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Sim IJskes - QCG <si...@qcg.nl>]

On 03-12-10 09:25, Jeff Ramsdale wrote:
> 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

Excellent! In order to make it possible for the discussion to resume 
it's full amplitude at a later stage i've got the following condensed 
version of the discussion:

# Compatibility requirements

JDK | Reason
- | -
1.4 | CDC/BlueRay depends on it.
1.5 | RealTime Java (RTJ) depends on it.
6 | Newer features

I will document this on the website.

Gr. Sim

-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Jeff Ramsdale <je...@gmail.com>]

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 <pa...@acm.org> 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 <ji...@zeus.net.au> 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 <pa...@acm.org> 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
>>>>>> mmcgrady@topiatechnology.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>
>>
>
>

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Patricia Shanahan <pa...@acm.org>]

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 <ji...@zeus.net.au> 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 <pa...@acm.org> 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
>>>>> mmcgrady@topiatechnology.com
>>>>>
>>>>>
>>>>>
>>>>
>>
>
>

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Peter Firmstone <ji...@zeus.net.au>]

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 <ji...@zeus.net.au> 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 <pa...@acm.org> 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
>>>> mmcgrady@topiatechnology.com
>>>>
>>>>
>>>>
>>>>    
>>>>         
>>>  
>>>       
>
>   

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Mike McGrady <mm...@topiatechnology.com>]

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 <ji...@zeus.net.au> 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 <pa...@acm.org> 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
>>> mmcgrady@topiatechnology.com
>>> 
>>> 
>>> 
>>>    
>> 
>> 
>>  
> 

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Peter Firmstone <ji...@zeus.net.au>]

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 <pa...@acm.org> 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
>> mmcgrady@topiatechnology.com
>>
>>
>>
>>     
>
>
>   

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Dennis Reedy <de...@gmail.com>]

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 <pa...@acm.org> 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
> mmcgrady@topiatechnology.com
> 
> 
> 

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[MICHAEL MCGRADY <mm...@topiatechnology.com>]

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 <pa...@acm.org> 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
mmcgrady@topiatechnology.com

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Patricia Shanahan <pa...@acm.org>]

Dennis Reedy wrote:
> On Dec 1, 2010, at 1133PM, Mike McGrady wrote:
> 
>> Like I said, Java 1.6 is incompatible with Java RTS and that os very serious in my neighborhood.  
> 
> Java 1.6 compiled to 1.5? 

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.

Patricia

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Dennis Reedy <de...@gmail.com>]

On Dec 1, 2010, at 1133PM, Mike McGrady wrote:

> Like I said, Java 1.6 is incompatible with Java RTS and that os very serious in my neighborhood.  

Java 1.6 compiled to 1.5? 

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Greg Trasuk <tr...@stratuscom.com>]

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 <pa...@acm.org> 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

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Mike McGrady <mm...@topiatechnology.com>]

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.

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 <pa...@acm.org> 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

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Patricia Shanahan <pa...@acm.org>]

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

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Dennis Reedy <de...@gmail.com>]

I would encourage that as you move along your 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. I dont think it's unreasonable to draw this line in the sand.

From my point of view backwards (pre 1.6) compatibility is required for client's that are not running on a 1.6 JVM. Service implementation does not seem to be the issue. If a wholesale replacement of the distribution is required, the requirements of the new distribution (River) must be met by those wanting to use the technology. Going forward, perhaps River should consider providing semantics for obtaining proxies that support specific versions of not only direct dependencies but also transitive dependencies (including JVM version requirements). In this way service producers can ensure that they support legacy clients that require outdated platform technology.

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.

Regards

Dennis

On Dec 1, 2010, at 707PM, Patricia Shanahan wrote:

> Peter Firmstone wrote:
> ...
>> The use of concurrent language features should be part of implementation rather than our public API, so in theory at least, the
>> jvm local components can utilise the latest language features and
>> run on the latest java platform while remaining network compatible
>> with older platforms and releases.
> 
> If everyone where running the current Java version, then whether we used
> particular API classes or not would indeed be implementation. The
> problem is getting the current Java version installed and available to
> us on *every* River-running system. Until we can do that, we can't use
> its features.
> 
> I'm scared that we are not QA testing with 1.4, and so may have
> accidentally introduced things that don't work with 1.4, but have not
> made a decision to abandon it.
> 
> ...
>> Concurrency is the future, at some point we've got a bullet to bite.
> ...
> 
> From my point of view concurrency is also the present and the past.
> 
> I remember my delight, in about 1983, when I switched from working on a
> multi-processor operating system to a compiler, and found I could do
> things like single stepping through code with the program doing exactly
> what it would have done at full speed, with no interrupts, timeouts, or
> other asynchronous changes in state. Amazingly, delightfully convenient.
> 
> But, yes, concurrency is spreading, and is not just for servers and
> professional workstations any more.
> 
> Patricia

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Patricia Shanahan <pa...@acm.org>]

Peter Firmstone wrote:
...
> The use of concurrent language features should be part of 
> implementation rather than our public API, so in theory at least, the
>  jvm local components can utilise the latest language features and
> run on the latest java platform while remaining network compatible
> with older platforms and releases.

If everyone where running the current Java version, then whether we used
particular API classes or not would indeed be implementation. The
problem is getting the current Java version installed and available to
us on *every* River-running system. Until we can do that, we can't use
its features.

I'm scared that we are not QA testing with 1.4, and so may have
accidentally introduced things that don't work with 1.4, but have not
made a decision to abandon it.

...
> Concurrency is the future, at some point we've got a bullet to bite.
...

 From my point of view concurrency is also the present and the past.

I remember my delight, in about 1983, when I switched from working on a
multi-processor operating system to a compiler, and found I could do
things like single stepping through code with the program doing exactly
what it would have done at full speed, with no interrupts, timeouts, or
other asynchronous changes in state. Amazingly, delightfully convenient.

But, yes, concurrency is spreading, and is not just for servers and
professional workstations any more.

Patricia

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Peter Firmstone <ji...@zeus.net.au>]

I think like that too.

Once we have a modular build, hopefully this will be easier to 
determine, I'd like to have my cake & eat it too. :-)

The use of concurrent language features should be part of implementation 
rather than our public API, so in theory at least, the jvm local 
components can utilise the latest language features and run on the 
latest java platform while remaining network compatible with older 
platforms and releases.

I guess it depends on how much work will be required.

I'm hoping we'll gain a better understanding as we work towards a 
modular release.

Concurrency is the future, at some point we've got a bullet to bite.

Cheers,

Peter.

Patricia Shanahan wrote:
> I have a constant tension between two ways of thinking.
>
> As a programmer, looking only at the best way to fix bugs and make the 
> software faster and more reliable, I sorely miss JDK 1.5 and 1.6 
> features, especially java.util.concurrent etc., which makes concurrent 
> programming much cleaner.
>
> On the other hand, I've interacted with people managing large 
> networks, and software developers who distribute their products to 
> organizations with large networks. Those two audiences tend to be 
> extremely conservative. Supporting an infrastructure software release 
> is a big deal, with enormous testing costs. Moving to a new release, 
> especially if it has to be done simultaneously on multiple systems, is 
> a major project, with months of planning and preparation.
>
> I am having a lot of trouble even deciding on my own position on which 
> releases to support.
>
> I would like to start a sub-project, perhaps as a Wiki page, on 
> writing a migration guide. If we can't come up with a good plan for 
> using our release strategy in a large network, we need to rethink the 
> release strategy. If we can, we should document it and ask the user 
> mailing list to review it.
>
> Patricia
>
>
> Gregg Wonderly wrote:
>> River's primary feature is network based communications and long 
>> running services with "compatibility" as a "key behavior" that makes 
>> things continue to work.  The original RMI implementation was 
>> unchangable from the outside.  The addition of JERI made 
>> "communication protocols" a deployment decision.  However, discovery 
>> still has to be "compatible" and we need to make real effort on 
>> "namespace" compatibility after the "switch to org.apache".  People 
>> will be forking river right and left and contributing nothing if we 
>> don't try very hard to "worry about compatibility" and "make it 
>> happen when at all possible".
>>
>> These are not desktop applications that get replaced by individual 
>> users randomly so they can take advantage of upgrades when they 
>> want.  This is about network based services with broadcast client 
>> deployment via ServiceUI, much like a web page is.  Since river is 
>> "infrastructure" and not "the service", we need to help users 
>> experience minimum impact on their deployments so that they can 
>> easily adopt new releases of river that include bug fixes for 
>> example.  The work that Patricia is doing to shake out transaction 
>> manager misbehaviors and probably leasing issues too, is the kind of 
>> "fixes" that we want everyone to be able to "accept" with "trivial 
>> compatibility issues".
>>
>> Gregg Wonderly
>>
>> On 11/24/2010 8:40 AM, Sim IJskes - QCG wrote:
>>> On 11/24/2010 03:11 PM, Patricia Shanahan wrote:
>>>
>>>> If we had started a formal vote, the qualification might indicate that
>>>> we had not yet done enough discussing. I suggest we continue 
>>>> discussing
>>>> a little longer, and then call a vote. We will probably be able to 
>>>> reach
>>>> a consensus proposal that will get a lot of definite positive votes.
>>>
>>> I'm aware off the differences between a formal and a informal vote. 
>>> A informal
>>> vote however is a clear indication how one will vote when a formal 
>>> vote is called.
>>>
>>> I can understand you want to go throught due process in determining 
>>> what we are
>>> going to do. But my personal impression from the mailing list 
>>> archives, is that
>>> the river project is completely gridlocked in subtleties. I'm not 
>>> saying that
>>> something agreed has a lifetime of infinity, but we have to start 
>>> somewhere.
>>> That means quick, decisive action, while keeping our options open.
>>>
>>> Suppose we declare to support 1.4, 1.5, 1.6 and CDC. How do we 
>>> validate this? I
>>> don't see us building a compatibity verification on short notice.
>>>
>>> If you want to go for river worlddomination, by keeping everything 
>>> compatible,
>>> you should bring a large suitcase of money. Then you can checkout an 
>>> older
>>> revision from the repo and build something with the horde of 
>>> programmers you are
>>> hiring.
>>>
>>> River has to grow from spurts from contributors, we are not going to 
>>> win a race
>>> by creating a swamp. I strongly believe that the current failure of 
>>> river is
>>> because of this longwinding process. We are not going to attract 
>>> more young
>>> eager bright committers if we keep on discussing the future of river 
>>> or the
>>> subtleties of compatibility.
>>>
>>> Gr. Sim
>>>
>>>
>>
>>
>
>

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Patricia Shanahan <pa...@acm.org>]

I have a constant tension between two ways of thinking.

As a programmer, looking only at the best way to fix bugs and make the 
software faster and more reliable, I sorely miss JDK 1.5 and 1.6 
features, especially java.util.concurrent etc., which makes concurrent 
programming much cleaner.

On the other hand, I've interacted with people managing large networks, 
and software developers who distribute their products to organizations 
with large networks. Those two audiences tend to be extremely 
conservative. Supporting an infrastructure software release is a big 
deal, with enormous testing costs. Moving to a new release, especially 
if it has to be done simultaneously on multiple systems, is a major 
project, with months of planning and preparation.

I am having a lot of trouble even deciding on my own position on which 
releases to support.

I would like to start a sub-project, perhaps as a Wiki page, on writing 
a migration guide. If we can't come up with a good plan for using our 
release strategy in a large network, we need to rethink the release 
strategy. If we can, we should document it and ask the user mailing list 
to review it.

Patricia


Gregg Wonderly wrote:
> River's primary feature is network based communications and long running 
> services with "compatibility" as a "key behavior" that makes things 
> continue to work.  The original RMI implementation was unchangable from 
> the outside.  The addition of JERI made "communication protocols" a 
> deployment decision.  However, discovery still has to be "compatible" 
> and we need to make real effort on "namespace" compatibility after the 
> "switch to org.apache".  People will be forking river right and left and 
> contributing nothing if we don't try very hard to "worry about 
> compatibility" and "make it happen when at all possible".
> 
> These are not desktop applications that get replaced by individual users 
> randomly so they can take advantage of upgrades when they want.  This is 
> about network based services with broadcast client deployment via 
> ServiceUI, much like a web page is.  Since river is "infrastructure" and 
> not "the service", we need to help users experience minimum impact on 
> their deployments so that they can easily adopt new releases of river 
> that include bug fixes for example.  The work that Patricia is doing to 
> shake out transaction manager misbehaviors and probably leasing issues 
> too, is the kind of "fixes" that we want everyone to be able to "accept" 
> with "trivial compatibility issues".
> 
> Gregg Wonderly
> 
> On 11/24/2010 8:40 AM, Sim IJskes - QCG wrote:
>> On 11/24/2010 03:11 PM, Patricia Shanahan wrote:
>>
>>> If we had started a formal vote, the qualification might indicate that
>>> we had not yet done enough discussing. I suggest we continue discussing
>>> a little longer, and then call a vote. We will probably be able to reach
>>> a consensus proposal that will get a lot of definite positive votes.
>>
>> I'm aware off the differences between a formal and a informal vote. A 
>> informal
>> vote however is a clear indication how one will vote when a formal 
>> vote is called.
>>
>> I can understand you want to go throught due process in determining 
>> what we are
>> going to do. But my personal impression from the mailing list 
>> archives, is that
>> the river project is completely gridlocked in subtleties. I'm not 
>> saying that
>> something agreed has a lifetime of infinity, but we have to start 
>> somewhere.
>> That means quick, decisive action, while keeping our options open.
>>
>> Suppose we declare to support 1.4, 1.5, 1.6 and CDC. How do we 
>> validate this? I
>> don't see us building a compatibity verification on short notice.
>>
>> If you want to go for river worlddomination, by keeping everything 
>> compatible,
>> you should bring a large suitcase of money. Then you can checkout an 
>> older
>> revision from the repo and build something with the horde of 
>> programmers you are
>> hiring.
>>
>> River has to grow from spurts from contributors, we are not going to 
>> win a race
>> by creating a swamp. I strongly believe that the current failure of 
>> river is
>> because of this longwinding process. We are not going to attract more 
>> young
>> eager bright committers if we keep on discussing the future of river 
>> or the
>> subtleties of compatibility.
>>
>> Gr. Sim
>>
>>
> 
> 

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Gregg Wonderly <gr...@wonderly.org>]

River's primary feature is network based communications and long running 
services with "compatibility" as a "key behavior" that makes things continue to 
work.  The original RMI implementation was unchangable from the outside.  The 
addition of JERI made "communication protocols" a deployment decision.  However, 
discovery still has to be "compatible" and we need to make real effort on 
"namespace" compatibility after the "switch to org.apache".  People will be 
forking river right and left and contributing nothing if we don't try very hard 
to "worry about compatibility" and "make it happen when at all possible".

These are not desktop applications that get replaced by individual users 
randomly so they can take advantage of upgrades when they want.  This is about 
network based services with broadcast client deployment via ServiceUI, much like 
a web page is.  Since river is "infrastructure" and not "the service", we need 
to help users experience minimum impact on their deployments so that they can 
easily adopt new releases of river that include bug fixes for example.  The work 
that Patricia is doing to shake out transaction manager misbehaviors and 
probably leasing issues too, is the kind of "fixes" that we want everyone to be 
able to "accept" with "trivial compatibility issues".

Gregg Wonderly

On 11/24/2010 8:40 AM, Sim IJskes - QCG wrote:
> On 11/24/2010 03:11 PM, Patricia Shanahan wrote:
>
>> If we had started a formal vote, the qualification might indicate that
>> we had not yet done enough discussing. I suggest we continue discussing
>> a little longer, and then call a vote. We will probably be able to reach
>> a consensus proposal that will get a lot of definite positive votes.
>
> I'm aware off the differences between a formal and a informal vote. A informal
> vote however is a clear indication how one will vote when a formal vote is called.
>
> I can understand you want to go throught due process in determining what we are
> going to do. But my personal impression from the mailing list archives, is that
> the river project is completely gridlocked in subtleties. I'm not saying that
> something agreed has a lifetime of infinity, but we have to start somewhere.
> That means quick, decisive action, while keeping our options open.
>
> Suppose we declare to support 1.4, 1.5, 1.6 and CDC. How do we validate this? I
> don't see us building a compatibity verification on short notice.
>
> If you want to go for river worlddomination, by keeping everything compatible,
> you should bring a large suitcase of money. Then you can checkout an older
> revision from the repo and build something with the horde of programmers you are
> hiring.
>
> River has to grow from spurts from contributors, we are not going to win a race
> by creating a swamp. I strongly believe that the current failure of river is
> because of this longwinding process. We are not going to attract more young
> eager bright committers if we keep on discussing the future of river or the
> subtleties of compatibility.
>
> Gr. Sim
>
>

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Patricia Shanahan <pa...@acm.org>]

Peter Firmstone wrote:
> Well this is a tough one, here are some ideas:
> 
>   1. Branch what we have now for release and simply reset the compiler
>      flag, to jsr14, which buys time until we have a more modular
>      build, then based on what we know then, decide if ongoing support
>      for remote clients using Java 1.4 is feasible.  For this release,
>      test on Java 1.4, 5 and 6.  We could adopt a policy that if a bug
>      exists on Java 1.4 or 5, but not on 6, then the fix is to upgrade
>      to Java 6.  Users would of course be free to submit a patch, but
>      we wouldn't actively support the earlier platforms.
>   2. Compile on JDK 1.6 and support only Java 5 and 6, drop support for
>      communicating with remote Java 1.4 clients.  If we find that it is
>      later possible to support Java 1.4 clients with the modular build,
>      users can skip the current release.  Users can work around the
>      Java 1.4 communication issue if they need to, by using proxy
>      codebases from the previous release only.
...
> I think you touched on something earlier, it's important we address ease 
> of deployment.

In both cases, I think we want to encourage a move towards 6. Even in a 
corporate environment, it is often difficult to simultaneously upgrade 
to a new JVM for a lot of jobs, on different computers.

I'm interested in probing the path for a current 1.4 installation to 6 
for each approach. The more I think about it, the more I feel that 
keeping 1.4 as a common language for proxies might be an advantage.

Patricia

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Peter Firmstone <ji...@zeus.net.au>]

Well this is a tough one, here are some ideas:

   1. Branch what we have now for release and simply reset the compiler
      flag, to jsr14, which buys time until we have a more modular
      build, then based on what we know then, decide if ongoing support
      for remote clients using Java 1.4 is feasible.  For this release,
      test on Java 1.4, 5 and 6.  We could adopt a policy that if a bug
      exists on Java 1.4 or 5, but not on 6, then the fix is to upgrade
      to Java 6.  Users would of course be free to submit a patch, but
      we wouldn't actively support the earlier platforms.
   2. Compile on JDK 1.6 and support only Java 5 and 6, drop support for
      communicating with remote Java 1.4 clients.  If we find that it is
      later possible to support Java 1.4 clients with the modular build,
      users can skip the current release.  Users can work around the
      Java 1.4 communication issue if they need to, by using proxy
      codebases from the previous release only.

 
Patricia's right, just because Sun didn't do it, doesn't mean we can't.  
Jini didn't succeed because it was maligned, J2EE was corporate Java, 
Jini wasn't marketed to the corporate environment and wouldn't gain much 
foothold now anyway, the toaster marketing didn't succeed either.

The one market that has captured the imagination of so many programmers 
when it comes to Jini's and now River's promise is that of Ubiquitous 
computing, the internet, has never been targeted, although Jini started 
moving in that direction with Jini 2.1.  Private networks are corporate 
environments, although River / Jini has some niche markets in 
specialized areas, River's true hope for success is the internet and the 
internet developer community, who seem happy to try almost anything.

Don't forget the embedded market, Java SE Embedded (Java 1.6) is MVM and 
has the Isolates API, in some ways, it's superior to Java SE, River can 
still shine here too.

It is true that I'm not currently working on an implementation for Java 
CDC, this would be a subset platform, because it's missing much of RMI, 
it can still use Discovery V2, since that is based on 
MarshalledInstance, not MarshalledObject.  Dropping support for 
communication with Java 1.4 based platforms long term means any Java CDC 
implementation would have to play in its own universe, there would still 
be other communications means available, like plain old serialization 
and Surrogate.  It would limit the possibility of creating interactive 
ServiceUI, because there would be no current compatible Server platform 
for SE. If the consensus is to go Java 5 and 6, and Drop 1.4, it will be 
unlikely that I'll do anything with Java CDC for the above reasons, but 
this wont dampen my spirit for River, were forging ahead in leaps and 
bounds.  We can't all agree all the time, but it's important we have the 
discussion.

I think you touched on something earlier, it's important we address ease 
of deployment.

Cheers,

Peter.

Patricia Shanahan wrote:
> Sim IJskes - QCG wrote:
> ...
>> We are not going to create a communication universe where every 
>> machine talks jini to every other machine. This was a goal Sun had. 
>> They did not succeed. Are we going to?
> ...
>
> There is nothing magic about Sun.
>
> The question of whether we can achieve something Sun didn't depends on 
> why they didn't. Obviously, Sun had more programmers than we have. On 
> the other hand, those programmers were always limited by conflicting 
> demands on their time and energy.
>
> I used to work for Sun - nothing to do with Jini, I was performance 
> architect for a couple of Sun's large servers - but I worked with a 
> lot of Sun programmers. They were capable, but no more so than the 
> current River team.
>
> Sometimes a small group operating without management interference can 
> achieve things that would be impossible for a large organized team.
>
> I think we should look at the usability and migration consequences of 
> the various options, and do the best we can with reasonable effort. In 
> particular, I would like to see a migration path that does not require 
> all communicating systems to change JVM version simultaneously.
>
> Patricia
>

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Patricia Shanahan <pa...@acm.org>]

Sim IJskes - QCG wrote:
...
> We are not going to create a communication universe where every machine 
> talks jini to every other machine. This was a goal Sun had. They did not 
> succeed. Are we going to?
...

There is nothing magic about Sun.

The question of whether we can achieve something Sun didn't depends on 
why they didn't. Obviously, Sun had more programmers than we have. On 
the other hand, those programmers were always limited by conflicting 
demands on their time and energy.

I used to work for Sun - nothing to do with Jini, I was performance 
architect for a couple of Sun's large servers - but I worked with a lot 
of Sun programmers. They were capable, but no more so than the current 
River team.

Sometimes a small group operating without management interference can 
achieve things that would be impossible for a large organized team.

I think we should look at the usability and migration consequences of 
the various options, and do the best we can with reasonable effort. In 
particular, I would like to see a migration path that does not require 
all communicating systems to change JVM version simultaneously.

Patricia

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Sim IJskes - QCG <si...@qcg.nl>]

On 11/24/2010 09:57 PM, Patricia Shanahan wrote:
> Version and compatibility issues in a distributed system are full of
> pitfalls. I would rather spend a few days discussing them now than make
> a decision that turns out to be wrong, and either killing River or
> having to do a massive back-track and retest effort in a few months time.

I understand your fears. I will sit on my hands while the discussion is 
underway. Some thoughts:
  * We can always backport fixes into older versions.
  * We don't have the resources a company like Sun had.
  * We don't have much to lose.
  * We can't verify compatibility.

My personal view is that we have to scale down on our ambitions.

We are not going to create a communication universe where every machine 
talks jini to every other machine. This was a goal Sun had. They did not 
succeed. Are we going to?

> I'll be happy if we end up with a well thought out decision that can be
> documented on the web site and communicated to users next week.

I would also be happy when we manage that in such a short time.

Gr. Sim

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Patricia Shanahan <pa...@acm.org>]

Sim IJskes - QCG wrote:
...
> I can understand you want to go throught due process in determining what 
> we are going to do. But my personal impression from the mailing list 
> archives, is that the river project is completely gridlocked in 
> subtleties. I'm not saying that something agreed has a lifetime of 
> infinity, but we have to start somewhere. That means quick, decisive 
> action, while keeping our options open.
...

Everything should be as simple as it can be, but no simpler.

There are a lot of things where I'm all in favor of quick, decisive 
action. If I find a bug, I'm going to check in a fix without a lot of 
discussion. I'm in favor of doing a single massive package rename for 
the com.sun.jini packages.

Version and compatibility issues in a distributed system are full of 
pitfalls. I would rather spend a few days discussing them now than make 
a decision that turns out to be wrong, and either killing River or 
having to do a massive back-track and retest effort in a few months time.

I'll be happy if we end up with a well thought out decision that can be 
documented on the web site and communicated to users next week.

Patricia

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Sim IJskes - QCG <si...@qcg.nl>]

On 11/24/2010 03:11 PM, Patricia Shanahan wrote:

> If we had started a formal vote, the qualification might indicate that
> we had not yet done enough discussing. I suggest we continue discussing
> a little longer, and then call a vote. We will probably be able to reach
> a consensus proposal that will get a lot of definite positive votes.

I'm aware off the differences between a formal and a informal vote. A 
informal vote however is a clear indication how one will vote when a 
formal vote is called.

I can understand you want to go throught due process in determining what 
we are going to do. But my personal impression from the mailing list 
archives, is that the river project is completely gridlocked in 
subtleties. I'm not saying that something agreed has a lifetime of 
infinity, but we have to start somewhere. That means quick, decisive 
action, while keeping our options open.

Suppose we declare to support 1.4, 1.5, 1.6 and CDC. How do we validate 
this? I don't see us building a compatibity verification on short notice.

If you want to go for river worlddomination, by keeping everything 
compatible, you should bring a large suitcase of money. Then you can 
checkout an older revision from the repo and build something with the 
horde of programmers you are hiring.

River has to grow from spurts from contributors, we are not going to win 
a race by creating a swamp. I strongly believe that the current failure 
of river is because of this longwinding process. We are not going to 
attract more young eager bright committers if we keep on discussing the 
future of river or the subtleties of compatibility.

Gr. Sim

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Patricia Shanahan <pa...@acm.org>]

Sim IJskes - QCG wrote:
> On 11/24/2010 01:52 AM, Peter Firmstone wrote:
>> +1  For the current build.
> 
> Voting does not allow for an extra qualification. Does this mean that 
> you will only vote +1 if a terminating clause is included?

I think we need to distinguish better between discussing and voting. I
suggest that when we are doing a formal vote we put "[VOTE]" in the
subject line, and have a definite proposition that we are voting on.
Until we do that, we are still discussing, "+1" is an idiom
indicating general agreement, and it can be qualified just as much as "I 
generally agree with the quoted message." could be qualified.

If we had started a formal vote, the qualification might indicate that
we had not yet done enough discussing. I suggest we continue discussing
a little longer, and then call a vote. We will probably be able to reach
a consensus proposal that will get a lot of definite positive votes.

Patricia

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Sim IJskes - QCG <si...@qcg.nl>]

On 11/24/2010 01:52 AM, Peter Firmstone wrote:
> +1  For the current build.

Voting does not allow for an extra qualification. Does this mean that 
you will only vote +1 if a terminating clause is included?

Gr. Sim

Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Peter Firmstone <ji...@zeus.net.au>]

+1  For the current build.

Although I still think we need to investigate a modular build, to enable 
compiling our proxy codebases to be compatible with JDK 1.4, for 
compatibility with earlier Jini releases running on earlier Java 
platforms.  I still would like to do a separate Java CDC release using a 
jini platform subset.  Doing either will only be possible if we make our 
build more modular.

Java CDC (Blue Ray & TV) looks to become a significantly larger client 
platform than Java SE, unless Java SE Embedded can break into the mobile 
phone market.

I've seen many OS / architectures become marginalised by neglecting the 
client.  Java is at risk here too.

We've got the benefit of infinite client flexibility with Jini, since 
the ServiceUI can be different for each client, even while utilising the 
same service.

Peter.

Christopher Dolan wrote:
> I had previous advocated for 1.5 support.  But now that I've learned
> that Thread.interrupt() breaks classloading in 1.5 and that there's no
> feasible workaround for River, I'm eager to abandon that JRE version.
> So I vote for 1.6 only.
>
> Chris
>
> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org] 
> Sent: Tuesday, November 23, 2010 10:35 AM
> To: river-dev@incubator.apache.org
> Subject: JVM version policy Was: Re: Build failed in Hudson:
> River-trunk-jdk1.5 #3
>
> Sim IJskes - QCG wrote:
> ...
>   
>> In order to make a decision/think of a fix i need a clear version 
>> support policy. Not something i need to trawl the mailing list
>>     
> archives 
>   
>> for. Anybody else having the same opinion?
>>     
> ...
>
> +1 on the need for a clear version support policy without depending on 
> trawling the mailing list archives. We should discuss and vote on a 
> policy, and then document it on the web site.
>
> I am strongly opposed to attempting to support any version that we do 
> not routinely regression test. In practice, that means supporting at 
> most two releases. If we think we can handle two, I suggest 1.5 and 1.6.
>
> If not, I think 1.6 only.
>
> Patricia
>
>   

RE: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3

[Christopher Dolan <ch...@avid.com>]

I had previous advocated for 1.5 support.  But now that I've learned
that Thread.interrupt() breaks classloading in 1.5 and that there's no
feasible workaround for River, I'm eager to abandon that JRE version.
So I vote for 1.6 only.

Chris

-----Original Message-----
From: Patricia Shanahan [mailto:pats@acm.org] 
Sent: Tuesday, November 23, 2010 10:35 AM
To: river-dev@incubator.apache.org
Subject: JVM version policy Was: Re: Build failed in Hudson:
River-trunk-jdk1.5 #3

Sim IJskes - QCG wrote:
...
> In order to make a decision/think of a fix i need a clear version 
> support policy. Not something i need to trawl the mailing list
archives 
> for. Anybody else having the same opinion?
...

+1 on the need for a clear version support policy without depending on 
trawling the mailing list archives. We should discuss and vote on a 
policy, and then document it on the web site.

I am strongly opposed to attempting to support any version that we do 
not routinely regression test. In practice, that means supporting at 
most two releases. If we think we can handle two, I suggest 1.5 and 1.6.

If not, I think 1.6 only.

Patricia