Chaotic Java

Sometimes, Generics can just cause a mess. Take for example the following definition I had to produce, just to get out of a Generified library I had somehow brought to life:

public final class PlayerFinishedAction<
        TGame extends TurnBasedGame<
              ? extends Board,
              TPlayer,
              ? extends Turn<Phase<TPlayer>>,
              ? extends Phase<TPlayer>>,
        TPlayer extends TurnBasedPlayer>

        extends DefaultAction<TPlayer, Location> {

You can only imagine the horrors inside a class defined that way. Needless to say, I had to re-evaluate the cost versus benefit that the generification of the library has brought to me.

I’d also like to highlight a previous post of mine about generified bi-directionality, and let it be reminded again that thanks to erasure, this is all in the end just a bunch of casts and overloads. What I mean to say is, make sure that the type-safety generated by the Generics mechanism is something of value and not just a nice touch, as it sometimes can make a simple application messier.

It seems that in almost every system I write has a bi-directional containment. For example, a Table instance containing Column instances that should know to reference back to the Table instance containing them. Sometimes, when writing an API that uses these kind of tables and columns and allows the user of the API to define them, type safety using Generics is wanted.

Let’s look at the non-Generic case first:

public interface Table {
  Collection getColumns();
}

public interface Column {
  Table getTable();
}

However, as said in the beginning of the post, we want Table to know which specific Column it is containing. So, we’ll define Table as Table<TColumn>:
Continue reading »

Autoboxing, a feature which seems like it had squeezed into JSR 201, is a convenience feature which has its own bag of tricks. This feature seems to come as a complement to the major EoD feature in Tiger, Generics. Since generics can’t be used with primitives as their types (i.e. Can’t declare Collection<int>), their wrappers are used instead (Collection<Integer>). This is due to erasure, as most annoying things about generics are (such as reflection data, an old rant of mine).

It’s obvious to see how autoboxing provides ease of use: Just taking foo(Integer num) as an example, the difference between foo(5) and foo(new Integer(5)) is notable! To take another case as an example, a call to bar(Integer[] arr) is simplified, using the varags feature, from bar(new Integer[] { new Integer(1), new Integer(2), new Integer(3) }) to bar(1, 2, 3), so the ease of development provided by this feature is nothing to ignore.

There are things that are less obvious about this new feature, though:

Continue reading »