CHAPTER 9 ■ SCALING YOUR TEAM
285
the server side, where we trust the code, this is not an issue. If we were writing code for an
untrusted world, we’d care a lot more about the semantics of the source code being enforced
by the execution environment.
So, there have been no new JVM instructions since Java was released. The JVM is perhaps
the best-specified piece of software this side of ADA-based military projects. There are
specs and slow-moving JSRs for everything. Turns out, this works to our benefit.
Present-Day Compatibility
The JVM has a clearly defined interface to debugging. The information that a class file
needs to provide to the JVM for line numbers, variable names, and so on, is very clearly
specified. Because the JVM has a limited instruction set and the type of each item on the
stack and of each instance variable in a class is known and verified when the class loads,
the debugging information works for anything that compiles down to Java bytecode and
has semantics of named local variables and named instance variables. Scala shares these
semantics with Java, and that’s why the Scala compiler can compile bytecode that has the
appropriate debugging information so that it “just works” with jdb. And, just to be clear,
jdb uses the standard, well-documented interface into the JVM to do debugging, and
every other IDE for the JVM uses this same interface. That means that an IDE that compiles
Scala can also hook into the JVM and debug Scala.
Scala’s operational characteristics are the same as Java’s. The Scala compiler generates
bytecode that is nearly identical to the Java compiler. In fact, that you can decompile Scala
code and wind up with readable Java code, with the exception of certain constructor oper-
ations. To the JVM, Scala code and Java code are indistinguishable. The only difference is
that there’s a single extra library file to support Scala.
Popping the Stack to the CEO or Board
Now, in most software projects, you don’t have CEOs and board members and everybody’s
grandmother asking what libraries you’re using. In fact, in every project I’ve stepped into,
there have been at least two libraries that the senior developers did not add but somehow
got introduced into the mix. (I believe in library audits to make sure there’s no license
violations in the library mix.) So, in the normal course of business, libraries are added to
projects all the time. Any moderately complex project depends on dozens of libraries. I
can tell you to a 100 percent degree of certainty that there are libraries in that mix that will
not pass the “Is the company that supports them going to be around in five years?” test.
Period. Sure, memcached will be around in five years, and most of the memcached clients
will not.
Making the choice to use Scala should be a deliberate, deliberated, well-reasoned
choice. It has to do with developer productivity, both to build the initial product and to
maintain the product through a two-to-five-year life cycle. It has to do with maintaining
19897ch09.fm Page 285 Thursday, April 23, 2009 4:33 PM