Odersky M. Programming in Scala

Подождите немного. Документ загружается.

Section 29.2 Chapter 29 · Combining Scala and Java 601

full possibilities of Java annotations, and further, Scala will probably one

day have its own reﬂection, in which case you would want to access Scala

annotations with Scala reﬂection.

Here is an example annotation:

import java.lang.annotation.

;

@Retention(RetentionPolicy.RUNTIME)

@Target(ElementType.METHOD)

public @interface Ignore { }

After compiling the above with javac, you can use the annotation as follows:

object Tests {

@Ignore

def testData = List(0, 1, -1, 5, -5)

def test1 {

assert(testData == (testData.head :: testData.tail))

}

def test2 {

assert(testData.contains(testData.head))

}

In this example, test1 and test2 are supposed to be test methods, but

testData should be ignored even though its name starts with “test”.

To see when these annotations are present, you can use the Java reﬂection

APIs. Here is sample code to show how it works:

for {

method <- Tests.getClass.getMethods

if method.getName.startsWith("test")

if method.getAnnotation(classOf[Ignore]) == null

} {

println("found a test method: " + method)

}

Here, the reﬂective methods getClass and getMethods are used to inspect

all the ﬁelds of the input object’s class. These are normal reﬂection methods.

The annotation-speciﬁc part is the use of method getAnnotation. As of

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

Section 29.3 Chapter 29 · Combining Scala and Java 602

Java 1.5, many reﬂection objects have a getAnnotation method for search-

ing for annotations of a speciﬁc type. In this case, the code looks for an

annotation of our new Ignore type. Since this is a Java API, success is

indicated by whether the result is null or is an actual annotation object.

Here is the code in action:

$ javac Ignore.java

$ scalac Tests.scala

$ scalac FindTests.scala

$ scala FindTests

found a test method: public void Tests$.test2()

found a test method: public void Tests$.test1()

As an aside, notice that the methods are in class Tests$ instead of class

Tests when viewed with Java reﬂection. As described at the beginning of

the chapter, the implementation of a Scala singleton object is placed in a

Java class with a dollar sign added to the end of its name. In this case, the

implementation of Tests is in the Java class Tests$.

Be aware that when you use Java annotations you have to work within

their limitations. For example, you can only use constants, not expressions,

in the arguments to annotations. You can support @serial(1234) but not

@serial(x

2), because x

2 is not a constant.

29.3 Existential types

All Java types have a Scala equivalent. This is necessary so that Scala code

can access any legal Java class. Most of the time the translation is straightfor-

ward. Pattern in Java is Pattern in Scala, and Iterator<Component> in

Java is Iterator[Component] in Scala. For some cases, though, the Scala

types you have seen so far are not enough. What can be done with Java wild-

card types such as Iterator<?> or Iterator<? extends Component>?

What can be done about raw types like Iterator, where the type param-

eter is omitted? For wildcard types and raw types, Scala uses an extra kind

of type called an existential type.

Existential types are a fully supported part of the language, but in practice

they are mainly used when accessing Java types from Scala. This section

gives a brief overview of how existential types work, but mostly this is only

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

Section 29.3 Chapter 29 · Combining Scala and Java 603

useful so that you can understand compiler error messages when your Scala

code accesses Java code.

The general form of an existential type is as follows:

type forSome { declarations }

The type part is an arbitrary Scala type, and the declarations part is a list of

abstract vals and types. The interpretation is that the declared variables and

types exist but are unknown, just like abstract members of a class. The type

is then allowed to refer to the declared variables and types even though it is

unknown what they refer to.

Take a look at some concrete examples. A Java Iterator<?> would be

written in Scala as:

Iterator[T] forSome { type T }

Read this from left to right. This is an Iterator of T’s for some type T. The

type T is unknown, and could be anything, but it is known to be ﬁxed for this

particular Iterator. Similarly, a Java Iterator<? extends Component>

would be viewed in Scala as:

Iterator[T] forSome { type T <: Component }

This is an Iterator of T, for some type T that is a subtype of Component. In

this case T is still unknown, but now it is sure to be a subtype of Component.

By the way, there is a shorter way to write these examples. If you write

Iterator[_], it means the same thing as Iterator[T] forSome { type T }.

This is placeholder syntax for existential types, and is similar in spirit to the

placeholder syntax for function literals that was described in Section 8.5. If

you use an underscore (_) in place of an expression, then Scala treats this as a

placeholder and makes a function literal for you. For types it works similarly.

If you use an underscore in place of a type, Scala makes an existential type

for you. Each underscore becomes one type parameter in a forSome clause,

so if you use two underscores in the same type, you will get the effect of a

forSome clause with two types in it.

You can also insert upper and lower bounds when using this placeholder

syntax. Simply add them to the underscore instead of in the forSome clause.

The type Iterator[_ <: Component] is the same as this one, which you

just saw:

Iterator[T] forSome { type T <: Component }

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

Section 29.3 Chapter 29 · Combining Scala and Java 604

Enough about the existential types themselves. How do you actually

use them? Well, in simple cases, you use an existential type just as if the

forSome were not there. Scala will check that the program is sound even

though the types and values in the forSome clause are unknown. For exam-

ple, suppose you had the following Java class:

// This is a Java class with wildcards

public class Wild {

Collection<?> contents() {

Collection<String> stuff = new Vector<String>();

stuff.add("a");

stuff.add("b");

stuff.add("see");

return stuff;

}

If you access this in Scala code you will see that it has an existential type:

scala> val contents = (new Wild).contents

contents: java.util.Collection[?0] forSome { type ?0 } =

[a, b, see]

If you want to ﬁnd out how many elements are in this collection, you can

simply ignore the existential part and call the size method as normal:

scala> contents.size()

res0: Int = 3

In more complicated cases, existential types can be more awkward, because

there is no way to name the existential type. For example, suppose you

wanted to create a mutable Scala set and initialize it with the elements of

contents:

import scala.collection.mutable.Set

val iter = (new Wild).contents.iterator

val set = Set.empty[???] // what type goes here?

while (iter.hasMore)

set += iter.next()

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

Section 29.3 Chapter 29 · Combining Scala and Java 605

A problem strikes on the third line. There is no way to name the type of

elements in the Java collection, so you cannot write down a satisfactory type

for set. To work around this kind of problem, here are two tricks you should

consider:

1. When passing an existential type into a method, move type parameters

from the forSome clause to type parameters of the method. Inside the

body of the method, you can use the type parameters to refer to the

types that were in the forSome clause.

2. Instead of returning an existential type from a method, return an object

that has abstract members for each of the types in the forSome clause.

(See Chapter 20 for information on abstract members.)

Using these two tricks together, the previous code can be written as follows:

import scala.collection.mutable.Set

import java.util.Collection

abstract class SetAndType {

type Elem

val set: Set[Elem]

}

def javaSet2ScalaSet[T](jset: Collection[T]): SetAndType = {

val sset = Set.empty[T] // now T can be named!

val iter = jset.iterator

while (iter.hasNext)

sset += iter.next()

return new SetAndType {

type Elem = T

val set = sset

}

You can see why Scala code normally does not use existential types. To do

anything sophisticated with them, you tend to convert them to use abstract

members. So you may as well use abstract members to begin with.

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

Section 29.4 Chapter 29 · Combining Scala and Java 606

29.4 Conclusion

Most of the time, you can ignore how Scala is implemented and simply write

and run your code. Sometimes it is nice to “look under the hood,” however,

so this chapter has gone into three aspects of Scala’s implementation on the

Java platform: what the translation looks like, how Scala and Java annota-

tions work together, and how Scala’s existential types let you access Java

wildcard types. These topics are important whenever you use Scala and Java

together.

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

Chapter 30

Actors and Concurrency

Sometimes it helps in designing a program to specify that things happen

independently, in parallel, concurrently. Java includes support for concur-

rency, and although this support is sufﬁcient, it turns out to be quite difﬁcult

to get right in practice as programs get larger and more complex. Scala aug-

ments Java’s native support by adding actors. Actors provide a concurrency

model that is easier to work with and can, therefore, help you avoid many of

the difﬁculties of using Java’s native concurrency model. This chapter will

show you the basics of how to use Scala’s actors library and provide an ex-

tended example that transforms the single-threaded circuit simulation code

of Chapter 18 into a multi-threaded version.

30.1 Trouble in paradise

The Java platform comes with a built-in threading model based on shared

data and locks. Each object is associated with a logical monitor, which can be

used to control multi-threaded access to data. To use this model, you decide

what data will be shared by multiple threads and mark as “synchronized”

sections of the code that access, or control access to, the shared data. The

Java runtime employs a locking mechanism to ensure that only one thread

at a time enters synchronized sections guarded by the same lock, thereby

enabling you to orchestrate multi-threaded access to the shared data.

Unfortunately, programmers have found it very difﬁcult to reliably build

robust multi-threaded applications using the shared data and locks model,

especially as applications grow in size and complexity. The problem is that

at each point in the program, you must reason about what data you are mod-

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

Section 30.2 Chapter 30 · Actors and Concurrency 608

ifying or accessing that might be modiﬁed or accessed by other threads, and

what locks are being held. At each method call, you must reason about what

locks it will try to hold, and convince yourself that it will not deadlock while

trying to obtain them. Compounding the problem, the locks you reason about

are not ﬁxed at compile time, because the program is free to create new locks

at run time as it progresses.

Making things worse, testing is not reliable with multi-threaded code.

Since threads are non-deterministic, you might successfully test a program

one thousand times, yet still the program could go wrong the ﬁrst time it

runs on a customer’s machine. With shared data and locks, you must get the

program correct through reason alone.

Moreover, you can’t solve the problem by over-synchronizing either. It

can be just as problematic to synchronize everything as it is to synchronize

nothing. The problem is that new lock operations remove possibilities for

race conditions, but simultaneously add possibilities for deadlocks. A correct

lock-using program must have neither race conditions nor deadlocks, so you

cannot play it safe by overdoing it in either direction.

Java 5 introduced java.util.concurrent, a library of concurrency

utilities that provides higher level abstractions for concurrent programming.

Using the concurrency utilities makes multi-threaded programming far less

error prone than rolling your own abstractions with Java’s low-level synchro-

nization primitives. Nevertheless, the concurrent utilities are also based on

the shared data and locks model, and as a result do not solve the fundamental

difﬁculties of using that model.

Scala’s actors library does address the fundamental problem by providing

an alternative, share-nothing, message-passing model that programmers tend

to ﬁnd much easier to reason about. Actors are a good ﬁrst tool of choice

when designing concurrent software, because they can help you avoid the

deadlocks and race conditions that are easy to fall into when using the shared

data and locks model.

30.2 Actors and message passing

An actor is a thread-like entity that has a mailbox for receiving messages.

To implement an actor, you subclass scala.actors.Actor and implement

the act method. An example is shown in Listing 30.1. This actor doesn’t do

anything with its mailbox. It just prints a message ﬁve times and quits.

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

Section 30.2 Chapter 30 · Actors and Concurrency 609

import scala.actors._

object SillyActor extends Actor {

def act() {

for (i <- 1 to 5) {

println("I'm acting!")

Thread.sleep(1000)

}

Listing 30.1 · A simple actor.

You start an actor by invoking its start method, similar to the way you

start a Java thread:

scala> SillyActor.start()

I'm acting!

res4: scala.actors.Actor = SillyActor$@1945696

scala> I'm acting!

I'm acting!

Notice that the “I’m acting!” output is interleaved with the Scala shell’s out-

put. This interleaving is due to the SillyActor actor running independently

from the thread running the shell. Actors run independently from each other,

too. For example, given this second actor:

import scala.actors._

object SeriousActor extends Actor {

def act() {

for (i <- 1 to 5) {

println("To be or not to be.")

Thread.sleep(1000)

}

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

Section 30.2 Chapter 30 · Actors and Concurrency 610

You could run two actors at the same time, like this:

scala> SillyActor.start(); SeriousActor.start()

res3: scala.actors.Actor = seriousActor$@1689405

scala> To be or not to be.

I'm acting!

To be or not to be.

I'm acting!

To be or not to be.

I'm acting!

To be or not to be.

I'm acting!

To be or not to be.

I'm acting!

You can also create an actor using a utility method named actor in object

scala.actors.Actor:

scala> import scala.actors.Actor._

scala> val seriousActor2 = actor {

for (i <- 1 to 5)

println("That is the question.")

Thread.sleep(1000)

}

scala> That is the question.

That is the question.

The val deﬁnition above creates an actor that executes the actions deﬁned in

the block following the actor method. The actor starts immediately when it

is deﬁned. There is no need to call a separate start method.

All well and good. You can create actors and they run independently.

How do they work together, though? How do they communicate without

using shared memory and locks? Actors communicate by sending each other

messages. You send a message by using the ! method, like this:

scala> SillyActor ! "hi there"

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index