Mangling Integers

by Dr. Heinz M. Kabutz

Welcome to the 102nd edition of The Java(tm) Specialists' Newsletter. I am in Johannesburg this week,
presenting my first Java 5 Delta Course - Letting the Tiger out of the cage. This
course is for professional Java programmers, who have already managed the
nuances of JDK 1.4. Java Tiger has many pitfalls, and the syntax is at
times, well, strange. Today we learned what this means:

A few words about Johannesburg. It is a young city, and bustling with
activity. I arrived much too early this morning since the chauffeur service
overestimated the traffic, and even at 6:30am, my customer's building was a
hive of activity. It is also a dangerous place to be, so the chauffeur is
not a luxury. For example, you should not walk down the road carrying a
notebook, a wallet or even a mobile phone. You could be relieved of your
burdens! On the positive side, the people here are very friendly and
welcoming.

Mangling Integers

When I was a kid, I enjoyed fiddling with computers, so my aunt Elke gave me
a sign that read: "To err is human, to really louse things up requires a
computer."

I believe that Java misses a feature, that would make it a lot safer. It
should be possible to make the contents of arrays immutable. A final handle
does not help at all, since the elements of the array can still be changed.

In Issue 14,
I gave an example of how it was possible to have
("hi there".equals("cheers !")) == true.
This could easily have been made impossible by adding a language feature to
prevent users from modifying the contents of an array.

However, this gets much worse with auto-boxing. Integer, Long, Short and
Byte have now got a new function called
Integer valueOf(int). This follows the Flyweight
Pattern, similar to String objects, but only caches Integer objects from
-128 to 127, inclusive. It either returns an Integer object from the cache,
or creates a new object.

Nice function this valueOf(int), but I wondered what would happen if that
cache were to get corrupted? The interesting part about this function is
that it is called by all the autoboxing code generated by the compiler.
So if it returned incorrect values, the entire number system of Java
would be corrupted ... for example ...

Of course, this is not Java's fault, but of lax security procedures. First
off, you should always run your programs with a security manager, even if
you do not think you need it. And of course, any libraries that you use
should be checked for malicious code.

It is a pity though that you cannot turn autoboxing off, and that you are
not able to easily find all places that use autoboxing, just to know what
code to verify. Who knows, maybe in future we will have a -Xlint option to
show us where autoboxing is used.

Oracle and Java are registered trademarks of Oracle and/or its
affiliates. Other names may be trademarks of their respective
owners. JavaSpecialists.eu is not connected to Oracle, Inc.
and is not sponsored by Oracle, Inc.