I agree on the latter point - that JSE5 is in some ways a complete shift
in Java paradigm. Whatever solution is chosen going forward, +1 for a
cross-Commons approach... otherwise figuring out compatibility between
Commons JARs will become even tougher.
I dislike the idea of putting version numbers into package names, but I
don't see a realistic alternative giving the fact that Java's handling
of JAR manifest versioning isn't as rigorous as we might like for this
sort of problem.
org.apache.commons.collection5.CollectionUtils is all well and good, but
what happens when we migrate to Mustang? Do we go with
org.apache.commons.lang6?
--
Stephen Smith, MEng (Wales).
http://www.stephen-smith.co.uk/
Stephen Colebourne wrote:
From: Kris Nuttycombe <[EMAIL PROTECTED]>
James Carman wrote:
I don't like forking all of commons together. To say
commons5-collections-1.0 doesn't work for me. Then, we have to get
all of
the commons projects to decide on "fork points." Am I understanding (c)
correctly?
I don't think there has to be commons-wide fork at all. I just see the
name change at the commons level rather than the package level being an
approach that can be useful to other packages, so that the other
projects that will inevitably make the switch can do so in a uniform
manner.
In the end, I'm most interested that whatever method is adopted be a
solution that can work for all of the commons projects that may want to
generify. BeanUtils could certainly be improved with generics, as could
Lang and others. In my shop, at least, we've been using JDK5 for over a
year now and the lack of progress towards creating generic versions of
the Commons components bespeaks a bit of stagnation. I've got the itch
for generics across the board; I'd like to be able to scratch it.
Yes. I regret using the word 'fork' now, as it has negative connotations. And I
agree that quite a few projects need generifications (or rather
Java5-ification). Now I'm on JDK5 at work (and its been a massive pain
upgrading) I'd like commons to support JDK5.
Consider [lang] - a good proportion of [lang] is providing ways to support JDK5
features on earlier JDKs. We might not choose to support them once we have a
JDK5 version. The same applies to [collections].
The commons5 name is quite a nice way to express all this. Is it really much
different to how Tomcat manages J2EE versions? And I definitely do not think it
involves forking the whole of commons!!! Not sure where that idea comes from,
but 'commons5' is just a naming conventinon (and package name) for those
projects which want a JDK5+ specific version.
We need to remember why JDK5 is so important - its because its almost a whole
new language. Its not a small incremental step like prior upgrades. We should
treat it as such. (Especially as lots of big enterprises are perfectly happy on
JDK1.4 and aren't planning to upgrade)
Stephen
---------------------------------------------------------------------
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]
