commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <billwbar...@verizon.net>
Subject Re: svn commit: r1326609 - in /commons/proper/io/trunk/src: changes/changes.xml main/java/org/apache/commons/io/FileUtils.java
Date Sat, 21 Apr 2012 05:49:10 GMT


-----Original Message----- 
From: JörgSchaible
Sent: Friday, April 20, 2012 6:54 AM
To: dev@commons.apache.org
Subject: Re: svn commit: r1326609 - in /commons/proper/io/trunk/src: 
changes/changes.xml main/java/org/apache/commons/io/FileUtils.java

Bill Barker wrote:

>>
>>
>> -----Original Message-----
>> From: Gary Gregory
>> Sent: Wednesday, April 18, 2012 6:15 AM
>> To: Commons Developers List
>> Subject: Re: svn commit: r1326609 - in /commons/proper/io/trunk/src:
>> changes/changes.xml main/java/org/apache/commons/io/FileUtils.java
>>
>> On Wed, Apr 18, 2012 at 12:38 AM, Stefan Bodewig <bodewig@apache.org>
>> wrote:
>>
>>>> On 2012-04-16, <ggregory@apache.org> wrote:
>>>>
>>>> > [IO-324] Add Charset sister APIs to method that take a String charset
>>>> name.
>>>>
>>>> The new methods cause problems for people who pass in null for the
>>>> charset as they want the platform's system default.  The compiler
>>>> doesn't know which of the writeStringToFile methods to pick if the 
>>>> third
>>>> param is null.
>>>>
>>>
>>>You are correct. See the release notes:
>>>
>>>Compatibility with 2.2 and 1.4:
>>>Binary compatible: Yes.>
>>>Source compatible: No, see the rare case in
>>>https://issues.apache.org/jira/browse/IO-318.
>>>Semantic compatible: No, see the rare case in
>>>https://issues.apache.org/jira/browse/IO-318.
>>>
>>>There are two solutions if you want to use the latest [io], as noted in
>>>the Jira:
>>>
>>>- type-cast the charset to String to Charset, or
>>>- use the API that does not have a charset.
>>>
>>>Thank you,
>>>Gary
>>>
>>
>> And this is exactly why I wouldn't touch commons-io for any new project 
>> in
>> my day job. I would choose guava instead 99 times out of 100.  If you 
>> want
>> to kill [io] this way, then I will continue to not vote on it. But IMHO,
>> it isn't a viable project anymore against guava without more
>> considerations for backwards compatibility.
>
>
>? What more can you expect than taking the new jar and replace an old one
>and your application simply runs?
>

As Stefan pointed out at the beginning of this thread, it isn't a drop in 
replacement. The [io] team has deliberately broken all backwards 
compatibility. That is why I'm sticking to my statement that will never use 
[io] ever again in my day job, and will recommend guava instead.

>- Jörg
>
>


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


Mime
View raw message