Stephans Blog

The title says it all. Thanks.

From the category “Bending Java near it’s Breaking Point” or “What a stupid but interesting idea”. I like to explore ideas in Java that are inside the language spec but outside of common usage or style guides. I think Java has a lot more to give than what people did the last ten years. Before dumping Java perhaps we should reconsider some of the “common wisdoms” about how to do things in Java.

My last post on beautiful Java, and why to never use String ;-) got me flamed like I haven’t been flamed since alt.amiga.advocacy times. The idea was to provide wrappers around String like Name to achieve several things: Have better typed method signatures, have a fluent interface and to better convey meaning.

Customer customer = new Customer( name("Stephan") );
...
Customer(Name name) {
...
}
...
public Name name(String value) {
...
}

The flames were mostly about creating lots of small objects, which people claimed are unnecessary and unmaintainable.

An alternative implementation would be:

Customer customer = new Customer( name("Stephan") );
...
Customer(String name) {
...
}
...
public String name(String value) {
 return value;
}

This implementation doesn’t achieve the same things as the solution before, but there is no new object necessary, only a new method.

But still the line Customer customer = new Customer( name("Stephan") ); is more readable than Customer customer = new Customer( "stephan" );. The Hotspot JIT should optimize the method calls away so there is no performance penalty.

A better idea? Or still too repulsive.

Thanks for listening.

As ever, please do share your thoughts and additional tips in the comments below, or on your own blog (I have trackbacks enabled). This line is shamelessly take from Daniel Tenner, who writes a really excellent blog.

After my 200 reader milestone in January, we’ve reached the 300 (317) reader milestone. Thanks to all the regular readers of this blog for listening. I know 300 is still not as many readers as others have, and it might drop below 300 the next day, but I’m still thankful for everyone of you (including those with comments who prove me wrong - as happened in the last posts - or whose comments make an interesting reading :-)

I’m working on a paper on Open Sourcing and - though I have quite some knowledge on the topic - cannot find a lot of relevant papers, posts or articles. Most hits are about open source not open sourcing and “open sourcing” doesn’t find relevant things. Any ideas? Any papers? Any links? Thanks :-)

Never, never, never use (unwrapped) String or long or int. Why? Those primitive types have no semantic meaning. They are hard to understand, hard to maintain, and hard to extend. I’ve been evangelizing this concept for some time, the essay “Object calisthenics” finally prompted be to write this post. Suppose we have an example of a cinema ticket booking service.

Update: If you just want to drop a comment telling me how revolting you find the idea, well, just don’t. I appreciate your comment, but sit back, think some time about it and move on coding. When you read someone else code with String id and you wonder what on earth the id is, come back and read this post.

Compare

public void bookTicket(
  String name,
  String firstName,
  String film,
  int count,
  String cinema);

with (and I know one would introduce an Order object for real code):

public void bookTicket(
  Name name,
  FirstName firstName,
  Film film,
  Count count,
  Cinema cinema);

The second one is much easier to understand, especially when your IDE is one that tells you during autocompletion of a method call bookTicket(String arg0, String arg1, String arg2, int arg3, String arg4) versus bookTicket(Name arg0, FirstName arg1, Film arg2, Count arg3, Cinema arg4). The second one is also much easier to read.

Compare

void book(String orderId);

with

void book(OrderId order);

In the first case the developer seeing the code wonders a.) where to get an orderId and b.) what an orderId really is, "1212", "ABC-123" or "12-34-45-SCHWEINEBACKE". In the second case he can search for the usage of the OrderId class, how it is used, read the javadoc and only pass validated and correct order ids into an application. You might think an orderId is just an orderId, easy to find. Legacy systems will change the id, the naming and semantics in often inconsistent ways. I’ve seen systems that name an order ID in serveral ways as “orderId”, “AuftragsId”, “id” and several other names and all meaning the same thing!

It’s easier to have a class with semantics than a domain-less String. Developers cannot as easily mess up. If you rely on static typing and use a startic type language (both object and reference) then maximize your benefits and create more classes. In the future an OrderId class can also easily be changed to hold long instead of an int, hold validation or id generation logic. It’s much harder to extend the initial String based version.

