DEV Community

Cover image for Java is Dead - Long Live Java
Jan Wedel
Jan Wedel

Posted on • Updated on

Java is Dead - Long Live Java

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:

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?

Java Stackoverflow results compared to other JVM languages

So, Java has still about 10 times as much questions as Kotlin which has passed Scala. What about popularity?

Alt Text
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);
    };
}
Enter fullscreen mode Exit fullscreen mode

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}
Enter fullscreen mode Exit fullscreen mode

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 (55)

Collapse
 
jwp profile image
John Peters

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.

Collapse
 
stealthmusic profile image
Jan Wedel

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.

Collapse
 
jwp profile image
John Peters

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.

Thread Thread
 
shogogan profile image
Victor Homem Heck

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.

Thread Thread
 
jwp profile image
John Peters

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.

Thread Thread
 
stealthmusic profile image
Jan Wedel

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.

Thread Thread
 
matthewekeller profile image
matthewekeller

You know the IDE is good when you hardly even have to type.

Collapse
 
cmiles74 profile image
Christopher Miles

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.

Collapse
 
matthewekeller profile image
matthewekeller

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.

Collapse
 
_hs_ profile image
HS

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.

Collapse
 
stealthmusic profile image
Jan Wedel

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 😞

Collapse
 
lukegarrigan profile image
Luke Garrigan

I'm a software engineer who has recently moved over to C# using a tonne visual studio.

Java still doesn't have an IDE remotely close to 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.

Collapse
 
jwp profile image
John Peters

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.

Thread Thread
 
stealthmusic profile image
Jan Wedel

Ok, that sounds pretty bad. Usually, the best idea is to keep everything default.

That question: how is any of this IntelliJs fault?

Thread Thread
 
jwp profile image
John Peters • Edited

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.

Thread Thread
 
stealthmusic profile image
Jan Wedel

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

Collapse
 
stealthmusic profile image
Jan Wedel

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

Collapse
 
johanneslichtenberger profile image
Johannes Lichtenberger

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?

Collapse
 
stealthmusic profile image
Jan Wedel • Edited

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.

Collapse
 
johanneslichtenberger profile image
Johannes Lichtenberger • Edited

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.

Thread Thread
 
stealthmusic profile image
Jan Wedel

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.

Thread Thread
 
stealthmusic profile image
Jan Wedel

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 record and 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).

Thread Thread
 
johanneslichtenberger profile image
Johannes Lichtenberger

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).

Thread Thread
 
stealthmusic profile image
Jan Wedel

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.

Collapse
 
gklijs profile image
Gerard Klijs

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.

Collapse
 
siy profile image
Sergiy Yevtushenko

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

Collapse
 
gklijs profile image
Gerard Klijs

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.

Thread Thread
 
siy profile image
Sergiy Yevtushenko

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.

Collapse
 
stealthmusic profile image
Jan Wedel

Thanks for this comment, that was exactly my point.

Collapse
 
shaijut profile image
Shaiju T • Edited

😄, 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.

  • Based on your experience, you can use C# or Java for building enterprise and large applications.
  • Instead JSF you can think of using Anuglar orReactorVueetc. for Front End.
  • Python for Machine Learning.
  • Go for 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.

Collapse
 
matthew_s_brown profile image
Matt Brown

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.

Collapse
 
michelemauro profile image
michelemauro

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.

Collapse
 
siy profile image
Sergiy Yevtushenko

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.

Collapse
 
maheshkale profile image
Mahesh K

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.

Collapse
 
siy profile image
Sergiy Yevtushenko

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:

  • slow, bloated, but very popular and widely used "safe choice" frameworks.
  • young programmers, who learned only couple popular frameworks to be "in trend" and get first job quickly.

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.

Collapse
 
stealthmusic profile image
Jan Wedel

Very well put!

Collapse
 
stealthmusic profile image
Jan Wedel

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.

Collapse
 
michelemauro profile image
michelemauro

I would rather play with npm breaking all day

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 😁

Collapse
 
andrewharpin profile image
Andrew Harpin

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.

Collapse
 
stevematdavies profile image
Stephen Matthew Davies

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.

Collapse
 
amineamami profile image
amineamami

Only a fool would assume that.

Collapse
 
michelemauro profile image
michelemauro

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 🤣

