Java is Always Pass-By-Value

This is probably the biggest common misconception in Java. It's starting to become a minor pet-peeve of mine. :P People say things like "Java is pass-by-value for primitives, but pass-by-reference for Objects.". This is not true.

In fact, Java always uses pass-by-value. The trick is that Java always stores references to Objects. When you pass in an object to a method, the object reference is passed by value. This is different than pass-by-reference. Java makes a copy of the reference variable and that's what the method uses. While a lot of the time you won't be able to tell the difference, there are some important cases where this makes a difference.

Here's an example:



The output of this program is:

a: 5
b: 10

This is unexpected behaviour if you think that Java is really pass-by-reference. What this code really did was swap two copies of references, not the references themselves. This caused me a few headaches in the past.

This is a misconception has been around for way too long. Spread the word. :P

Common Interview Question: Abstract Classes vs. Interfaces

I had an interview today where, yet again, I got asked the difference between an abstract class and an interface. In fact, I would estimate about 50% of the job interviews I've had for Java development have asked this exact question.

The answer is pretty straight forward. An interface defines some behaviour that can be added to an existing class. The class can choose how to implement that behaviour, but by implementing the interface, they are saying that they have some capability.

And abstract class isn't used to add capabilities to an existing class. Instead, it's meant to be a basis for future classes. Abstract classes can also do some things that interfaces can't, specifically have state and default method implementations.

If you have a job interview for a Java developer position, I recommend that you know how to answer this question.

<3 Software Engineering (and Mockito)

At work today, I took a lot of time to write unit tests properly. There was a lot of refactoring, dependency injection, and mocking. I was using Mockito as a mocking framework, and I am very impressed so far. The syntax is simply beautiful. Simple, to-the-point, elegant. Check it out:

Wow. This is so clean! Look at line 7. It reads like an English sentence. Or Ruby. Go figure. Certainly not like most noisy Java code.

Today I remembered why I really love software development. It's so cool to see such complicated modules of code working together in such elegant ways. Things like dependency injection and programming to modular interfaces all come together to let you do some really powerful things, like unit testing. I'm so impressed that you can take any random component in a huge, complex system, and be able to run it in isolation. The amount of software engineering it takes to get that to work in a huge system is quite impressive. It reminds me why I'm so fascinated by software engineering.

Exceptions in Java

Java has two types of exceptions: checked and unchecked. Unchecked exceptions are the traditional exceptions you see in languages like C++ and C#. Checked exceptions are essentially more explicit versions of unchecked exceptions. Checked exceptions require that the developer explicitly declare what exceptions a method could throw. The compiler will then enforce methods higher in the call stack to either catch the exception, or propagate it to a higher level.

Checked exceptions are a feature specific to Java. It was introduced into Java as an experiment, and the general consensus from developers is that the experiment failed. This is probably why no newer languages support them.

What's the problem with checked exceptions? They seem like a great idea in theory. They allow the code to be explicit with all error handling code, and make it impossible to forget to catch an exceptions. Unfortunately there are a lot more drawbacks with checked exceptions.

My main issue with them is that they clutter the code quite a bit. There is a lot of extra noise that goes into your code when you use checked exceptions. Not only does this make the code less readable, but it slows down development. For instance, you should not have to catch every single exception when you are writing test code or quick prototypes. A lot of the time, developers will just "swallow" the exceptions with empty catch blocks, because there is no intelligent way to recover. Does your tiny app really need to catch OutOfMemoryExceptions around every statement that might allocate memory? Even if you do catch it, how will you gracefully recover? The extra verbosity becomes noise that clutters the program's logic.

This argument reminds me of static typing vs. dynamic typing. If you choose static typing, you lose some flexibility, but gain some extra static analysis from your compiler. The same thing applies with checked exceptions, however the benefit they offer isn't worth the inflexibility.

What are your opinions on checked and unchecked exceptions in Java?