Implementation with a fluent interface

The classes should be implemented as simple Domain classes, sometimes as immutable value objects, which just wrap String and attach some semantic meaning to the String.

public class Name {
   public Name(String name) {
      ...
   }
   public static Name name(String name) {
     return new Name(name);
   }
}

One would wonder if the solution is too noisy. Assuming

new Customer(new FirstName("Stephan"), new Name("Schmidt"));

is certainly noiser than a String argument:

new Customer("Stephan", "Schmidt");

The first is easier to understand though, and with static methods can be changed to

new Customer(firstName("Stephan"), name("Schmidt"));

This also solves the problems that with many arguments developers from reading the code don’t understand what each parameter means, especially in longer (refactor to parameter object!) parameter lists. This is another approach to Fluent Interface builders.

My last post on how to use generics with immutable objects could also be extended with value objects instead of primitives.

new Point(10,10);

new Point(x(10), y(10));

where x(10) and y(10) create Xpos and Ypos value objects.

Domain objects vs. primitivs in interview questions

One of the interview questions I like is to ask people about an interface for a price search. I usually give them

... searchByPrice(...)

and let candidates fill in the missing parts. Some will write

Vector searchByPrice(double start, double end)

which is bad code from several points of view (using double for money, no domain objects, untyped Vector).

Others with more domain based thinking write

List<Product> searchByPriceRange(Price start, Price end)

or even us the Range pattern by Fowler:

List<Product> searchByPriceRange(PriceRange priceToSearch)

The last solution is easy to extend and understand. Answering this question often starts an interesting discussion on interface design, maintainablity and domain modelling. Whatever you think about this interview question, don’t forget to once and for all: Do not use double for money.

Thanks for listening and don’t use String, int and long (or double for money).

Update:

If you find the usage of Classes instead of Strings repulsive, look at another example, zip code. Most people I’ve seen in lots of code use a primitive for zip code which creates a lot of problems when going i18n.

Customer {
   String name;
   String street;
   String city;
   String zip;
}

(some will have used int for the zip code but get faster into trouble than the String users)

instead of

Customer {
   String name;
   Address address;
} 

Address {
   ZipCode code;
}

Still think Strings are a good idea in your code or “the simplest thing that could possibly work”?

When reading about the status of Qi4j on Rickards blog, I stumbled about

Entities are really cool. We have decided to split the storage from the indexing/querying, sort of like how the internet works with websites vs Google, which makes it possible to implement really simple storages. Not having to deal with queries makes things a whole lot easier.

We made the same experience when we developed the SnipSnap wiki application several years ago. We had a split in storages and search, each part with it’s own Java interface (a component could implement both of course). This way we could have Lucene, database and in-memory search and database and file (XML, plain text) storage. We were very flexible with storage and search this way and people could easily implement different storage backends because developers have been freed from the search implementation. Rickard seems to have made the same experiences:

We have one EntityStore based on JDBM (persistent binary hashmap), one on JGroups (replicated cluster hashmap), one on Amazon S3 (for global storage), and one on iBatis (for RDBMS storage)

So today SnipSnap would easily be able to supply a S3 backend, because of the split, whereas others which rely on the storage/search combination have much more problems to support a storage-only backend. So they have problems to support S3 or WebDav out of the box.

Why don’t more people split the problem of storage into storage and search? After some contemplation on the topic, perhaps it’s the unholy legacy of databases. Databases make it easy to solve the search/storage problem with only one technology. After 30 years of databases the problems have merged in a way that most developers think of them as one problem. By splitting the problem again, projects will be freed for better backends and better search solutions. Open Source projects will emerge which adress each of the problems better than current databases do.

This of course breaks the DAO pattern and the usage of the EntityManager as an DAO replacement and should be replaced by a Storage and Search pattern. Free your mind! Storage and search are two different things, if you split them, you gain flexibility.

Thanks for listening.

