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.
Java is slooooow.
ReplyDeleteWe 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.
Javascript is a subset of Java. This might be an old one but some people still believe it.
ReplyDelete"Java function / method arguments are passed by reference"
ReplyDeleteI 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).
Write once, run anywhere: from embedded controllers to enterprise servers it doesn't need optimisation per implementation
ReplyDeleteMyth:
ReplyDeleteEverything is an object
(Even though those instructors try to force OOP down your throat)
Java is dead.
ReplyDelete(See this 1999 reference.)
That Java and the Java Virtual Machine are the same thing
ReplyDeleteYou lose control over memory mismanagement if you use Java. Nope you can still write memory hogs regardless of the garbage collection.
ReplyDeleteImports can affect performance
ReplyDeleteOr, having package.* and unused imports has performance impact. No, it doesn't - this information is used only at compile-time.
Myth: Object pooling is required for performance.
ReplyDeleteA 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.
Object reference creation is expensive
ReplyDeleteI'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.
Asserts are of no use / are poor man's exceptions
ReplyDeleteString concatenation is expensive, and you should use a StringBuffer/StringBuilder
ReplyDeleteWhile 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.
There are no pointers in Java
ReplyDeleteThat Java is a simple language. Yes, the core language is simple, but most of the complexity is just pushed into the libraries.
ReplyDelete.net and Java - oh they're the same. We can change over really easily later in development.
ReplyDeleteJava is dead for the desktop
ReplyDeleteThere 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.
Nobody uses applets anymore
ReplyDeleteAu 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.
Myth: Being statically typed Java's less powerful than dynamically typed languages
ReplyDelete[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.
The name "Java" and the name of the Java is purely coincidental.
ReplyDeleteJava is the new C++. Again circa 1995
ReplyDeleteMyth: File systems in Java operate like Unix
ReplyDeleteWrong!!!
The file separator is not limited to /
Absolute paths do not begin with a file separator
MYTH: Java doesn't support multiple inheritance.
ReplyDeleteThis 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.