【文章內(nèi)容簡介】 the piler is producing .class files that begin with 0xCAFEBABE, just like javac does. Also note what happens if you fire up the Java bytecode disassembler that es with the JDK (javap) and point it at the generated Rational 7 class, as shown in Listing 9: Listing 9. Classes piled from C:\Projects\scalaclasses\codejavap private classpath classes Rational Compiled from public class Rational extends implements { private int denom。 private int numer。 private int g。 public Rational(int, int)。 public Rational unary_$tilde()。 public toString()。 public Rational $div(Rational)。 public Rational $times(Rational)。 public Rational $minus(Rational)。 public Rational $plus(Rational)。 public int denom()。 public int numer()。 private int g()。 private int gcd(int, int)。 public Rational(int)。 public int $tag()。 } C:\Projects\scalaclasses\code The operators defined in the Scala class transmogrify into method calls in the best tradition of Java programming, though they do seem to be based on funny names. Two constructors are defined on the class: one taking an int and one taking a pair of ints. And, if you happen to be at all concerned that the use of the uppercase Int type is somehow a in disguise, note that the Scala piler is smart enough to transform them into regular Java primitive ints in the class definition. Testing, testing, 123... It is a wellknown meme that good programmers write code, and great programmers write tests。 thus far, I have been lax in exercising this rule for my Scala code, so let?s see what 8 happens when you put this Rational class inside of a traditional JUnit test suite, as shown in Listing 10: Listing 10. import .*。 import static .*。 public class RationalTest { @Test public void test2ArgRationalConstructor() { Rational r = new Rational(2, 5)。 assertTrue(() == 2)。 assertTrue(() == 5)。 } @Test public void test1ArgRationalConstructor() { Rational r = new Rational(5)。 assertTrue(() == 0)。 assertTrue(() == 1)。 // 1 because of gcd() invocation during construction。 // 0over5 is the same as 0over1 } @Test public void testAddRationals() { Rational r1 = new Rational(2, 5)。 Rational r2 = new Rational(1, 3)。 Rational r3 = (Rational) reflectInvoke(r1, $plus, r2)。 //r1.$plus(r2)。 assertTrue(() == 11)。 assertTrue(() == 15)。 } // ... some details omitted } Aside from confirming that the Rational class behaves, well, rationally, the above test suite also proves that it is possible to call Scala code from Java code (albeit with a little bit of an impedance mismatch when it es to the operators). The cool thing about this, of course, is 9 that it lets you try out Scala slowly, by migrating Java classes over to Scala classes without ever having to change the tests that back them. The only weirdness you might notice in the test code has to do with operator invocation, in this case, the + method on the Rational class. Looking back at the javap output, Scala has obviously translated the + function into the JVM method $plus, but the Java Language Specification does not allow the $ character in identifiers (which is why it39。s used in nested and anonymous nested class names). In order to invoke those methods, you either have to write the tests in Groovy or JRuby (or some other language that doesn39。t pose a restriction on the $ character), or you can write a little bit of Reflection code to invoke it. I go with the latter approach, which isn39。t all that interesting from a Scala perspective, but the result is included in this article39。s code bundle, should you be curious. (SeeDownload.) Note that workarounds like these are only necessary for function names that aren39。t also legitimate Java identifiers. A better Java Back when I was first learning C++, Bjarne Stroustrup suggested that one way to learn C++ was to see it as a better C (see Resources). In some ways, Java developers today might e to see Scala as a better Java, because it provides a more terse and succinct way of writing traditional Java POJOs. Consider the traditional Person POJO shown in Listing 11: Listing 11. (original POJO) public class JavaPerson { public JavaPerson(String firstName, String lastName, int age) { = firstName。 = lastName。 = age。 } public String getFirstName() { return 。 } public void setFirstName(String value) { 10 = value。 } public String getLastName() { return 。 } public void setLastName(String value) { = value。 } public int getAge() { return 。 } public void setAge(int value) { = value。 } public String toString() { return [Person: firstName + firstName + lastName: + lastName + age: + age + ]。 } private String firstName。 private String lastName。 private int age。 } Now consider its equivalent written in Scala: Listing 12. (threadsafe POJO) class Person(firstName:String, lastName:String, age:Int) { def getFirstName = firstName def getLastName = lastName 11 def getAge = age override def toString = [Person firstName: + firstName + lastName: + lastName + age: + age + ] } It isn39。t a plete dropin replacement, given that the original Person had some mutable setters. But considering the original Person also had no synchronization code around those mutable setters, the Scala version is safer to use. Also