Immutable objects help with avoiding bugs. Suppose I have two interfaces implementing the Immutable Interface pattern. One interface for Point and one with MutablePoint. The pattern suggests a cast to ImmutablePoint p; ((Point)p).setX( 1.0 ); get the mutable interface. This isn’t safe and can be replaced with a Generics solution.

First we have the mutable point:

public interface MutablePoint {
   public void setX(int x);
   public void setY(int y);
}

which we want to create from an Immutable object without a cast:

  Point point = point(10,10);

  MutablePoint mPoint = point.makeMutable();
  mPoint.setX(20);

The second benefit beside the missing cast is that users of the Point interface know there is a mutable interface which they can get in a defined way.

The makeMutable() method comes from a generic interface called Mutable

public interface Mutable<T> {
   public T makeMutable();
}
 

which is extended by the Point interface.

public interface Point extends Mutable<MutablePoint> {
   public int getX();
   public int getY();
}

Our Point implementation now only needs to implement MutablePoint and Point. Voila.

public class DefaultPoint implements Point, MutablePoint {
   private int x = 0;
   private int y = 0;

   public DefaultPoint(int x, int y) {
      this.x = x;
	  this.y = y;
   }

   public int getX() { return this.x; }
   public void setX(int x) { this.x = x; }
   public int getY() { return this.y; }
   public void setY(int y) { this.y = y; }

   public Point point(int x, int y) {
		return new DefaultPoint(x,y);
   }

   public MutablePoint makeMutable() {
      return this;
   }

}

A negative side effect is that people who have a reference to a Point object can get a mutable version. When the main point is to have more immutable objects. The other way round is often better, have MutablePoint and create an immutable version.

Thanks for listening.

Update: As pointed out, making an mutable object from an immutable one will break the contract, as will making an immutable one from an mutable one. You do need to copy the object to be safe. For example with a BeanCopier or a copy constructor I’ve wrote about in Beautiful Java: Reflection and the BeanCopier. Better name the method asMutable than makeMutable

public MutablePoint asMutable() {
   return new DefaultPoint(this.x, this.y);
}

It seems as it does not end.

Reading a comment from John Resig, the (or one of the geniuses, sorry if there are more :-) genius behind jQuery, a library which was for some time a basis for ExtJs (beside YUI), irritated me a lot.

We (the jQuery project) worked hard with them to try and fix bugs and add features for an ExtJS integration layer. They turned around and built their own, specialized, library (removing the need for any of our work) and then mutated the licensing into this bizzaro scheme that they have now. We can’t, in good consciousness, even recommend their library anymore due to its very nature. On top of this they ended up hiring our lead evangelist to promote their work. I can’t speak for everyone on the team but I feel quite frustrated and used.

I’m speechless about the style of ExtJS. Without the not correct comments on my blog by Jack I wouldn’t believe someone could act this way.

I think you are missing the point. This has nothing to do with money, we are doing fine financially. It had to do with cleaning up what had until 2.1 been a hodge-podge of licenses that came out of necessity into a clean simple licensing structure that is aligned with what we expected all along.

says Jack. Sure it’s about money, everything could be clear - or to most people is clear - with the LGPL. No need to switch to the GPL at all. When it’s about being open source, switch to the ASL. And I find it highly irritating how Jacks kids are always dragged into this ydiscussion as in “my kids are waking up so I have to cut this short.” and “With my third child due, and savings running low”. I have no kids on my own but most certainly not drag them into a business discussion as an excuse.

Funny thing: “Ext JS is currently asking for input on two FLOSS exceptions to help make open source usage of Ext JS more flexible.” if this plays out like the switch to LGPL or GPL, hooray another episode in this mind boggling soap opera.

Update: “The intention of this exception is to allow for more liberal licensing of extensions, language packs, themes and open source developer toolkits and frameworks for Ext libraries under a variety of open source licenses.” on their blog.

Sure, because the more liberal the licenses of extensions are, the better it would be for the commercial side of ExtJS. Best to have the extensions as Apache licensed code and ExtJS to be GPL. The Ext LLC can reuse and resell the extensions without bothering. “(Note: this exception is not for applications and does not grant any exception for the library itself. A FLOSS exception on the libraries for open source applications will be addressed in the exception discussed in “Next Up” below).” This is so ridiculous and gives Open Source such a bad name. They hurt everyone who tries to make a living in the open source space.

