Common Java Myths

These are questions which are likely to be too advanced to ask in any interview as they may just put candidates off.  Never the less, they may be work practising in your own time.

Myth 1) System.exit(0) prevents finally being called

Why does this code

    System.setSecurityManager(new SecurityManager() {
        @Override
        public void checkExit(int status) {
            throw new ThreadDeath();
        }
    });

    try {
        System.exit(0);
    } finally {
        System.out.println("In the finally block");
    }

print

In the finally block

and why doesn't it print a stack trace?

Myth 2) String str = "Hello"; In this code, str is a String object.

Unlike C++, all variables are either primitives or references.  variables cannot be objects.  This means when you have an expression like

    String str = "Hello";

    String text = "Bye";

    str == text; // compares two references, not their contents.

    str = text; // assign the reference text has to str.

In many cases, there is little difference but it causes real confusion with lines like this.

    final StringBuilder sb = new StringBuidler();

    sb.append("Hello"); // The reference sb is final, not the instance it references.

    method(sb); // method can alter the instance, but it cannot change the reference.

Myth 3) Java has memory leaks as a C++ developer would understand them.

On Wikipedia, a memory leak is; "In computer science, a memory leak occurs when a computer program incorrectly manages memory allocations. In object-oriented programming, a memory leak may happen when an object is stored in memory but cannot be accessed by the running code.<sup>"

However, in Java, objects are always accessible, and it those objects which are not strongly accessible which are cleaned up.   The term for memory leak in Java means; any undesirable increase in retained memory, usually due to resources being recorded in collections when they are no longer needed.</sup>

Myth 4) Multi-threading is hard

Multi-threading is hard if you have no discipline.  If you just throw a bunch of code and a bunch of threads together, you get a hard problem to solve, it's going to be a mess.

However, if you use only as many threads as you need, control how threads interact, use some simple patterns everyone in your team understands, the problem becomes very simple.  The challenge then is getting the whole team to follow the rules. ;)

Myth 5) I don't need to understand the relative performance of different operations if I care about performance.

Recently I read a question which involved an integer addition, memory access, modulus, and print to console.  Despite the fact that each of those is order of magnitude slower than the previous in that list the individual was trying to speed up the fastest operation addition, but using more expensive operations.

When you want to improve performance you need to replace more expensive operations with cheaper ones and if your bottleneck is hardware e.g. reading millions of files on a hard drive, changing the software isn't going to help because it's not the cause of the problem.

Myth 6) Random number always look random

A specific combination of random numbers are just as likely as number with a pattern.  This question is a repost of a question I posed on this blog. Many couldn't believe that a Random number generator could produce a sequence which doesn't appear random at all.

Myth 7) float point should be avoided because it has random errors.

Floating point will produce the same error for the same operation every time.  The error is predictable and thus manageable.  If you know what you are doing and stick to some simple rules like rounding your results, floating point code is not less error prone than using BigDecimal except it is easier to read and about 100x faster (and produces no garbage)

Myth 8) Timezones are timeless

A common cause for confusion is the fact that over time, timezones change.  This means that Europe/London at epoch was 1970/1/1 01:00 not 00:00, why? Between 1968 and 1970 London was in Daylight saving time for 2.5 years.

Many other timezone changed in the last few years.  Moscow was GMT+3 and now it is GMT+3 (from 27 March 2011) If you check a time in 2010, you should see GMT+3 not +4.

For you think that sounds strange,

• In Sweden 1721, they had a February the 30th
• In England 1751, the first day of the year was March 25th, and there was an 11 days difference with France.
• When the USA adopted the Gregorian Calendar, it did so retrospectively so recorded dates for a few hundred years could refer to either calendar. (Often both dates are given to minimise confusion)  e.g. George Washington's birthday changed from 11th Feb 1731 to 22nd Feb 1732.

Myth 9) When you read a non-volatile value in one thread, you see a updated value eventually.

This has come up twice in the last day on StackOverflow. Basically, the JIT can optimise code where it in-lines non-volatile fields which a thread doesn't change.  Once the code compiles (you can see this with -XX:+PrintCompilation) it might never see a change you perform later in another thread.  Adding a random synchronized block, or print statement can slow down the process or confuse the JIT and it doesn't perform the optimisation (either in time, or at all)

For more, Demonstrating when volatile is required

Myth 10) Most content on Java Interview Questions is accurate.

A very high percentage of Java Interview Questions are either out of date (more than ten years only and don't apply to any modern version of Java) or they are misleading, or just plain wrong.  Unfortunately these get compiled and recycled without checking the answers.

I would look at answers on StackOverflow as these have better pier review.  Above all, avoid sites like rose india which has a surprising consistently poor quality.  If you are feeling pedantic, try to find how many spelling mistakes (in class names and technical terms) and myths you can find in one post.  Part of the problem is there is no effective way to provide feedback and get this stuff corrected.