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. I have no problem bumping major versions., package names, and Maven coords in order to keep a project evolving at 21st century speeds. 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
