On 8 October 2013 21:11, Gary Gregory <garydgreg...@gmail.com> wrote: > On Tue, Oct 8, 2013 at 2:11 PM, sebb <seb...@gmail.com> wrote: >> On 8 October 2013 17:36, Gary Gregory <garydgreg...@gmail.com> wrote: >>> On Oct 8, 2013, at 10:09, James Carman <ja...@carmanconsulting.com> wrote: >>> >>>> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <ebo...@apache.org> wrote: >>>>> >>>>> That's not the issue. We want to avoid unresolvable incompatibilities in >>>>> transitive dependencies. Our components are used by many projects, an >>>>> incompatibility could render impossible the use of two components >>>>> together, and you are stuck until the components are updated to use the >>>>> same version of the common dependency. >>>>> >>>>> ASM and BouncyCastle are two examples of widely used projects that don't >>>>> care at all about the compatibilities, and this is causing pain and >>>>> wasting time to a lot of smart people. >>>> >>>> I think you misunderstand my intent. We have left out features before >>>> (ones that folks blogged about and said they liked) because a user >>>> could do something stupid with it. >>>> >>>> What you're talking about is "jar hell" and we have already addressed >>>> that with our naming convention for major release bumps (changing >>>> artifactId and package name). I'm cool with that idea and I think >>>> it's a pretty good approach. I don't see anyone else doing it, which >>>> is interesting. >>>> >>> >>> Yep, our approach works. You cannot be kind of binary compatible, it's >>> all or nothing. >> >> Yes and no. > > You can't tell me with a straight face that binary compatibility is > not a strict true/false attribute ;) > > While I agree with the overall feel of your message, my experience > makes be love BC. Even small apps that end up with layers of 3rd party > jar deps leads you immediately to jar hell if there is no binary > compatibility within packages. This is why our change of package name > (and maven coords) guideline works so well. > > Sure, some corner method is a tucked away class may never be used > outside the jar, but, if it's public, don't break it. You just do not > know what call sites are going to do.
Each incompatibility needs to be decided on its merits. For example, if a class or method is clearly documented as internal or experimental, then anyone that relies on it should not be surprised if problems occur. Just the same as if one uses a class from a sun.* package. There are other examples where the field or code may be part of the public API, but nevertheless making use of it is clearly wrong. For example, writing to an entry in a protected final array which contains constants. (The array should have been private with an accessor). I'm sure there have been other cases. > I have no problem bumping major versions., package names, and Maven > coords in order to keep a project evolving at 21st century speeds. I prefer that to jar hell and/or stagnation, however the downside is additional work downstream. The choice is not always black/white. > This is probably why I am OK with a stricter BC definition. > > Gary > > >> >> Yes, one can say unambiguously that a particular change is - or is not >> - binary compatible according to the Java compatibility rules. >> >> But it may still be OK to break binary compatibility without package >> renames if the likelihood of it affecting end users is extremely low. >> >> I think the way to approach binary incompatibility is as follows: >> - check whether it's really necessary to break compatibility; >> sometimes it happens by accident and can be fixed >> - if the break really is necessary, evaluate how likely it is to >> affect 3rd party code. >> >> Depending on the severity of the break, it may be necessary to change >> package name/Maven coordinates, or it may just require a warning in >> the release notes. >> >> It's not always easy to get this right, which is where it's useful to >> have a community of experienced developers. >> >>> I do like the idea of internal package names like >>> Eclipse does. This would not stop me from hacking my way in there but >>> at least I should not be surprised if a minor version breaks internal >>> binary compat. >> >> +1 >> >> But it's not always obvious initially which classes are which. >> >> [Also of course one should start by making everything private >> (especially mutable fields) and only increasing visibility as needed.] >> >>> Gary >>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
