commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject [VFS] BC breaks in VFS 2.1 RC1
Date Fri, 06 May 2016 21:40:14 GMT
I'm creating a new thread here instead of hijacking the VOTE thread.

First, let me express my gratitude to Stian Soiland-Reyes for RM'ing a
release, I'm sure he did not know what he was getting himself into! ;-)

Part of me writing this here is flushing out for myself, voters, and casual
observers what it is we are doing ;-)

We have BC breakage in VFS 2.1 RC1 in two areas:

- Adding methods to public interfaces
- Other stuff like removing fields, changing fields from protected to
private, changing method arg types.


I see three areas that need consideration:

(0) For simple clients that only use the higher-level interfaces and
methods, there are no problems. So this is a non-issue marker I suppose.

(1) For advanced clients that get their fingers in deep into VFS, they
break. Example:

- org.apache.commons.vfs2.provider.tar.TarFileObject: Accessibility of
field entry has been weakened from protected to private.
- org.apache.commons.vfs2.provider.webdav.WebdavFileProvider: Removed field
- and so on.

Remedies for these kinds of breaks are simple and easy: Just change stuff
back and mark @deprecated in Javadoc and @Deprecated.

(2) For providers, they break unless they extend our root classes like
AbstractFileObject and DefaultFileSystemManager, and use our default
classes like DefaultFileContent.
For "simple" providers, there probably won't be any issue, but who knows?
Does anyone have a 2.0 provider?
For advanced providers that do more of their own thing instead of reusing
our base classes, then breakage.

It seems to me that we should pick the low-hanging fruits and fix the
simple stuff.

All of this is moot if we were to go to 3.0 now.


E-Mail: |
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition <>
Spring Batch in Action <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message