Bryce, I've been in a similar position for the past year or so. It's
only now that my employer is properly moving into JSE5. I believe we've
previously agreed that backwards compatibility with JSE4 is not a major
aim of genericising Commons Collections, hence why we're on an entirely
different Subversion branch.
IMHO what we need to do now is agree upon an agenda for the
Collections-Java5 SVN branch based on this thread's discussion, and vote
upon it.
01. Removing all deprecated classes and methods. (I'm +1)
02. Removing (*not* deprecating) methods specifically related to type
safety pre-JSE5, e.g. MapUtils#getDouble. (+1)
03. Renaming usage of the Singleton design pattern to help usage of
static imports, e.g. TruePredicate#getInstance. (-1)
04. Porting generics into the Commons Collections codebase. (-1)
With regards to my -1: rather than rename getInstance methods, I would
prefer to remove them and solely rely upon utility methods such as
PredicateUtils#truePredicate.
At what point do we think we'll have a consensus?
Steve.
---
Stephen Smith, MEng (Wales).
http://www.stephen-smith.co.uk/
Bryce L Nordgren wrote:
Stephen Kestle <[EMAIL PROTECTED]> wrote on 03/12/2007
09:15:11 PM:
Bryce L Nordgren wrote:
Are you going to still produce binary releases which are compatible
with
1.4, even though they won't be able to compile the new source releases?
Or
are you going to use some sort of code stripper thingy which gets rid
of
generics for backwards source compatibility?
No, not as far as the conversation is going.
Bear in mind that SDKs <=1.4
inspired this library due to perceived shortcomings in the reference
implementations of the collection framework interfaces. It seems
counterintuitive to make SDKs >= 1.5 the only platform on which this
can
compile. But as long as the binaries stay backwards-compatible, that's
OK.
Why bother? The current collections serve very well for <=1.4. The
major pain is coming from 1.5 users having to suppress warnings all over
the place if they want to use commons-collections.
I understand that the binary break will limit the backwards
compatibility, but if you're needing to develop for 1.4 and 1.5, use 1.4
libs. As far as I see, most people leap to Java 5 rather than tip
toeing.
First, let me understand the proposal. Is a 1.4 compatible version of
commons-collections going to continue to be supported simultaneously with
the 1.5+ "reboot"? Your answer above indicates "no".
If the answer is in fact "no", you answered your own question ("Why
bother?") with "if you're needing to develop for 1.4 and 1.5, use 1.4
libs." You raised a very good reason to bother. However, if the answer is
"yes", I can go away happy and stop bothering everyone with large codebase
maintenance issues.
My perspective may not be common. The GeoTools project has been under
development for years. It is modular and has many many separate
developers, some of whom have moved onto greener pastures. The "official"
policy is that we develop for Java 5 now. Yet there is a sizable code base
developed during the time of 1.4. Although we have our Java 5 advocates,
there is no one with the budget of time or money to pull the entire code
base forward simultaneously. So if it happens at all, it must happen by
means of "tip toeing". Veteran, well-tested code may eventually be phased
out, but realistically we're talking years. We may see Java 1.8 before the
last of 1.4 is phased out. We just don't have the developer power to
factor in the latest compiler toys every two years (and deal with the new
bugs introduced by the process), no matter how shiny the new toys are.
Ergo, we need access to quality 1.4 libraries for the foreseeable future.
Bryce
---------------------------------------------------------------------
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]
