There're a lot of incorrect opinions among developers - some root in misunderstanding, lack of knowledge or bad experience from past. Java developers are usually up to date with the changes, but I often hear from non-Java developers and general IT world that:
- Java is slow
- Java is buggy/not secure
- Java is not free, so you need to pay a lot to Oracle for licenses
- Java is verbose, outdated language, with API that is awkward to use
I understand that without proper context, any information can be misinterpreted, so I will try to glue it together so that it makes sense :).
Is Java slow?
Short answer: No.
I remember back at my university days, I was trying to get into competetive programming. It is basically all about algorithms and data structures and you write code to solve some problem. The verification is done on a remote server which tests your solution against input dataset. Only language I knew back then was Java, and the server supported assesment of Java written solutions. The main source of loathing from the guys writing in C was that Java solutions took significantly more time to execute and that's why time limit had to be increased for Java.*
Fast-forward to 2020, Java is one of the most popular languages in the world and JVM-based solutions dominate the world of data-intensive computation. Apache Kafka, one of the leading platforms for high-speed stream processing is running on JVM. This fact itself, should disprove the statetment of Java being slow.
When it comes to performance, however, rarely something beats a compiled code. But it is like comparing apples and oranges, since Java bytecode runs on JVM - which gives it one of its main advantages: portability. Once C code is compiled against specific platform, it can be run only on that platform. But Java compiled bytecode can be run on almost any platform.
Other thing is that since its inception, JVM has evolved and there are also multiple implementations which are focusing on increasing the throughput and reduce latency, like GraalVM.
The slowness usually comes from the experience with working with badly written, outdated applications (e.g. GUI based apps in Swing). Unfortunately, Java gives a lot of freedom to create applications and it might happen that while something works, it does not necessarily need to perform well. I think this StackOverflow answer summarizes it the best.
*By the way the slowness was caused by JVM being started so that code can run.
Is Java buggy or not secure?
Short answer: No.
Again, there are many proven examples of Java-based solutions, with high focus on security: payment processing, digital signature, embedded devices (ATMs) and so on. Java has wide support for cryptography, authentication and authorization, SSL etc., so it gives you the tools to build secure applications. However, with any codebase bugs can happen, and JDK is not free of those. Luckily, there're frequent updates which fix the critical issues.
The main source of "bugginess" as perceived by users, other than the application code itself, might come from the fact, that the Java runtime (JRE) is not up to date on the machine. If the issue happens with application running on server, it is the fault of infrastructure maintainer for not keeping the JRE updated. And the same is with users. Do you remember these annoying pop-ups telling you that there's new version of Java? Do you remember also closing and ignoring it? Well, you just made your computer vulnerable.
Maybe the issue is with additional component (JRE) that you need to maintain on your computer, but most of the Java applications nowadays are bundled with JRE and do not require users to have one installed. This reduces the issue one degree down.
Is Java free?
Short answer: Yes.
Where does the confusion come from? In 2019 Oracle announnced changes in licensing model, that require buying subscription if you are using Oracle Java in production. This means that either you have a server based apps that run Java or you have a desktop application that you sell with bundled JRE. Having Oracle Java SE subscription will give you access to extended support.
That being said, if you don't need to have this premium support, you can still opt out and switch to OpenJDK or any other providers. There are many stable and open-source implementations of JDK, that most of the time will give you the same experience as with Oracle JDK. So the long answer is also yes, since you have a choice to select different vendor.
Java is verbose, "write-only" and obsolete language
Short answer: No.
Java has a long history and it was missing some constructs in older versions, but as any language it keeps evolving and improving. Let's take this snippet of code written in Java 7:
private static void java7() {
List<Person> persons = new ArrayList<>();
persons.add(new Person("Luke Warm", 10));
persons.add(new Person("John New", 15));
persons.add(new Person("Elsa Snow", 19));
persons.add(new Person("Mary Rose", 25));
Map<Maturity, List<Person>> adultAndChildrenMap = new HashMap<>();
for (Person person : persons) {
if (person.age >= 18) {
if (adultAndChildrenMap.containsKey(Maturity.ADULT)) {
adultAndChildrenMap.get(Maturity.ADULT).add(person);
} else {
List<Person> adults = new ArrayList<>();
adults.add(person);
adultAndChildrenMap.put(Maturity.ADULT, adults);
}
} else {
if (adultAndChildrenMap.containsKey(Maturity.CHILD)) {
adultAndChildrenMap.get(Maturity.CHILD).add(person);
} else {
List<Person> children = new ArrayList<>();
children.add(person);
adultAndChildrenMap.put(Maturity.CHILD, children);
}
}
}
System.out.println(adultAndChildrenMap);
}
This is unnecessarily long and difficult to read. There've been many improvements since Java 7, so the code above can be now written as:
private static void java11() {
var persons = List.of(
new Person("Luke Warm", 10),
new Person("John New", 15),
new Person("Elsa Snow", 19),
new Person("Mary Rose", 25)
);
var adultAndChildrenMap = persons.stream()
.collect(Collectors.groupingBy(
person -> person.age >= 18 ? Maturity.ADULT : Maturity.CHILD
));
System.out.println(adultAndChildrenMap);
}
Current Java release cycle is 6 months and while version 11 is the LTS (long term support), current version is 14, which brings even more improvements either as preview or stable features. The problem with Java is that it rolls a big "ball of legacy", which needs to support (e.g. the existence of default methods in interfaces introduced in Java 8).
Since Java 8, the most notable Java update which was released in 2013, there have been many updates which aim to reduce verbosity and increase readability, including:
- Improved factory methods for Collection API (
Map.of(),Set.of(), etc.) - Stream API improvements (
takeWhile/dropWhile) - Local variable type inference (
var list = new ArrayList<String>();) - Improved
Stringutility functions (repeat(),isBlank(),indent(), etc.) -
Multiline
Strings:
String html = """ <html> <body> <p>Hello, world</p> </body> </html> """; -
int numLetters = switch (day) { case MONDAY, FRIDAY, SUNDAY -> 6; case TUESDAY -> 7; case THURSDAY, SATURDAY -> 8; case WEDNESDAY -> 9; }; -
if (obj instanceof String s) { // can use s here without explicit casting } else { // can't use s here } -
record Point(int x, int y) { }
As with any language, in order to use it effectively you need to learn all the constructs. For some, the first code example written in Java 7 will be more readable than the second one, but that's just because they have not learned the new ways of writing the code.
Conclusion
There's a lot to add to each of these topics and it is worth mentioning that sometimes it's not black-and-white situation (especially with the performance). I also know, that similar false statements are out there for other languages (Python being slow, C#/.Net copying Java or JavaScript invented by aliens that are waiting for us to go mad while writing application using it and then taking over the planet).
I hope that you enjoyed this article and feel free to add your most beloved myths about Java or any other language in the comments!
Top comments (25)
I'm also baffled by all those people claiming that Java is "slow" - its JIT compiler and its JVM are heavily optimized, for sure if you look at raw speed it runs circles around Ruby, Python, or PHP.
It's only when you start comparing it to C/C++ that you could call it "slow" but that's a weird comparison, C and C++ are like "high level assembly", they're used for totally different things than what Java is used for.
In reality the idea that Java is "slow" is an urban myth and not based on anything.
This is actually the first time I read that "Java is slow" is a thing. I've always thought that the common disposition is to write your v1 on Python/PHP/Ruby, release it ASAP, and then rewrite it in Java for speed once you're earning millions.
I've heard the "Java is slow" thing many times, but I've never really understood where it comes from. Yes, if you write it in assembly or C then it's faster "duh" but that's not the point hope.
Maybe it harkens back to the old days of Java 1 and the failed "applets" concept, which gave it a bad name. And I see some people complaining about JVM startup time and memory usage, or GC pauses, although in those areas a lot of progress has been made as well.
If you can criticize Java for anything then it would be its verbosity and the slow evolution of the language (but even those two have been addressed recently) - but not its speed per se.
Yeah, I've seen companies doing that. For instance writing machine learning/intensive data processing in Python and when bottlenecks are found, they rewrite parts of the application to Scala/Java.
Java "buggy or not secure" is IMO entirely due to perceptions of client side Java, which nobody uses and which only causes problems.
Client side Java is, was, will be, and always has been, an epic failure, and should have been retired years ago ... Java belongs on the server, period.
I agree. However, there're a lot of client-sided applications for digital signatures (e.g. eGovernment) using Java Web Start and while I'm not an expert in this area, I don't know whether there are any other cross-platform solutions that would do the same.
Hm yes I guess there are some niche apps where it's popular, e-signatures used by e-government would be one example ... but isn't it possible nowadays to do that kind of stuff simply with Javascript? Which I think would be vastly preferable over foisting Java or Web Start on the end user.
I believe you when you say there are still apps out there which use client side Java, but my guess is they're just old legacy apps, and the government doesn't have the resources to rewrite them ... but for new apps probably nobody would consider Java anymore (or Silverlight, or Adobe Flash for that matter).
Also, cheerpj can compile the stuff to js, depending on what level of hardware/network access it needs.
WOW just wow, how many people in this world would know that :-) .... "CheerpJ Applet Runner", that's just genius
Need to give this a look, thanks!
People who like messing around on old sites with archive.org :)
What modern developers call is slow, is sometimes not the language per se, but the workflow around the language and tooling. For example developing something Python is the workflow is pretty simple, edit - run - observe. The feedback loop is short. I can type and observe the effect immediately. The same advantage for example using flutter. Every time i hit save in my IDE/editor the UI gets updated almost immediately.
Java on the other hand has the following development cycle:
Type → compile → package as jar → run → wait for web server to start up → observe code change. The sad part of all this is that modern Java frameworks such as springboot compile, package and run my web apps sometimes in under 15 seconds. But still for them script kiddies is just to slow. In fact I have seen some "modern" java script tooling frameworks take sometimes even longer to build a fully deployable artifact.
Ah yes, but at least the java package manager (maven) doesn't let me die of old age before it's done, nor does it create singularities on my file system 😆
(on a more serious note, hot reloading can alleviate much of what you mention)
In all honesty my experience of the tooling for Javascript was much worse than I've ever experienced with Java. Specifically adding a dependency via NPM would sometimes break my project build to such an extent that I had to start almost from scratch. At this stage I rather deal with "slow" Java than me having to start the same project everytime NPM crash my project.
I'm currently learning SpringBoot with Udacity.
Taking a dip in Java ecosystem, it's so vast.
I love the lambda functions they added in 8. when a ROR dev sees it gives us a breather and appreciate how nice Java syntax has changed in recent years
What do you mean ? JavaScript was totally created by aliens !
Just kidding.
Great article. Java isn't going anywhere and i feel it gets a bad rep because compared to JS or python it is more daunting to get into. But like you point out, it's gotten a lot better over the years.
This sums up lots of misconceptions nicely! Thanks man! Java has evolved a lot in the last years and now supports many innovative features like Lambas, functional programming and neat switches expressions 😀
Great article! Thanks :)
But do Java programmers wear glasses? 🤔
SCNR 😁 great article
Just a question!
Does google have to pay Oracle for using java or not in android?
Btw nice article
The Oracle lawsuit is about the APIs, not Java nor the JVM per se. Android doesn't run java, but the original Dalvik VM offered an API that very closely matched the Java one, even if the target object code was for a totally different platform.
The core fact that Oracle affirms is that an API is copyrightable, and that the copyright holder can block a use of it.
Well that's a separate story :D, and a separate lawsuit which is still not settled.
That's why Google is pushing kotlin ,maybe.
Kotlin needs a JVM underneath, though.
On Android it doesn't use JVM, but their own implementation ART (and DVM, formerly). The Java bytecode is transpiled during build to ART bytecode (btw I'm not an Android dev, so this might be a huge simplification).
But I think the whole lawsuit is about Android API being basically Java. It's not that like they said "you can write your Android applications in Java", it's "we have here a very familiar SDK that you can write your Android applications in, as easy as Java" :D