commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rory Winston <rwins...@eircom.net>
Subject Re: [net] JDK 1.4+ Branch?
Date Sun, 29 Jan 2006 22:30:15 GMT
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 <43DBD5BF.9030902@eircom.net>, 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: 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