serg.io

Generics in Java are not so bad. Stop your moaning!

2008-08-28T20:02:00.011+01:00

It seems a commonly held belief that due to type erasure, Java's implementation of generics is somehow tainted. I mean, it is just compiler magic right? The comparison with the .net languages is a frequent one. Having generic type information availble at runtime certainly has benefits in that reflection works and the .net CLR is able to make more optimisations by avoiding the casting / boxing overheads.

The argument for Sun's decision to go with type erasure - backwards compatibility - is well appreciated. However, I didn't realise until recently that generics were bolted onto .net after the initial release. Obviously Microsoft didn't wait as long as Sun did, but they were definitely not there from the outset. So, all of the same compatibility problems that Java suffered applies to net too. But, as Microsoft opted for the non-backwardsly compatible route and allowed reifiable types, they essentially deprecated all of the existing library classes that work with non-generic types.

Which in many ways seems like a real shame. From a purely aesthetic point of view, C# is a very elegant language that neatly avoids a lot of Java's legacy cruft. What a shame to have a whole package of non-generic collections classes sitting in the background like a wart on the core API. And so early on in the language's lifetime.

Here's another example. As Enum already existed in C#, it could not be generic-afied (pretty sure that is not a verb...) without breaking all existing usages. So Enum in C# does not have a crazy looking definition like in Java:


public abstract class Enum<E extends Enum<E>> 
extends Object implements Comparable<E>, Serializable

