commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [VFS] Analysis of binary compatibility breaks between 1.0 and 2.0; release strategy
Date Wed, 17 Nov 2010 00:19:19 GMT
On 17 November 2010 00:06, ralph.goers @dslextreme.com
<ralph.goers@dslextreme.com> wrote:
> I'm not sure why the tool didn't catch it, but a few methods now return
> Map<String, Object> where they previously returned Map. I didn't check for
> generics other than "Map<".

Surely these are equivalent at run-time?

Generics are a compile-time feature.

> Ralph
>
> On Tue, Nov 16, 2010 at 1:21 PM, sebb <sebbaz@gmail.com> wrote:
>
>> Clirr reports the following problems when comparing the codebases
>> (prior to the vfs2 package rename)
>>
>> 1) Selectors: Changed from interface to class
>> This contains only constants. The interface was not actually
>> implemented by any VFS classes; the constants were referenced using
>> the class name
>> If any user classes were lazy and implemented the interface rather
>> than using the qualified name, then they would break.
>> But this seems rather unlikely.
>>
>> 2) util.UserAuthenticatorUtils: Added final modifier to class
>> - class has static methods only, so no point in sub-classing it
>>
>> 3) FileSystemOptions: Added final modifier to class
>> - this class appears to be internal use only
>>
>> 4)
>> provider.HostFileNameParser$Authority: Accessibility of field hostName
>> has been weakened from public to private
>> provider.HostFileNameParser$Authority: Accessibility of field password
>> has been weakened from public to private
>> provider.HostFileNameParser$Authority: Accessibility of field port has
>> been weakened from public to private
>> provider.HostFileNameParser$Authority: Accessibility of field scheme
>> has been weakened from public to private
>> provider.HostFileNameParser$Authority: Accessibility of field userName
>> has been weakened from public to private
>> - These are all changes to a protected nested class; seems to be
>> internal use only
>>
>> 5) FileSystemConfigBuilder: Accessibility of method 'public
>> FileSystemConfigBuilder()' has been decreased from public to protected
>> This is the default ctor of an abstract class. The other ctor was
>> already protected. User code should not be instantiating this class
>> directly.
>>
>> 6) util.UserAuthenticatorUtils: Accessibility of method 'public
>> UserAuthenticatorUtils()' has been decreased from public to private
>> This is a class with static methods only; it should never be instantiated
>>
>> 7) FileContent: Method 'public boolean hasAttribute(java.lang.String)'
>> has been added to an interface
>>   FileContent: Method 'public void removeAttribute(java.lang.String)'
>> has been added to an interface
>> There is a single implementation: DefaultFileContent
>>
>> 8) FileSystem: Method 'public java.lang.String getRootURI()' has been
>> added to an interface
>> There is an AbstractFileSystem class which all other VFS
>> implementations subclass.
>>
>> 9) FileSystemManager: Method 'public boolean
>> hasProvider(java.lang.String)' has been added to an interface
>> There is a DefaultFileSystemManager which is the most likely route for
>> any 3rd party implementations.
>>
>> These 3 interfaces are part of the public API as far as I can tell.
>> However, would user code ever directly implement the interfaces?
>>
>> ==
>>
>> It looks to me as though user code is very unlikely to be affected by
>> any of the binary changes.
>> The only changes that might perhaps affect user code are 1), 7), 9)
>> and possibly 8)
>>
>> Also, the latest Gump run of vfs 1.x (which is actually using the SVN
>> code commons/proper/vfs/tags/preVFS2package temporarily) does not have
>> any dependee failures (apart from Doxia which fails for an unrelated
>> reason).
>>
>> I think it would be safe to release 2.0 using the package o.a.c.vfs
>> (rather than vfs2).
>> [It needs to be 2.0 because of the API changes and there are a lot of
>> new providers etc.]
>> However this would mean reverting to the old groupId (unless we can be
>> sure that relocation POMs work).
>>
>> [Note: The recent StringBuilder changes can be made
>> backwards-compatible by adding back the old API methods].
>>
>> As I see it, there are the following options:
>>
>> 1) Release 2.0 as described above.
>> Upside: no need for downstream users to update their code.
>> Downside is the change to o.a.c groupId may not be possible. Slight
>> risk of user API break.
>>
>> 2) Release 2.0 using vfs2 and groupId o.a.c
>> Upside: Can fix groupId. No need to maintain any API compatibility;
>> can drop all deprecated code.
>> Downside: All downstream users need to recode their applications.
>>
>> If the consensus is to stick with VFS2 and option 2, then I think we
>> need to look very carefully at the code to ensure that there aren't
>> any areas of the code that would benefit from an API change.  In
>> particular, we should delete all deprecated code.
>>
>> Otherwise there might have to be VFS3 which would force all downstream
>> users to recode their applications yet again.
>>
>> Or perhaps we could release an ALPHA or BETA version, with the proviso
>> that the API might change when the final version is released?
>> At least then downstream users would be warned.
>>
>> ---------------------------------------------------------------------
>> 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