commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject Re: [lang] Java 5
Date Fri, 10 Oct 2008 15:10:50 GMT
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


Mime
View raw message