Category Archives: Programming

Java Tip #1: foreach with index

When you are working with Java some hours each day, you soon develop an own programming style and collect some ideas how to make your code nicer. From time to time, I’ll present some of my most favorite ideas here.

Today, let’s look at the foreach loop. I guess, you often use code like this:

for (int i = 0; i < list.size(); i++) {
  Element e = list.get(i);

Not really nice, is it? As Java programmers we are used to read and understand such code quickly, but there must be a better way, since what we want to say is only “For each element of the list…”. But hey, we have the foreach loop since Java 5:

for (Element e : list) {

Very nice, isn’t it? Unfortunately we have lost the index of the current element now, which was stored in the variable i before. For this, I’m using two solutions. The first one is using a custom iterator, which I will explain in a later Java Tip. The second one is using an index together with foreach, that runs over a Range (use import static of the Range.range method):

for (int i : range(list)) {
  Element e = list.get(i);

Though we do not get a one-liner, we get rid of the increment at least. The Range class is also very useful for other cases, for example when counting from 1 to 10:

for (int i : range(1, 10)) {

Downloads: Range

Clojure Concurrency

For a seminar at university I had to write about parallel programming on the JVM with Clojure. Because I am new to Clojure and did not believe all the euphoric statements about Clojure, I did not only prepare a paper and presentation slides, but also a little demo application called Clojure Sheep.

Clojure Sheep is actually based on Rich Hickey’s ant simulation he presented in his Clojure Concurrency talk, but I removed some logic to concentrate more on the concurrency features and to make it easier to also create a version written in Java. My experiences:

  • It’s quite easy to write the code in Clojure (I have to admit of course, that I had the ants source, which made it even easier ;)). You can fully concentrate on the application logic and don’t have to worry about locking. Instead, you are forced to use transactions at the right places.
  • But instead of thinking about locks, you have to think about for which data you want to use which concurrency primitives. For example, if I had used a single ref for the whole 2d vector of cells (instead of using a ref for each cell), this would probably decrease performance a lot.
  • The Java version was much harder to implement. I could not find a good locking strategy that guarantees maximum thoughput but still doesn’t worry me. So, to make the code as easy as in Clojure, I decided to use a global lock for everything. Of course, this destroys performance! (If you have better ideas, tell me. I already got some ideas from the Clojure mailgroup).
  • When testing on a quadcore machine with 1000×1000 cells and 1000 sheep, the Clojure solution performed about 50 times faster (!) than the Java implementation. This is not surprising given the bad locking strategy I have chosen – but it is cool when you think about the programming complexity of both solutions, which are about the same.

Overall, these results encourage me to try out Clojure for Zong! now. I think, I’ll begin to port some of the core code (basic data structures) to Clojure. Because of the immutable and persistent structures, this could already solve our tremendous open problem how to realize undo/redo in a fast and memory-saving way.

Modularizing Zong!

Project Jigsaw is one of the most important features of JDK 7: Instead of a huge monolithic package the JDK will consist of smaller moduls, that can be loaded on demand and can thus decrease the download size, startup time and memory footprint. I thought that this is a good idea, and it should be applied to Zong! too:

splitproject

Of course Zong! is way smaller than the JDK, but with now more than 50.000 lines of code it is quite complex already (and there is much more to come, I guess we will need more than 150.000 lines of code for all planned features). But I see two advantages in modularization:

  1. A programmer is forced to write cleaner code, that doesn’t have dependencies between arbitrary packages. For example, the util package can not use classes from the viewer package and is thus easier to test and to share with other projects. Of course, these dependencies were avoided before too (at least more or less. It really took me some time to remove the few ones, and I must say, this was really dirty code before!), but now there is a technical barrier that forbids them.
  2. The sources, which will be free software, are strictly separated from our proprietary code. This is a very important step for releasing them to the public soon (already this winter!).

Intonation Ear Training

As the conductor of a bavarian brass band I often have to intonate the different instruments in the orchestra. Because I found no website or free program where you can practice your intonation hearing I decided to write a little applet:

Intonation Ear Training Applet

Have fun practicing 🙂

Because I’m getting more familiar to Clojure and like the language very much, I decided to write it in this language. It worked quite well despite of some teething troubles which Clojure still has. Because of that I’ve written a little tutorial how to create applets, and I hope it will encourage more developers in giving it a try.

Experimenting with Clojure

In former days, Visual Basic 6 was the language of my choice. A lot of people tried to convince me that VB is crap and I should learn a “real” language like C++. Nevertheless, I was happy with VB and even built some nice stuff with it.

Later, when I switched from Windows to Linux, I was looking for a new language and found Java. I like Java still very much, and it is great to write and compile code only one time and it runs on all platforms (at least in theory. Bolzplatz 2006 was more complex, but anyway it was a good decision to choose Java). But when you become a more experienced developer, you soon notice that Java has several severe limitations (the project where I encountered these problems in particular was CUP2, a parser generator for Java, which was the topic of my Bachelor’s Thesis. There, I had lots of “fun” with reflection and such things).

Some days ago I read Paul Graham’s article called Beating the Averages, which I really recommend reading. He states, that every programmer is happy with his favourite language and is more or less restricted in his thinking. This prevents him from switching to the really most powerful language (which is, as he thinks, LISP).

For already two years I am trying to learn LISP, so far without success (mostly because lack of time). This week I took the time and started some experiments with Clojure, a modern LISP for the JVM. My goal was to replace the Java-SLE-solver of the slur layout engine by Clojure code.

My experiences so far:

  • Clojure is not very easy to understand for a programmer that only worked with imperative languages before
  • Anyway it is possible to learn the basics quite fast, that means, using the features without exactly knowing why or how it works
  • Clojure opens up a new dimension of programming. LISP as a “programmable programming language” allows you to do things that you will never be able to do in Java (for example, please don’t wait for Sun until they finally add closures to Java. They won’t do it ever, I guess).

Actually, I could finish my Gauß-solver, and I like the code. However, since I am a newbie in functional programming, I guess there are lots of things I could optimize. My Java solution needed 300 ms for solving 1.000.000 3×3 SLEs, but my Clojure version needs 33 seconds (ouch!). Here is the code – if you have any suggestions, please tell me 😉

This experiment has encouraged me to gain more experience in LISP now, perhaps we can use some Clojure code in Zong! in the future (it integrates nearly seamlessly into Java!). If not, LISP will at least make me a better programmer.