river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Easton-Marks <coachjeremyeastonma...@gmail.com>
Subject Re: Migration to Java 5 - Summary
Date Fri, 03 Apr 2009 12:06:09 GMT
When are we proposing to make these changes? This release? A future point
release? Or River 3.X?

I think we should continue to work in 1.4 for this release unless anyone
sees any immediate need for it. I am personally going to have difficulty
selling the idea to my boss to use River if progress towards a full release
out of hibernation is not done.

Since upgrading to 1.5 or 1.6 can significantly change out code base I think
it would be best to wait for the next major release. At that point we can
use a minimum of 1.5 and possible 1.6.

On a completely different point. What are we doing about documentation,
examples, and other things of that nature?

Jeremy R. Easton-Marks

"ĂȘtre fort pour ĂȘtre utile"


On Fri, Apr 3, 2009 at 6:47 AM, Peter Firmstone <jini@zeus.net.au> wrote:

> Just thought I'd go back over the messages and post a summary:
>
> Those in favour of using Java 6 features:
>
> Jeremy Easton-Marks
> Greg Wonderly
> James Grahn
>
> Those in favour of using Java 5 features:
>
> Dennis Reedy
> Jim Waldo
> Jonathan Costers
> Greg Trasuk
> Niclas Hedhman
> Dan Rollo
> Greg Wonderly
> Jukka Zitting
> Sean Landis
> Peter Firmstone
> James Grahn
>
>
> Those who would like to see continued support for  JRE 1.4 (bytecode only,
> using Retrotranslator):
>
> Patrick Wright
> Greg Trasuk
> Wade Chandler
> Peter Firmstone
>
>
> I propose posting the following items on Jira:
>
> 1. Migration to Java 5 Language Features and API
> 2. Use of Generics in JavaSpace API, as suggested by James Grahn.
> 3. Implementation of Retrotranslator for JRE 1.4 Runtime support.
>
> Best Regards,
>
> Peter Firmstone.
>
> Gregg Wonderly wrote:
>
>> James Grahn wrote:
>>
>>> Actually, Gregg, what I had in mind was this:
>>>
>>> public <T extends Entry> T read(T template, Transaction txn, long
>>> timeout)
>>>
>>
>> I always forget about that very handy way to restrict parameters and
>> return values to the same type.  That will be a useful way to help manage
>> that the types are in the right hierarchy.
>>
>> Gregg Wonderly
>>
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message