Scala Guide for Java Developers

Scala is written specifically for the Java™ platform, so its syntax design makes Java code-coding people feel relaxed. At the same time, Scala provides the JVM with the inherent power of functional languages, and starts with these functional design concepts. In this issue of the Scala Guide series for Java developers, Ted Neward will introduce nuances between the two languages, starting with some control structures such as if, while, and for. As you will learn, Scala provides these structures with features and complexities that are not available in their Java equivalents.

So far, in this series, we've discussed Scala's fidelity to the environment, demonstrating how Scala combines many of the Java core object features. If Scala is just another way to write an object, it will not have any noticeable place, or it is no longer so powerful. Scala's combination of functional concepts and object concepts, as well as its emphasis on the efficiency of programmers, makes it more complex and more subtle to learn Scala language than Java-cum-scala programmers imagine.

For example, use Scala for control structures such as if, while, and for. Although these control structures look like older, better Java architectures, Scala actually adds some completely different features to them. This month's article is about entry-level readings that you can expect to get when using Scala's control structure, rather than making a lot of mistakes (and writing a bunch of error codes), and then risking your frustration to find the difference.

Revised Person.scala

In the previous article in this series, you learned that Scala can define POJO by defining methods that mimic the traditional "getter and setter" required for an POJO environment. After the article was published, I received an email from Bill Venners, a co-author of the upcoming official Scala reference using Scala programming (see Resources). Bill points out a simpler way to do this, which is to use the Scala.reflect.BeanProperty annotation, as follows:

Listing 1. The modified Person.scala

class Person(fn:String, ln:String, a:Int)
　　 {
　　 @scala.reflect.BeanProperty
　　 var firstName = fn

　　 @scala.reflect.BeanProperty
　　 var lastName = ln

　　 @scala.reflect.BeanProperty
　　 var age = a
　　 override def toString =
　　　　 "[Person firstName:" + firstName + " lastName:" + lastName +
　　　　 " age:" + age + " ]"
　　 }

The method in Listing 1 (the revision of listing 13 in the previous article) generates a Get/set method pair for the specified var. The only drawback is that these methods do not actually exist in Scala code, so other Scala code cannot invoke them. This is usually not a big problem, because Scala will use the generated methods for the fields it generates for itself; If you don't know beforehand, then these might be a surprise to you.

After looking at the code in Listing 1, the most shocking thing to me is that Scala does not only demonstrate the power of the concept of combinatorial functions and the concept of objects, it also demonstrates some of the benefits of object language in the 30 years since the first release of Java.

Control is a fantasy.

Many of the strange, incredible things you'll see can be attributed to Scala's functional features, so it might be useful to give a brief introduction to the background of functional language development and evolution.

In functional languages, it is not uncommon to build more and more advanced structures directly into the language. In addition, language is defined through a set of core primitives. After combining functions that pass functions as objects, higher-order functions that can be used to define functionality look like they are outside the core language, but in fact it's just a library. Similar to any library, this feature can be replaced, expanded, or extended.

The synthesis characteristics of a set of core primitives can be traced back to the use of Smalltalk, Lisp, and Scheme in the the 1960s and 70. Languages such as Lisp and Scheme are enthusiastically sought after because of their ability to define higher levels of abstraction at a lower level of abstraction. Programmers can use advanced abstractions to build more advanced abstractions. Now when you hear about this process, it's usually about domain-specific languages (or DSL) (see Resources). In fact, it's just a process of building abstractions on top of abstractions.

In the Java language, the only choice is to use API calls to do this; in Scala, you can implement it by extending the language itself. Attempting to extend the Java language poses the risk of creating extreme scenarios (corner cases) that threaten global stability. Trying to expand Scala only means creating a new library.