Saturday, January 30, 2010

It was a wonderful Saturday morning. I rose up and started my morning really slowly, was staying at a friend's house. At some point I took my laptop, plugged in my USB stick and prepared to do some useful things with my time.

USB is not responding, oh well that happens every now and then, lets replug, still not working... A small alarm indicator went in my head. Lets try the other port, computer recognize the stick, the free/used space match, but... OH MY GOD, NO FILES!!!

*Sigh* just two months ago I lost a 250g disk to a hardware malfunction... I've decided to run chkdsk, and indeed, errors were found, but there was insufficient disk space on the stick for chkdsk do finish his thing (and a good thing that!). It was a mistake to use chkdsk, I should have used a recovery software right away.

Unfortunately at this point all I was left to work with was scattered blocks of that on the hard drive, so simple undelete procedures didn't work. DiskDigger however, managed to recover most of my important files, the docs and pictures especially.

Now I'm left with the annoying task of sorting through the unnamed files... This really ruined my Saturday.

What do you think will happen now? This code will compile, but during runtime Hibernate will hit us with an IllegalArgumentException in class: com.codeark.parentchild.ChildImpl, getter method of property: id

This is a result of me telling hibernate to expect a ChildImpl (targetEntity) while in practice that collection contained AnotherChildImpl class, which hibernate knows nothing about.

Why is this so bad?

This exception will not occur until the program tries to persist a ParentImpl with an AnotherChildImpl bomb waiting to explode in its children collection. That event can happen far into the (runtime) future. Although I doubt such a bug will make it to production if you have decent integration and QA, its still within the realm of possibilities; it would be best if we do what ever we can to prevent that eventuality.

Our HashSet collection is now of ChildImpl type instead of just Child, I've changed that throughout the class's internals and external API. Our class still complies with Parent's contract, since we've changed Parent.getChildren() from Set<Child> to Set<? extends Child>

As an added bonus, we no longer need the targetEntity=ChildImpl.class annotation for ParentImpl.getChildren().

Last small caveat, I've marked the class as "final" since subclassing it without proper annotations/mapping might expose us to similar problems.