10 Myths About Java in 2019

To be more precise: Java is heavy compared to interpreted languages like Python, Ruby, or JavaScript.

I can see how this is a common opinion. If you tried Java anytime before 2014, chances are you had to jump through a lot of hoops to get things set up. You had to install a JDK, a build tool (or IDE), then configure your IDE or build tool to work. The getting started process was heavy.

But no more! In 2019, you can create a Spring Boot app with start.spring.io in seconds and the build tool is included in your download.

As far as the language is concerned, it is…​ "high ceremony" in that it requires a bit more plumbing to create basic applications. Java 8 reduced a lot of complaints when it added lambdas; some even say lambdas have caused a reduction in enthusiasm for Scala. Urs Peter has a good article on Java 8 vs Scala: a Feature Comparison.

The major gripe I’ve seen from developers is you have to write getters and setters for POJOs (plain old Java objects). This will soon be eliminated with Java Records. You can eliminate writing tedious getters and setters now using Project Lombok.

Other than that, "heavy" can refer to static typing or EJBs (Enterprise Java Beans). "Java is heavy" makes me think of Java EE, app servers, and EJBs. Yet, the Java I use today feels lightweight - I wait less time for Spring Boot to compile/start than I do for my TypeScript to compile!

Super-fast startup times have become a trend; popularized by Micronaut and Quarkus. Even Spring Boot has been influenced by this movement.

As far as Java EE is concerned, well that’s over. Jakarta EE is the 🔥 new thing and MicroProfile is leading the charge to standardize Java microservice architectures that are cloud ready. MicroProfile even offers a way to create applications using the command line, much like Spring Boot.

Is it true? In the past, yes. Not in 2019.

I had to ask for clarification on this one: "I remember having to write longer "sentences" in Java". They also mentioned having to use fully qualified references inline.

This is typically not the fault of the language, but rather frameworks. After all, Spring Framework’s longest class name is 97 characters long!

I agree that frameworks can be overly verbose but it’s useful for class names to be expressive. Regardless, you can use whatever names you like for your classes. Just don’t use an I prefix for your interfaces. That convention died long ago.

Using fully qualified class names is only a problem when you have the same class name in different packages. I’ve only run into this a handful of times in projects I’ve worked on. Adding import x as y to the Java language would solve this problem, but it’s rarely an issue IMO.

Is it true? No. Java isn’t long-winded. Some of its popular frameworks are.

Now that I know the intricacies of Maven and Gradle, I think dependency management works quite well in Java. However, I do remember migrating AppFuse from Ant to Maven back in 2005 took a full year and I had to go to the hospital for burnout at one point. Now that I’m recovered, and Maven hasn’t changed much in 10 years, I rarely think about how to use it.

I realize that people new to Java don’t feel the same way. When they open a large pom.xml or build.gradle and they want to add a new dependency, they might not know where to add it. Especially if the project uses profiles and has multiple <dependency> blocks.

For Node projects, all you need is a package.json project and it’s pretty straightforward. Want to add custom behavior? Just add some lines to the script block. Want to add a new dependency? Just run npm i groupId/artifactId.

I do think it would be cool if Maven and Gradle had something like mvn add groupId/artifactId.

I also think dependency resolution is much better in Java than in JavaScript. Maven and Gradle store artifacts in a single location instead of within each project and the convention in Java projects is to lock down the version. JavaScript projects tend to use version ranges and people break semantic versions rules all the time. Maven supports version ranges too, but virtually no one uses them in Javaland.

As far as packaging goes, just create a JAR. Nothing else is really necessary. Make JAR, not WAR!

Is it true? Yes. While most Java developers would say dependency management is not confusing, the fact people feel like they have to learn Maven and Gradle indicates otherwise. No one has to learn how package.json works to be an effective Node developer. As for webpack, that’s a whole different ball game! 😅

Java supports primitives like int and boolean, and object types like Integer and Boolean. Primitives use less memory and are much faster. So why does Java recommend you use objects? I can think of a couple of reasons:

Baeldung has a good post on Java Primitives versus Objects.

Is it true? Yes. We prefer objects over primitives for the reasons stated above. You can use lighter and faster primitives but beware of the caveats.

