Every time I teach a beginner's course, I am reminded of just how ugly Java really is. Here's a simple example:
- Comparing two "int" variables, you use ==
- Comparing two Integer variables, you probably want
Comparing *any* object, you want to use equals(), there's no "probably".
- But it is possible to have two different Integer objects with the same value - this is when you wand ==
No, you don't. Comparing two Integer objects, as any other object, with ==, will compare the two references to the object in order to determine if they point to the same object. The object contents won't be looked at. This is simple to learn and teach, and elegant as a design. I find no ugliness whatsoever in this.
- But Java wants to save memory, so in fact == and equals yield the same result for values from -128 to +127
Although you didn't mention it, you are thinking about autoboxing. Java makes efficient use of memory and, by using == to test object identity instead of equals() you can detect this optimization. This can't influence any working code (because comparing the results of
A more advanced example are the generics that disappear when the code is compiled. I understand the arguments for doing it this way, but I disagree with them - if you have generics, you ought to be able to query the types at run-time. There are lots and lots of highly questionable design decisions - basically, 20 years of backwards compatibility.
It's past time to clean house. Building a new language on top of the established JVM technology seems like a very good idea indeed. Perhaps Scala can fulfill this role...
Scala has type erasure, too, and IIRC it was designed by one of the guys who are responsible for the design of type erasure in Java.
I've noticed several design suggestions in your code.