Java Tools For Healthy Code

12. August, 2011

While any good developer makes sure that his code is healthy all the time *cough*, tools can be a lot of help.

Venkatt Guhesan has compiled a list of 11 tools that you should know about.

Tools To Analyze Java hs_err Files

28. July, 2011

Java crash dumps contain lots of valuable information but one thing is missing: The versions of the libraries installed.

I’ve started a new project on github to gather this info from a hs_err_pid file: Java-hs_err_pid-List-Library-Versions

Currently, only Debian is supported.



Taming Java GC

14. July, 2011

Taming the Java garbage collector (GC) is still one of the most mysterious areas of the Java VM. Aleksey Ragozin has published an excellent series of articles about the topic. Here are my favorites:

Restarting a Java App

9. July, 2011

Leo Lewis posted some code to restart a Java app.

Java Finalizer Exploit

6. July, 2011

Did you know that your Java code may be vulnerable to an exploit based on finalization? I didn’t.

This article from IBM’s developerWorks explains how it works.

Basically, you can safe a reference to an object in the finalize() method. At this time, the object may even be in an inconsistent state (the finalizer will be called when the constructor threw an exception).

As for the solution: I don’t like it very much. It adds even more clutter to the existing code and doesn’t relay its purpose very well. Someone refactoring the code might feel tempted to remove the “useless additional constructor.” Worse, you need to do this in all your classes which check their parameters.

I would prefer a solution where the compiler or some other tool fixes these issues by generating the necessary code. Especially if you look at more complex cases: What happens if an exception is thrown at a later stage of object creation? Your code is still vulnerable but it seems to be safe. How would you know?

Maybe a better solution would be to check the heap for references to any finalized objects and throw an error “finalization failed”. But that’s probably impossible without breaking backwards compatibility.

Or Oracle could invent a better solution for the finalization problem (which is basically garbage collection for non-memory-resources) so we would not need finalizers anymore.

UI Editor With Preview

28. June, 2011

One of the big problems with WYSIWYG editors is that they don’t really cut it. They look good in the beginning but as your experience grows, the editor tends to get in your way of getting things done.

Stackoverflow used an interesting solution: There is a wiki markup editor and a preview which is updated as you type. So you get the best of both worlds: You can see your intention and the result at the same time.

Riena is now following along the same path: They created a preview which updates when you save your UI code. That way, you can quickly see the effect of your changes without stumbling over tedious property editors all the time.

Jazoon 2011, Day 2 – Compositional CRUD: A novel approach for doing CRUD in Enterprise/SOA Environments – Rene Mas and Thipor Kong

26. June, 2011

Compositional CRUD: A novel approach for doing CRUD in Enterprise/SOA Environments – Rene Mas and Thipor Kong

One of the advantages of CRUD is that each operation is simple to understand and implement. Every developer knows thatdependencies are bad. The disadvantage is that the operations are so simple. If you need something more complex, you have to execute many of them and this can get complex in its own right. Worse, the usual CRUD APIs only allow to execute the operations individually.

The idea behind Compositional CRUD is to be able to build arbitrarily complex commands from simple CRUD operations. All of them can be executed as a single operation (within one transaction, for example). This applies the ideas of the command patternand Promise Pipelining.

Seems like such an obvious idea, it’s probably already patented …

Jazoon 2011, Day 2 – JavaFX 2.0 With Alternative Languages – Groovy, Clojure, Scala, Fantom, and Visage – Stephen Chin

26. June, 2011

JavaFX 2.0 With Alternative Languages – Groovy, Clojure, Scala, Fantom, and Visage – Stephen Chin

Stephen showed how to use JavaFX 2.0 with other programming languages like Groovy or Scala. This is possible because the next version of JavaFX has a pure Java API for everything.

It was nice to see how well Groovy and Scala fared versus JavaFX itself. Even a dedicated Xtext-based DSL might not yield much better results.


Jazoon 2011, Day 2 – Java Concurrent Animated – Victor Grazi

26. June, 2011

Java Concurrent Animated – Victor Grazi

One picture says more than a thousand words. Now imagine what an animation can say. Victor did several for us to better understand the classes in java.util.concurrent. You can find the software on sourceforge: javaconcurrenta

Here is an example:

Very nice. I know a lot about threads and concurrency (the Amiga had preemptive multitasking back in 1986) but even I was surprised by the ReentrantReadWriteLock example: If you have a writer waiting for the lock and another reader comes along, should it get the lock immediately or should it wait for the writer to complete?

My first instinct was to get all the (quick) readers out of the way but chances are that, when all readers have been processed, another one might have come along, effectively starving the writer.


Jazoon 2011, Day 2 – NoSQL – Schemaless Data-stores Not Only for the Cloud – Thomas Schank

26. June, 2011

NoSQL – Schemaless Data-stores Not Only for the Cloud – Thomas Schank

Thomas gave an overview of some NoSQL databases and the theoretical background of it.

The main points are: SQL databases get inefficient as the data grows and if you need to split the data between instances (how do you join tables between two DB servers? Even if you can, performance is going to suffer).

But there are new problems: Data can be inconsistent for a while (keyword: MVCC).

OTOH, these databases don’t need locks and, as Amazon demonstrated, any kind of lock will eventually become a bottleneck:

Each node in a system should be able to make decisions purely based on local state. If you need to do something under high load with failures occurring and you need to reach agreement, you’re lost. If you’re concerned about scalability, any algorithm that forces you to run agreement will eventually become your bottleneck. Take that as a given.

Werner Vogels, Amazon CTO and Vice President

And since the servers can heal inconsistencies, broken connections don’t mean the end of the world. The acronym of the hour is BASE: Basically Available, Soft-state, Eventually consistent.

Interesting stuff, especially since every company owns a super-computer today. My own team has one with 64 cores, 64GB of RAM and 16TB of disk space sitting in 8 boxes spread under the desks of the developers. Not much but it only costs $8 000. And if we need more, we can simply buy another node. Unfortunately, it’s hard to leverage this power. I’ll come back to that in a later post.

One thing to take with you: If you can’t stand JavaScript but you need to write it, have a look at CoffeeScript.


%d bloggers like this: