"While still important and definitely not legacy, Java is not one of today's growth technologies," said Torsten Volk, an analyst at Enterprise Management Associates in Boulder, Colo. "All of these traditional Java vendors should be focusing on pivoting toward today's fast-growing stuff, such as Python, JavaScript and Node.js."

That strikes me as a profoundly ignorant statement. Most of the value in the Java ecosystem lies in the JVM. There are many languages running on it, Java is only one. Java has improved a lot, but Scala and Kotlin both provide alternatives with their own strengths. Clojure also has a vibrant community.

As more focus centers on datacenter efficiency, I suspect there will be a move away from JS and Python as they both have performance limitations based on design.

Java is much stronger in that regard, but it'll be interesting to see how the newer AOT compiled languages do - Julia, Rust and Swift.

Java is a fine language, and the JVM is a powerful environment that enables some really cool things - Kotlin and Scala prime among them. That said, I wouldn’t be surprised if we are past peak Java/JVM in terms of new projects and developer mindshare. Java was an excellent tool for a world where ecosystems were rather self-contained, lots of code had to be written in-house, and source code distribution platforms and good tooling for cross-language development weren’t nearly as prevalent. A developer could basically do everything they needed in Java, unless they needed super-performant code, in which case they’d drop to C/C++.

The proliferation of great new languages, stellar package managers, and comprehensive tooling have reduced the need for a single, do-it-all language. Now, there are a wide variety of languages that are better fit for specific domains (I.e. Go is very good for small services, python is good for data science and prototyping, rust is good for system programming, typescript is good for Frontend, etc), and the barrier to entry for all of those languages in a professional environment is lowering (if not already low). To me, this means that the next generation of developers will be versed in several of these more domain-specific languages, rather than spend their career working with a single language. Java may well be one of these languages, but I see a possibility that it will gradually fade out of mainstream greenfield development. Of course, the world is now built on the JVM so it will stay for a very long time, but maybe not for new projects.

Our agency does mainly Java, .NET, C++, JavaScript.

Any candidate needs to be very strong to warrant the respective department to replace one of those pillars.

That's great news. I'm personally more a Python fan, but I see all around me how good, stable enterprise problems are solved by Java coders. Last Java version I used was still pre-Oracle, so I can't say if they did a good job or not. But I can say when it comes to open source I have much more trust in Red Hat as a company.

At my work place, I have recently switched to java 8. As I do not like Oracle, I really welcome the replacement of Oracle by Red Hat. Good ridance. I wish java had nothing to do with Oracle.

The actual people doing OpenJDK development and research of new features are mostly on Oracle's pay check, regardless of which company is doing maintenance.

Lets not forget that besides IBM, which only made a single offer, no one else cared about saving Sun's assets.

So had it not been for Oracle, which even kept Maxime alive and made it into Graal, Java would have been effectively stuck and version 6, and the only new Java projects would be migration ones.

That's an interesting point.

It seems everybody was overinvested in Java but nobody wanted to take care of it. And then Oracle, as much as it was "for bad reasons" took it and keeps developing it.

So Java was Priceless and Worthless at the same time it seems.

Exactly, Google had the perfect opportunity to own Java, tailor it to their vision and avoid the lawsuit altogether. No reason to complain afterwards.

Never-mind Google, Java being the behemoth that it is, would have been better off if it ended up at Apache Foundation or some other neutral third party.

> The actual people doing OpenJDK development and research of new features are mostly on Oracle's pay check, regardless of which company is doing maintenance.

That's only because Oracle hollowed-out the JCP (Java Community Process) and reduced its function to rubber-stamping Oracle-developed tech. Java was the crown-jewel they paid for - they had the right to do what they wanted with it; but to be clear - it wasn't the community/other companies slacking, Oracle chose to do R&D of Java internally because they wanted to control the roadmap.

Oracle has been part of Java community since 1997, presented quite a few Java related ideas alongside Sun and IBM like the NC, had their own JVM, was the first RDMS vendor to support Java as stored procedure language, is active addiding AOT support, a 3rd party feature only, considered tabu at Sun with JIT über Alles as the only true way, and JEP process is much more open to 3rd parties than JSRs ever were under Sun's management.

There is plenty of Red-Hat, Amazon, Alibaba, ARM, Intel tech on OpenJDK, which doesn't hide the fact that the large majority of OpenJDK developers are Oracle's employees.

Haters are going to hate, no matter what.

Why Java 8 and now directly 11 or 12? 8 is already at the end

We are at JDK 8 now too and will move towards the next LTS (JDK 11) near the end of the year. The transition from Java 8 to Java 11 feels more involved than the transition from Java 7 to Java 8 was. Everything seems to work, but a lot of major libraries are still throwing lots of warnings, and to really get the most out of the transition developers and existing codebases should get comfortable with the new module system as well.

Moving to a non-LTS release (12) is a non starter of course.

