Code Monkeyism

Pretty Printer for JSON in Java?

… with output as HTML in color? Any ideas?

American vs. European style of Software Development

There are two different cultures in the US and Europe. The US is more about freedom and power, one can get to the top alone, gun slinger mentatlity. Europe is more about security and safety, about making it as a group. This can be seen in foreign policy, gun laws, social security and health care (as always this is a generalization. If you want to know more about that, read “The European Dream” from Jeremy Rifkin.) I’m not saying one is better than the other, just that they are different.

These two styles can also be found in software development. [I don't talk about American vs. European developers - just about development styles] One group of developers favor security and safety, another group favors power and freedom. The security group tends to static languages like Java, to conservative architectures and technologies. The other groups tends to meta-programming, dynamic languages and try every new technology which flows down the river - merb, mongrel and everything that is hip. Both come from a different background and different experiences.

I think this view explains a lot different cultures and their goals and views.

Thanks for listening.

Short Book Review on “The Definitive Guide to Terracotta” by Apress

Some small notes: The book was kindly supplied by Apress. The review was lost, tried to be rescued, not found and finally written again from my notes, all because my MacBook crashed ;-)

A short review of the Apress Book “The Definitive Guide to Terracotta” by Terracotta Inc.

I didn’t do reviews before so this is my first review here. As I’m reading lots and lots of books (currently “Practical API Design” and “Clean Code”) I thought it would be good to combine my blogging with the book reading and write some reviews. But I don’t know how, so let’s try :-) Most of the time I do two things with book reviews. First I read the conclusion and the rating, second I have a look at the table of contents. You can do the second here. And the first one in short: Good book.

Slightly longer: If you need or want to know about Terracotta (TC), it’s the book to buy. It’s written by the Terracotta guys, you can’t get better and more accurate information.

For those who are more interested in some details: The book is about a software solution called Terracotta to distribute -transparently- the Java Virtual Machine memory over several JVMs. This leads to some very interesting use cases and new approaches to scalability. Terracotta calls itself virtual heap.

The book starts with a good introduction and motivation to virtual heaps, big heaps spread over several JVMs - not to be confused with distributed caching or clustering POJOs. Both can be done with TC but much more. So the main part of “The Definitive Guide to Terracotta” focuses on use cases. Those are quite good motivated, explained and described with many examples and working code.

Use cases which are covered include:

• Caching for (web) applications
• Writing a cache layer yourself with TC
• Using TC together with ehCache
• Speeding up Hibernate with distributed caching
• TC for the second level cache
• TC for detached instances
• Distributing sessions over several servers
• Grid computing
• Clustering Spring out of the box

All examples are relevant to building todays web applications and easy to follow - more like a cookbook. The authors finish the book with chapters on TC integration modules (TIM) which are drop in replacements into your application for some of the described use cases and scenarios (and more). That part includes using and creating TIMs. At last there is a - rather small chapter on performance optimizations. A good start but I’ve missed something there.

After some praise now some things I didn’t like:

• Split brain problem which you may run into is not solved, you need to do it yourself over WAN for high availability (with a message bus for example)
• Chapter about optimizations but not extensive enough and not enough information about deployments and deployment scenarios
• Minor point: Roadmap on back looks stupid

My conclusion: A rating on 0 to 10 doesn’t make sense to me. Either it’s a should-buy or not. For Definitive Guide to Terracotta, buy it if you want to evaluate or use Terracotta. Be aware that it’s missing some industry stories on deployments and usage.

Higher Order Objects

With all this talk about higher order functions: Nearly all OO programming languages support higher order objects!

(Which are objects that take other objects to perform a task)

Higher order functions might be a big “Ah” moment in FP, but the concept is really very simple and basic in OO.

Update: Dear Dzone readers, there is not much content here, because there is not much to say. OO languages support higher order objects. Thanks.

Update 2: Functions take values as parameters. Functions which take functions as parameters are called higher order functions. Objects take values as parameters. Objects which take objects as paramaters are higher order objects. As the concept is very basic in OO, people don’t talk about it.

Site was down

The site was down on Sunday and Monday, sorry for that. Thanks for coming back.

Difference between Spring and .NET as a plattform?

Not much. Both are written only by one company which makes the source available. Really. But you have to pay for Spring.

