Details
-
Wish
-
Status: Closed
-
Major
-
Resolution: Not A Problem
-
2.11.0
-
None
-
None
Description
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.