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]
<mailto:[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]
<mailto:[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.
--
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.
