The solution

You might expect it to print out 104, "10" being the sum of the fields and then "4" being the number of fields. You would of course be wrong :-)

If you run the following code you won't get a number out at all, you'll get an exception:

Exception in thread "main" java.lang.IllegalArgumentException: Attempt to get test.Outer field "test.Outer$Inner.this$0" with illegal data type conversion to int
        at sun.reflect.UnsafeFieldAccessorImpl.newGetIllegalArgumentException(UnsafeFieldAccessorImpl.java:46)
        at sun.reflect.UnsafeFieldAccessorImpl.newGetIntIllegalArgumentException(UnsafeFieldAccessorImpl.java:111)
        at sun.reflect.UnsafeQualifiedObjectFieldAccessorImpl.getInt(UnsafeQualifiedObjectFieldAccessorImpl.java:41)
        at java.lang.reflect.Field.getInt(Field.java:499)
        at test.Outer.(Outer.java:21)
        at test.Outer.main(Outer.java:29)

The key here is actually down to an implementation detail of Java - specifically how inner classes have a reference to their outer classes. If we make the inner class static (static inner classes don't have a reference to their enclosing class) then the problem goes away and we get the expected output, 104. So what's happening here?

It might help to think how a non-static inner class can always access its outer class. And it also might help if I tell you it's more along the realms of hackery than black magic! The key here is a field, this$0, that the compiler puts in every inner class. This is set by a constructor the compiler also puts in the inner class which is called when an object of this type is instantiated. It's an implementation detail, but quite a geeky and fun one to play around with. If you decompile the class files, you can actually see this extra field and constructor in plain daylight.

I got the idea for this puzzle from http://www.javaspecialists.eu/archive/Issue062.html - this explains this implementation detail far more accurately if you want to take a look.

So, we've got an extra field in the class that's of type Outer, not int. So when we try to call getInt() on this field, we understandably get an error.

As a follow on puzzle which you should now be able to answer, if we change this line:

catch(IllegalAccessException ex) {}

to:

catch(Exception ex) {}

what's printed out now?


The answer? 105. The values that are ints are still summed, so we get 10, but there's still 5 fields in the Inner class!

This is quite frankly a shoddy way to do things anyway, and the chances of doing something like this in real life are rather remote. But how could we fix it? One option is to check for synthetic fields and ignore them - synthetic fields are ones generated by the compiler and not by the user. So if we put if(field.isSynthetic()) continue; as the first line in the for loop and check for similar synthetic fields in counting them at the end, the problem goes away. There's a catch though - there's no requirement for the compiler to actually mark anything as synthetic. It's a bit like using a well established class in the sun package - while it might help in situations like this and is likely to be fine, it shouldn't really be relied upon.

This may seem like a silly example, but it does serve a few lessons. First, as shown by the follow on puzzle, if you just catch all exception types and expect everything to work, you may well get caught out by bugs you weren't expecting, but can really bite you later. Secondly, don't use reflection to loop through fields. It's just plain wrong. If you really have to, at least check for synthetic fields and make sure the fields are of the type you expect. And lastly, decompiling compiled code and looking at the results can be rather interesting in uncovering some Java implementation details!