Chaotic Java

I guess I completely missed out on this because it seems like there was a better looking documentation of Java out there (still a prototype, but is stable) and I kept using the old JavaDoc one.

Anyway, if you’re using JavaDoc and want to have killer web documentations, take a look at this open source project, DocWeb!

I can see one good thing about it and one bad thing: It allows for dead-easy translation of the documentation using the community as translators – Great for open source projects that are relying on the community for so many things, just takes their minds off needing to manage it. However, it is being installed as a servlet which requires you to have some sort of container for it.

I wonder if the open-source hosts (SourceForge, Tigris, Google Projects, etc) are going to start supporting this feature?

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 »