It's kicking the can a bit, but there's the "--release 8" javac flag you can use in 11.

9, 10 and 11 are following a new release schedule of timed releases (every 6 months), whereas 8 was still a traditional feature release.

I would say that aside of the module system that came with a huge list of now inaccessible internal methods that a lot of dependencies relied on even though they shouldn’t have, there was even more change between 7 and 8 than there was between 8 and 11

Yeah, Oracle changed what one major version upgrade meant from JDK 8 onwards. For production purposes JDK 9 and 10 effectively don't exist.

There's still a heap of stuff that doesn't work on Java 9+ (for example, we use Apache Flink which is planning support but isn't there yet). Like Python 2, Java 8 will stick around at least until there aren't any blockers for getting off it.

Yep, I'm the same - Spark will be stuck on Java 8 until it is rid of logj12, not sure what log4j1 is doing, but it doesn't work on Java 9 and Spark's Hadoop dependencies are riddled with log4j12. What's nice to see is that that log4j2 team have been helping with the work in the Spark project.

>not sure what log4j1 is doing

If it's the bug I ran into then their code to detect running on a legacy JVM is tripping with the new JVM version numbers and it thinks that it's running under ancient Java 1.x. It's then saved in the org.apache.log4j.helpers.Loader.java1 field.

To migrate some code that needs log4j12 to more recent versions of Java I ended up writing a hack that accesses Loader before log4j uses it and manually sets that field to "false"

Lots of stodgy Fortune 500's have tons of Java 8 still around. RedHat will deepen those relationships by giving those companies a cheaper path than Oracle for support.

Java 8 is "at the end" according to whom?

Also note that 9 and 10 were basically alpha versions. Nobody deployed 9 and 10. And 12 will probably have the same fate.

It was eol-ed this January for commercial use.

That's for Oracle's build only. OpenJDK 8 is alive and well, with Red Hat leading the supports.

It's nice to hear from Cameron Purdy and TheServerSide. Two important sources of Dev Info from many years back. (Circa 2000 or so for TSS?)

2020 of course

While Java certainly has a value for a maintenance, because of the troves of legacy projects, I am not sure why anyone would want to start a new project with it. From Scala Native, Kotlin Native (closer to Java world) to Elixir (Beam VM), from Rust to OCaml, from Go to F#, etc. I wish all these money and efforts were directed to development of newer, better languages, rather than reinforcing Java. I was pleasantly surprised to see that recently linked Mercury startup uses Haskell.

I learned to code in Python, I loved Erlang, I dabble in Elixir when I can, and I loved F#, and I code in Scala, Kotlin,Java, JS and Python in my day to day work, depending on where in the codebase I am.

The things that are hard to beat about the Java world is the ecosystem, the tooling and the package management. Stuff more or less works without too much hassle, there's often a good library for what you want to do, and you're building on decades of previous industry work.

In terms of package management, the most unreliable parts of our project are Node and Python.

in what way are they unreliable?

both can be proxy-cached on your local network to remove external dependencies.

both have ... uuuh... okay package managers (poetry/pipenv for python, npm/yarn for node) with *.lock files to properly define their dependencies. How does this differ from maven/gradle?

honestly, i prefer the node/python package management. Maven/Gradle is just so incredibly extensible making it insanely powerful.. But it comes at the cost of complexity and developers being unable to actually understand whats happening.

Because some guy in some library used by a library in an SDK I use didn't set a fixed version for his dependency which has been updated and has a serious bug in it... My app isn't working. Now I have to go through my requirements and set the exact versions that worked last time we released, have an enormous requirements file, and I'll probably never touch it again and have stale dependencies. Yeah... I don't like pip

Can't generate a lockfile if conflicting dependency requirements exist. I type pipenv install --skip-lock far too often.

Why not Java ?

The JVM is now better than ever, the language is modernized, the library ecosystem is excellent. If you don't like the systax, alternative languages are well-developed and intergrated.

Java has been a pretty usable language since java8 and become steadily better. There is a lot of bikeshedding going on, but you can create pretty neat stuff with very little code.

Even maven which is imho terrible to set up is a nice tool and the amount of libraries and tooling coming with it are amazing.

Modern Java is quite a fantastic language. They are steadily releasing new features (8 - lambdas, 9 - modules, 10 - type inference, 11 - jvm improvements, 12 - switch expressions, future - coroutines) and imo better than most of the languages you mentioned because it is quite simpler and with a larger ecosystem.

Newer doesn't automatically make a language better.

Starting over with a new language has a huge marginal cost. You have to calculate spending the budget on improving the current vs building the new. And its likely that after several years when your new language is production ready - the existing has improved enough. But it might also have become worse.

The latest versions of java are actually quite nice and implement a lot of modern features from those languages. It wouldn’t be my first choice but it’s by no means a bad or dated language.

Libraries and tooling. And a pretty good track record.