The bill is much higher if you don't clean up your own mess, and it typically gets called to account when you're most in need of higher velocity.
Case in point... Sun/Oracle took too long to add modules so they could remove deprecated code from Java, they've been suffering from postponed or feature-limited releases as a result. Once you have modules, it becomes far easier to release everything else in a perfectly useable but less than 100% complete condition, because you then have the scope to revert design choices in a subsequent version. On 19 July 2012 22:04, Jess Holle <[email protected]> wrote: > It's great if someone foots the bill for religious refactoring. > > Not all organizations will. > > Nor can I say that I'd argue for footing such a bill when one has millions > of lines of code that work just fine but just happen to have been written > against older versions of Java. Who cares if they use Enumeration or > Iterator if they work? > > Worse, if you have loads of 3rd-party libraries, you can't reasonably > refactor all of them to some new version of Java, especially if some are > closed source. You can try to find alternatives, but you can't always. > > This puts organizations in an expensive rock-and-a-hard-place spot -- and > many will simply stay behind. That unnecessarily fractures the Java > community. This is coming from someone who has spent a lot of time and > energy to run and compile everything with the latest JVM, latest Tomcat, > latest of most everything. Even so, refactoring everything for purity's > sake -- that's not even in the top thousand priorities. > > > On 7/19/2012 3:57 PM, Kevin Wright wrote: > > I'm currently working on an application that consists of 74 distinct > modules in GitHub, most of which are in scala. One of the smaller modules > I've recently been working on has 45k lines, this is down from 70k about a > month ago (hey, I practice what I preach, and am a strong believer in > staying clean of technical debt) > > Across all projects, we're well over a million lines of code (most of > which is Scala, remember, and so equivalent functionality to 3-5x that many > lines of Java), all under 2 years old. So in terms of size, I'm working at > the same order of magnitude. > > One of our "secrets" in getting where we are now, having an application > that we can work on at blazing speed, is a willingness to cut code and to > refactor ruthlessly. If it begins to look "enterprise", if there's any > obvious technical debt, then that's a code smell - it's not bragging > material. > > I can honestly say that refactoring to new versions of APIs, or removing > the use of deprecated methods has never been a problem. The very same IDEs > that you previously referred to are particularly good at this sort of > challenge, and *this* is the correct use of a decent tool - instead of > simply hiding stuff. > > > > > On 19 July 2012 21:13, Jess Holle <[email protected]> wrote: > >> To give some further insight: >> >> The enterprise application I work on has been on the market for over a >> dozen years now. The latest version has millions of lines of code, some >> portion essentially unchanged in the last 12 years and some using the very >> latest Java 7 features and much in between. The latest version uses many >> dozens of libraries ranging from Java 1.1 era libraries that are no longer >> maintained to some that require Java 7. Requiring that everything jump to >> some new version of java.lang or java.util or any such to move to Java 'n' >> (or module rev 'n') would postpone any move to Java 'n' (or module rev 'n') >> by a long, long time and cause us an enormous amount of expense that we'd >> scream at Oracle about for years to come. >> >> Oracle's not stupid -- such a move would be digging their own grave. >> It's not the sort of language or platform evolution their customers can >> tolerate. >> >> >> On 7/19/2012 2:59 PM, Jess Holle wrote: >> >> Note that with something like OSGi juggling multiple versions of one >> module within a JVM you still have java.lang.String and java.lang2.String >> interoperability issues -- except they both have the same class name (just >> different Class objects, different methods, etc) to add to the confusion. >> >> There's no free lunch here. >> >> On 7/19/2012 2:43 PM, Jess Holle wrote: >> >> P.S. For similar reasons most any open source project with any brains >> keeps all old methods and classes around once their APIs are initially >> stable -- and moves to an entirely new package when they find they need to >> violate this. That allows use of old and new APIs in parallel within the >> same classloader without any OSGi fanciness. Breaking API compatibility >> otherwise is nasty, user-vicious behavior. Moving to a new package for >> Java classes is a non-starter in most cases -- better to deal with cruft >> than to deal with java.lang.String and java.lang2.String interoperability >> issues. >> >> On 7/19/2012 2:39 PM, Jess Holle wrote: >> >> The problem is that you then can't move to the latest module and thus get >> access to the new APIs anywhere in your JVM unless/until you expunge all >> usages of the old APIs from all of your own millions of lines of code and >> all of the dozens of 3rd-party libraries you use. >> >> This is a Python 3 schism. You wouldn't be able to move to the latest of >> module X until your whole world was an ivory tower. >> >> This would be a guaranteed recipe for all enterprise Java shops to stick >> on whatever release was before this -- forever. You'd schism the community >> each and every time you produced a new module version. >> >> On 7/19/2012 2:35 PM, Kevin Wright wrote: >> >> Who's being forced? >> >> You don't specify modules at all and you automatically get the latest >> version of the standard lib modules compatible with java 7 APIs. >> >> You specify LATEST, and you're exposed to changes in API's >> >> You specify exact version numbers, and you're certain that your code will >> compile and run, even against a newer version of java. >> >> People can move at their own pace, however slow that may be, but it may >> also be a fast pace - in which case you'll no longer be held back by the >> demands of backward compatibility all the way to java 1.0 >> On Jul 19, 2012 8:20 PM, "Jess Holle" <[email protected]> wrote: >> >>> On 7/19/2012 2:09 PM, Kevin Wright wrote: >>> >>> And how does simply hiding stuff deal with this "unfortunate" mess: >>> >>> http://docs.oracle.com/javase/7/docs/api/java/util/class-use/Enumeration.html >>> >>> No amount of {display: none} in the javadoc CSS will allow those >>> methods to return an iterator instead, not unless you deprecate them all >>> and implement new versions with subtly different names, and that's just one >>> of the more obvious examples! >>> >>> Just use a wrapper Iterator (with unsupported operation for remove()). >>> >>> Jigsaw is the *only* way we'll be able to bump up version numbers and >>> genuinely remove methods or change their signatures. As you said, this >>> stuff can be hidden in JavaDoc (hell, ScalaDoc already does something >>> similar by banishing them to the bottom of the page: >>> http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/index.html#scala.collection.Traversable >>> ) >>> >>> But... That then has to be reimplemented for each and every tool, in >>> each and every language running on the Java *platform*. And it *still* >>> doesn't allow you to change signatures in a backwardly-compatible fashion. >>> >>> Ah... So you're suggesting creating substantially different (gutted) >>> APIs for new versions of the core library modules, thereby forcing one to >>> update everything one would use in their whole JVM process to use the new >>> APIs for that module rather than old ones in order to use anything >>> (including bug fixes) from the new module version. That's a complete >>> non-starter as I see it -- that's back to Python 3.0 albeit on a more >>> granular scale. That would be chaos for anyone with millions of lines of >>> code and many dozens of 3rd-party libraries in their JVM, i.e. those with >>> large enterprise applications like many in Java's bread-and-butter space, >>> including me. >>> >>> In reality Jigsaw is nothing more than a "move crufty *classes* into a >>> separate, optional module" solution here. Changes within a class still >>> require all the same API evolution considerations one had before. That's >>> life in the real world. >>> >>> -- >>> Jess Holle >>> >>> -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
