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<".
Ralph On Tue, Nov 16, 2010 at 1:21 PM, sebb <seb...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