Collapse
 
stealthmusic profile image
Jan Wedel

How can I join? 💰💰💰

Collapse
 
gajatko profile image
Jacek

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

Collapse
 
stealthmusic profile image
Jan Wedel

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().
  • I consider operator overloading actually harmful but YMMV.

But my article was not intended to convince you to use any other language. Use the tool you're happy with.

Collapse
 
michelemauro profile image
michelemauro

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.

Collapse
 
stealthmusic profile image
Jan Wedel

Great summary 👍

Collapse
 
chrisza4 profile image
Chakrit Likitkhajorn

Java is dead. Leave the sinking ship, Kotlin, golang, whatever it is, learn another language!

I think Java is here to stay. The Java technology itself is a cool technology, especially the JVM. I never see anyone claim that Java is dead, but my experience might be different from you.

However, I think we should also learn another language. Learning other languages such as Kotlin, Clojure, Scala, Golang, Haskell, Elixir, etc. will open developers up to a new design pattern and paradigm. Programmers will understand that Java design patterns are not be-all-end-all best practices in programming.

I like modern Java. I annoyed by some Java developer try to enforce Java design pattern to other language and then complain about how the code is not clean. I annoyed by some people attitude around serious enterprise technology is holier-than-thou. Of course, that is not a Java fault at all. I just share where my frustration around Java come.

Collapse
 
awwsmm profile image
Andrew (he/him)

This is a great article, Jan, thanks for writing it! I have a piece coming out soon about updates to Java since Java 8 was released and I'm sure I'll refer to this post as I'm putting the finishing touches on it!

Collapse
 
stealthmusic profile image
Jan Wedel

Thank you, looking forward to your article.

Collapse
 
_hs_ profile image
HS

Great post, finally summarised stuff I talked about to a lot of people. Kotlin was supper good looking easy etc but it some problems in the beginning when I tried to integrate it with Spring. Of course now it's super fine with a lot of stuff but Java 11 then 13 happened so it was much easier to rewrite project to new Java rather than new language. Clean up a code with vars and there you go :D. Data classes and lombok didn't provide me much as my domain models usually don't have getters and setters and response/request classes are mostly written by Alt + Insert and choosing getters and setters in IntelliJ. And Scala was hard to learn because I had to learn also new frameworks and crazy stuff from Erlang like Actors (ok those are older but Erlang was famous for implementing them). So I postponed it and left it to learn later, in case I need more performance with large data. Meanwhile Java got faster with Rx and I'm still waiting for fibers to clean up the mess I made with --> some(this::linked).map(x -> calls(x,"anothervar")).toList().toMaybe().

I just still miss very much ?. and ?? from C#. Or Kotlin ones i think ?:. That's about it. I agree with a lot of people on Kotlin looks better but I still don't see that much benefit. And begin more functional does not solve every problem. Neither does immutability. If you have problems with state it might be framework or your code some times not mutability itself. Data classes from Kotlin gave me so much more code to write because I needed to let users enter wrong stuff and validate it to get correct error message to them rather then being unable to compile or hacking a way through getting good enough messages. I guess it's my code writing style that keeps me from new languages. I even considered learning Elixir because I like the syntax and it's great for real-time stuff but even it's developers admit that it's slow in some cases where data is big and slow to process. So I'll wait for loom :D

Collapse
 
stealthmusic profile image
Jan Wedel

Sounds like a good plan to me 😊👍

Collapse
 
matthewekeller profile image
matthewekeller

Strongly typed languages are easier to understand and maintain. People can "play smart" by acting like they are too smart for java but in the end the money will follow the paradigm that works the best and is the easiest to maintain. Java is a lot like C and Pascal but helps you avoid mistakes that you can make in those languages. A coding language is simply a collection of types, if statements, and loops. Like the game of chess you can make complicated things our of simple components but the beauty of it is the simpleness at is root, and java is like that. Nodejs, on the other hand, is an overcomplicated mess with a learning curve that has no practical justification in bothering with. I love javascript for manipulating the DOM on the browser where it belongs, but I hate the API centric world of Agular and React that tell me "I'll write HTML for you". Writing HTML and doing DOM operations was so difficult right .... no it wasn't.

Collapse
 
mohsenabn78 profile image
mohsen

Thanks. This article is very good. Java is best and we love java