Scala is an interesting language - it’s JVM based and compiled down to its Java equivalent. This gives it the ability to work directly with Java libraries. As it currently stands, there are quite a few libraries that are available under the Scala platform, but using the Java based libraries can be less than optimal.

For example, when using the Twitter4j library to send a tweet, you have to perform all of the setup rituals as you would in Java. An example of this is as follows:

[java] val twitterClient: Twitter = new TwitterFactory(TwitterScanner.buildFromConfig().build()).getInstance() val creds = twitterClient.verifyCredentials() twitterClient.updateStatus(“Test”) [/java]

Ok, that was a little deceptive, as that the TwitterClient provides a means to get a singleton and it ingests the credentials via the properties. However, for most cases where the user credentials, the singleton won’t be used. How would this be different if the library was Scalafied?

I would propose that the class would be modified to allow for the following:

[scala]

Twitter.updateSatus(“This is a message”)

[/scala]

How is this possible? Assuming that the Twitter client connection was already defined in the scope, tt’s possible due to implicit parameters. Implicit parameters are an extension of a function to bring outside context into a function. They can behave in the same way that a class bringing in contextual data into a constructor and producing a context dependent class. (This is similar to asking for the connection string and credentials for a class that is responsible for dealing with a database).

The definition for the class as defined would be the following:

[scala] Object Twitter { def updateStatus(val message: String)(implicit val twitterConnectionRequest : TwitterClient) : Int = { …. } } [/scala]

Ultimately, the functionality will be the same, but the end result is that the code is easier to read, and you’ll be able to focus on functionality versus setup. How does this work? The second set of parameters allows for the isolation/grouping of parameters. Since all of the parameters in the second set are implicit, Scala allows for the use of the method without the second set. Additionally Scala matches the implicit values from the scope of where the method is being called.

For example the following Java code for dealing with a VMware like environment:

[java] public class MajorUtility { public String cloneVMAndStartSync(String vmIdToClone, VMWareClient vmc) { String result = “”; VMWareMachine vmw = vmc.getVM(vmIdToClone); if (vmw != null) { vmc.stop(); VMWareMachine newMachine = vmc.clone(); while (!newMachine.isReady()) { Thread.sleep(1000); } result = newMachine.getId(); } return result; } } [/java]

Would become:

[scala] object MajorUtility { def cloneVMAndStartSync(vmIdToClone: String)(implicit val vmWareClient: VMWareClient): Optional[String] = { var result: String = Future[String] => { “” } val vmw: VMWare = getVM(vmIdToClone) if (vmw.isPresent) { stopVm() result = cloneVM(vmIdToClone).onSuccess { case value => value.getId } } result.get() } } [/scala]

The major difference between the two is examples are the following:

  1. All of the functional calls to work with the VMware server are implicitly sent into the function.

  2. The functions called are statically imported. (Via object classes in Scala)

  3. The cloneVM Method returns a Future object rather than a state. If the state fails, then the future returns a “onFailure” callback. (Which you can handle, but that’s beyond the scope of this article.)

  4. The value of getting the ID is changed in the future. This means that this operation is kicked off and the value is to be retrieved later.

  5. The code is a bit easier to understand as that the cloneVm operation would return immediately and it would put the processing in the background.

  6. The use of Optional simplifies the null check. (This is the case in the return statement and in the return variable.)

From here, the equivalence of the Java libraries to Scala bring added benefits. It gives the possibility for the code to be more readable, easier to write, and allows for the developer to focus on the functionality needed.