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 16:23:32 GMT
Yes, I do agree, but again I'm completely non binding. Migrating code to
new packages (or new classnames) where binary compatibility cannot be 
granted. Unfortunately I cannot foresee how many places would need to be
refactored to support "double" classes/packages ... internally I mean,
from a user POV they will call the new class in the the new package if
they want/need support for jdk5 stuff.

Simone

James Carman wrote:
> I'm +1 for moving forward, but I would rather change the package name
> rather than break backward compatibility.  There are a lot of
> libraries out there that depend on commons-* and you may need older
> versions on your classpath to get them to work.
>
> On Fri, Oct 10, 2008 at 11:07 AM, Simone Gianni <simoneg@apache.org> wrote:
>   
>> 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
>>
>>
>>     
>
> ---------------------------------------------------------------------
> 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