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 practicing 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.

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.^{"
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.}

Myth 4) Multi-threading is hard

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 has a February the 30th
• In England 1751, the first day of the year was March 25th, and there was 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) Most content on Java Interview Questions is accurate.