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 »

If I try to look at the path software made in its lifetime, I’d see that the amount of configuration required to build an application started with none, gradually grew bit by bit as more and more components were starardised until it reaches the state we’re in today, the too much configuration stage.

Quickly peeking at a J2EE application’s configuration file would reveal the horror and meaning of too much configuration. A huge, generally unmaintainable file, which essentially allows for configuration of anything in your application - Only that in practice, it allows almost nothing at all, a result of its size and complexity.

Continue reading »