[all] The JDK1.5 issue [was: [net] JDK 1.4+ Branch?]

[Stephen Colebourne <sc...@btopenworld.com>]

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 <43...@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
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [all] The JDK1.5 issue [was: [net] JDK 1.4+ Branch?]

[Rahul Akolkar <ra...@gmail.com>]

On 1/29/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> 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.)
>
<snip/>

As I indicated briefly before, IMO, we need to encourage 1.4 or Tiger
branches. Its an indication that we are moving forward as a community
rather than stagnating. We understand there are many people who have
to use <= 1.3, many times for reasons beyond their control -- thats
why so many of our components support those JDKs.

While creating a branch to push up the JDK version, which version is
chosen should be upto the developers creating the branch, I wouldn't
want to rule out 1.4 if anyone sees value in it or is not ready to go
to Tiger yet. I also think we shouldn't worry as much about the lack
of developer resources. Its takes one developer to start a branch, and
time will tell if it becomes successful and gets incorporated in a
future (presumably major version) release of the component.

If developers are willing, the fact that new ideas within a component
require a higher JDK version should never be the *only* limiting
factor for the introduction of these ideas.

-Rahul


> Stephen
>
>
<snap/>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org