9 Java Programming Myths Busted
Java has been around for 25 years -- plenty of time to build a mythology. Here, we bust up nine of the most prominent myths surrounding this widely used programming language.
![](https://eu-images.contentstack.com/v3/assets/blt69509c9116440be8/bltd38795e663308261/64cb3b8e68fcd52a887cc301/Image_1.png?width=700&auto=webp&quality=80&disable=upscale)
Java is, according to most ways of measuring such things, the most popular programming language in the world. In spite of this, there are many persistent myths about the language, even among those who use Java daily.
Since its debut 25 years ago, Java has been seen by some as something less than a "real" programming language. Whether because of Java's genesis as a language designed to program set-top boxes, or because Java's founders had the temerity to promise "write once, run anywhere" functionality for the language, there have been detractors from the beginning.
Yet Java has become popular both as a teaching language in universities and as a general-purpose programming language in many companies. Its popularity is why it's worth examining some of the myths surrounding Java. Whether a myth tends toward the positive or the negative, relying on magical thinking can leave you unprepared for situations in the real world.
[How can you help build the next generation of programmers? Read 9 Fun Tools for Teaching Kids to Code.]
Let's look at nine myths that can keep developers from making full use of Java.
Once you're finished reviewing these, I'd love to know what you think about Java as a programming language. Are there other myths that you've seen or heard about the language? Do you use it as one of your main languages for development?
Are you in the camp that sees Java as unfit for true enterprise programming? Let me know what you think about Java -- and the myths -- in our comments section below.
If you come out of the world of C and C++, you're used to thinking of memory leaks in a very specific way. In those languages, memory leaks happen when memory locations are misallocated and the application loses the ability to get at stored data. This kind of memory leak is unlikely because objects are always accessible. It doesn't mean memory leaks can't happen in Java.
In Java, memory leaks happen when a programmer gets sloppy and doesn't clean up when objects and variables are no longer needed. The application grabs more and more memory until it either runs out of memory or starts interacting with other poorly behaving applications in unpredictable ways. For the programmer, the lesson is clear: Just because one form of memory leak isn't on the table, doesn't mean you can get sloppy. You still have to clean up after yourself when you've finished using objects and variables.
This is one of those myths with roots in the same sort of mindset that leads people to do things like cross the Atlantic Ocean in a 12-foot boat because it's the only boat they have.
It's possible, with enough skill and rich libraries, for you to have a reasonable career programming in nothing but Java. If you're going to build applications that are incredibly performance-sensitive, or need to manipulate hardware in an intimate fashion, though, you'll be much happier and more effective if you use other languages for at least some of your work.
While Java isn't as ignorant of the underlying hardware as some critics claim, it doesn't have the facilities you need to do a lot of direct hardware programming. The syntax of Java is based on C++, so bite the bullet and learn C/C++, and then don't be afraid to use them when the project demands. You and your company will be happier and less frustrated if you do.
OK, so I talked about why you might need to learn other languages because of Java's somewhat unfeeling relationship with hardware, but it's really a matter of degrees. It's also a question of precisely what hardware you're trying to directly control. For the most commonly accessed hardware, Java has gained some very real control structures.
If you're not trying to do something like write process control applications, the most frequent hardware you want to control is video. Java now has an extensive collection of libraries to deal directly with various video controllers. It has a full-screen exclusive mode (FSEM), making video control much faster, much smoother, and much more successful than previously possible, even for high-demand applications like games.
Most of the concern about Java and security comes from the idea that an applet introduced via a web page will be able to access, corrupt, and erase a hard drive without any notice or approval. It's a very scary thought.
Like many things that scare us, it doesn't stand up to scrutiny. In this case, an applet trying to do anything with local storage will cause a security exception and stop execution. If an applet is digitally signed, when it tries to access local storage the user will see a pop-up asking if he or she recognizes the signing organization. If the user is in any way unsure about this, they simply click "no" and the applet stops.
On the scary scale, it ranks above cute fluffy bunnies, but not by much.
In many cases, Java applications will, in fact, use a web browser as a front end. They do this courtesy of the applet structure mentioned earlier. This is convenient because it uses a familiar user interface and a common display framework, saving time for user and developer alike.
Java applications don't have to use a web browser for their graphical wrapper, though. The JVM mentioned earlier is the mechanism allowing Java applications to execute without relying on any web browser. The nice thing is, between applets and JVMs, developers have two mechanisms they can use to implement write once, run anywhere software. And that's something every IT executive with P&L responsibility will appreciate.
One of the more annoying facets of modern computer use is the regular announcement telling you it's time to upgrade Java on your computer. You're directed to a download site. You get the software, restart your browser, and move on. Unless, of course, you're one of the people who routinely ignore those announcements and are now happily running a version of Java that is between two and five points behind the current distribution.
If you can keep running applets even though your software is hopelessly out of date, it's simply further proof all of the versions are really the same, right? Well, no. In each new version there are security updates and performance improvements. Users (and developers) who insist upon sticking with out-of-date Java are opening themselves up to a variety of security issues while enjoying the worst possible performance.
Java was initially developed by programmers at Sun Microsystems. When Oracle bought Sun, it also bought Java. Except, of course, for the part of Java that is open source. It's different ... but the same. Got it?
One of the few points at which all of this matters is Java Development Kit. There are two widely used versions, OpenJDK, which is an open source project; and Java Platform, Standard Edition, which is owned and controlled by Oracle.
One of the myths is only Java SE is suitable for enterprise development. OpenJDK, says the myth, is too slow and not scalable. Numerous large enterprise users have proven this myth untrue. Choose a JDK based on its features and support, not because you think one is more suited to "real" development than the other.
I've talked about this in a couple of ways, but I've come back to it because it's one of the most persistent areas of Java myth-making. In times of old, when binary dinosaurs ruled the earth, you could argue the infrastructure and overhead required to make software device independent would necessarily add so much weight to the total package the result would be slow and unwieldy.
In today's versions of Java running on today's hardware, none of this is true. Sure, it's possible to write bad software in Java, but you can do so with pretty much any language. If you're going to create a slow, inelegant program, though, you need to look at the dev team, not Java itself.
So there are nine myths, some positive, some negative. What's your take? I'd love to know what you think -- and whether there are any other languages that deserve the myth-breaking experience here at InformationWeek. Let me know. I'll see you in the comments section below.
I've talked about this in a couple of ways, but I've come back to it because it's one of the most persistent areas of Java myth-making. In times of old, when binary dinosaurs ruled the earth, you could argue the infrastructure and overhead required to make software device independent would necessarily add so much weight to the total package the result would be slow and unwieldy.
In today's versions of Java running on today's hardware, none of this is true. Sure, it's possible to write bad software in Java, but you can do so with pretty much any language. If you're going to create a slow, inelegant program, though, you need to look at the dev team, not Java itself.
So there are nine myths, some positive, some negative. What's your take? I'd love to know what you think -- and whether there are any other languages that deserve the myth-breaking experience here at InformationWeek. Let me know. I'll see you in the comments section below.
-
About the Author(s)
You May Also Like