(Angelika Langer has the best explanation of this initially baffling splurge of brackets.

Which means that parsing a String to an enum value cannot be done in a typesafe way, and takes some hoop jumping in C#:


//  Parsing String to Enum in C#
Colour colour = (Colour)Enum.Parse(typeof(Colour), "RED");

Compare this to the elegant version possible with Java's api:


//  Parsing String to Enum in Java
Colour colour = Colour.valueOf("RED");

It feels like a missed opportunity. The brave decision was to break backwards compatibility for the sake of a purist and better functioning approach to generics. Pity then to sidestep the controversy by not applying this to all of the existing libraries - C# is already saddled with crufty code in its core libraries.

New year's resolution - be concise, but not terse

2008-01-12T22:00:00.000Z

I've just finished Strunk and White's classic The Elements of Style which I strongly recommend. It teaches you to review your writing before inflicting it on its readers. The book is under 100 pages which proves the authors understand concise use of the language. On top of that, it is an enjoyable little book to read. In the same way, the brevity of your coded language is important. Here's a great example from the Java api:

Set<Colour> primaries = EnumSet.of(RED, BLUE, YELLOW);

There is something beautiful about the perfectly-named method "of". Since Effective Java we all know to favour static factory methods over constructors. When dealing with generics it is even more important. Until constructor type inference arrives in Java, the constructor version would be comparatively cumbersome

Set<Colour> primaries = new EnumSet<Colour>(RED, BLUE, YELLOW);

In some future generation of the language, an operator overloading could provide more terse code. Maybe something like:

EnumSet<Colour> primaries += {RED, BLUE, YELLOW};

I'd argue that the of method is aesthetically more pleasing than the overloading. That's the difference between being concise and terse. Brief, clear and accurate, but not to the point of alienating those that have to read it.

The obligatory shameless cross link self promotion blog entry...

2007-11-16T09:23:00.000Z

Check out my new mercifully short post on the codingthearchitecture blog.

I recently told Simon via twitter* that I wouldn't call myself an architect until I posted on the codingthearchitecture blog. He mocked me. To be honest, I still do not know if I would use that term as in my experience it can sound a little standoffish.
* does the act of mocking someone on twitter have a verb - "twatter" maybe?

Java generics and constructor type inference

2007-10-07T21:33:00.000+01:00

I started thinking about this over a curry with some colleagues who had some strong opinions on Java's generics. A lot of the flack directed at generics in Java, and even at Java itself, relates to its apparent verbosity. Take the classic example of instantiating a new Map.


Map <Integer, String> crudeCache = new HashMap<Integer, String>();

Why are the type parameters declared twice? Can't the compiler infer the types used in the call to the generic constructor from the reference declaration? This has been asked before, and there are a few proposals, but Neal Gafter's recent post seems the slickest to me.

He proposes this syntax


Map <Integer, String> crudeCache = new HashMap<>();

where the final <> is a signal to javac to do its type inference magic. I like that. The amount of typing is not that important - I haven't measured it, but I am sure I spend more time looking reading, and thinking about code than actually typing it. Anyway, I rely on my IDE to do a lot of boilerplate coding. However, this syntax looks much more elegant and readable. So, then why not go one step further and omit the <>:


Map <Integer, String> crudeCache = new HashMap();

Can't the compiler infer type in this case too? Unfortunately not, as this would be confused with a backwardly compatible call to a raw type constructor. Remember that raw types really are different from unbounded wildcards, so for compatibility with legacy code they need to stay. It is a pity that the least frequent use (raw type) would be the most terse.

Type inference in general is a pretty tricky problem. Java tries on occasion in a fairly simplistic way. Take for example


List noStrings = Collections.emptyList();

In that situation javac manages to infer the type from the reference assignment. Interestingly, the implementation of the emptyList method is rather crude looking. It simply casts a raw List into the desired type and hides this chicanery behind a @SuppressWarnings("unchecked"). However, typing is not compromised - you can't ever get anything out of the list, as it is immutable and has zero size, so the apparently unsafe cast is sound.

When you not encumbered by backwards compatibility, simple syntax comes more easily. Take for example how Scala handles this issue:


val scalaMap = new HashMap[Int, String](1, "types inferred")

Whilst that concise syntax looks like it comes from a dynamically typed language, Scala is as statically typed as Java. But as the type system is so well constrained, the designer (who was on the original Java generics "GJ" team) has been able to use local type inference to provide both the generic type information, and the type of the reference declaration itself. I am impressed by the clean look, but I think I'd miss the reference type on the left had side of the assignment as it must help when reading through the code. Interesting to see what can be done on the jvm when you start with a clean sheet though.

Hudson - great for when you need a lightweight CI tool in a hurry

2007-08-14T21:03:00.000+01:00

On a recent project a colleague recommended Hudson which turned out to be a very good call indeed. The team was genuinely impressed. Despite the tagline claiming it is an "Extensible continuous integration engine" - seriously Hudson people, drop the "engine" - that smells like a programming vapourword. Anyway, continuous integration tools seem to be aligning themselves into two camps, big fat do everything ones, and small neat lightweight ones. Hudson is now firmly at the top of my list of the second flavour.

So this is why it is well suited to short, dare I say agile, projects:

Trivial installation – the released package is a war file, so you drop it in your web container of choice and away you go.

Configuration – going with the lightweight rapid theme, there is not much to configure. However, Hudson scores with a really intuitive gui. No need to read the docs.

Feature set – it had everything required for the tight timescale project I was working on – namely subversion integration (naturally), cron (quartz I guess) style scheduling, rss feeds for build results, JUnit report rendering, and a really sweet unix tail style build output watcher.

and this is what is not quite perfect

Missing a couple of features, such as support for alerting build status over chat, and delayed commit.

Although there seems to be a decent swell of support for Hudson, and it has an open extension system, there just aren’t that many compelling extensions yet.

No support that I could find for adding in code coverage reporting.

A successful build shows a blue rather than red traffic light. That’s just confusing. Like is blue good or bad?

Really though, I am just splitting hairs. Hudson was very impressive.

Java application config choices

2007-08-05T22:00:00.000+01:00

I took some good-natured jibing on my last project about the level to which I wanted to make the application configurable. My innate pedantry meant that I was driven to throw as much of the configuration and even logic into external files. Frameworks like Spring positively encourage this - why would you ever have a hard-coded static constant, when you can inject a value from xml? And why stop there - why not config your Spring config files with a PropertyPlaceholderConfigurer... Well, my colleagues have made me think a bit more about this approach. Clearly, there is some config data that no-one is quibbling about - database credentials for exmple, simply do not live hard coded into the application. But what about other meta data? Like say a number format pattern? Or an SQL string?

There are lots of choices for where metadata can reside, and picking the appropriate one is key. Databases and properties files are great for config that often needs changing on the fly. For example, the number format for a column in an online report. However, they add a level of indirection during development which is anooying as the data is physically separated from the source. They are also not well suited to refactoring, although IDEs ease some of the pain these days.

Annotations are at the other extreme as they are bound to the source. They're appropriate for a different category of metadata - when your config drives the code's core functionality. The classic example is a SQL (or an object query language) string which is well suited to living in annotated methods in DAOs. There is no point having it in an easliy-changed properties file because when you change your SQL you are fundamentally impacting the behaviour. That is not a runtime activity. However, annotations are more verbose to create. Moreover they are easily abused and overused resulting in bloated, messy code.

As an aside, and a great example of annotation abuse, I really don't like JUnit 4's @Ignore - if the test is broken then fix the damn thing! That is just encouraging sloppiness. It is even worse than commenting out a broken test as it kind of looks official - like you somehow meant to do it. As much as I hate to admit it, at least a chunk of commented out test code is a big red flag that shouts at you to go back and get the thing to pass.

So to sum up, the choices available in Java are increasing all the time. Spring for example ships with more and more annotations. In addition support is there for bean wiring by xml, properties files and programatically through the api. In a slightly obtuse way, their new dynamic language support can be thought of as config - you can certainly use it to inject new bahaviour at runtime. The choice can only be a good thing (I don't want to be forced to use EJB 2 deployment descriptors ever again). It just means I've got to think more carefully about where application metadata should live and not just dump anything that looks like config into properties files.

Easy transactional DAO JUnit tests using Spring

2007-05-15T14:32:00.000+01:00

This is nice quick win from the wizards at Spring. It is all in the doco, but I thought it was worthy of a post as it is very elegant. Unit testing a traditional DAO always gives the problem of what to do with test data that gets left in the database. Even if individual developers have their own database schema that gets cleared down and set up each time your test suite runs, you can get problems with data from one test polluting the next. In the worst case, your test cases start to depend on the order in which they're run.

Spring provides an absurdly long named, but very handy superclass for your JUnit test cases: AbstractTransactionalDataSourceSpringContextTests

Writing your test cases in a subclass of this will mean that each case seamlessly runs in its own transaction. Spring starts a transaction before the test case method is invoked, then rolls it back on completion (pass or fail).

Here's an example:


package io.serg.dao;
 
import java.util.Collection;
import org.junit.Test;
import org.springframework.test.
    AbstractTransactionalDataSourceSpringContextTests;
import io.serg.Customer;
 
public class CustomerDaoTest extends 
    AbstractTransactionalDataSourceSpringContextTests {
 
   private ICustomerDao customerDao;
 
   public void setCustomerDao(ICustomerDao customerDao) {
      this.customerDao = customerDao;
   }
 
   @Test
   public void testGetAllCustomers() {
 
      Collection customers = this.customerDao.getAllCustomers();
      assertNotNull(customers);
      assertFalse(customers.isEmpty());
   }
}

The bean config to get this to work is very simple:


<bean id="customerDao" 
   class="io.serg.dao.CustomerDao">

  <property name="dataSource" ref="dataSource"/>
</bean>
 
<bean id="dataSource" 
   class="org.apache.commons.dbcp.BasicDataSource"
   destroy-method="close">
   
  <property name="driverClassName" value="${jdbc.driverClass}"/>
  <property name="url" value="${jdbc.url}"/>
  <property name="username" value="${jdbc.username}"/>
  <property name="password" value="${jdbc.password}"/>
</bean>
 
<bean id="transactionManager" 
   class="org.springframework.jdbc.//
   datasource.DataSourceTransactionManager">

  <property name="dataSource" ref="dataSource"/>
</bean>

Note that we're using Spring's autowire by type to inject the transaction manager into our unit test superclass. Still don't know what my feelings are about autowiring - my inate fear of all things magical means I'm trying to resist, but it does seem very neat in small examples like this.

Clearly this is a very simple example, but more complex interactions with the database can be tested in this way, including the case where you do actually want to commit a transaction part way through a unit test (see the javadocs for org.springframework.test.AbstractTransactionalSpringContextTests, specifically the setComplete() method and defaultRollback property).

This is a particularly sweet solution for the problem of unit testing your DAOs. You don’t need a separate test database per developer and you can run these concurrently and let the RDBMS handle the traffic.

The principle argument against this technique is that you are still physically hitting the database so you are not just unit testing the DAO code. But in all honesty, unless you are going to mock up your datasource and jdbc connection (very painful) there is little alternative. In the real world, unless you go down the OR mapping route, your DAO and database are irrevicably linked. Furthermore, Spring allows you to write very clean DAOs which do almost nothing beyond handle the interaction with a relational database, so what else is there to test anyway?