2006-09-22
volatile is the new synchronized
Bill Pugh and folks have done an outstanding job to clarify and simplify Java's memory model. And they have done a great job to get the word out and raise awareness for the issues. Yet what can happen is that people have now gotten nervous about safe publishing and visibility and start sprinkling volatile pixie dust. Reminds me of the generous application of "synchronized" when one wasn't quite sure ...
2006-09-21
Issues of an aging star
Three bug reports (36541, 37356, 38713), some observations: Tomcat is full of clever(TM) and buggy concurrency code. Even experienced maintainers may not know how the memory model works. On a popular project, the more stupid people you're dealing with, the more resistant you get to suggestions - to the point where you refuse to accept that you're wrong. I don't have the scoop on the Tomcat / Glassfish relationship but obviously, there's a lot of bitterness involved, too.
Sad to see, in a way.
2006-09-15
Nil is back with a vengeance ...
TL2, the OO programming language we built in school has no distinction between expressions and statements. Everything is an expression and correspondingly has a type. The Exception class sports a method "raise" - which needs to have a special type: an exception can be thrown at any point in the program, where any type is expected. For example
i :Int := anException.raise()
The return type of raise() is Nil, corresponding to the bottom type. By definition, Nil is subtype of all types in the system, that's why the above line typechecks.
raise :Nil (* the signature of raise *)
Looking back at this I'm now wondering why we chose subtyping over parametric polymorphism. Instead of "raise() produces a value that fulfils every other type", we could as well have said "raise() produces any type you want":
raise(T<:Void) :T (* T is a type parameter bounded by the top type "Void", i.e. any type *)
Why I'm writing this? I came to think of the parametric throw method at a discussion on Remy's blog. And now, Nil has resurfaced in the form of ... java.lang.Unreachable. Do we really need a name for the it?
The situation pretty much resembles the one with empty lists. With generics introduced in Java 5, there is no type to assign to the EMPTY_LIST constant in java.util.Collections. Instead of coming up with a new type we have a polymorphic method emptyList() to give us the empty list of choice. I say we could do the same with the closure that always throws (as in "der Geist, der stets verneint...").
