Java 7: Fork and join decomposable input pattern

In my recent blog I have introduced the fork and join framework of Java 7. This blog presents a little framework on top of raw fork and join. The framework implements the decomposable input pattern (dip) - which originated from my own laziness when I was using the framework a couple of times. I have realized that I was writing the same code every time when I was implementing a slightly different use case. And you know, let's write a little peace of software that I can reuse. The decomposable input pattern framwork was born.

Java 7: Fork and join and the jam jar

Another Java 7 blog, this time it's about the new concurrency utilities. It's about plain fork and join in particular. Everything is explained with a straight code example. Compared to Project Coin concurrency is an inherently complex topic. The code example is a little more complex. Let's get started.

Java 7: Project Coin in code examples

This blog introduces - by code examples - some new Java 7 features summarized under the term Project Coin. The goal of Project Coin is to add a set of small language changes to JDK 7. These changes do simplify the Java language syntax. Less typing, cleaner code, happy developer ;-) Let's look into that.

Java EE 6 and the snowball effect

Java EE application servers increase their feature sets (APIs and administration features) whilst business applications get smaller and smaller. This introduces a new issue: if you need a single feature of a new application server version you'll get a complete package of features that you didn't need in the first place (the snowball effect). Let me give you an example: in WebSphere 7 IBM provides a high speed integration adapter for IMS assets. We need that, but we don't need all the rest that gives us a headache in terms of migration efforts. Now, if the amount of APIs increase in Java EE with every version, I predict that this problem starts to get more and more complicated. That's a reason why I don't appreciate the fact that Java EE standardizes former framework functionality like dependency injection (CDI). Business applications may get smaller, but application server feature sets get huge this way. Is that a good trend?

Characteristics of successful developers

Many blogs exist about personal (soft) characteristics of successful developers. Here is a short listing of some interesting links:

50 characteristics of a great software developer
Top 10 Traits of a Rockstar Software Engineer
Five essential skills for software developers
Manifesto for Agile Software Development
Manifesto for Software Craftsmanship

This one blog now is my personal view on that very topic. It's of course subjective to my own history and environment and I don't claim that the list is complete. Also, I do not have the discipline to always have all those characteristics a 100% myself. We're all humans, so don't take them to serious :-) Last not least: success must not be the target of your work. The target is to work on your own virtues, some of those virtues are the topic of this blog.

Threading stories: volatile and synchronized

In my last blog about the volatile modifier I have introduced a little program that illustrates the behaviour of volatile in a Java 6 (26) Hotspot VM. Since that day I had some interesting discussions that I wanted to share in this blog. It adds another valuable insights on the volatile modifier.

Threading stories: Why volatile matters

Many years ago when I learned Java (in 2000) I was not so concerned about multithreading. In particular I wasn't concerned about the volatile modifier. I don't know why, but I never had problems without volatile, so maybe I thought it could not be so relevant. I've suddenly changed my mind when I first analyzed a wierd behaviour of an application that only existed when the application was deployed to a server JVM. Todays JVMs make a lot magic stuff to optimize runtime performance on server applications. In this blog I show you an example to get fimiliar with problems that arrize in multithreaded applications, when you don't recognize the importance of understanding how Java treats shared data in multithreaded programs.