Paul Pogonyshev created IO-767:
----------------------------------

             Summary: FileUtils will become unextendable in future according to 
@deprecated comment
                 Key: IO-767
                 URL: https://issues.apache.org/jira/browse/IO-767
             Project: Commons IO
          Issue Type: Wish
          Components: Utilities
    Affects Versions: 2.11.0
            Reporter: Paul Pogonyshev


Source code of FileUtils currently has this in the doccomment before the 
constructor: "@deprecated Will be private in 3.0.". This will make FileUtils 
unextendable, breaking existing code (e.g. that of our application).

Our usecase: we extend several *Utils classes from Apache Commons libraries to 
add our own utility methods, yet still avoid caring if they are "from a 
standard library" or our extension. E.g. we can use code like 'import 
our.application.FileUtils;' and then 'FileUtils.copyDirectory(...)' (using 
Apache-provided method) and 'FileUtils.doSomeFunnyStuff(...)' (using our 
internal utility function). Thus we don't clutter 'import' block and avoid 
either 1) specifying fully-qualified class name if we had to use two different 
'FileUtils' classes; or 2) renaming our class into something ugly like 
'OurAppFileUtils'.

If Apache Commons makes their utility classes unextendable, we will no longer 
be able to do this. This is the disadvantage for us and anyone else using 
similar class layout. I don't see any advantages in making utility classes 
unextendable other than having compiler bark at 'new FileUtils()' code some 
newcomers would try once in lifetime.

Proposal: make utility classes abstract instead, so that they can be extended, 
but not instantiated. If you absolutely want to prohibit instantiation even of 
subclasses (also anonymous), add a protected constructor like this:

{{    public FileUtils() {}}

{{        throw new UnsupportedOperationException("FileUtils may not be 
instantiated");}}

{{    }}}

Yes, this would at runtime instead of at compilation time, but I'd say that's 
worth it for something that should practically never be atempted anyway.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Reply via email to