commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Viraj Turakhia" <virajturak...@gmail.com>
Subject Re: [lang] Java 5
Date Fri, 10 Oct 2008 19:27:49 GMT
+1 in moving to JDK 1.5.

New contributor, but always wanted to see 1.5 supported libraries in commons.


-v

On Fri, Oct 10, 2008 at 9:53 PM, Simone Gianni <simoneg@apache.org> wrote:
> 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
>
>



-- 
The first right of human is the right of EGO.
--
http://www.xperienceexperience.blogspot.com

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


Mime
View raw message