commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [VFS] Analysis of binary compatibility breaks between 1.0 and 2.0; release strategy
Date Wed, 17 Nov 2010 14:35:29 GMT

On Nov 17, 2010, at 2:54 AM, sebb wrote:

> On 17 November 2010 07:17, Ralph Goers <> wrote:
>> I'm not suggesting we change these. Since we are adopting Java 5 I would prefer to
change these now and move forward.
> To change or not to change? Sorry, cannot understand the last paragraph.

Sorry I wasn't clear.  

My feeling is that if we are upgrading to Java 5 then we should do it correctly. Go ahead
and break compatibility where required. In that view the changes done to the Comparables were
done correctly.  I suspect they will cause very few problems in any case.  Since we have changed
the package name and artifactId I just wouldn't worry about it.   

I agree we should remove the deprecated APIs - there don't appear to be many of them - although
I do find myself wondering why in AbstractFileObject doSetLastModifiedTime was deprecated
in favor of doSetLastModTime. I actually prefer the former name.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message