Changing access modifier, yes it will. I guess, even if someone was using constructor for this utility static methods class, that can mitigated by scheduling the change for next major release. I'm more interested if there is any special reason behind decision to make the constructor public in the first place.
Similarly, I'm interested on any thoughts about refactoring out OperatingSystemUtils, anyone have anything against that, maybe against it being part of commons-io. One use case where I'd use it is in a JUnit test which uses JUnit Assumes API and has OS specific test cases. Kind regards, Stevo Slavić. On Sun, Jul 22, 2012 at 3:30 PM, sebb <[email protected]> wrote: > On 22 July 2012 14:08, Stevo Slavić <[email protected]> wrote: > > Hello Apache Commons community, > > > > Is there any special reason for FileSystemUtils constructor to be public? > > Shouldn't it be private instead? > > > > What do you think about refactoring FileSystemUtils, to move OS stuff > into > > separate OperatingSystemUtils class exposing isWindows, isUnix, > > isPosixUnix, isSolaris, isMac, getOs API? > > > > Here's the link to current FileSystemUtils revision: > > > http://svn.apache.org/viewvc/commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileSystemUtils.java?revision=1304052&view=markup > > Sounds like this will break binary and/or source compatibiliy. > > > Kind regards, > > Stevo Slavić. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
