Starting from Java 5 Java language departed from WYCIWYG (What You See is What You Get) principle and introduced some new features that violated that principle. In hind sight it was well justified. Good example of some feature is "try with resources" block (introduced in java 7) that closes all closeable resources opened in the try block. So now programmers don't have to write "finally" clause with another "try-catch" within it to close the resources and catch possible exceptions there. But the downside is that people who never wrote that annoying "finally" clause may not fully understand how it works, and that was the value of WYCIWYG.
So I would like to discuss some not very obvious pitfall with Inboxing feature. Inboxing is when there is a method that accepts a primitive parameter - such as int, but the invoker of the method passes an Instance of a corresponding class - such as Integer into the method. Java compiler and a runtime will automatically convert Integer instance into primitive int and pass into the method. So the programmer doesn't have to worry about doing it. So it is transparent.
But what would happen if there is a variable of type Integer and its value is null, and such a variable is passed as a parameter into a method receiving int? Well, behind the scene the method will be called on the Integer variable to convert it to int. But since Our variable has a null value a NullPointerException will occur at the line where the method is invoked, and the control will never even be passed to the method itself. I don't think that it is very obvious and transparent behavior. And that is the price we all pay for this nice feature and for departing from WYCIWYG. But as always this a trade off situation - you get something you loose something.
Is inboxing the right name for that process? I thought it is unboxing that is causing the Exception.
I would say that is not a problem with boxing, but with letting nulls loose in your app. The idea of boxing is so you can write this sort of thing:-The idea of the valueOf method (which was introduced at the same time as boxing) is to allow you to create instances without using the new operator, and to avoid duplicates of frequently‑used values. It is not intended that you should pass an Integer object to it, so obviously whoever designed that thought it was not a major problem.
I don't think the correct term is WYSIWYG, but syntactic sugar. WYSIWYG refers specifically to user interface design.
If a developer tries to unbox a null Integer and they get an exception, then it's up to them to fix it. This doesn't seem like that much of a problem.
A developer that uses try-with-resources without understanding what it really does probably also would have blindly used a finally statement without knowing exactly what it does. That doesn't mean that syntactic sugar isn't incredibly important in making a language pleasant to work with for an experienced developer.
Two of the things I've been aching for a long time for Java to add are the null-conditional operator and the null-coalescing operator. These can easily be implemented through syntactic sugar, but would make the life of many developers a lot easier. In this case there is almost no downside.
I do some of my very best work in water. Like this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop