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