Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=btopenworld.com;
  h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Antivirus:X-Antivirus-Status;
  b=Agp1pKI4sViii9+6xhxQO4ZGR99tSuTxi+0Jb9SVfBP6Tw7rgOm5JqAXjyXQN07PApHZkciyW+j5QH+rFEBfX3fCI2ci5UEYfH9ejZH2ILk7v/8p3sfk7VJ79hjOubcDvky1R6wKWq+/vV3J/E2LcEQ6AViObDdrpJXboAe1atw=
  ;
Message-ID: <47AABCF7.7050307@btopenworld.com>
Date: Thu, 07 Feb 2008 08:10:31 +0000
From: Stephen Colebourne <scolebourne@btopenworld.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Jakarta Commons Developers List <dev@commons.apache.org>
Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
References: <55afdc850802042047u29b4507fg2f26e3f355c2205e@mail.gmail.com>
	 <55afdc850802060351i646061caq19bb63ac3693059c@mail.gmail.com>
	 <47AA179E.60709@btopenworld.com>
 <55afdc850802061705p2c066936n7c355ce77041a453@mail.gmail.com>
In-Reply-To: <55afdc850802061705p2c066936n7c355ce77041a453@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Niall Pemberton wrote:
>>> [Note CharSequence replaces String and/or StringBuffer flavours]
> 
> OK for the above I added new methods, rather than changing the method
> signature - so still compatbile atm:
>    http://svn.apache.org/viewvc?view=rev&revision=619188

Although, the API is now bigger. If we decide to break binary 
compatibility later, we need to remember to delete duplicates like this.

>> All the other changes are binary compatible. Except for the problem that
>> the bytecode format for Java 5 is different as well, so you'd need
>> retrotranslator to help you out as well.
> 
> Anything that depends on a JDK 1.5 IO version will have to also be
> minimum JDK 1.5  and therefore direct or indirect users must be
> running on JDK 1.5 - so I don't see any need for retrotranslator or
> issues for users. Have I missed something?

Hmm, yes we should be OK.

>> In addition to the changes above, you will probably want to change most
>> APIs that take in a Collection to take an Iterable instead.
> OK I just had a quick scan and it looks we have the following methods
> where we could do this:
>     FilenameUtils.isExtension()
>     FileUtils.convertFileCollectionToFileArray()
>     FileUtils.writeLines()
>     IOUtils.writeLines()
> but this could also be done by just adding new flavours with an
> Iterable, rather than changing the existing methods.

Agreed, additional method can be added. Its certainly not as neat as 
just one method, and deprecation won't help (as any code linking to [io] 
will always pick the method taking a Collection, until the method is 
removed - hence removing the deprecation will never really be possible).

>> We should probably remove all references to arrays in the public API, as
>> generics and arrays work badly together, and I would strongly recommend
>> treating arrays as a type not to be exposed on any public API post-Java5.
> 
> Perhaps you could expand more on this because I don't see a big issue
> for IO. - are you thinking along the following lines:
> http://www.tbray.org/ongoing/When/200x/2005/06/12/Comparable

Kind of. Arrays and Generics do not work well together. One example is 
passing a generified list to a vararge method:
  public void process(List<String>... values)
This will always generate a warning, as the list gets converted to an array.

In general, arrays work poorly with generics, to the point that you 
can't avoid the warnings. My recommendation would be to replace arrays 
in the API with Collection/Iterable/List as appropriate. Existing API 
users can easily adapt, and they will thank us for the lack of warnings.

Stephen

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