Sorry, this would better go to twitter - but I’m not twittering.

Another thought. And not because I want to bash ExtJS, but because I’ve been interested into the GPL, open source licensing and the implications for over a decade.

IANAL. The best situation for the company behind ExtJS would be if extension developers stay with the LGPL for their extension (or switch to a more liberal Apache license). The people who buy the OEM license from Ext can then use the extension. If someone releases his ExtJS extension as GPL, to be more “in line” with ExtJS, people with the OEM license cannot use the plugin, because it’s GPL (they can use the extension in a way that their customer need to download and install the extension on his own, but this is most often too cumbersome for customers. They are not allowed to distribute their commercial application with the extension or any code which references the extension).

The plugin writers do not gain anything for staying with the LGPL license, but Ext LLC gains a lot. It makes their OEM license much more valuable. If every Plugin writer switches to the GPL version, this could have an impact on the OEM sale. Especially because most enterprise won’t touch GPL software.

The best for a plugin author is to also go to a dual GPL/commercial license.

Very interesting situation.

Update: Very interesting

My very short review of The ThoughtWorks Anthology. The ThoughtWorks Anthology contains 13 essays on software development from different people. The quality of the essays varies widely but in the end: Recommended.

Solving the Business “Last Mile”

Excellent. Worth the book alone. This essay will lead the community to accept that there is a growing last mile problem for companies between the end of development and the going live.

One Lair and Twenty Ruby DSLs

Nothing really new, but an extensive overview over several DSL techniques in Ruby.

The Lush Landscape of Languages

Sub-par. Only interesting if you know nothing about the differences in programming languages. Filler stuff.

Polyglot Programming

Awful. For an explanation see below.

Object Calisthenics

Interesting and thought provoking. Could make you a better developer.

What is an Iteration Manager Anyway?

Good new insights about the general role of Scrum Masters and other Iteration Managers in agile projects.

Project Vital Signs

The team mood chart is genius.

Consumer Driven Contracts: A Service Evolution Pattern

Do your SOA from the consumer side not the provider side, excellent idea.

Domain Annotations

Very good! If your into Domain Driven Design, a must read.

Refactoring Ant Build files

I’ve been developing Ant build files since the beginning of Ant, but still got some insights.

Single-Click Software Release

Some good points for the deployment process, worth reading.

Agile vs. Waterfall Testing for Enterprise Web Apps

Overview of testing methods and how the fit for agile, solid but could have more punch.

Pragmatic Performance Testing

Sorry to the author, I didn’t read this one :-)

Let me illustrate how bad some parts of the book are. One essay with a clear bias against Java wants to establish how awful Java is and how wonderful other JVM languages like Groovy and JRuby are. After a distorted line number example there is an even more distorted isBlank example. For Java the author presents an implementation from Jakarta Commons, a heap of notoriously bad code.

public static boolean isBlank(String str) {
 int strLen;
 if (str == null || (strLen = str.length()) == 0) {
  return true;
 }
 for (int i = 0; i < strLen; i++) {
  if ((Character.isWhitespace(str.charAt(i)) == false)) {
   return false;
  }
 }
 return true;
}

For comparison the JRuby example (which has other performance and memory characteristics) is short

class String
  def blank?
      empty? || strip.empty?
  end
end

One who is moderatly fluent in Java would write the following code though:

  public static boolean isBlank(String string) {
    return isEmpty(string) || (isEmpty(string.trim()));
  }

  public static boolean isEmpty(String string) {
   return null == string || string.length() == 0;
  }

Not as nice and short as the JRuby example, but much better than the ugly Commons example. And with static imports the methods aren’t that ugly to use than before in Java. A isBlank("Hello") works.

But beside some bad essays the book is worth it’s money (Well it is cheap).

Thanks for listening.

Update: Lowell: “If you are using Java 6, there is a new method: String.isEmpty(). You could use that in your Java example and then you wouldn’t need to write your own.” Thanks.