[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17528851#comment-17528851 ] 

Gary D. Gregory commented on IO-767:
------------------------------------

All FileUtils methods are static so there is nothing to inherit on the instance side. Creating an instance of this class therefore does not make sense should be considered an anti-pattern. While the constructor was deprecated, the class was not made final to preserve binary compatibility. 

A future, and currently unplanned major release for 3.0 would take the opportunity to most likely remove all deprecated code and make any other binary breaking changes that would be useful. Such a major release would be made with a change of package name and Maven artifact ID such that 2.x and 3.x can co-exist.

So there is nothing to do here IMO.

> 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)