Java Urban Myths

Question

^{_{Along the line of C++ Urban Myths and Perl Myths:}}

What are the Java Urban Myths? That is, the ideas and conceptions about Java that are common but have no actual roots in reality.

As a Java programmer, what ideas held by your fellow Java programmers have you had to disprove so often that you've come to believe they all learned at the feet of the same drunk old story-teller?

Ideally, you would express these myths in a single sentence, and include an explanation of why they are false.

Answer 1

Java is slooooow.

We all know there's some tasks at which Java can't beat C for speed (like low-level bit-twiddling where Java has to do a lot of copying and type conversion while C can use unions and pointer juggling). By now we also should all have seen the benchmarks where Java code runs as fast as (sometimes a little faster than) C.

But still, often you only have to mention Java to get knee-jerk jokes about how horribly slow it is.

Answer 2

That Java and the Java Virtual Machine are the same thing

Answer 3

Myth: Being statically typed Java's less powerful than dynamically typed languages

[Edit] Ok, so it seems some explanation might be helpful here. On a theoretical level almost all computer languages, apart from SQL, are equally powerful (see http://en.wikipedia.org/wiki/Turing_completeness). Practically this means that for in any language X you can write a compiler or interpreter for any language Y thus making them more or less identical and thus equally powerful.

On a more pragmatic level these days it's not the language that matters most of the time, but the IDE, libraries, APIs etc that make for good programming.

Answer 4

Write once, run anywhere: from embedded controllers to enterprise servers it doesn't need optimisation per implementation

Answer 5

Javascript is a subset of Java. This might be an old one but some people still believe it.

Answer 6

That Java is a simple language. Yes, the core language is simple, but most of the complexity is just pushed into the libraries.

Answer 7

Myth: Everything is an object

(Even though those instructors try to force OOP down your throat)

Answer 8

.net and Java - oh they're the same. We can change over really easily later in development.

Answer 9

Java is dead.

(See this 1999 reference.)

Answer 10

You lose control over memory mismanagement if you use Java. Nope you can still write memory hogs regardless of the garbage collection.

Answer 11

"Java function / method arguments are passed by reference"

I have argued with some pretty intelligent people about this one. I would guess that some people reading this thread might still be inclined to disagree (though I suppose it wouldn't be a very good answer if that weren't the case).

Answer 12

Java is the new C++. Again circa 1995

Answer 13

Asserts are of no use / are poor man's exceptions

Answer 14

There are no pointers in Java

Answer 15

MYTH: Java doesn't support multiple inheritance.

This one is a huge Java myth: you can have multiple interface inheritance and THERE ISN'T A SINGLE THING THAT YOU COULD DO WITH CONCRETE IMPLEMENTATION INHERITANCE THAT YOU CANNOT DO TOO WITH INTERFACE INHERITANCE.

As a matter of fact some OO languages are "purely abstract" and support multiple inheritance.

As another matter of fact James Gosling himself said regretting not having gone "pure interface" with Java:

http://www.artima.com/intv/gosling13.html

And as the final matter of fact Bjarne Stroustrup said something similar regarding C++'s "pure abstract classes":

http://www.artima.com/intv/modern.html

Since then I have consistently pointed out that one of the major ways of writing classes in C++ is without any state, that is, just an interface.

So I think that "Java doesn't support multiple inheritance" is one of the biggest myth about Java. Usually spread by people that don't understand neither OO nor delegation.

Note that the article by Gosling I linked to above talks exactly about this and it mentions delegation. Because this is what it's about.

Sadly a lot of not-so-knowledgeable programmers mistake "multiple implementation inheritance" (which Java doesn't support) with "multiple inheritance", which Java fully supports.

Same programmers are very confused about mutliple inheritance and mistake "inheritance" for "code reuse", which is of course rubbish.

And of course there isn't a single OOD using multiple inheritance that could not be translated to a Java OOP.

So you may disagree with me but then you'd be disagreeing with Bjarne Stroustrup and with James Gosling too and, anyway, it would be impossible for you to come up with a single OOA/OOD example using multiple inheritance that I could not translate to Java using multiple interface inheritance.

Answer 16

String concatenation is expensive, and you should use a StringBuffer/StringBuilder

While true in some cases (e.g., concatenation within loops), modern Java compilers will optimize String concatenation (using the + operator) to StringBuffer/StringBuilder based concatenation anyway.

Answer 17

Myth: Object pooling is required for performance.

A few years ago Java, it seemed like everyone was espousing pooling objects to avoid the "cost" of creating and disposing frequently used objects over and over again. Aging information on The Internet being what it is, I see people who still run into this old chestnut every once in a while.

The truth: from java 1.4 on (at least), generational garbage collectors have made the cost of creating and reclaiming an object cheaper than looking it up from a stored cache, especially when the cache has to be thread safe. Future optimizations (stack allocation via escape analysis, for example) threaten to make it even cheaper.

The moral of the story: it's likely best to just create objects when needed and throw them away, unless your profiler tells you differently.

Answer 18

Object reference creation is expensive

I've seen people declare references outside of of loops thinking it is "more efficient," at the expense of the reference being scoped wider that it has to be.

Answer 19

Java is dead for the desktop

There were some questions about that on SO. No, it isn't dead - it has many frameworks, components and tools and much enterprise software is made using a desktop client.

Swing additions in JDK 7 are here to support the thesis that Java isn't dead for the desktop.

Answer 20

Imports can affect performance

Or, having package.* and unused imports has performance impact. No, it doesn't - this information is used only at compile-time.

Answer 21

Nobody uses applets anymore

Au contraire. In many enterprise environments, where it's guaranteed that the users have the appropriate JRE installed, applets are used for many tasks, such as digital signing, customized printing, etc.