Going Back And Forth From Javadoc and Scaladoc

I looked at the Akka framework while going through Venkat’s book. One things I did not like about Akka is that it does not take too long until you work with Scala APIs besides Akka. Many of them do not have javadocs. So you have to read scaladoc to use them. It is not that hard, but it just seems like every time I look at scaladoc I have to learn it from scratch again.

So in this post I will try to explain scaladoc for Java developers.

Look at the javadoc for the Akka class UntypedActor, and then the scaladoc for UntypedActor. In the javadoc, we can see that akka.actor.UntypedActor inherits from java.lang.Object. In Scala, it inherits from scala.Any, which seems to be the Scala equivalent of java.lang.Object.

The Java class implements the akka.actor.Actor interface. The Scala class implements from the trait akka.actor.Actor. I do not know how a trait is different from a class or an interface. In the scaladoc, Actor and Any are pointed out at the same place in the scaladoc. In the javadoc, the interface and the parent class are in different spots in the file.

The first method in the javadoc is getContext(), which returns an UntypedActorContext. The methods are in a table, and the return values are all on the left side of the table.

getContext is not the first method listed in the scaladoc. I do not know exactly what “Type Members” are. The getContext() method is listed in the “Concrete Value Members” section. The section for getContext() is listed like this:

The javadoc has this: 

The difference is that in scaladoc the return value is listed after the name of the function. I am not too clear what “def” means.

Let’s look at a method that takes an argument. Let’s look at “onReceive”. This method is abstract.

Here is the method in the javadoc:

Here is the method in the scaladoc:

I think that “Unit” in Scala is like returning void in Java. In both cases, the methods take a parameter named “message”. In the javadoc, we see the parameter’s type and then its name. In the scaladoc, we see the parameter’s name, and then its type.

Lastly, I will look at a method that takes a couple of parameters for review. The method is preRestart().

Here is the method in javadoc:

Here is the method in scaladoc:

Every time I mention Scala on this blog, I mention that I do not like it. I thought I should mention it in this post just for consistency.

What To Do With Myself

I am not clear what I should use my free time doing. Right now I am still going through the Struts 2 tutorials, and I am also upgrading a few web apps that I made a few years ago.

I tried to recompile an old app with Maven, and it took a long time because I had to track down the latest versions of all the dependencies. I am also struggling with testing it as well. I am having a hard time setting things up so that the tests hit a different database than the “production” app. I could just edit the hibernate.cfg.xml file in src/main/resources, but I would prefer to do things the “right” way.

I tried using src/test/resources/hibernate.cfg.xml, but that did not work. I know that editing the prod file is not quite correct, but I figure I could spend more time trying to work on that, or I could write some tests.

It is a bit frustrating that there are  a LOT of sample apps that do not have tests included, and also do not have test configurations as well.

I know some people say that tests should never touch the database, but personally I think that is kind of dumb. All this app does is change the database. I am not against mocking and stubbing, and if you are calling external services you need it. But I do not understand the stance that some fundamentalists take that your tests should NEVER touch the database. Changing databases is what a lot of applications do. If all you are doing is using mocks, then you are not testing your app. You are testing some artificial thing that is not really your app.

Maven Notes

Here are some Maven notes.

To use properties in your pom.xml file:

First, define the property:

Here is how to use it in a file:

To run a specific class:

To run a specific test file:

To run a specific test in that file:

I will update these notes as I learn more.



Spock Notes

I have started using the Groovy testing framework called Spock.

It looks like a nice testing framework, but it also seems a bit disorganized. The code is on github, but the main site seems to be on Google Code. They are working on some new documentation, which is incomplete, but has a link to some old documentation. On the old Google Code site, Spock Basics and Getting Started are good places to get started. Someone on the mailing list referred me to some javadocs, some groovydocs, and another set of javadocs. I am not too clear why there are two sets of javadocs. Someday I will get the code from github, and see what I can build  myself.

