I'd like to broaden the original [net] thread and ask how is commons
going to handle JDK1.5? Or in the case of [net], is a JDK1.4 branch
worthwhile?
So far, commons has stuck with JDK 1.2/1.3 pretty much across the board.
This is because
a) JDK1.4 doesn't give that many benefits over 1.3
b) a lot of people use 1.3 still (Websphere etc)
c) limited developer resource to manage multiple branches
So, my proposal is that [net], and other commons projects jump from a
1.2/1.3 base now, to a 1.5 base for the future. I believe that we are
now starting to see 1.5 move forwards, perhaps towards the tipping point
of much wider adoption. JDK1.5 can change radically the API design
through generic and enums and this gives the opportunity for new
development and new life to some of these projects. (New development
often attracts new committers)
I can't comment on the specifics of the [net] case, but I'd like commons
as a whole to think seriously about how to handle the JDK1.5 issue.
(As you may guess, my opinion is to skip 1.4 and go for 1.5 branches.)
Stephen
Rory Winston wrote:
Daniel
Thanks for the comments. A few thoughts:
* I didnt realise until you mentioned it that MatchResult was a JDK 1.5+
feature. It seems a bit short-sighted of the Sun engineers concerned not
to have included it in 1.4, especially as the rest of java.util.regex
seems to mimic ORO/Jakarta Regexp uncannily in most regards. I guess one
approach would be to build a custom MatchResult interface, but this
would also have to handle the JDK 1.5 scenario.
* You're correct that there is no inherent advantage, at least
functionality-wise, in removing the ORO dependency. I think the major
boost is that it makes [net] free of all other dependencies - i.e. it
becomes just a single jar download. A lot of new users seem to get
bitten by the ClassNotFoundException they get if ORO is not in the
CLASSPATH.
* The FTPClient/TelnetClient area: actually, I may have misremembered a
comment you made some time back, in which I think you may have expressed
a desire to break the dependeny here. I think at least what we should
look at is making any incremental changes to the threading code that may
be required.
* I dont know how much has been added since 1.4.1 to merit a 1.4.2
release - maybe we should just go for a 1.5.0 (with FTPS)?
Thanks
Rory
Daniel F. Savarese wrote:
In message <[EMAIL PROTECTED]>, Rory Winston writes:
I think that this might be a good point to consider introducing a
version of Commons-Net that uses JDK 1.4+ as a baseline. My reasoning
is
I've long advocated branching to take advantage of JDK 1.4, but I
had a more radical agenda. I believe the underpinnings of Commons Net
need to be redesigned without being afraid to break compatibility.
My suggestion was for this new Commons Net 2.0 to be in a new package:
org.apache.commons.net2. At the time, the incremental evolution path
was preferred.
* We could remove the (oro) jar dependency;
I think that's a side-effect of moving to JDK 1.4, not a reason in and
of itself for JDK 1.4. There are no benefits to java.util.regex over
oro in the context used by Commons Net.
* It could be a good opportunity to "clean up" the threading code and
socket handling, and make use of NIO;
I believe that's the main reason to make the move.
Of course, JDK-1.3-compatible releases could still continue on HEAD,
or we could move the 1.4+ branch to HEAD and the 1.3 code to a
maintenance branch.
Assuming we're talking about continuing incremental evolution, I believe
we should cut a 1.4.2 release with all the current bug fixes included
and branch from there. JDK 1.3 would be supported in maintenance
releases based off of 1.4.2 (e.g., 1.4.3, 1.4.4, etc.) that would only
include bug fixes. New development based on JDK 1.4 would continue
on the main trunk. Taking the FTPS code contribution into account, I'd
change that to releasing a 1.4.2, then incorporating the FTPS code in
a 1.5 release compatible with JDK 1.3, and branching from there as
per the original scenario. The only situation in which I'd suggest doing
it differently is if someone was really itching to write NIO or other
JDK 1.4 stuff in the near term, in which case I think we'd have to let
that happen on a separate branch until the FTPS code was incorporated
into the trunk. Then after the 1.5 release off of the trunk, we'd merge
changes from the JDK 1.4 branch into the main trunk and only do JDK 1.3
releases off of the 1.5 tree.
daniel
---------------------------------------------------------------------
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]
