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