First off, I am not much of a Spock expert. I know I am not using all of the things Spock has to offer. I started porting a DNS server from Java to Groovy, and I decided to start by porting the tests from Java to Groovy. (At this point, very little of the actual server code has been ported. After seeing a lot of byte arrays in the tests, I wonder if writing a DNS server in Groovy is a good idea.) The tests were in JUnit, and after porting them to Groovy, I decided to port them to Spock.

You can find my Groovy Spock tests at the DNS Groovy project here. I have both Spock and JUnit tests in that directory.

I ported the JUnit tests to Spock tests. I extended a couple of classes. I extended org.spockframework.util.ObjectUtil as MyGroovyUtil, and org.spockframework.util.Assert as MyGroovyAssert. I add them to the tests like this:

The classes that I am extending are abstract. But after extending, I was able to use their methods. Here are a few examples of the methods I used and how I used them to port the test from JUnit:
  • assertEquals becomes mgu.equals
  • assertNull(XXX) becomes mgu.equals(null, XXX)
  • assertTrue becomes mga.assertTrue
  • assertFalse(x == y) becomes mga.that( x != y)
  • assertFalse(XX.YY) becomes mga.that(!XX.YY)
  • assertNotSame(m_h, h2) becomes !mgu.equals(m_h, h2)
  • assertSame(x, y) becomes mgu.equals(x, y)


I took some code by Venkat S to test the java.util.concurrent.locks interface. I tried porting them from JUnit to Spock, but I was not able to get some of them to work with Spock. Perhaps I will try again in the future. You can find the original JUnit tests in this directory, and my attempts at porting them to Spock are in this directory. Venkat’s code is in this directory. He has a method that adds some values to a map, and he refactors it so that the actual update is in a method called by the put method between the locking and unlocking.


Image from World Digital Library, assumed allowed under Fair Use. Image from the Ashburnham Pentateuch, or Tours Pentateuch, a Latin manuscript of the first five books of the Old Testament from the 6th century or 7th century. Its place of origin is unknown.


Thoughts On Groovy and Grails

I have been going to the Austin Groovy and Grails group. It seems like Groovy is gaining some momentum. It was gaining some momentum, and then for a couple of years it lost some steam, but now it’s coming back.

I have heard some rumbles that Java shops have gone with Rails since they not find some Grails devs. I wonder if there is anything to these anecdotes. It seems like it would be cheaper for Java devs to learn Grails than Rails. If you go with Rails, not only do you have to learn a new language, but a whole new ecosystem.

I have also heard from a lot of people whose companies are using JRuby. These companies have a huge investment in Java code, and they do not want to throw that away, but they want a more dynamic, agile language that is more amenable to TDD. Which makes me wonder why they did not choose Grails. The reasons they go with JRuby is the whole reason Groovy and Grails were invented.

I have worked with JRuby, and frankly it is more trouble than it is worth. There was a presentation about it recently at Austin on Rails, and the speaker showed a slide with some JRuby code. He said, “This code looks odd to a Java developer. It also looks odd to a Ruby developer.” I thought to myself that is a good reason to not use JRuby. Outside of Ruboto, I think JRuby is a solution looking for a problem.

Another issue with JRuby is you lose the ability to use all the gems written in C. There goes a lot of the power of Ruby.

One reason people give for going to JRuby is that the JVM handles concurrency better than MRI. That is true, but for me that does not change the fact that Groovy is easier to work with on the JVM is than Ruby since that is the environment that it was built for. I just do not find JRuby as easy to work with as MRI Ruby or Groovy/Grails. The whole point of Ruby was to be easier for developers, and I think JRuby takes that away. If MRI has a weakness, then fix it, or just drop Ruby entirely. Don’t try to fit a square peg into a round hole just so you can still tell yourself you’re a Ruby developer. It’s just not worth it in my opinion.

I think that if Elixir can get off the ground, then a lot of Ruby developers will go with that. I am not an Erlang developer, so for all I know Elixir may be another square peg/round hole issue.

Done With Venkat S’s Book

I am finally all through Programming Concurrency on the JVM by Venkat Subramaniam.

I am looking at some code he wrote to test classes in the java.util.concurrent.lock package. I might go through that.

