On 17 November 2010 00:06, ralph.goers @dslextreme.com <ralph.go...@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 <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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
