[jira] [Closed] (IO-767) FileUtils will become unextendable in future according to @deprecated comment

["Gary D. Gregory (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IO-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary D. Gregory closed IO-767.
------------------------------
    Resolution: Not A Problem

Closing: Information is given and no feedback from the reporter.

> 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
>            Priority: Major
>
> 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)