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