JsonBuilder for Scala, REST and Jersey

How to generate Json for REST? If you’re suspicious of automatic generation like me?* I’ve created a markup builder which can be used with Json and made a look into the future in my post “The best Markup Builder I could build in Java”:

“Closures in Java 7 will make it much easier to write a MarkupBuilder. The Action and Loop inner classes will go away and the code will be more Groovy like.”

* For a discussion on why you might not want to use JAXB and XStream see the comments on “REST: Lean JSON and XML from the same code”

Let’s have a look at this quote again. I didn’t use Groovy but with some interest in Scala - because it might be more maintainable than Java after 5-years project life time as it is more concise but not riddled with the Ruby-problems or unreadable for most as Haskell is - I looked at my JsonBuilder code and tried it with Scala.

I went back to the “Experiments to nicely generation JSON” post and did adapt it to Scala.

@Path("/hello")
class HelloWorldResource {
  @GET
  @ProduceMime(Array("text/html"))
  def hello() = "Hello"

  @Path("/world")
  @GET
  @ProduceMime(Array("text/html"))
  def helloWorld = $(
      $("id", 128),
      $("name", "stephan"),
      $("roles", roles.map(r => $("name", r.name))),
      $("adress", $(
        $("street", "mine!"),
        $("city", "Berlin")
      ))
  )

}

The generating code looks the same as in Java, with the possibility to include functions for generating nodes. My Java code did need anonymous inner classes to achieve the same - with more noise and less power. The methods are shorter and the focus lies more on generating the JSON data, not the method boilerplate code. Next will be WebBeans or Guice integration.

Ive struggled with some Scala constructs, the JsonAdapter which implements MessageBodyWriter was a little hard to write, especially:

   def writeTo(node:Node, aClass:java.lang.Class[_],
                typ:Type,
                annotations:Array[Annotation],
                mediaType:MediaType,
                stringObjectMultivaluedMap:MultivaluedMap[String,Object],
                outputStream:OutputStream):Unit = {
    val writer = new OutputStreamWriter(outputStream);
    writeTo(node, writer)
    writer.close()
  }

 [...]

  def isWriteable(dataType:java.lang.Class[_], typ:Type, annotations:Array[Annotation]) = {
    classOf[json.Node].isAssignableFrom(dataType);
  }

But everything works now and I can move on to adapt and learn how to do it better in Scala.

The migration wasn’t that hard, some problems exists and my Scala code looks more like Java than Scala, but it’s a beginning. One of my fears is to translate between Seqs, Lists, Arrays and Java Lists and Iterators all the time when interfacing with Java libraries. Not sure yet how to fix that, perhaps with some wrappers. Scalaz might help too. We’ll see in my future adventures into Scala.

Thanks for listening.

Scala and Netbeans

Compared to my IntelliJ IDEA experience, Netbeans works much better with Scala (but worse with Maven). Netbeans does recognize correct code compared to IDEA - but recognizes illegal code as legal too. For example it doesn’t tell you if you implement all methods from an abstract class. And lots of other things are missing from what we are used to in Java. My guess Scala IDEs are 5 years behind Java. Hope they catch up soon.

Scala, Maven and Jersey

As a small side note, I’ve got

import javax.ws.rs.{Path, GET, ProduceMime}

@Path("/hello")
class HelloResource {
  @GET
  @ProduceMime(Array("text/html"))
  def hello() =  "Hello World"
}

working with Maven2, Jetty and Jersey. Took some time but was interesting. Any ideas for Array("text/html") (Scala does’t support varags the same as Java does) Perhaps a clever implicit? Need to think more.

Scala and IntelliJ IDEA

I’ve played around with the latest Scala plugin for IntelliJ IDEA and I consider it alpha quality at best. It’s hard to get compilation going and it gets often confused with parsing (for very basic files, 10 lines of Scala with annotations for Jersey this time). It feels like Eclipse which will also present errors which are none (for Java!) and after inserting a blank line and saving again, the errors go away.

Scala is harder to parse (type inference, implicits, …) than Java, but this needs to get better to be usable. They hinted that it’s too far behind to get into 8.0, I hope not to far.

But kudos for supporting Groovy, JRuby and Scala and doing their best.

Update: I have the nagging thought in the back of my head and a eerie feeling in my stomach that IDEA can’t to better for Scala than for Groovy because of implicits etc. Hope I’m wrong :-)

