Java control flow exercises
I came upon an interesting blog post about Java control flow. The author listed six examples (from LASER 2009 summer school on Software Testing) of pseudo Java code, and you have to determine what the value of the int b is, as well as whether an Exception is thrown or not. You can assume the program will execute with proper syntax, and proper throws Exception on the method signature.
Here are my answers, and explanations. The actual answers will be posted in the author’s next blog entry.
1. What is the value of b at the end of this code:
foo () {
int b = 1;
b++;
}
My answer: b is 2
2. What is the value of b at the end of this code:
foo () {
int b = 1;
while (true) {
b++;
break;
}
}
My answer: b is 2 because it gets incremented one first iteration of the while loop, then the loop breaks.
3. What is the value of b at the end of this code and tell us if this executes normally or with an exception:
foo () {
int b = 1;
try {
throw new Exception();
}
finally {
b++;
}
}
My answer: The exception is thrown, and then b is incremented to 2. And since the exception in not caught, it is thrown from the method.
4. What is the value of b at the end of this code and tell us if this executes normally or with an exception:
foo () {
int b = 1;
while (true) {
try {
b++;
throw new Exception();
}
finally {
b++;
break;
}
}
b++;
}
My answer: b is incremented in the try block, then exception is thrown. In the finally block, b is incremented again, then a static return from break brings control flow to the end of the method where b is once again incremented, and no exception is thrown from the method. So, b is 4 at the end, and no exception is thrown… in fact, you don’t even need a throws Exception in the method signature because this method cannot throw Exception.
5. The previous sample was too long, what does this return:
int foo () {
try {
return 1;
}
finally {
return 2;
}
}
My answer: the return 2 is the last statement executed in the method, so it returns 2.
6. If you have answered properly to the above questions, then you are definitely quite an expert. To prove it, tell us the value of b at the end of the call as well as the return value:
int b;
int foo () {
b = 0;
try {
b++;
return b;
}
finally {
b++;
}
}
My answer: b is incremented in the try block, then returned; return value is 1 from the method. Then the finally block executes and increments b, so it is 2 at the end (but return value is still 1).
I think that made sense. Nes pas?
Programming Language Trends (Java==Cobol?)
I ran some queries through Google Insights, just for fun. One of the queries I ran was python vs. java vs. ruby vs. erlang vs. cobol, under the Programming category. Here’s the resulting graph of growth relative to category.

Ignore the dark blue line, it’s a plot of the Programming category (which is actually sliding.. hmm).
Seems like Erlang and Ruby have generated a lot of interests over the last three years, with 242% and 124% growth in interest since January, 2004. Python has remained rather steady, losing 5%. Java on the other hand has dropped quite significantly, at -53% growth since January 2004. And Cobol is way down at -62%.
It gets more interesting when you view the interest by region. The most interesting data I think is that Java and Cobol are both pretty cold world-wide except for one region: India. Take a look at these regional maps.
Search volume for Java:

Search volume for Cobol:

My guess is that a lot of companies now out-source Java and Cobol projects to India. They are both languages that people need to continue to support, probably for legacy systems, but just aren’t fun and definitely kills innovation. As Brett McLaughlin (author of several O’Reilly Java books) said, Java isn’t unimportant, but it’s big business in many cases, and that tends to suck experimentation and fun out in sneaky ways.
A few more (completely useless?) things to note:
- Russia loves Erlang.
- Ruby is obviously hot in Japan, but also in Belarus (who whudda thunk it).
- Python and Ruby are gaining traction in the US, but Canada is lagging still (c’mon Canucks!).
- Japan is pretty lukewarm to Python, and it has a pretty high search volume index for Cobol compared to most every other country.
Java Is Just Too Slow
Java is slow. And by slow I don’t mean it’s execution speed. I’m talking about development speed.
Java forces you to plan too much. Don’t get me wrong, there’s nothing inherently bad about planning. The problem is that innovation and planning don’t always go hand-in-hand. When you’re making yet another boring spreadsheet application that’s been done a million times before, you can plan out exactly what needs to be done before writing code because you know exactly what you need However, when you’re innovating you need to code as you go. Your ideas may just work, it might need some tweaking, or it may turn out to be horrible. The point is, you won’t know until you start hacking away at the code.
Java is so verbose that in order to really work with it you need to plan ahead. You need to know what Objects you need to create, what methods and variables (private or public?) it should have, and how they need to interact with each other. Oh, and after all that you need to compile your code before seeing the result. As a simple demonstration of this, let’s work with a JSON object in Java (using Gson), then in Python (using simplejson).
Let’s use the following JSON object:
{
'foo': {
'bar': 10,
'baz': 20
},
'phrase': 'Hello World!',
'myArray': [1, 2, 3, 4, 5]
}
Let’s access some data in Java. Wait, first we need to create some Objects to deserialize the JSON string to.
class MyObj1 {
private int bar;
private int baz;
MyObj1() {}
}
class MyObj2 {
private MyObj1 foo;
private String phrase;
private int[] myArray;
MyObj2() {}
}
Now we can deserialize the JSON string and get some properties from it.
String json = "{'foo': {'bar': 10, 'baz': 20}," +
"'phrase': 'Hello World!'," +
"'myArray': [1, 2, 3, 4, 5]}";
MyObj2 json = gson.fromJson(json, MyObj2 .class);
system.out.println(json.foo.bar); //--> 10
system.out.println(json.phrase); //--> Hello World!
system.out.println(json.myArray[1]); //--> 2
Now let’s try the same thing in Python.
import simplejson
json = simplejson.loads('{"foo": {"bar": 10,' +
'"baz": 20}, "phrase": "Hello World!",' +
'"myArray": [1, 2, 3, 4, 5]}')
print(json['foo']['bar']) #--> 10
print(json['phrase']) #-> Hello World!
print(json['myArray'][1]) #--> 2
By the way, the above python code is 100% executable using the interactive shell assuming simplejson is installed (easy_install simple-json). The Java code will need some main method with whatever else, I just didn’t bother – usually my IDE at work writes all the skeleton code for me.
So which do you think is simpler? If you knew you’ll be dealing with a lot of JSON would you go with Python or Java? Another thing to keep in mind is that if I change the JSON string, the Python code would require virtually no effort, whereas the Java code will need class changes, recompiling, etc. Not to mention if I changed the array to something like ["I'm a string", 1234, {"a": 1, "b": 2}, 3, 4, 5]. Sure you can do it in Java, but WHY? You can probably see why Java developers are forced into so many hour-long planning meetings. If you get the wrong the first time you really pay the price.
To be successful on the Web you need a platform that allows you to be innovative. Traditionally, software development involves a long period of planning before any code is written. You go through iterations of UML diagrams before typing a sinlge line of code. This just won’t cut it on the Web.
Traditional software is like cartoon drawing. You usually start with some storyboard sketches of the overall story. This gives the artists a way to previsualize the motion graphic before starting on the real thing. Web applications, on the other hand, is more like a bunch of sketches that are never quite finished. That is, web applications are always evolving, and this evolution happens in smaller steps, and more frequently. You need a language that can allow you to take these smaller steps, and I don’t believe Java is the right tool for this.