I have a feeling that a lot of what I went through might be obsolete soon. There was a lot of code that could be done more concisely with lambdas, which are coming soon in Java 8. I think you might be able to do extend the ReadWriteLock class and have it take some code that you want to make thread-safe. In one of the times I saw him, he said that locks take care of any issues you would have with the synchronized keyword.

The problem is that you really need to use try/catch/finally blocks, and you should use the tryLock() method, and use a timeout. It can be a lot of code.  You might want to change one variable, but instead of having one line in your setter, you might need about 6. But if you could send that one line to a LockLambda (or whatever you want to call it), it would be better. You might need two, which granted is still more than one, but the LockLambda could handle all the try/catch/finally/get the lock/set the timeout/release the lock work for you, and you might be able to re-use the same LockLambda class.

I might blog about Akka, although I am not too thrilled with it. I do not like Scala, and some of the Akka APIs call Scala APIs. I liked GPars better. Although there were some things in GPars that are not worth the effort to use in Java, you can pretty much use just the GPars APIs. You do not need to look at any Groovy if you do not want to. I think some things I did not like with Akka will be easier once lambdas come out. But I still do not like Scala.

I may still look at the Play Framework.


2013-07-14 Concurrency Update

I have been going through Venkat’s book, but I think I might bail on going any further.

The book came out in 2011, and there have been a LOT of changes to Akka in that time. They stopped using Multiverse for STM, and started using ScalaSTM. There were a lot of changes from version 1 to version 2 (starting actor systems, creating actors, sending messages, pretty much everything). There was a change in the API as I was going through the book.

Some of the method calls require inline Runnables or Callables, and that gets kind of awkward. I think I will move on to other things and come back when there is another edition of the book. Or I might wait until Java 8 comes out. I think the closures will make things easier.

Plus, since Akka is written in Scala, a lot of things are unwieldy in Java. I really do not like Scala. It has the syntactical elegance of Perl, with the simplicity and focus of C++. It is like religion or cigarettes: Its advocates tell me that if I gave it a chance I would see how wonderful it is. I did, and it’s not.

That said, I have no issue with the idea of using something written in Scala. I might take a look at the Play Framework. That is not as odd as it seems. I do not like working with C code. But a LOT of important stuff is written in C: The JVM, MRI, databases, the Linux kernel. If I refused to work with anything written in C, I would need to find a new line of work.

One language I think I will take a closer look at is Clojure. At first I was skeptical about it: It’s just another Lisp, and Lisp has never caught on, so why bother? But I have kept an eye on it, and I think this might be The Lisp That Sticks.

Plus, I have noticed something interesting about Lisp. A lot of people will start out developing in one language, and then they will become dissatisfied, and move to another. And then another. And then another. But it seems like when people find Lisp, they stop moving around. They seem to find what they are looking for.

In the next few months there are some Clojure meetups that will go over some Clojure web frameworks. I might look at them before that.

When Ken Kousen was here for the Groovy meetup, he said that he had a boss who kept saying, “Oh, we could do that in Lisp 20 years ago.” He thought it was really annoying. He said it was more annoying when he realized his boss was right.

Image from the Rheinau Psalter, a 13th century manuscript housed at Central Library of Zurich. Image from e-Codices. This image is assumed to be allowed under Fair Use.

Upcoming Meetups

There are a couple of user group meetups this week that I had a part in organizing.

On Tuesday, Roger Brinkley, the host of the Java Spotlight podcast, will speak at Austin JUG. He has spoken at CJUG a few times. I put him in touch with the leader of the Austin JUG. I did not know that Roger would be in San Antonio this week. So it was a pretty nice coincidence that he happened to be in Texas this week.

Then on Thursday, Ken Kousen will speak at the Austin Groovy and Grails group. I am on the list for the Houston JUG. He spoke there a few months ago. I went to his website, and he was going to speak in Houston and Dallas in the same week. I just emailed him out of the blue, and I told him there is a Groovy/Grails group in Austin. I told him he should speak in Austin someday. He emailed me back, and said it was not possible at that time, but he would like to do it someday. I put him in touch with the organizers, and he will be here on Thursday.

