Java is dead. Leave the sinking ship, Kotlin, golang, whatever it is, learn another language!
Is that really true?
History
Let's look at the history first. I've been doing Java development since about 2005, starting with embedded devices programmed in J2ME. Java SE (or J2SE) was already at version 1.5 but in J2ME, the language was compatible with Java 1.3 and only a subset of the JDK was supported. E.g., it didn't even had any Map implementations.
At the time of writing, Java 13 has already been released and it's been a hell of a journey. Since Java 1.3 over the past 17 years we've had features like those being added:
| Java Version | Selected Features |
|---|---|
| 1.4 | Regular Expressions, Non-blocking I/O |
| 5.0 | Generics, Annotations |
| 6 | JAX-WS, JWM + Compiler extensions |
| 7 | Dynamic languages support |
| 8 | Lambdas, streams, optionals |
| 9 | Module system, JShell |
| 10 |
var keyword, Graal |
| 11 | Running Java files like scripts |
| 12 | Switch expressions |
| 13 | Text blocks, Class data sharing |
NIO is still the base of non-blocking and reactive web frameworks. Without annotations, aspect-oriented programming that e.g. the Spring framework leverages would have not been possible. Extensions of the compiler made Lombok possible. Lambdas, streams and optionals moved Java closer to a functional programming style (although it's still not a functional language) and allowed to reduce the amount of boilerplate. Switch expressions are a little step on the road to pattern matching (see section below). And dynamic language support made it possible or at least easier to bring dynamically typed languages like Ruby and Python to the JVM.
Sources:
- https://howtodoinjava.com/java-version-wise-features-history/
- https://en.wikipedia.org/wiki/Java_version_history
Java = JVM + Language
When we talk about "Java", we should actually talk about the Java Virtual Machine (JVM) and the Java language.
When you run a Java application, the Java source code (*.java) first has to be compiled to Java byte code (*.class) which is the same on all platforms, hence the slogan "Write once, run everywhere". The byte code is optimized to be interpreted and run fast instead of directly interpreting the Java source code as it is done with JavaScript e.g.
The JVM itself is a platform specific implementation (e.g. Linux, Windows, Mac) of a Java runtime. It basically takes the previously generated byte code and runs it on the target environment. In the early versions of Java, the byte code has been interpreted which was relatively slow. From Java 1.3 on, the HotSpot VM which is a Just-In-Time (JIT) compiler has become default. It identifies high-frequently run code (i.e. the "hot spot" within the code) and compiles the byte code to native machine code which is much faster.
Since then, a lot of smart people at Sun / Oracle have improved the the JVM to be extremely fast. And by "extremely fast" I mean comparable or even faster than an equivalent C++ implementation because the JIT can generate more optimized machine code based on the known CPU and knowledge about the actual code and data flow at runtime.
Don't Follow the Hype
That is the reason why the JVM ecosystem is flourishing, setting the stage for a whole set of new language that compile to Java byte code:
- Groovy
- Clojure
- Jython
- Scala
- Kotlin
There is a long and growing list of others.
Recently, I found this in my twitter timeline:
This looks amazing right? First, let's have a look at what it is. It's the percentage of questions asked about that language that month. So, Kotlin is a relatively new and also popular language, no doubt about it. So, naturally, a lot of people are asking questions.
But wait... one language is missing! What about Java?
So, Java has still about 10 times as much questions as Kotlin which has passed Scala. What about popularity?
Source: TIOBE Index
Although the graph is declining, Java is still #1 (I know, I know, TIOBE results are debatable). Let's see where Kotlin and Scala are... Rank 30 and 35, respectively.
Ok, what about job opportunities? As a Java programmer, you don't have to search very long to find a decently paid job offer in the industry. There might be languages that will provide a higher salary but they are harder to find.
So don't get me wrong: I love new languages, especially when they bring new concepts that expand your horizon a bit and push other languages to adapt faster. Go and learn them!
I've learned and used a lot of different language, starting from BASIC, Pascal, Assembler, C, C++ over Erlang, Scala and Python and most recently TypeScript.
A few years ago, Scala for example has been hyped a lot. People were saying that it is going to replace Java. Although Scala has some very appealing features, eventually it didn't.
Currently, Kotlin is hyped a lot as well. It has some strategic advantages compared to Scala as it is pushed by both JetBrains (the makers of IntelliJ) and Google (Kotlin is the language to-go for Android development) which allowed it to quickly gain traction. And it's a great language for sure. But similar to Scala, I don't believe that it will replace Java.
When switching from Java to another language, there are always issues. Some things are just not working as they do with Java, some things are not compatible, some tools are not available. Whatever it is, this results in less people either want to or succeed at switching.
So the next time you'll hear news like "Mega Corp. uses the new XYZ language" doesn't mean the whole company does. Maybe it's just one or two teams of a 100.000 employees. When a new language has "that great new feature" that Java doesn't have, it doesn't mean it can easily replace Java, the JVM, the community and Java's tooling.
So why is Java so successful?
In my opinion, it is the result of a couple of different factors:
- The language is relatively easy to learn and has a similar Syntax as C and C++
- The language is relatively stable, backwards compatible (Java 9, oh, Java 9)
- It is still able to adapt to new paradigms and technologies
- The JVM is a pretty damn fast runtime (see above)
- A lot of large companies are running their business on it which simply means: Job opportunities (see above)
- You'll virtually find any problem already solved as an open source library with licenses that allow commercial use
- The tooling is pretty great
The Future
So after looking at the status quo, let's have a look at the future. There are a lot of promising projects that are planned to be included in one of the next releases.
There are already a couple of in depth articles, so I will just briefly mention them here.
Loom
In my opinion, Project Loom is one of the most game-changing additions to the JVM and the language. It might appear to be rather uninteresting at first glance: Loom will bring "Fibers" aka. light-weight threads to the JVM. So why bother?
Unlike threads, you can run millions of Fibers, which have a low memory footprint, on a single core. Using Fibers, you can build continuations and tail-call optimizations which in turn allow to build non-blocking code that looks synchronous but does not block a thread. That means no code cluttered with chained callbacks or observables as it is common in e.g. vert.x or RxJava. I've written about it here:
https://dev.to/stealthmusic/dont-drink-too-much-reactive-cool-aid-20lk
Graal
Graal is another candidate for a game changer, in my opinion. Graal is actually not a single "thing". There is the GraalVm compiler that implements the new compiler extension API of the JVM to replace the existing JIT compiler with a JIT compiler written in plain Java. Then there is GraalVM Native Image that allows to compile Java code to a native binary which can drastically reduce memory usage and increase startup time of an application from seconds to milliseconds.
Although this sounds amazing and you can already try it, it is still in an early phase. I tried it myself and it was far from being production-ready or even just easy to use. It doesn't play well with frameworks or library that use reflection a lot (Spring, Hibernate). Without further insight, Graal will compile Spring Boot application with JPA to a native image with a fall-back work-around that simply bundles and runs the JVM and JDK within the image which doesn't give you the above advantages.
There are frameworks like Micronaut and Quarkus popping up that allow to leverage the full potential of native image though and I know that the Spring team is also working hard to get it working with Graal.
This might allow to use Java applications in areas where golang currently shines and fast a start-up and low memory usages is a must.
Amber
Project Amber brings data classes and sealed types to Java. It is a language feature and attempts to reduce the boilerplate code that is needed when created a POJO: Some fields, getters, setters. It will allow you to write something like record Point(int x, int y) { }.
The features that Amber brings will also make it easier to implement pattern-matching.
There are a couple of ideas to pattern-matching. The first was switch expressions which has been released as a preview with Java 12 that allowed to directly assign the switch expression result to variable e.g.
Pattern matching in instanceOf will make it easier to work with unknown types and render type casting ofter an instanceOf obsolete.
Then there is object deconstruction that allow to extract parts of an object or list into into its components:
int eval(Node n) {
return switch(n) {
case IntNode(int i) -> i;
case NegNode(Node n) -> -eval(n);
case AddNode(Node left, Node right) -> eval(left) + eval(right);
case MulNode(Node left, Node right) -> eval(left) * eval(right);
};
}
This replaces a lot of code clutter that would be necessary to implement the above.
And what would be really cool is pattern matching in methods (not sure if this planned):
int multiply(0, int b) { return 0}
int multiply(int a, 0) { return 0}
int multiply(int a, int b) { return a * b}
Valhalla
Project Valhalla attempts to allow immutable (great for concurrency) reference-free objects. An array e.g. is currently a list of references to its values instead of a list of the values itself. It will also allow to use primitive types (such as int e.g.) as generic types. E.g. List<int> instead of List<Integer>.
Conclusion
So, to conclude, I honestly don't think that Java is dead. It has an active community, a rich ecosystem including tooling, a ton of libraries and frameworks, it is able to adapt and evolve while being backwards compatible (mostly) and it is still widely used in the industry.
Cover Photo by Shoot N' Design on Unsplash
Top comments (54)
Java was a leader at first. But then many years of lagging C#'s innovations made me jump ship.
Java still doesn't have an IDE remotely close to Visual Studio. But alas none of that matters because Node and Javascript/ Typescript will displace .Net and Java. The new word is Isomorphic design, and it's already taking root.
Funny thing is, I forgot to mention that I’m doing Typescript professionally...
I’m using IntelliJ for both Java and Typescript and it’s an awesome IDE, I am amazed every day by the ingenuity. But I haven’t tried Visual Studio recently. Are talking about VS Code?
Although in some aspects, typescript is a fun language, I have to admit that I am really happy when I’m going back to Java during Full Stack development.
For C# it's Visual Studio the big brother of VS Code. I use VS Code for all Typescript development. Its Git integration is nice. Our backend is .Net core / C#. Haven't yet gone pure Typescript but will soon.
Talking about IDE's, I used to code on VisualStudio, now when possible I use Rider, as it's from jetbrains and it's what i'm used to(I'm an Android Developer, so AndroidStudio).
My problem with visual studio and vscode are that they are bad out of the box (in my opinion), while Webstorm, Rider and IntelliJ are great out of the box.
But the main thing is: use what you like, there are no perfect IDE, there are many options, and some are better than others in certain points.
Yes indeed, I recently worked in two very large companies where Intellij was king. Here in Minneapolis, most of the really large banking and retailing operations are all Java shops; which surprised me, the .NET guy.
I've worked with a couple of IDEs so far, Visual Studio (very long time ago), Eclipse, NetBeans, XCode and since 6-7 years, it's IntelliJ. It is just so well engineered, beautiful and fast, there is just nothing I can complain.
But, the IDE is just a tool. So whatever you're productive with is fine.
You know the IDE is good when you hardly even have to type.
I do both Java and C# and I have been very disappointed in Visual Studio. There have been times when my whole machine slows to a crawl as VS does... something. In my opinion, IntelliJ IDEA provides a better experience then Visual Studio.
When my work becomes more .Net Core heavy, I look forward to putting Visual Studio to the side and spending more time with IntelliJ Rider.
We always used Eclipse because it was free and pretty solid. Never used IntelliJ. Used Netbeans and the windows hotkeys for copy and paste didn't work in it so I was done almost immediately. Also, the merge preview feature for svn and git was command line which was a joke.
Well, one of the worst things I ever tried was Visual Studio. Constant lock downs, slow downs, slow detection od writing and such. Live code was interesting thing but it's just too heavy. I get that people use a lot of stuff from it but for us where text/code is more important than features yet we still like smart code suggestions and smart search IntelliJ benefits more as VS does tend to slow down quite frequently or even freeze.
Btw I did use 2017 and 2019 version recently so it's not the issue with old versions. I'm not saying it's bad just that it got me frustrated MORE times than IntelliJ did (meaning intellij gets me also but everything does so its quantity that matters). VS Code on the other hand was great (of course even this one crashes or freezes but rarely happened to me). The only reason I'm not switching to Code is IntelliJ's smart code suggestions and cleanups.
Yeah, sometimes I also get frustrated about IntelliJ but then I’ll check the task Manager and find out that my company virus scan is slowing everything down to a point where even auto completion takes 10s 😞
I'm a software engineer who has recently moved over to C# using a tonne visual studio.
Intellij is years ahead of Visual Studio, JetBrains just have it right. I'd say the best thing about VS is Resharper, also JetBrains.
Luke, I couldn't disagree more. My last Intellij experience with Java, just last year; was majorly painful. The developers used so many plug-ins and non-default configurations, that not even they knew what was needed for a new install.
It took us 6 weeks to smooth out the rough edges. Oh they'd say, we don't use Maven, we use Gradle, then they say you need this or that like access to the super-secret class repository they had. Totally frustrating.
Ok, that sounds pretty bad. Usually, the best idea is to keep everything default.
That question: how is any of this IntelliJs fault?
It's not IntelliJ's fault other than its default set up didn't appear to be what our developers wanted, so they added tons of stuff and they didn't seem to have a standard install. I went to IntelliJ site and downloaded it, but that was just the start of trouble for me.
Visual Studio will install everything you need from the start except MarketPlace add-ons. But no market place add on is an absolute dependency for VS to function.
Did you use Ultimate or community version? The latter certainly has a couple of things missing, but the defaults of IntelliJ are based on language defaults and common sense. If it needs a lot of configuring in your team, then your team is probably far from standards. All settings if IntelliJ can be exported and shared, BTW
I was just assuming that... As mentioned in one comment above, I've worked with XCode and it felt like the stone ages compared to IntelliJ
Great article, but the callback APIs in Vert.x allowed to implement the other "higher level" or better alternatives very easily. For instance Kotlin Coroutines based methods... and also Promise/Future based versions.
BTW: I think Fibers are only the pendant to other languages coroutines implementations, right?
Yes, coroutines are a way to implement synchronous looking asynchronous code.
Fibers are a JVM feature as an alternative to heavyweight threads. On top of that, you can build coroutines as a language feature. You can also build Erlang-style Actors without any hacking like byte code manipulation.
So, I guess It's also a big win for Kotlin and Scala. However, what are "lightweight" threads? I guess I understood Coroutines in general, that when the thread would be blocked by I/O for instance, a suspending function suspends itself and a continuation is stored in a scheduler. The thread can do other things until a scheduler decides, that the suspending function / continuation should be resumed on whatever thread/thread pool is specified when I/O is done. However, here threads are always heavyweight and the Coroutines in Kotlin are called Lightweight for instance. However, what the JVM add as lightweight threads? Have to read again about fibers. I think that's like the distinction between the upcoming record types (data classes in Kotlin) and the JVM value types. There, I also have no clue what value types on the JVM mean.
First, there are couple of talks on YouTube if you want to get into the details, e.g. youtube.com/watch?v=vbGbXUjlRyQ
Your assumption about coroutines is right. Fibers is the underlying JVM concept. A fiber is basically a data container that is able to hold stackframes (e.g. local variables) as well as pointer that knows the current location in the code. When a operation blocks, the pointer is saved and the OS thread can be used to run another Fiber until the data is available and the initial Fiber resumes the code using the pointer and the stack.
Record types are basically syntactic suger. If you want to write a simple data holding class that has a couple of fields, a constructor and getters and setters, you can simply use
recordand you don't need to actually write all that but you can still use it.Value types are a memory optimization in the JVM where you can actually pack all primitive types (int, String) and arrays in a sequencial order in memory without the needs of references (pointers).
Thanks a lot, will watch this talk now. I assume Roman and his team use some workaround / not the optimal solution to implement in Kotlin Coroutines without this JVM enhancement. But that said it'll help Kotlin as well.
I have to say Kotlin might be hyped, but almost all items from Effective Java for instance can be implemented much easier and the defaults (for instance that classes can not be extended per default are much better -- should probably be like that as it's just a few years old). Also I think Generics for instance are much better implemented/easier to use as well as the non null type hierarchy and a lot of other stuff is great. Nontheless, I still mostly (have to) write Java code in my day to day job and I hesitate to mix Java/Kotlin in one module in a multi maven module project of mine :) but I use it in one module exclusively (using Vert.x and its Coroutine based API, which I think is really great).
Yeah, maybe that’s a nice way to sneak in new language to just mix them. 😉
However, if you’re working in a team in a larger code base, you will need to get a team agreement first.
It's funny you start with a ship analogy. In a discussion recently Java was the mammoth tanker, moving steadily, but slow. It has some advantages. Like with new features it can look at some of the other JVM languages and learn from it, to do it right the first time. These is some disadvantage to being backwards compatible. Like nullability which seems better in Kotlin. But if you make wrong assumption in nullability in Kotlin the whole program crashes. While in Java you can do the same, check at the borders, you do need a bit more disapline.
Kotlin does one right thing: clearly separates nullable and non-nullable types and lets compiler do the rest. But same thing is possible in Java by using class like Option (Optional does not always does the job) to mark nullable values. There are more details about this approach in my article
Option could still be null. There are several annotations that could help with nullability but some work compile time and some runtime, it's easy to get it wrong.
Annotations are useless. And this is just a matter of properly handling of null values coming from external code and matter of habit to use Option where value can be nullable. There should be no cases when Option itself can be null. In fact this is extremely convenient to assume that all variables are not null and removes a lot of headache and mental load. But, well, convenient use of this approach is impossible without a significant doze of functional code. Which is good too, but, of course requires changes in habits and mental model.
Thanks for this comment, that was exactly my point.
😄, I used to have questions like which language is better ? After discussing with my friends and listening to people online, I realized that Its better to stop asking these questions. Instead start asking which tool is better for current Job and Trend.
Choose the right tool for the Job.
C#orJavafor building enterprise and large applications.JSFyou can think of usingAnuglar orReactorVueetc. for Front End.Pythonfor Machine Learning.Gofor Micro Services based performant applications.In future maybe today's Languages and Framework may be outdated, so to survive you will be forced to learn new language of that time.
Conclusion:
Developer Happiness, stick to the language which make your life easier, like easy to read syntax, maintainable, has Good IDE. I like C# for current work, and its up-to you to decide what you like.
Its always good to be Open to learn any language as required and Choose the right tool for the Job.
Hope this helps.
I work for one of the biggest names in IT. If you want to get work for a client, you would be best served by knowing Java. If I had my wishes, I would do C# or Python, but those are in far less demand with Python being a trickle of opportunities. My current and last project even included mainframe with one converting mainframe batch jobs to Java Spring Batch.
Spring is an excellent technology: boring, dependable, never surprises, and you can upgrade for free new features with minimal breakage. That's exactly what I want when I have to deliver value with as predictable a pace as possible.
Java definitely requires modernisation, but main one lies not in the language itself, but rather in the ways and approaches we're using to create applications. Lightweight frameworks, reactive design, compile-time reflection, functional style, exception-less processing and much more - all these things will affect Java ecosystem far more than any new language feature.
Unfortunately, existing libs (including java standard library) and widely used frameworks rarely support this style of programming, so switching to it will be much harder and longer than adding some new feature to language itself.
Java will be still forced on us by those dinosaurs people who have industry experience of 20 years or so. They don't care about new changes in tech. They continue to put the govt and top 500 MNCs under java. And god, I would rather play with npm breaking all day than wasting my system resources trying to set things up with java. No thanks. Even in 2019 with 16GB RAM, Eclipse is slow on macbook and also on Windows 10 laptop. Give 100GB RAM and Java promises you to slow things down. Java is not dead. But please atleast put her in retirement home now.
Bad programs can be written in any language. And Java is not an exception. But it's also possible to write fast and efficient apps in Java.
So if your saw slow and bloated apps, it's not Java to blame. Usually behind such apps one can find two things:
Such combination can produce artefacts of unlimited size with infinite resource consumption.
But, again, Java has nothing to do with that. Same issue can be found in projects written in other languages.
Very well put!
Wow, I can sense a lot of frustration from your comment. I actually don't know where you are working or where your experiences comes from but it sounds pretty bad.
I can only speak from my experiences, but most Java developers I personally know are young, smart, motivated and care a lot about changes in tech.
So I think you should not blame Java for your bad experience.
Regarding the IDE's, you can use any IDE or even an editor to code. No one forces you to (And if someone does, it's probably bad leadership). IntelliJ and certainly also Eclipse are very powerful tools. That requires a lot of RAM. So if you don't need all those features, go and use vim, emacs, VSCode or whatever you like.
I would rather finish my job, deliver value to my clients and go home on time, thank you.
I may be a dinosaur, but I'm appalled by how you can be hacked because your dependency management system can execute code instead of just downloading it. The Java ecosystem solved the dependency problem 15 years ago, and it is much much harder to publish malicious code with it.
And if Eclipse is slow on your macbook with 16Gb... that's strange, because I used it for years on 3-to-5 yr old Pros and Airs with that and lower specs and never had a problem. You should probably invest on an SSD, it'll do wonders for your work. Now I have Win10 both at work and at home, and the difference between SSD (work) and magnetic (home) is abyssal, even if the CPU specs and the equipment age are very close.
Have fun with whatever stack you choose 😁
It comes round every few years or so, this or that language is dead. Some new language jumps ahead.
They said it ages ago about C, but it's still alive and kicking.
Given how much tech is written in Java, it'll be being maintained for decades to come.
Absolutely! The mere fact that many companies are still choosing to use Java as thier primary enterprise language in new projects, shows how much value is placed in Java. C# is close, particularly due to the advent of MS Dynamics and such like, but frameworks like Spring still give a huge amount of flexibility and power to the JVM.
It certainly will be interesting to see where Java goes in the Future, both as a language itself, and in the development of the JVM in competition with other Platforms.
Only a fool would assume that.
I already cashed my dollar for the n-th "Java is Dead" article. It's at least 15yrs that they give me a steady revenue flow 🤣
How can I join? 💰💰💰
It's fun how you get excited about upcoming (or not)features of Java which have been in C#, like, for years. And we're still coding in a language where comparing two same strings might result in false... and you have to use "add"or "subtract ( )" methods instead of operators. Java is dead on the inside, like a zombie
As I said, it's actually not a problem that other languages are ahead and try things out. That's certainly no reason to switch to a new language.
To your other points:
==compares references so every Java developers knows after month or so to use.equals().But my article was not intended to convince you to use any other language. Use the tool you're happy with.
The recent 6-months release cycle is trying to reverse the trend that started in the early 2010. Java was far ahead of C# until 2011-2013 maybe, and then remained still for years waiting for 7 and 8 while C# was first reducing the distance, and the hopping forward in leaps and bounds. Now we're closing in again, and the JVM platform is already so competitive with the .Net one that choosing one or the other is a matter of available skills or choice.
The JVM is stronger than ever, and getting all the latest in innovation and research. Java is playing catch-up with both the internal (Scala, Kotlin) and external (C#, F#) competition, but its appeal as boring, dependable technology is far from gone.
Great summary 👍