Java’s flaws: Why Primitives Are Bad
I use Java every day for the majority of my work. This isn’t that uncommon, as Java is one of the most used languages in businesses today. While the language has improved greatly from it’s 1.0 release, some of the legacy features still make working with the language very painful.
Primary I’m talking about Java primitives. Primitives in Java were one of the features taken from languages such as C and C++ that really should have been left out. If it weren’t for those 8 primitive types, Java would be a real Object Oriented Language. Because of those primitives, we can’t really call it that, which can cause some problems when using some OO methodologies.
The reason why primitives are bad is that they are not Objects. A primitive is not extended from the Object class like every other Object in Java. This reduces a primitives ability to participate in polymorphism by casting to the Object class. If a data type cannot be cast as an Object, it is unable to participate in generic methods that accept Objects as their argument.
Of course the first argument someone will bring to me is the availability of Autoboxing that came with Java 1.5. Autoboxing will automatically convert a primitive to its Object counterpart and visa versa on the fly with no additional programming thought. Problem solved right? Well not exactly.
You see while base primitives can be converted automagically to Objects via autoboxing, primitive arrays cannot. Ok well sure they can be created and cast to an object, but the resulting object cannot be initiated via reflection. This is because the ‘class’ of a primitive array has no constructor since it’s not a real Object.
So why would anyone want to create a primitive array, cast it to an object, just to create a similar one again via reflection? Who messes with reflection anyway?
If you’re mocking an interface where one of the methods utilizes a primitive array as a parameter, JMock cannot create an expectation for that method being called by passing it in the class of the parameter because the parameter cannot be initiated via reflection. The best you can do is use an expectation that ignores all calls to that mocked object, but then you can’t verify that a method gets called or called a certain number of times.
Why would you even have an interface that used a primitive array rather than an array of the Object wrapper? Well Java has several built in such as String.getBytes(). There are 3rd party transmission libraries that send byte arrays over the wire to a receiver which cannot be tested due to the method signature having a primitive array.
It’s possible that I haven’t dived far enough into the language to find a work around for this language flaw yet. Perhaps it is possible to utilize primitive arrays as objects for mocking that I haven’t discovered. Unfortunately, forums don’t yield much else of interest on the topic either.
If anyone knows of a way to create a JMock Expectations object with a primitive array parameter in one of the mocked method calls, let me know. I’m at a loss and not very fond of the language at this point.