Concurrency Without Pain in Pure Java

Here are the notes I took when Venkat Subramaniam was here for Austin JUG. I will mostly present them as I typed them.

Why Concurrency? Why do we care?

We now have mutli-core processors. Things that work well on one core may not work well on multiple cores.

The Java memory model controls how info goes back and forth from main memory and working memory.

His arguments in his classes are all final.

In the account class. Should the getBalance() be synchronized?

“synchronized” gets a lock and crosses the memory barrier, working and main memory.

Accessing a volatile variable, wait, join, a few other calls where you cross the memory barrier. We could compromise the invariant, like during a constructor.

So if you do not make getBalance synchronized, you might get an old value.

The code could have deadlock, or livelock (you wait, but nothing waits for you).

When you call synchronized, you might wait forever. There is no time out. So you use the Lock interface.

So for ReentrantLock you could call tryLock, or throw the Exception, then you have to unlock it.

You can order the accounts by ID to removed threat of dead lock.

95% of Java code is broken for concurrency. (Is he including code for Groovy, Scala, Clojure?)

Synchronize and suffer model.

Solutions: Software Transactional Memory (from Clojure) and Actors (Scala)

STM: We modify a variable (data) in our code. Shared mutability is bad. A few solutions: Avoid mutability. STM says let’s have a special type of variable: Managed mutable variable. It will only change in certain circumstances: a transaction.

Identity: Values are immutable. The stock price at 1:00 is different than at 1:10. But the 1:00 price will never change.

The identity is “google stock price”, points to a different value at different times.

We must protect the identity.

The problem in Java is that many times the problems happen without warning or error message. In STM, you get an error message.

This changes it in a transaction. If there are conflicts, the transaction is aborted and retried. Up to 100,000 times.

Can we do it in Java? He used ref and dosync, so can we use them in Java?

clojure.lang.Ref. Look at his code, see what class he uses for Ref.

The set method will use Lambda expression in Java 8. For now, we could do a Callable. LockingTransaction.runInTransaction

He is using an inline Callable.call()

What if you try to put more in the to account than is the from amount? It will throw an exception.

When to use STM? When you have multiple readers, multiple writers, and infrequent write collision. Not too many things are good for high-write collision.

You should not modify unmanaged variables in a transaction. Do not write to a file, print out messages, do not send email.

What about a long-running task

Another solution to shared mutability: isolated mutability.

Problem with encapsulation: Many threads can call the methods that change your private variables.

It is like voice mail: Many people can leave him a message, he gets a lot of messages, he goes through them one at a time. Actors have built-in message queue. Asynchronous messages.

The Actor runs on a separate thread.

When do actors make sense?

The fields are immutable. The messages are not, so they should be immutable.

You can have variables in an Actor, since only one thread will touch an Actor.

When does Actor make sense: Single threaded tasks sequentially

It punishes readers as much as writers. In STM, readers are never blocked. Writers are punished.

Purpose of Actor is not to deal with shared mutability, you want to prevent concurrent access, you want to serialize.

New concurrency API in Java 8.

You need Java 8 with Lambdas.

Look at java.util.streams.*

:: is a method reference

can be done as

Java is getting more functional

Synchronize and shared mutability can be avoided

JDK 5 concurrency is the assembly code of concurrency

Image from the Rheinau Psalter, a 13th century manuscript housed at Central Library of Zurich. Image from e-Codices. This image is assumed to be allowed under Fair Use.


Still Going Through Venkat’s Book

I am still going through Venkat S’s book.

I had gotten through the chapter on STM. A lot of the examples for STM dealt with some old versions of APIs. The first time I just read through them pretty slowly. I was able to follow. But then I did a bit more googling, and I was able to find later versions of the STM libraries he was using.

I had already started the chapter on actors. I decided to go back and work on the STM examples. It is taking a bit of time.

Image from  Aurora Consurgens, a 15th century manuscript housed at Central Library of Zurich. Image from e-Codices. This image is assumed to be allowed under Fair Use.