commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Gianni <simo...@apache.org>
Subject Re: [lang] Java 5
Date Fri, 10 Oct 2008 15:07:35 GMT
Hi all,
non binding +1 for moving to new versions supporting JDK 5 features,
even if breaking compatibility with older versions and rewriting APIs.
There is a lack of good libraries like lang, beanutils etc.. in the
post-1.5 jdks (see the recent thread i participated in regarding
generics), and many projects are dealing with problems with generics,
enums and so on.

Simone

James Carman wrote:
> Matt, good idea to revive this.  Commons needs to come to grips with
> JDK5.  It reaches its EOSL on 10/30/2009 and our libraries don't even
> support it yet!  We need to come up with an approach to this package
> renaming issue and just move forward.
>
> On Fri, Oct 10, 2008 at 10:44 AM, Matt Benson <gudnabrsam@yahoo.com> wrote:
>   
>> Resurrecting this thread from 3.5 months ago as my
>> itch is returning:
>>
>> --- Niall Pemberton <niall.pemberton@gmail.com> wrote:
>>
>>     
>>> On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell
>>> <flamefew@gmail.com> wrote:
>>>       
>>>> On Thu, Jun 12, 2008 at 5:05 AM, sebb
>>>>         
>>> <sebbaz@gmail.com> wrote:
>>>       
>>>>> On 12/06/2008, James Carman
>>>>>           
>>> <james@carmanconsulting.com> wrote:
>>>       
>>>>>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>>>>>>
>>>>>> <niall.pemberton@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>             
>>>>>>>> Do you mean that the removal of the enums
>>>>>>>>                 
>>> would mean that we have to
>>>       
>>>>>>  >> change package names?
>>>>>>  >>
>>>>>>  >> Would class/interface removals necessitate a
>>>>>>  >> package name change?  I haven't really
>>>>>>             
>>> thought that through.
>>>       
>>>>>>  >
>>>>>>  > Perhaps not, neither had I
>>>>>>  >
>>>>>>             
>>>>> Removal of a *public* interface/method/class
>>>>>           
>>> means that the API is not
>>>       
>>>>> compatible, as it is not possible to replace the
>>>>>           
>>> jar without breaking
>>>       
>>>>> classes that use these items.
>>>>>           
>>>> I think we need to make a final decision on this.
>>>>
>>>> There seems little argument against moving to 1.5
>>>>         
>>> in theory. And no
>>>       
>>>> one is concerned with using 1.5 features in new
>>>>         
>>> development. The one
>>>       
>>>> open question is: "Should we rename the package"?
>>>>
>>>> * If we goto 1.5, we have to remove the enum
>>>>         
>>> package. It's been
>>>       
>>>> deprecated for a good while and a source code fix
>>>>         
>>> is very easy. Any
>>>       
>>>> client that is 1.5 based has had to remove it
>>>>         
>>> already.
>>>       
>>>> * We have a handful of other deprecated methods
>>>>         
>>> that we've said will
>>>       
>>>> be removed in 3.0. We've removed methods in the
>>>>         
>>> past (I'm pretty sure
>>>       
>>>> we did that for 2.0).
>>>>
>>>> I'm 50/50 right now. On the one hand, yes I think
>>>>         
>>> we should remove
>>>       
>>>> things and it's not a major version problem. If
>>>>         
>>> people are having pain
>>>       
>>>> it would be very easy to build a separate jar with
>>>>         
>>> the deprecated
>>>       
>>>> methods. However.... if we are going to start
>>>>         
>>> writing new generics
>>>       
>>>> code etc, it is going to be impossible to manage
>>>>         
>>> to keep that separate
>>>       
>>>> from the existing code. How will people know what
>>>>         
>>> to code where?
>>>       
>>>> In which case I think we should just dive right
>>>>         
>>> into LangTwo now. svn
>>>       
>>>> cp the trunk to a branch for maintenance, and
>>>>         
>>> release of the current
>>>       
>>>> bugfixes if we ever need to, and start a new
>>>>         
>>> LangTwo on the current
>>>       
>>>> trunk.
>>>>         
>>> *If* lang2 breaks compatibility, then IMO we should
>>> use a new package
>>> name, but moving to JDK 1.5 minimum doesn't
>>> necessarily dictate that
>>> (assuming that we release a compatibility jar for
>>> the enum package
>>> which has to be removed). IMO it would be better to
>>> go through putting
>>> in the JDK 1.5 features that don't break
>>> compatibility and building up
>>> a list of possible changes that do. Then we make the
>>> decision on
>>> whether compatibility-breaking features seem worth
>>> it. If it is, then
>>> lets go all the way, remove deprecations, change the
>>> package name and
>>> put them in. If not, then lets leave the package
>>> name and
>>> deprecations. We've had a similar discussion over
>>> Commons IO and IMO
>>> so far nothing has come up that seems worth the
>>> whole sale package
>>> name change - so I think making the decision first,
>>> without any JDK
>>> 1.5+ features on the table for consideration is a
>>> mistake.
>>>       
>> Let's see, adding generics shouldn't break
>> compatibility; would varargs?  Beyond that anything
>> _added_ doesn't break compatibility because we're
>> talking about existing code with drop-in jar
>> replacement, right?  Have I correctly outlined the
>> differences between breaking and non-breaking changes
>> in this context?  If so, I'd like to go ahead and
>> start with the plan.  More likely I've missed
>> something; let's flush it out.
>>
>> -Matt
>>
>>     
>>> Niall
>>>
>>>       
>>>> Gump btw is going to go mad :) It'll think we're
>>>>         
>>> breaking compatibility.
>>>       
>>>> Hen
>>>>         
>>>       
>> ---------------------------------------------------------------------
>>     
>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail:
>>> dev-help@commons.apache.org
>>>
>>>
>>>       
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>   


-- 
Simone Gianni            CEO Semeru s.r.l.           Apache Committer
MALE human being programming a computer   http://www.simonegianni.it/


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


Mime
View raw message