You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2010/09/14 03:26:14 UTC
Modular Build, Java 5, (Was: Re: Unexpected Test Results)
Some time back, we voted to include Java 5 language features.
We didn't vote to drop support for Java 1.4 at the time and I was
considering different options for ongoing maintenance support of Java 1.4.
The last release 2.1.2, still supports Java 1.4
What I'd like to consider is that the previous branch be used to
maintain support for Java 1.4 and our next release only support Java 1.5
onward. However an additional requirement of a distributed platform
release, is that it plays nicely with existing Java 1.4 installations,
which means smart proxy's still need to be compiled in Java 1.4 bytecode
(and perhaps Service API). Service API will be already installed in the
clients local classpath for Java 1.4 installations, but the smart proxy
code depends on Service API and won't compile if they're Java 1.5.
So while Serialization compatibility is maintained across releases, we
just need to have compatible bytecode.
Perhaps with maven provisioning there could be an opportunity for
clients to select platform compatible bytecode at some time in the future.
I guess we need to figure out how to compile the majority of classes
using "1.5", while compiling proxy classes using "1.4".
It is possible I think, to specify different class paths in the client
jvm's of the test suite, so potentially we could test the current
distribution with clients using the previous release and Java 1.4, while
the server uses Java 5 or 6.
This might require a separate release of the Test Suite, this would be
useful to test binary compatibility also, very important in a
distributed environment.
This allows a migration path away from Java 1.4.
"jsr14" is a build hack.
To achieve this, I think we'll need to change the way we currently
package River, to be more modular along the lines Dan Rollo has suggested.
This might also be an opportunity to break out the Service
Implementations into separate components or subprojects perhaps, each
depending on the platform and test kit and each having it's own tests.
Allowing one to develop on a small component of the platform and run
only relevant tests, for faster feedback. All components might be
assembled and run on Hudson.
Possible Components:
Service API. (Java 1.4)
Jini Platform (depends on Service API) (Java 5)
Jini libraries. (Java 5)
Jini Security Policy.
Test Kit
Jini Compatibility Tests.
Reggie
Mahalo
Outrigger
Phoenix
Fiddler
Norm
Mercury
A client developer then only needs the Platform and Service API jar's.
Then when someone creates their own djinn, they can add the services as
they require them, reducing complexity for new developers.
Regards,
Peter.
Patricia Shanahan wrote:
> Found it. common.xml contains a macro definition, javac-cmd, which I
> believe does the actual compilation. It defaults the -target parameter
> to "jsr14". Changing it to "1.5" allows my Iterable construct to
> compile, but should continue generation of java 1.5 compatible code.
>
> "jsr14" was an interim mode for experimentation with the 1.5 features
> on a 1.4 JVM. It does support for-each for a Collection, but not
> Iterable, which was added in 1.5, which explains my problem.
>
> Any class files that work on 1.4 should also work on 1.5, explaining
> Peter's observation.
>
> Should River continue 1.4 support? If yes, we need to test on 1.4, as
> well as 5, 6, and potentially 7. Note that there may be a performance
> price, such as less efficient autoboxing code. If no, we should change
> the target default to "1.5".
>
> Patricia
>
>
> On 9/13/2010 3:38 PM, Patricia Shanahan wrote:
> ....
>> Here's a theory. There is some parameter (or parameters) we don't know
>> about being passed to javac as part of the ant all.build that affects
>> the compiler's personality. It is generating 1.5 compatible code, and
>> rejecting a construct that I think should be accepted.
> ...
>> On 9/13/2010 1:16 PM, Peter Firmstone wrote:
>>> [java] -----------------------------------------
>>> [java]
>>> [java] # of tests started = 581
>>> [java] # of tests completed = 581
>>> [java] # of tests skipped = 21
>>> [java] # of tests passed = 581
>>> [java] # of tests failed = 0
>>> [java]
>>> [java] -----------------------------------------
>>> [java]
>>> [java] Date finished:
>>> [java] Tue Sep 14 01:08:05 EST 2010
>>> [java] Time elapsed:
>>> [java] 19953 seconds
>>> [java]
>>>
>>> BUILD SUCCESSFUL
>>> Total time: 332 minutes 40 seconds
>>>
>>> These test results are from qa.run executing on Java 5, so I was
>>> expecting some test failures, knowing that the test suite doesn't
>>> compile with JDK 1.5.
>
Re: Modular Build, Java 5, (Was: Re: Unexpected Test Results)
Posted by Jonathan Costers <jo...@googlemail.com>.
Please do. Thanks!
2010/9/15 Peter Firmstone <ji...@zeus.net.au>
> Jonathan Costers wrote:
>
>> Make sure we have the original River distribution working OK (i.e. get all
>> test passing): +1
>>
>>
> I've got skunk/pepe passing alright, I've removed the problematic
> experimental code. Would you like me to remove the experimental classes
> from trunk?
>
> Actually there is one test in jtreg we need to look into, but I figure we
> can wait for the qa tests to be right first.
>
> Worry about issues that are not even relevant if we don't have a working
>> distributrion: -1
>>
>>
>> 2010/9/15 Sim IJskes - QCG <si...@qcg.nl>
>>
>>
>>
>>> On 09/15/2010 01:56 AM, Peter Firmstone wrote:
>>>
>>>
>>>
>>>> I don't want to have to answer user queries like: "I've set up a new
>>>> djinn group for my new Apache River nodes, but my existing Jini nodes
>>>> can't discover the new group. The new nodes are using my existing
>>>> programs and they work among themselves, but the new Registrars aren't
>>>> working with my older nodes. The new nodes services work with my old
>>>> clients only if they register with existing Registrars. Reggie seems
>>>> broken in Apache River 2.2.0?"
>>>>
>>>>
>>>>
>>> Why don't we just worry about creating a working River, and let the
>>> compatibility issues be solved by the market? Most deployments are done
>>> within the boundaries of a single organization. They should have done
>>> this
>>> incompatible upgrade multiple times, it not something that is unique to a
>>> river upgrade. Most bigger organizations will have their own
>>> software-library, and establish their own software baselines by cloning
>>> our
>>> vcs.
>>>
>>> Keep compatible: -1
>>>
>>> Gr. Sim
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
Re: Modular Build, Java 5, (Was: Re: Unexpected Test Results)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Jonathan Costers wrote:
> Make sure we have the original River distribution working OK (i.e. get all
> test passing): +1
>
I've got skunk/pepe passing alright, I've removed the problematic
experimental code. Would you like me to remove the experimental classes
from trunk?
Actually there is one test in jtreg we need to look into, but I figure
we can wait for the qa tests to be right first.
> Worry about issues that are not even relevant if we don't have a working
> distributrion: -1
>
>
> 2010/9/15 Sim IJskes - QCG <si...@qcg.nl>
>
>
>> On 09/15/2010 01:56 AM, Peter Firmstone wrote:
>>
>>
>>> I don't want to have to answer user queries like: "I've set up a new
>>> djinn group for my new Apache River nodes, but my existing Jini nodes
>>> can't discover the new group. The new nodes are using my existing
>>> programs and they work among themselves, but the new Registrars aren't
>>> working with my older nodes. The new nodes services work with my old
>>> clients only if they register with existing Registrars. Reggie seems
>>> broken in Apache River 2.2.0?"
>>>
>>>
>> Why don't we just worry about creating a working River, and let the
>> compatibility issues be solved by the market? Most deployments are done
>> within the boundaries of a single organization. They should have done this
>> incompatible upgrade multiple times, it not something that is unique to a
>> river upgrade. Most bigger organizations will have their own
>> software-library, and establish their own software baselines by cloning our
>> vcs.
>>
>> Keep compatible: -1
>>
>> Gr. Sim
>>
>>
>>
>>
>>
>>
>
>
Re: Modular Build, Java 5, (Was: Re: Unexpected Test Results)
Posted by Jonathan Costers <jo...@googlemail.com>.
Make sure we have the original River distribution working OK (i.e. get all
test passing): +1
Worry about issues that are not even relevant if we don't have a working
distributrion: -1
2010/9/15 Sim IJskes - QCG <si...@qcg.nl>
> On 09/15/2010 01:56 AM, Peter Firmstone wrote:
>
>> I don't want to have to answer user queries like: "I've set up a new
>> djinn group for my new Apache River nodes, but my existing Jini nodes
>> can't discover the new group. The new nodes are using my existing
>> programs and they work among themselves, but the new Registrars aren't
>> working with my older nodes. The new nodes services work with my old
>> clients only if they register with existing Registrars. Reggie seems
>> broken in Apache River 2.2.0?"
>>
>
> Why don't we just worry about creating a working River, and let the
> compatibility issues be solved by the market? Most deployments are done
> within the boundaries of a single organization. They should have done this
> incompatible upgrade multiple times, it not something that is unique to a
> river upgrade. Most bigger organizations will have their own
> software-library, and establish their own software baselines by cloning our
> vcs.
>
> Keep compatible: -1
>
> Gr. Sim
>
>
>
>
>
Re: Modular Build, Java 5, (Was: Re: Unexpected Test Results)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Thanks Sim,
Interesting, target 1.4 might not be the solution. Looks like the
safest way is to compile your target with the jdk version you're targeting.
Cheers,
Peter.
Sim IJskes - QCG wrote:
> I haven't checked the claims in the article, but interesting none the
> less:
>
> http://madbean.com/2006/target14/
>
> On 09/15/2010 10:45 AM, Peter Firmstone wrote:
>> Since we're not gaining by breaking compatibility in this case, I'd
>> first like to experiment / investigate the possibility of having a build
>> that allows the smart proxy's and existing Service API to be compiled
>> with target=1.4 and the rest of the build compiled with target=6.
>>
>> After investigating the possibility of a solution, we can vote on the
>> issue then if you still feel strongly about it.
>>
>> I was hoping someone already knew of a solution.
>>
>> Peter.
>>
>
Re: Modular Build, Java 5, (Was: Re: Unexpected Test Results)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
I haven't checked the claims in the article, but interesting none the less:
http://madbean.com/2006/target14/
On 09/15/2010 10:45 AM, Peter Firmstone wrote:
> Since we're not gaining by breaking compatibility in this case, I'd
> first like to experiment / investigate the possibility of having a build
> that allows the smart proxy's and existing Service API to be compiled
> with target=1.4 and the rest of the build compiled with target=6.
>
> After investigating the possibility of a solution, we can vote on the
> issue then if you still feel strongly about it.
>
> I was hoping someone already knew of a solution.
>
> Peter.
>
Re: Modular Build, Java 5, (Was: Re: Unexpected Test Results)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Since we're not gaining by breaking compatibility in this case, I'd
first like to experiment / investigate the possibility of having a build
that allows the smart proxy's and existing Service API to be compiled
with target=1.4 and the rest of the build compiled with target=6.
After investigating the possibility of a solution, we can vote on the
issue then if you still feel strongly about it.
I was hoping someone already knew of a solution.
Peter.
Sim IJskes - QCG wrote:
> On 09/15/2010 01:56 AM, Peter Firmstone wrote:
>> I don't want to have to answer user queries like: "I've set up a new
>> djinn group for my new Apache River nodes, but my existing Jini nodes
>> can't discover the new group. The new nodes are using my existing
>> programs and they work among themselves, but the new Registrars aren't
>> working with my older nodes. The new nodes services work with my old
>> clients only if they register with existing Registrars. Reggie seems
>> broken in Apache River 2.2.0?"
>
> Why don't we just worry about creating a working River, and let the
> compatibility issues be solved by the market? Most deployments are
> done within the boundaries of a single organization. They should have
> done this incompatible upgrade multiple times, it not something that
> is unique to a river upgrade. Most bigger organizations will have
> their own software-library, and establish their own software baselines
> by cloning our vcs.
>
> Keep compatible: -1
>
> Gr. Sim
>
>
>
>
>
Re: Modular Build, Java 5, (Was: Re: Unexpected Test Results)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09/15/2010 01:56 AM, Peter Firmstone wrote:
> I don't want to have to answer user queries like: "I've set up a new
> djinn group for my new Apache River nodes, but my existing Jini nodes
> can't discover the new group. The new nodes are using my existing
> programs and they work among themselves, but the new Registrars aren't
> working with my older nodes. The new nodes services work with my old
> clients only if they register with existing Registrars. Reggie seems
> broken in Apache River 2.2.0?"
Why don't we just worry about creating a working River, and let the
compatibility issues be solved by the market? Most deployments are done
within the boundaries of a single organization. They should have done
this incompatible upgrade multiple times, it not something that is
unique to a river upgrade. Most bigger organizations will have their own
software-library, and establish their own software baselines by cloning
our vcs.
Keep compatible: -1
Gr. Sim
Re: Modular Build, Java 5, (Was: Re: Unexpected Test Results)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Patricia Shanahan wrote:
> On 9/14/2010 2:55 AM, Peter Firmstone wrote:
>> Tom Hobbs wrote:
>>> In my mind, it's an attractive proposition to drop support for the
>>> older
>>> JVMs and go straight into 1.5 - however I'm only one user and I
>>> wouldn't
>>> have a problem if River did that.
>>>
>>> I think this question should be asked on the River Users list as
>>> well. If
>>> there are active users out there who monitor River updates and the
>>> lists
>>> then getting their feedback might make our decision easier.
>>
>> That's a good point Tom, this project does need more focus on users.
>
> I think we should also ask users whether to do a smaller release soon
> or wait until we have more content. In the longer term, I am a
> believer in basing performance work on measurement. My current
> TaskManager scalability mission cries out for access to a real
> workload that exhibits scalability problems.
>
>> In this case it would be about offering the user less and asking if it's
>> ok.
>> The only thing that Java 1.5 offers in Proxy code and Service API are
>> some additional classes, not much good for API, but useful for some
>> smart proxy's needing concurrency perhaps. But this is already possible.
>> Once we take the users mind away from supporting Java 1.4 in Service
>> API, however, we have to explain the difficulties of using Generics in
>> Service API. For example you can use Specific generics List<Apple>, but
>> not bounded wildcards, like List<? extends Fruit>, or List<T>
>
> We will have to solve those problems anyway to go to 1.6, the current
> Java release. I am currently having to work around the lack of the 1.6
> features in java.util.TreeSet.
When making changes, it's important to understand the impacts of the
change before making the decision. We must consider the distributed
environmental impacts, not just the local jvm impacts.
I propose we go to Java 6 now and drop support for older jvm's as
proposed, but continue to compile platform smart proxy's and Service API
with target = 1.4
The kind of backward compatibility I'm talking about is, I have 200 nice
shiny new racks units, with Java 6, Apache River 2.2.0 and it's going to
play nicely with my other 400 Java 1.4 RU with Jini 2.1 and 600 Java 5
RU with Jini 2.1.
I'm not proposing we support new installations of Java 1.4 or 5 with
this release, just that we don't cause issues with existing
installations. Lets keep our users on the upgrade path, I'm not sure
we've convinced the big corporate users to migrate to Apache River from
Jini 2.1 yet, in fact Orbitz migrated away. Gigaspaces has a large user
pool, lets ask them? If users plug in Apache River 2.2.0 and
incompatibility issues arise, they're not going to replace their Jini
2.1 boxes, in which they've gained confidence, they're going to pull the
plug on Apache River.
The failure I experienced with the RemoteEvent and the Java CDC
experiment, was caused by trying to retain Serialized form compatibility
with previous releases, while changing object fields. If were going to
have islands of compatibility, it doesn't bode well for an internet
based River.
Adopting a mindset of Service compatibility by honoring existing
platform Service API still allows a great deal of flexibility and change.
We can change the back end implementation, we can change the proxy
implementation, if we migrate away from a monolithic build, we can have
multiple service implementations for multiple platforms.
At the absolute minimum, we should compile Reggie's Proxy and API with
target=1.4, the reason is, ServiceRegistrar and ServiceItem allow
services to fail to unmarshall, it's in their contract, in which case
incompatible Services are simply not used by older clients.
I don't want to have to answer user queries like: "I've set up a new
djinn group for my new Apache River nodes, but my existing Jini nodes
can't discover the new group. The new nodes are using my existing
programs and they work among themselves, but the new Registrars aren't
working with my older nodes. The new nodes services work with my old
clients only if they register with existing Registrars. Reggie seems
broken in Apache River 2.2.0?"
If MarshalledObject's serialized form remains the same, but the bytecode
becomes incompatible, you still discover the service, you just can't use it.
These are the classes in the Reggie proxy, I'll do a ClassDep run and
find the platform dependents:
$ tail -100 reggie-dl.deps
com/sun/jini/action/GetBooleanAction.class
com/sun/jini/logging/Levels.class
com/sun/jini/logging/Levels$ClassReplacingObjectOutputStream.class
com/sun/jini/logging/Levels$LevelData.class
com/sun/jini/logging/LogUtil.class
com/sun/jini/reggie/AdminProxy.class
com/sun/jini/reggie/ClassMapper.class
com/sun/jini/reggie/ClassMapper$EntryField.class
com/sun/jini/reggie/ClassMapper$FieldComparator.class
com/sun/jini/reggie/ConstrainableAdminProxy.class
com/sun/jini/reggie/ConstrainableEventLease.class
com/sun/jini/reggie/ConstrainableRegistrarLeaseMap.class
com/sun/jini/reggie/ConstrainableRegistrarProxy.class
com/sun/jini/reggie/ConstrainableRegistration.class
com/sun/jini/reggie/ConstrainableServiceLease.class
com/sun/jini/reggie/EntryClass.class
com/sun/jini/reggie/EntryClassBase.class
com/sun/jini/reggie/EntryRep.class
com/sun/jini/reggie/EventLease.class
com/sun/jini/reggie/Item.class
com/sun/jini/reggie/Matches.class
com/sun/jini/reggie/ProxyVerifier.class
com/sun/jini/reggie/Registrar.class
com/sun/jini/reggie/RegistrarEvent.class
com/sun/jini/reggie/RegistrarImpl_Stub.class
com/sun/jini/reggie/RegistrarLease.class
com/sun/jini/reggie/RegistrarLeaseMap.class
com/sun/jini/reggie/RegistrarPermission.class
com/sun/jini/reggie/RegistrarProxy.class
com/sun/jini/reggie/Registration.class
com/sun/jini/reggie/RenewResults.class
com/sun/jini/reggie/ServiceLease.class
com/sun/jini/reggie/ServiceType.class
com/sun/jini/reggie/ServiceTypeBase.class
com/sun/jini/reggie/Template.class
com/sun/jini/reggie/Util.class
Peter.
Re: Modular Build, Java 5, (Was: Re: Unexpected Test Results)
Posted by Patricia Shanahan <pa...@acm.org>.
On 9/14/2010 2:55 AM, Peter Firmstone wrote:
> Tom Hobbs wrote:
>> In my mind, it's an attractive proposition to drop support for the older
>> JVMs and go straight into 1.5 - however I'm only one user and I wouldn't
>> have a problem if River did that.
>>
>> I think this question should be asked on the River Users list as well. If
>> there are active users out there who monitor River updates and the lists
>> then getting their feedback might make our decision easier.
>
> That's a good point Tom, this project does need more focus on users.
I think we should also ask users whether to do a smaller release soon or
wait until we have more content. In the longer term, I am a believer in
basing performance work on measurement. My current TaskManager
scalability mission cries out for access to a real workload that
exhibits scalability problems.
> In this case it would be about offering the user less and asking if it's
> ok.
> The only thing that Java 1.5 offers in Proxy code and Service API are
> some additional classes, not much good for API, but useful for some
> smart proxy's needing concurrency perhaps. But this is already possible.
> Once we take the users mind away from supporting Java 1.4 in Service
> API, however, we have to explain the difficulties of using Generics in
> Service API. For example you can use Specific generics List<Apple>, but
> not bounded wildcards, like List<? extends Fruit>, or List<T>
We will have to solve those problems anyway to go to 1.6, the current
Java release. I am currently having to work around the lack of the 1.6
features in java.util.TreeSet.
Patricia
Re: Modular Build, Java 5, (Was: Re: Unexpected Test Results)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Tom Hobbs wrote:
> In my mind, it's an attractive proposition to drop support for the older
> JVMs and go straight into 1.5 - however I'm only one user and I wouldn't
> have a problem if River did that.
>
> I think this question should be asked on the River Users list as well. If
> there are active users out there who monitor River updates and the lists
> then getting their feedback might make our decision easier.
>
That's a good point Tom, this project does need more focus on users.
In this case it would be about offering the user less and asking if it's
ok.
The only thing that Java 1.5 offers in Proxy code and Service API are
some additional classes, not much good for API, but useful for some
smart proxy's needing concurrency perhaps. But this is already
possible. Once we take the users mind away from supporting Java 1.4 in
Service API, however, we have to explain the difficulties of using
Generics in Service API. For example you can use Specific generics
List<Apple>, but not bounded wildcards, like List<? extends Fruit>, or
List<T>
Personally I can't see any reason or benefit as to why client or
platform Service API should be compiled with anything later than jsr14.
Separately compiled code needs to have the same type casts at run time.
Generics suffer from erasure and are replaced by type casts.
It would of course nix any remaining hopes I had for a Java CDC release,
after my recent failure, I have been considering creating an RMI
optional package to support it (rather than removing the need for RMI,
distribute it instead) Oracle and IBM have long since stopped
distributing the RMI optional package. Investigations are that it may be
possible to load the optional package upon instantiation, similar to the
way the jsk-policy.jar is now loaded. CDC will become a larger Java
client platform than the PC due to BlueRay and Digital TV, these come
with network connections. The ServiceUI would be very suited to
interactive Television. Server Platforms need clients too.
Long term I think we should still be making the build modular,
regardless of any decision taken with java 1.4.
By taking the build modular, it makes life easier for a greater
developer pool, just like our new Merge model.
Peter.
> Also, it'd be good to start getting into the habit of consulting users when
> significant decisions like this are being discussed.
>
> Release early and often. This decision can be delayed to a later release,
> rather than delaying the next release to contain the results of this
> decision.
>
> On Tue, Sep 14, 2010 at 8:53 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>
>> Yes it's a little daunting isn't it. It would make development,
>> maintenance and compatibility easier once we bite the bullet.
>>
>> Any volunteers?
>>
>> I had planned to release before Christmas, perhaps it should be a
>> maintenance release of the last branch, until we get a modular build and
>> Java 1.4 to 5 migration sorted.
>>
>> Or do we let the release slip until March 2011 (1 year release) and aim for
>> a modular build, supporting Java 5, or do we do both?
>>
>> Peter.
>>
>>
>>
>> Patricia Shanahan wrote:
>>
>>
>>> What time frame are you thinking of for all this? I was a bit naive
>>> thinking we could easily switch to 5.
>>>
>>> In order to make TaskManager progress, I need to pick a runAfter parameter
>>> type. While things are in flux, I think I'll go with Collection<Task>, so I
>>> can work with the jsr14 hack.
>>>
>>> If we go to 5 for the thread package, I can do a refactoring pass to
>>> change to Iterable<Task>. There are a lot fewer runAfter declarations
>>> because of the switch to an abstract class with a default implementation.
>>>
>>> Patricia
>>>
>>>
>>> On 9/13/2010 6:26 PM, Peter Firmstone wrote:
>>>
>>>
>>>> Some time back, we voted to include Java 5 language features.
>>>>
>>>> We didn't vote to drop support for Java 1.4 at the time and I was
>>>> considering different options for ongoing maintenance support of Java
>>>> 1.4.
>>>>
>>>> The last release 2.1.2, still supports Java 1.4
>>>>
>>>> What I'd like to consider is that the previous branch be used to
>>>> maintain support for Java 1.4 and our next release only support Java 1.5
>>>> onward. However an additional requirement of a distributed platform
>>>> release, is that it plays nicely with existing Java 1.4 installations,
>>>> which means smart proxy's still need to be compiled in Java 1.4 bytecode
>>>> (and perhaps Service API). Service API will be already installed in the
>>>> clients local classpath for Java 1.4 installations, but the smart proxy
>>>> code depends on Service API and won't compile if they're Java 1.5.
>>>>
>>>> So while Serialization compatibility is maintained across releases, we
>>>> just need to have compatible bytecode.
>>>>
>>>> Perhaps with maven provisioning there could be an opportunity for
>>>> clients to select platform compatible bytecode at some time in the
>>>> future.
>>>>
>>>> I guess we need to figure out how to compile the majority of classes
>>>> using "1.5", while compiling proxy classes using "1.4".
>>>>
>>>> It is possible I think, to specify different class paths in the client
>>>> jvm's of the test suite, so potentially we could test the current
>>>> distribution with clients using the previous release and Java 1.4, while
>>>> the server uses Java 5 or 6.
>>>>
>>>> This might require a separate release of the Test Suite, this would be
>>>> useful to test binary compatibility also, very important in a
>>>> distributed environment.
>>>>
>>>> This allows a migration path away from Java 1.4.
>>>>
>>>> "jsr14" is a build hack.
>>>>
>>>> To achieve this, I think we'll need to change the way we currently
>>>> package River, to be more modular along the lines Dan Rollo has
>>>> suggested.
>>>>
>>>> This might also be an opportunity to break out the Service
>>>> Implementations into separate components or subprojects perhaps, each
>>>> depending on the platform and test kit and each having it's own tests.
>>>> Allowing one to develop on a small component of the platform and run
>>>> only relevant tests, for faster feedback. All components might be
>>>> assembled and run on Hudson.
>>>>
>>>> Possible Components:
>>>>
>>>> Service API. (Java 1.4)
>>>> Jini Platform (depends on Service API) (Java 5)
>>>> Jini libraries. (Java 5)
>>>> Jini Security Policy.
>>>> Test Kit
>>>> Jini Compatibility Tests.
>>>> Reggie
>>>> Mahalo
>>>> Outrigger
>>>> Phoenix
>>>> Fiddler
>>>> Norm
>>>> Mercury
>>>>
>>>> A client developer then only needs the Platform and Service API jar's.
>>>>
>>>> Then when someone creates their own djinn, they can add the services as
>>>> they require them, reducing complexity for new developers.
>>>>
>>>> Regards,
>>>>
>>>> Peter.
>>>>
>>>>
>>>> Patricia Shanahan wrote:
>>>>
>>>>
>>>>> Found it. common.xml contains a macro definition, javac-cmd, which I
>>>>> believe does the actual compilation. It defaults the -target parameter
>>>>> to "jsr14". Changing it to "1.5" allows my Iterable construct to
>>>>> compile, but should continue generation of java 1.5 compatible code.
>>>>>
>>>>> "jsr14" was an interim mode for experimentation with the 1.5 features
>>>>> on a 1.4 JVM. It does support for-each for a Collection, but not
>>>>> Iterable, which was added in 1.5, which explains my problem.
>>>>>
>>>>> Any class files that work on 1.4 should also work on 1.5, explaining
>>>>> Peter's observation.
>>>>>
>>>>> Should River continue 1.4 support? If yes, we need to test on 1.4, as
>>>>> well as 5, 6, and potentially 7. Note that there may be a performance
>>>>> price, such as less efficient autoboxing code. If no, we should change
>>>>> the target default to "1.5".
>>>>>
>>>>> Patricia
>>>>>
>>>>>
>>>>> On 9/13/2010 3:38 PM, Patricia Shanahan wrote:
>>>>> ....
>>>>>
>>>>>
>>>>>> Here's a theory. There is some parameter (or parameters) we don't know
>>>>>> about being passed to javac as part of the ant all.build that affects
>>>>>> the compiler's personality. It is generating 1.5 compatible code, and
>>>>>> rejecting a construct that I think should be accepted.
>>>>>>
>>>>>>
>>>>> ...
>>>>>
>>>>>
>>>>>> On 9/13/2010 1:16 PM, Peter Firmstone wrote:
>>>>>>
>>>>>>
>>>>>>> [java] -----------------------------------------
>>>>>>> [java]
>>>>>>> [java] # of tests started = 581
>>>>>>> [java] # of tests completed = 581
>>>>>>> [java] # of tests skipped = 21
>>>>>>> [java] # of tests passed = 581
>>>>>>> [java] # of tests failed = 0
>>>>>>> [java]
>>>>>>> [java] -----------------------------------------
>>>>>>> [java]
>>>>>>> [java] Date finished:
>>>>>>> [java] Tue Sep 14 01:08:05 EST 2010
>>>>>>> [java] Time elapsed:
>>>>>>> [java] 19953 seconds
>>>>>>> [java]
>>>>>>>
>>>>>>> BUILD SUCCESSFUL
>>>>>>> Total time: 332 minutes 40 seconds
>>>>>>>
>>>>>>> These test results are from qa.run executing on Java 5, so I was
>>>>>>> expecting some test failures, knowing that the test suite doesn't
>>>>>>> compile with JDK 1.5.
>>>>>>>
>>>>>>>
>>>>
>>>
>
>
Re: Modular Build, Java 5, (Was: Re: Unexpected Test Results)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 14-09-10 10:50, Tom Hobbs wrote:
> In my mind, it's an attractive proposition to drop support for the older
> JVMs and go straight into 1.5 - however I'm only one user and I wouldn't
> have a problem if River did that.
+1
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Modular Build, Java 5, (Was: Re: Unexpected Test Results)
Posted by Tom Hobbs <tv...@googlemail.com>.
In my mind, it's an attractive proposition to drop support for the older
JVMs and go straight into 1.5 - however I'm only one user and I wouldn't
have a problem if River did that.
I think this question should be asked on the River Users list as well. If
there are active users out there who monitor River updates and the lists
then getting their feedback might make our decision easier.
Also, it'd be good to start getting into the habit of consulting users when
significant decisions like this are being discussed.
Release early and often. This decision can be delayed to a later release,
rather than delaying the next release to contain the results of this
decision.
On Tue, Sep 14, 2010 at 8:53 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> Yes it's a little daunting isn't it. It would make development,
> maintenance and compatibility easier once we bite the bullet.
>
> Any volunteers?
>
> I had planned to release before Christmas, perhaps it should be a
> maintenance release of the last branch, until we get a modular build and
> Java 1.4 to 5 migration sorted.
>
> Or do we let the release slip until March 2011 (1 year release) and aim for
> a modular build, supporting Java 5, or do we do both?
>
> Peter.
>
>
>
> Patricia Shanahan wrote:
>
>> What time frame are you thinking of for all this? I was a bit naive
>> thinking we could easily switch to 5.
>>
>> In order to make TaskManager progress, I need to pick a runAfter parameter
>> type. While things are in flux, I think I'll go with Collection<Task>, so I
>> can work with the jsr14 hack.
>>
>> If we go to 5 for the thread package, I can do a refactoring pass to
>> change to Iterable<Task>. There are a lot fewer runAfter declarations
>> because of the switch to an abstract class with a default implementation.
>>
>> Patricia
>>
>>
>> On 9/13/2010 6:26 PM, Peter Firmstone wrote:
>>
>>> Some time back, we voted to include Java 5 language features.
>>>
>>> We didn't vote to drop support for Java 1.4 at the time and I was
>>> considering different options for ongoing maintenance support of Java
>>> 1.4.
>>>
>>> The last release 2.1.2, still supports Java 1.4
>>>
>>> What I'd like to consider is that the previous branch be used to
>>> maintain support for Java 1.4 and our next release only support Java 1.5
>>> onward. However an additional requirement of a distributed platform
>>> release, is that it plays nicely with existing Java 1.4 installations,
>>> which means smart proxy's still need to be compiled in Java 1.4 bytecode
>>> (and perhaps Service API). Service API will be already installed in the
>>> clients local classpath for Java 1.4 installations, but the smart proxy
>>> code depends on Service API and won't compile if they're Java 1.5.
>>>
>>> So while Serialization compatibility is maintained across releases, we
>>> just need to have compatible bytecode.
>>>
>>> Perhaps with maven provisioning there could be an opportunity for
>>> clients to select platform compatible bytecode at some time in the
>>> future.
>>>
>>> I guess we need to figure out how to compile the majority of classes
>>> using "1.5", while compiling proxy classes using "1.4".
>>>
>>> It is possible I think, to specify different class paths in the client
>>> jvm's of the test suite, so potentially we could test the current
>>> distribution with clients using the previous release and Java 1.4, while
>>> the server uses Java 5 or 6.
>>>
>>> This might require a separate release of the Test Suite, this would be
>>> useful to test binary compatibility also, very important in a
>>> distributed environment.
>>>
>>> This allows a migration path away from Java 1.4.
>>>
>>> "jsr14" is a build hack.
>>>
>>> To achieve this, I think we'll need to change the way we currently
>>> package River, to be more modular along the lines Dan Rollo has
>>> suggested.
>>>
>>> This might also be an opportunity to break out the Service
>>> Implementations into separate components or subprojects perhaps, each
>>> depending on the platform and test kit and each having it's own tests.
>>> Allowing one to develop on a small component of the platform and run
>>> only relevant tests, for faster feedback. All components might be
>>> assembled and run on Hudson.
>>>
>>> Possible Components:
>>>
>>> Service API. (Java 1.4)
>>> Jini Platform (depends on Service API) (Java 5)
>>> Jini libraries. (Java 5)
>>> Jini Security Policy.
>>> Test Kit
>>> Jini Compatibility Tests.
>>> Reggie
>>> Mahalo
>>> Outrigger
>>> Phoenix
>>> Fiddler
>>> Norm
>>> Mercury
>>>
>>> A client developer then only needs the Platform and Service API jar's.
>>>
>>> Then when someone creates their own djinn, they can add the services as
>>> they require them, reducing complexity for new developers.
>>>
>>> Regards,
>>>
>>> Peter.
>>>
>>>
>>> Patricia Shanahan wrote:
>>>
>>>> Found it. common.xml contains a macro definition, javac-cmd, which I
>>>> believe does the actual compilation. It defaults the -target parameter
>>>> to "jsr14". Changing it to "1.5" allows my Iterable construct to
>>>> compile, but should continue generation of java 1.5 compatible code.
>>>>
>>>> "jsr14" was an interim mode for experimentation with the 1.5 features
>>>> on a 1.4 JVM. It does support for-each for a Collection, but not
>>>> Iterable, which was added in 1.5, which explains my problem.
>>>>
>>>> Any class files that work on 1.4 should also work on 1.5, explaining
>>>> Peter's observation.
>>>>
>>>> Should River continue 1.4 support? If yes, we need to test on 1.4, as
>>>> well as 5, 6, and potentially 7. Note that there may be a performance
>>>> price, such as less efficient autoboxing code. If no, we should change
>>>> the target default to "1.5".
>>>>
>>>> Patricia
>>>>
>>>>
>>>> On 9/13/2010 3:38 PM, Patricia Shanahan wrote:
>>>> ....
>>>>
>>>>> Here's a theory. There is some parameter (or parameters) we don't know
>>>>> about being passed to javac as part of the ant all.build that affects
>>>>> the compiler's personality. It is generating 1.5 compatible code, and
>>>>> rejecting a construct that I think should be accepted.
>>>>>
>>>> ...
>>>>
>>>>> On 9/13/2010 1:16 PM, Peter Firmstone wrote:
>>>>>
>>>>>> [java] -----------------------------------------
>>>>>> [java]
>>>>>> [java] # of tests started = 581
>>>>>> [java] # of tests completed = 581
>>>>>> [java] # of tests skipped = 21
>>>>>> [java] # of tests passed = 581
>>>>>> [java] # of tests failed = 0
>>>>>> [java]
>>>>>> [java] -----------------------------------------
>>>>>> [java]
>>>>>> [java] Date finished:
>>>>>> [java] Tue Sep 14 01:08:05 EST 2010
>>>>>> [java] Time elapsed:
>>>>>> [java] 19953 seconds
>>>>>> [java]
>>>>>>
>>>>>> BUILD SUCCESSFUL
>>>>>> Total time: 332 minutes 40 seconds
>>>>>>
>>>>>> These test results are from qa.run executing on Java 5, so I was
>>>>>> expecting some test failures, knowing that the test suite doesn't
>>>>>> compile with JDK 1.5.
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
Re: Modular Build, Java 5, (Was: Re: Unexpected Test Results)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Yes it's a little daunting isn't it. It would make development,
maintenance and compatibility easier once we bite the bullet.
Any volunteers?
I had planned to release before Christmas, perhaps it should be a
maintenance release of the last branch, until we get a modular build and
Java 1.4 to 5 migration sorted.
Or do we let the release slip until March 2011 (1 year release) and aim
for a modular build, supporting Java 5, or do we do both?
Peter.
Patricia Shanahan wrote:
> What time frame are you thinking of for all this? I was a bit naive
> thinking we could easily switch to 5.
>
> In order to make TaskManager progress, I need to pick a runAfter
> parameter type. While things are in flux, I think I'll go with
> Collection<Task>, so I can work with the jsr14 hack.
>
> If we go to 5 for the thread package, I can do a refactoring pass to
> change to Iterable<Task>. There are a lot fewer runAfter declarations
> because of the switch to an abstract class with a default implementation.
>
> Patricia
>
>
> On 9/13/2010 6:26 PM, Peter Firmstone wrote:
>> Some time back, we voted to include Java 5 language features.
>>
>> We didn't vote to drop support for Java 1.4 at the time and I was
>> considering different options for ongoing maintenance support of Java
>> 1.4.
>>
>> The last release 2.1.2, still supports Java 1.4
>>
>> What I'd like to consider is that the previous branch be used to
>> maintain support for Java 1.4 and our next release only support Java 1.5
>> onward. However an additional requirement of a distributed platform
>> release, is that it plays nicely with existing Java 1.4 installations,
>> which means smart proxy's still need to be compiled in Java 1.4 bytecode
>> (and perhaps Service API). Service API will be already installed in the
>> clients local classpath for Java 1.4 installations, but the smart proxy
>> code depends on Service API and won't compile if they're Java 1.5.
>>
>> So while Serialization compatibility is maintained across releases, we
>> just need to have compatible bytecode.
>>
>> Perhaps with maven provisioning there could be an opportunity for
>> clients to select platform compatible bytecode at some time in the
>> future.
>>
>> I guess we need to figure out how to compile the majority of classes
>> using "1.5", while compiling proxy classes using "1.4".
>>
>> It is possible I think, to specify different class paths in the client
>> jvm's of the test suite, so potentially we could test the current
>> distribution with clients using the previous release and Java 1.4, while
>> the server uses Java 5 or 6.
>>
>> This might require a separate release of the Test Suite, this would be
>> useful to test binary compatibility also, very important in a
>> distributed environment.
>>
>> This allows a migration path away from Java 1.4.
>>
>> "jsr14" is a build hack.
>>
>> To achieve this, I think we'll need to change the way we currently
>> package River, to be more modular along the lines Dan Rollo has
>> suggested.
>>
>> This might also be an opportunity to break out the Service
>> Implementations into separate components or subprojects perhaps, each
>> depending on the platform and test kit and each having it's own tests.
>> Allowing one to develop on a small component of the platform and run
>> only relevant tests, for faster feedback. All components might be
>> assembled and run on Hudson.
>>
>> Possible Components:
>>
>> Service API. (Java 1.4)
>> Jini Platform (depends on Service API) (Java 5)
>> Jini libraries. (Java 5)
>> Jini Security Policy.
>> Test Kit
>> Jini Compatibility Tests.
>> Reggie
>> Mahalo
>> Outrigger
>> Phoenix
>> Fiddler
>> Norm
>> Mercury
>>
>> A client developer then only needs the Platform and Service API jar's.
>>
>> Then when someone creates their own djinn, they can add the services as
>> they require them, reducing complexity for new developers.
>>
>> Regards,
>>
>> Peter.
>>
>>
>> Patricia Shanahan wrote:
>>> Found it. common.xml contains a macro definition, javac-cmd, which I
>>> believe does the actual compilation. It defaults the -target parameter
>>> to "jsr14". Changing it to "1.5" allows my Iterable construct to
>>> compile, but should continue generation of java 1.5 compatible code.
>>>
>>> "jsr14" was an interim mode for experimentation with the 1.5 features
>>> on a 1.4 JVM. It does support for-each for a Collection, but not
>>> Iterable, which was added in 1.5, which explains my problem.
>>>
>>> Any class files that work on 1.4 should also work on 1.5, explaining
>>> Peter's observation.
>>>
>>> Should River continue 1.4 support? If yes, we need to test on 1.4, as
>>> well as 5, 6, and potentially 7. Note that there may be a performance
>>> price, such as less efficient autoboxing code. If no, we should change
>>> the target default to "1.5".
>>>
>>> Patricia
>>>
>>>
>>> On 9/13/2010 3:38 PM, Patricia Shanahan wrote:
>>> ....
>>>> Here's a theory. There is some parameter (or parameters) we don't know
>>>> about being passed to javac as part of the ant all.build that affects
>>>> the compiler's personality. It is generating 1.5 compatible code, and
>>>> rejecting a construct that I think should be accepted.
>>> ...
>>>> On 9/13/2010 1:16 PM, Peter Firmstone wrote:
>>>>> [java] -----------------------------------------
>>>>> [java]
>>>>> [java] # of tests started = 581
>>>>> [java] # of tests completed = 581
>>>>> [java] # of tests skipped = 21
>>>>> [java] # of tests passed = 581
>>>>> [java] # of tests failed = 0
>>>>> [java]
>>>>> [java] -----------------------------------------
>>>>> [java]
>>>>> [java] Date finished:
>>>>> [java] Tue Sep 14 01:08:05 EST 2010
>>>>> [java] Time elapsed:
>>>>> [java] 19953 seconds
>>>>> [java]
>>>>>
>>>>> BUILD SUCCESSFUL
>>>>> Total time: 332 minutes 40 seconds
>>>>>
>>>>> These test results are from qa.run executing on Java 5, so I was
>>>>> expecting some test failures, knowing that the test suite doesn't
>>>>> compile with JDK 1.5.
>>>
>>
>>
>
>
Re: Modular Build, Java 5, (Was: Re: Unexpected Test Results)
Posted by Patricia Shanahan <pa...@acm.org>.
What time frame are you thinking of for all this? I was a bit naive
thinking we could easily switch to 5.
In order to make TaskManager progress, I need to pick a runAfter
parameter type. While things are in flux, I think I'll go with
Collection<Task>, so I can work with the jsr14 hack.
If we go to 5 for the thread package, I can do a refactoring pass to
change to Iterable<Task>. There are a lot fewer runAfter declarations
because of the switch to an abstract class with a default implementation.
Patricia
On 9/13/2010 6:26 PM, Peter Firmstone wrote:
> Some time back, we voted to include Java 5 language features.
>
> We didn't vote to drop support for Java 1.4 at the time and I was
> considering different options for ongoing maintenance support of Java 1.4.
>
> The last release 2.1.2, still supports Java 1.4
>
> What I'd like to consider is that the previous branch be used to
> maintain support for Java 1.4 and our next release only support Java 1.5
> onward. However an additional requirement of a distributed platform
> release, is that it plays nicely with existing Java 1.4 installations,
> which means smart proxy's still need to be compiled in Java 1.4 bytecode
> (and perhaps Service API). Service API will be already installed in the
> clients local classpath for Java 1.4 installations, but the smart proxy
> code depends on Service API and won't compile if they're Java 1.5.
>
> So while Serialization compatibility is maintained across releases, we
> just need to have compatible bytecode.
>
> Perhaps with maven provisioning there could be an opportunity for
> clients to select platform compatible bytecode at some time in the future.
>
> I guess we need to figure out how to compile the majority of classes
> using "1.5", while compiling proxy classes using "1.4".
>
> It is possible I think, to specify different class paths in the client
> jvm's of the test suite, so potentially we could test the current
> distribution with clients using the previous release and Java 1.4, while
> the server uses Java 5 or 6.
>
> This might require a separate release of the Test Suite, this would be
> useful to test binary compatibility also, very important in a
> distributed environment.
>
> This allows a migration path away from Java 1.4.
>
> "jsr14" is a build hack.
>
> To achieve this, I think we'll need to change the way we currently
> package River, to be more modular along the lines Dan Rollo has suggested.
>
> This might also be an opportunity to break out the Service
> Implementations into separate components or subprojects perhaps, each
> depending on the platform and test kit and each having it's own tests.
> Allowing one to develop on a small component of the platform and run
> only relevant tests, for faster feedback. All components might be
> assembled and run on Hudson.
>
> Possible Components:
>
> Service API. (Java 1.4)
> Jini Platform (depends on Service API) (Java 5)
> Jini libraries. (Java 5)
> Jini Security Policy.
> Test Kit
> Jini Compatibility Tests.
> Reggie
> Mahalo
> Outrigger
> Phoenix
> Fiddler
> Norm
> Mercury
>
> A client developer then only needs the Platform and Service API jar's.
>
> Then when someone creates their own djinn, they can add the services as
> they require them, reducing complexity for new developers.
>
> Regards,
>
> Peter.
>
>
> Patricia Shanahan wrote:
>> Found it. common.xml contains a macro definition, javac-cmd, which I
>> believe does the actual compilation. It defaults the -target parameter
>> to "jsr14". Changing it to "1.5" allows my Iterable construct to
>> compile, but should continue generation of java 1.5 compatible code.
>>
>> "jsr14" was an interim mode for experimentation with the 1.5 features
>> on a 1.4 JVM. It does support for-each for a Collection, but not
>> Iterable, which was added in 1.5, which explains my problem.
>>
>> Any class files that work on 1.4 should also work on 1.5, explaining
>> Peter's observation.
>>
>> Should River continue 1.4 support? If yes, we need to test on 1.4, as
>> well as 5, 6, and potentially 7. Note that there may be a performance
>> price, such as less efficient autoboxing code. If no, we should change
>> the target default to "1.5".
>>
>> Patricia
>>
>>
>> On 9/13/2010 3:38 PM, Patricia Shanahan wrote:
>> ....
>>> Here's a theory. There is some parameter (or parameters) we don't know
>>> about being passed to javac as part of the ant all.build that affects
>>> the compiler's personality. It is generating 1.5 compatible code, and
>>> rejecting a construct that I think should be accepted.
>> ...
>>> On 9/13/2010 1:16 PM, Peter Firmstone wrote:
>>>> [java] -----------------------------------------
>>>> [java]
>>>> [java] # of tests started = 581
>>>> [java] # of tests completed = 581
>>>> [java] # of tests skipped = 21
>>>> [java] # of tests passed = 581
>>>> [java] # of tests failed = 0
>>>> [java]
>>>> [java] -----------------------------------------
>>>> [java]
>>>> [java] Date finished:
>>>> [java] Tue Sep 14 01:08:05 EST 2010
>>>> [java] Time elapsed:
>>>> [java] 19953 seconds
>>>> [java]
>>>>
>>>> BUILD SUCCESSFUL
>>>> Total time: 332 minutes 40 seconds
>>>>
>>>> These test results are from qa.run executing on Java 5, so I was
>>>> expecting some test failures, knowing that the test suite doesn't
>>>> compile with JDK 1.5.
>>
>
>