commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Date Sun, 10 Sep 2006 21:31:04 GMT
You'd integrate it into your builds. However, this doesn't help with  
missing APIs (though I believe retrotranslator does take care of some  
of these). It's a pretty good solution for providing JDK 5 binaries  
for JDK 1.4.

However, I don't think this addresses the issue being faced - and it  
isn't entirely a JDK 5 related one, but something that is faced  
whenever a component might want an extreme makeover.

IMO, this is the best pattern to follow:
- keep the maintenance branches going for the previous release, and  
bump trunk to the next major version
- if new functionality can be isolated to a new package or a separate  
module, do that (eg, some libraries like xwork have an xwork-tiger  
module for jdk5 related code)
- if the update can remain api compatible, then there is no need to  
change package names (eg, the JDK added generics to a lot of the  
runtime without making incompatible changes to the public interfaces)
- if the update must change the api, consider changing the package  
name (but only do so if there is a need to use both versions of the  
jar in a single classloader, for example lucene was able to safely  
overhaul their api for 2.0 because it would be unlikely both would be  
in the same classloader)

Obviously, the final one is a last resort and should be avoided -  
especially since that case would be quite prevalent for commons. If  
it really really really was needed for some reason, I'd call it  
o.a.c.net2 (or hopefully something better) rather than net5,  
reflecting the API not the JDK it is designed for because that'll  
quickly be outdated as JDK 6 comes out.

I think these are all general principles to apply to API evolution,  
not just for JDK 5 related changes. Didn't collections go through  
this (backwards-incompatible API change, not a JDK5-ification) Îin  
the past for 3.0? Any experiences that can be learned from there?

HTH,
Brett

On 11/09/2006, at 7:16 AM, Henri Yandell wrote:

> How does that work exactly? Can we happily write 1.5 stuff and then
> let the user take the 1.5 jar and retroweave it before using it, or do
> we have to integrate retroweaver into our builds (though not our
> sources I hope?)?
>
> Hen
>
> On 9/10/06, Jochen Wiedmann <jochen.wiedmann@gmail.com> wrote:
>> May I point out, that tools like retroweaver or retrotranslator  
>> can be
>> used to write code with most 1.5 features while still compiling for
>> 1.4? I don't know whether this applies to the commons-net project,  
>> but
>> for most projects I know, this should still be fine.
>>
>>
>> Jochen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message