Tag Archives: java

Another builder pattern for Java

Posted on by

Whenever you have a domain object, data transfer object, parameter object or any other object that can’t be instantiated with constructor parameters only, you need to create a builder for its class.

The great thing about Java is that it is statically typed so a builder can give you compiler errors if you forget to set the compulsory parameters. If you use the builder in this pattern, you also get a very fluent interface that imposes order on the parameters. When using the builder, your IDE will suggest the next parameter to set.

read more »

Hur man kan hantera Continuous Delivery med MongoDB

Posted on by

MongoDB är en schemalös, dokumentorienterad databas som har fått stor popularitet i den agila världen bland annat därför att man inte behöver underhålla något databasschema.

MongoDBs schemalöshet gör att många leds att tro att Continuous Delivery blir en promenad i parken, eftersom det ju inte behövs några datamigreringar när man driftsätter en ny version av koden!

Rent teoretiskt är detta sant, men är ett sluttande plan in i Land of Crappy Code™ !

För att slippa onödig komplexitet i form av varierande utseende på lagrade domänobjekt beroende på deras ålder, rekommenderar jag att man utför regelrätta datamigreringar även när man använder MongoDB!

Jag rekommenderar även att datamigreringen är en del av applikationen — till skillnad från skript som skall köras vid sidan av innan applikationsstart — helt enkelt för att eliminera risken för misstag.

Jag har i mitt sidoprojekt Varmfront.nu utvecklat en kompakt liten lösning som i MongoDB implementerar det som Flyway gör för SQL.

Mönstret bygger på Spring Data for MongoDB och Spring JavaConfig, och migreringarna är skrivna i Java. That’s right folks, no XML here :D

Läs vidare, så får du se hur man kan göra!

read more »

Stop the Line – Build Quality In with Incremental Compilation

Posted on by

We in the software industry are still far behind when it comes to automated quality checks. Toyoda Sakichi for example invented the automated loom with stop the line capability almost 100 years ago. I write more about that in my first blog in a three-part series on building the quality in on the SmartBear blog.

It may seem old school, but every now and then I’ll start pristine Emacs and hack away on a piece of Java. I mainly do this for small stuff, since starting or setting up Eclipse takes a little bit too long for such minor projects. Even so, I don’t do this as often as I used to.

Why? I guess you know the answer: Nowadays, even the thought of not having instant feedback on syntactical and semantical correctness makes me shudder. It’s like coding in the dark. Incremental compilation is one of those great innovations that have increased the quality of our work.

Read the rest of the blog at SmartBear.

Size matters, why and how to measure your heap

Posted on by

I have had to deal with memory problems in Java applications a few times. A lot has been written about this already, but this time I ran into a slightly different issue that surprised some of my colleagues so I decided to write about it here. Contrary to popular belief, a big JVM heap size is not always better when it comes to performance.

The problem

I came to the customer site to help them with their performance problems of a fairly large J2EE-system Web Service/Hibernate/MySQL system. They had several customers running the system, but only the largest was experiencing problems. The application suddenly froze and stopped processing transactions. All sorts of hypotheses were discussed, but no one could really for sure say what the problem was. And there was little data to work on.

read more »

Code archeology 101: Custom Exception Hierarchies

Posted on by

After having worked with various legacy codebases one discovers certain recurring traits and patterns. The topic of today is the Custom Exception Hierarchy encountered in Java legacy code. This phenomenon is rather Java-specific because of that language’s checked exceptions.

So what is a Custom Exception Hierarchy? It’s an exception hierarchy, with some strangely named exception at its root, present throughout the entire codebase and used everywhere. The author(s) of such hierarchy obviously felt that exceptions like IllegalStateException or IllegalArgumentException, or the like weren’t sufficient for the sophisticated needs of their application, so they came up with a better suited hierarchy of checked exceptions.

read more »

Is your software architecture explicit?

Posted on by

You know, every system has a software architecture and a software design. Whether you think about your system’s architecture or not, it will have one.

Here is an example of two methods in a class I recently saw. It is not architecture, it is good old OOD, but it exemplifies what can happen if you do not think before you code.


protected String getSystemArg(final String key) {
  return parameters.get(ARG_PREFIX + key);
}

public Map<String, String> getSystemArgs() {
  final Map<String, String> map = new HashMap<String, String>();
  for (final Map.Entry<String, String> e : getParameterMap().entrySet()) {
    if (e.getKey().startsWith(ARG_PREFIX)) {
      final String newKey = e.getKey().substring(ARG_PREFIX.length());
      map.put(newKey, e.getValue());
    }
  }
  return map;
}

Both methods in the class handles the same parameter map. The first method returns a “SystemArg” for a specific key from the parameter map. The same parameter map that the second method in some obscure way gives you in total (but with keys without the ARG_PREFIX).
The first method is protected. The second is public. Which one would you have used if you have a key for which you want a “SystemArg”? Which one would you like to use?
This is an example of what you get if you do not think about your design. A public interface of a class that blatantly shows the inner workings, and a protected interface that is what should have been the public one in the first place.

To me, an explicit architecture is visible. All team members knows about it, i.e. it is well communicated. To make such an architecture you need to be aware of the decisions you make and why. This means that the team(s) need to have discussions, perhaps draw some interaction diagrams on a white board, maybe make a domain model and whatnot. Just do something. Anything is better than nothing.

White board area next to Sprint Backlog

White board area next to Sprint Backlog

Example of explicit architecture

Example of explicit architecture.

Agile does not prohibit you from doing design or architecture. It certainly does not prohibit you from using your brain. It only states that you shouldn’t do it all upfront, but rather evolve it over time, just as your requirements evolve. So please, think about your architecture and make it explicit. Because if you get an implicit architecture, you will be knee-deep in technical debt and then you will call me to come and fix it…

Why I am excited about Datomic

Posted on by

Background
A couple of years ago, I watched this talk/video called “Are we there yet” by Rich Hickey. In it he sorts out a way of thinking about identity, value, state and time. That view feels quite natural and is maybe even close to reality as we perceive it. He moves on to persistent data structures and different techniques to get from one state to the next. How to progress from one immutable value to the next (e.g. STM). And multiversion concurrency control. Watch the video.

Following that reasoning, Clojure is a natural consequence. Interesting because of the ideas above, built in.

Moreover, when this thinking makes it into a database like Datomic, that’s even more interesting.

read more »