Update 2: An update to the Scala plugin destroyed my IDE, it is no longer able to start. It says I should remove the plugin, but doesn’t tell me where it is.

Immer wieder Ärger mit Lichtblick

Nach unserem letzten - langen - Ärger mit Lichtblick, der sich nur mit Drohung von rechtlichen Schritten lösen lies, nun erneut Ärger: Nach einem Umzug haben wir zwar eine Endstromstand bekommen mit einer Gutschrift, diesen Monat aber wurde 2x unter 2 Vertragsnummern der gleiche Monatsbetrag abgebucht. Wieder Ärger, wieder Telefonieren, wieder drohen mit Rechtsmitteln. Dabei will ich nur ganz normal Strom aus der Dose.

Functional design patterns and cargo cult blogging

Again, I’ve found someone. I considered stopping last time. But this one is too good. I will only pick some parts of the post, there is not enough time to fight all stupidity there is in the world - I need to choose my battles. As the last two posts, I’ve again chosen someone who rants and has an aggressive and insulting tone without any knowledge of the matter the writes about.

Let’s start. Don’t get fooled by the beginning of his post:

“At the same time, I actually think I’m a fairly good programmer. I also think I have a fairly good understanding of what most of these buzzwords actually mean [...]“

As well see shortly, contrary to his introduction he has absolutely no clue what he’s writing about. The first subject of his lengthy rant are design patterns:

“What is so wonderful about design patterns? Some of them are known to be goddamn awful constructs that will only pollute your codebase. What a design pattern really is, is a makeshift solution to a shortcoming in your language. A proper language would make every single design pattern redundant.”

He’s glorifying functional programming later. Do only I find it funny that people ranting against design pattern (the OO ones) don’t see that currying and monads are FP design patterns? Design patterns are best practices for designing software solutions and have nothing to do with OO.

Design patterns in OO languages and Java in particular, are not part of the language. They form a solution to common problems on top of the language. The state monad, the monte carlo monad, backtracking monads, maybe and either monads. All solve problems outside the functional domain of the language. (One could argue currying is not a design pattern but an implementation pattern. Go read the Beck book.)

Simple minded people everywhere. Who can’t see the wood for the trees. This seems prevalent in the functional community - at least the people who blog. If you want to read something about functional programming that is insightful read something from apocalisp. And use OCaml or Scala, or sneak good ideas into your Java code with functional Java.

“What is a design pattern? Code duplication? It’s a recipe for writing the same code over and over. And we all know that this is bad. You shouldn’t have duplicate code.”

The poster has no clue what a design pattern is. He quotes the Visitor pattern himself. The Visitor pattern is a clever way to use handlers with double dispatch and polymorphism. There is no duplication:

public void visit(Customer customer) {
  // do something with customer
}

And though other languages don’t need the visitor pattern - Nice with multimethods for example - they essentially do the same thing:

handle(Customer customer)
{
  // do something with customer
}

The solution is the same. Those languages have internalized the constructs and have syntactic sugar for less boilerplate. They don’t have new concepts. The concepts are the same.

This is how he describes a Factory

“An object that wraps a function that you can tailor to construct and return an object so you don’t have to construct it completely from scratch when you need it.”

Thats more of a Prototype or Singleton pattern. Factory is a different solution to a different problem.

This makes me sound like a design pattern evangelist. But though I’ve learned a lot about programming from design patterns, I rarely use them. Mostly not because they are bad, but there are myriads of other problems to solve - which can’t be solved by common Design Patterns (yet?).

That said, some should be used more often, NullObject especially. And some are bad - Singletons! No, Singletons are excellent as a pattern. Only the implentation in Java is not very useful with a static method. Inflexible and often hard to test. As most creational patterns, Singletons have been replaced with IoC/DI containers. Those offer more options, creating Singletons -as a concept - being one of them.

Reflection?

“And while it doesn’t have the same buzzword appeal, reflection as a language feature may be worth mentioning too. That too is just a workaround to compensate for missing language features. Great, so it lets you inspect a class to see what methods it has? That should never be necessary. If it has a method, I should be able to call it without going behind the code with introspection.”

