"Jesús M. Navarro" <jesus.nava...@undominio.net> writes: > If you don't do that already is because you know that your app will fail > day-in day-out because foo developer (and bar, and zoot...) is not > sensible enough not to break backwards compatibility between foo_1.2.3 > and foo_1.2.4. Russ is right in that when things go that way, things > are completly wrong in the long run in so many manners it's not even > funny. The fact this behaviour is "business as usual" on Java > development it's only a measure of its average quality.
I also feel like I should say here that many Java developers *do* do this properly. I've moved Java projects to new versions of common Java libraries like Spring or various Apache infrastructure libraries and had them just work. Often even across major releases, but very commonly with minor releases. I don't think the current state of the art is actually as dire as all that. Java offers very good mechanisms for information hiding and minimizing the exposed API so that libraries can adjust for compatibility issues, and good Java programmers use those facilities. > Oh! and another hint: "if ain't broken don't fix it" is not such a > valuable knowledge with regards to open source if only because of the > outer testing base and the work it takes to jump over more than a few > releases (exponential, not linear, to the distance). Right, what you end up with is five or six or more copies of the same library at different versions, frozen there because no one dares to try to update and test, and then when that library has a security vulnerability, you have to backport the fix to all these slightly different versions. It's a nightmare. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqqzk0zw....@windlord.stanford.edu