There are many dynamic language aficionados that simply hate static typing. If you’re not a fan of static typing, Java probably won’t work for you. However, if you want to deploy apps on the JVM, you might like Groovy! It doesn’t have static typing by default, but you can add it if you want it.

I’m not sure I understand why non-Java developers think the Diamond Operator sucks. Maybe because you need to type it? My IDE usually handles that code completion for me.

Is it true? Yes, Java requires strong typing. And large codebases usually benefit from it.

In the days of J2EE, EJB, and early Spring versions, this was true. However, the default config files for Java apps are properties files, which are pretty tough to mess up. I’ve rarely misconfigured a properties file; I certainly can’t say the same for JSON or YAML.

Spring created XML Hell, forcing developers to create pages and pages of XML to configure their Spring beans. After all, Spring’s most popular feature was dependency injection and XML provided a convenient way to do it in 2004.

But the Spring team also created a better alternative called Java Config, becoming mainstream in 2014 with Spring Boot. It’s pure Java, which enables a much safer config mechanism because you have all the benefits of inspection, autocompletion, and error checking that an IDE will do for you.

Is it true? No. Not in 2019.

When most people think of Java development, you have to install a JDK, install your IDE, point your IDE to the correct JDK, etc. It’s no surprise people think Java IDEs are heavy.

If installing a JDK is a pain for you, use SDKMAN! Same goes for managing your JAVA_HOME environment variable. SDKMAN has extracted this problem away for me, and it’s just no longer a concern.

It’s true that if you have more than one JDK installed, you will have to configure your IDE to point to it. I think you’d have the same problem with Node, Ruby, or .NET; this is not a Java-specific problem.

So are Java IDEs heavy? Yep. In fact, when I first started programming in Java (in the late 90s), I used HomeSite because I found it fast to startup and lightweight to use. I didn’t use an IDE until Eclipse came along! Eclipse was the first IDE fast enough to be tolerable. These days, I use vi, TextMate, or VS Code when I need a lightweight editor.

Is it true? If you only have one JDK installed, I don’t think so. Otherwise, yes.

Defining JAVA_HOME can be required, but not if you use SDKMAN. I ran export JAVA_HOME= and was able to run Maven and Gradle just fine.

Is it true? Yep. Don’t use JAVA_HOME.

Stupidly complex are some awfully strong words. Let’s dig in.

When using HomeSite to write Java, I had to look up package names and manually add the imports. Today? With an IDE, the import happens automatically. With an IDE, code completion happens. With an IDE, I’m prompted to refactor code and make it simpler.

Even when writing JavaScript or TypeScript, I prefer an IDE for the auto-imports and code completion.

Is it true? Yes. I think development, in general, and no matter the programming language, is complex without an IDE. IDEs can save you thousands of keystrokes in a day and are tremendously helpful when refactoring.

I think most Java developers will agree that licensing has been a confusing topic recently. Especially since the JDK became OpenJDK and with so many different distributions.

The funny thing about this particular point is no non-Java developers mentioned it. Even though we as Java developers think it’s confusing, no one outside of the Java community is really concerned. Maybe it’s because they’re no longer interested in Java.

Is it true? No. Java licensing is not confusing. If you’d like to download and install a JDK, use AdoptOpenJDK. If you’d rather use something that automates installing Java and switching Java versions, use SDKMAN! For more info on this subject, see Which Java SDK Should You Use?

In my experience, most of the people that hate Java these days are JavaScript developers. They love the dynamic nature of JavaScript and how it can now be used on the client and server. Personally, I love the combination of JavaScript on the front end and Java on the backend. You’ve also got to love that this was the vision for JavaScript from day 1 when it was first announced:

Do you recommend using them together? Yes. JavaScript + Java is like peanut butter and jelly. See JHipster.

We’re big fans of Java, JavaScript, and many other languages here at Okta. And there are diehard Ruby, Python, C#, Groovy, and Kotlin fans in our midst. While we tend to write about the most popular languages on this blog, at the end of the day we’re also curious developers. We like to learn new things and try to keep an open mind.

Do you hear about other Java myths you feel compelled to refute? Did we miss any you agree with? Let us know in the comments!

If you’d like to read some tutorials about using Java and JavaScript, check out these links:

For more fun tech talk, follow us @oktadev on Twitter or subscribe to our YouTube channel.