Never used Reflection I suppose. Or any meta programming. Read The Art of the Metaobject Protocol. It’s about CLOS! Yes I know, Java has a very weak MOP and CGLIB only goes so far.

He goes on ranting about agile development.

“What does it mean? Anticipating that changes will happen? Testing every part of your code? Working as a team, with other programmers? Get the customer involved? Let them see regularly what you’re up to?”

Nope. It means “Individuals and interactions over processes and tools [...]” which a little googling would have turned up. But of course ranting without any knowledge is easier. Knowledge hinders one ranting.

For some real insight into agile, read about Agile vs. Lean. Lots of people like agile because it helps with lean development.

The post is titled “Cargo-cult programming”, what he mainly attributes to Java developers. Cargo cult programming? His post is more like cargo cult ranting. Like lots of bloggers - see the two I’ve written about before - who only parrot what others say about design patterns, functional programming, Java or agile development. Count yourself one more cargo cult blogger.

I hope you’ve read the original post. It’s fun from a certain point of view as you see in this post.

Thanks for listening.

PS: When wanting to comment on his post, his blog told me “Sorry, but it seems you are a Spambot.” That says a lot about the blogger, keeping to oneself and not listening to others helps staying without knowledge and helps with more ranting. I hope none of my commentators see a spam bot message ;-)

Direct access 300 times faster in Java?

Dear DZone and Reddit readers: Some test might result in a great difference between direct access and getters. Running a modified test with -server is 20 times faster for direct access compared to getters. If more stupid benchmarking is involved, this can increase. I suspect the server JVM is optimizing a lot. If you want to learn something, read the linked microbenchmark article :-) The difference between 300 and 20 is 15 times tough. A modified version which uses more than one test object seems to behave different (more than 2). See comments for a discussion on the causes - the JVM might completly inline an object if it detects only one read-access object inside a loop.

They sure seem to come in droves. After my last post, about a Ruby developer who is stupider than a piece of wood, there is another one! He laments how awful Java and OO developement is and how wonderful functional programming. Well functional development is nice, and I often use it with Java, but his post is rather funny because of the errors in it. The post is full of half-knowledge, things he quotes without any knowledge by himself. The blogosphere is full of those people.

I’m not refuting the article line by line, only the best parts:

“While we’re harping about performance, consider that setter and getter methods [in Java] take 300 times longer than direct access. Not percent. Times.”

I found this line hilarious.

public class Test {
  public int value = 42;
  public int getValue() {
    return value;
  }

  public static void main(String[] args) {
    Test test = new Test();
    int dummy;
    for (int i=0; i<1000000; i++) {
      dummy = test.value;
      dummy = test.getValue();
    }

    long tDirektStart = System.currentTimeMillis();
    long sum = 0L;
    for (int i=0; i<1000000000; i++) {
      sum += test.value;
    }
    long tDirekt = System.currentTimeMillis() - tDirektStart;

    sum= 0L;
    long tGetterStart = System.currentTimeMillis();
    for (int i=0; i<1000000000; i++) {
      sum += test.getValue();
    }
    long tGetter = System.currentTimeMillis() - tGetterStart;

    System.out.println("Direkt: " + tDirekt + " " + sum);
    System.out.println("Getter: " + tGetter + " " + sum);
  }
}

I know, micro benchmarking, I’m not sure what the JVM does in this case, inlining, loop unrolling, object removal, virtual methods and all - and it shouldn’t matter because the JVM optimizing getters is the whole point, but it should enable us to look at the 300 times slower claim:


Direkt: 3470 42000000000
Getter: 3454 42000000000


300 times faster? You bet.

Oh, only one more:

So here’s another problem, one that’ll knock that smug look off the Pythonistas faces. If you’ve ever done a serious project in an OO language then you’ll almost certainly have run into the fragile base class problem.

After more than 10 years of Java and lots of experience in C++, most people agree that inheritance should have been left out of every language - it might be good for frameworks but otherwise it does a lot of harm. The coupling is to big with inheritance. So for the last years people use more often composition not inheritance with Composite Oriented Programming being the extreme. Half knowledge and a blog - a dangerous combination. These “Get the facts” posts take to much time, I’ll need to think about another format for them - or perhaps don’t do any more of them.

The essence of it? Use the right tool, but don’t get fooled by people with outrageous claims - most of the time they are wrong.

Thanks for listening.