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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
