Hacker News Reader

Comment by _lbaq | Hacker News Reader

Working in the JVM world I'm always surprised to hear that its dying, the JVM and Java moves faster forward than ever, Graal is about to go 1.0, a bunch of very interesting (very) low latency GCs are in the pipe (for example ZGC and Shenandoah) and lots of other interesting projects like Valhalla promise to keep the JVM relevant for the next 20 years. Oracle have made some moves to monetize on parts of its investment, but the situation is largely misrepresented.

Ref:

- https://openjdk.java.net/projects/valhalla/

- https://www.graalvm.org

- https://wiki.openjdk.java.net/display/zgc/Main

- https://wiki.openjdk.java.net/display/shenandoah/Main

View on HN

Too little too late, and I highly doubt that (5-year-old) Valhalla will deliver even one of the promised features (value types) in the next 3 years. Remember that the original plan was to have all Valhalla features in Java 10.

Java/JVM was in the ideal position to dominate the software world for the whole 21th century 15 years ago. Instead they did an IE6 and stagnated for so long that their competitors became plain better.

I'd say Java/JVM is now where IE was in 2008. Still massive majority market share, but in decline because people are switching to competitors. LLVM and webassembly are eating JVM's cake, and a multitude of languages like Kotlin, C#, Go, Rust and even Javascript and Python are chipping away at Java's market share.

> webassembly [is] eating JVM's cake

It's hard for me to take all the "Java is dying" threads seriously when they don't even seem to understand where Java plays. Webassembly? Really? That's a client-side tech, and 99.999% of Java devs ceded the browser battleground pre-9/11.

Java's bread and butter is EAI, ETL, and server-side business application development. Particularly with pieces requiring heavily distributed design. Node might pick away at some of the lowest-hanging fruit (e.g. JavaScript webdevs writing their own REST endpoints to fetch user settings from the database). But most of that crowd doesn't understand what the terms "EAI" or "ETL" even mean. Hell, most of that crowd has never had the experience of working for a company that turns a profit. The next major downturn will be interesting to watch...

And JavaScript is the only JVM-alternative to take seriously at all. Hype trains come and go for Rust, .NET Core, Go, etc. But they never really gain serious traction beyond a non-Java niche area, and/or devolve into endless arguments about generics or whatever.

I've seen zero actual encroachment into anything that earns me money for the past 10 years now, and at this point I'll probably be retired before I have to worry about it.

You're right that Java is entrenched in a lot of the enterprise space, but I think you're being quick to dismiss entrants that have gained steam in the last few years.

For example, Go is becoming the default in Kubernetes applications. It's eating tech companies that became large in the last few years like Lyft and Uber. It'll spread to other large tech companies like Amazon or IBM with ease. It will possibly get picked up by a significant number of universities for undergrad courses within a few years as well.

Seriously, people. K8s is a container orchestration system. Yes, it's written in Go, like Docker itself. DevOps tooling is a niche area where Go has been very successful. But k8s runs whatever you put into your Docker containers.

I've seen no indication of it changing which languages people choose to containerize (Node containers probably being way more common than Go ones). If anything, easy containerization negates one of Go's strongest selling points (i.e. standalone executables with no need for a runtime environment).

Exactly! In the enterprise world, there is a lot of Java and .NET code that isn’t going away for a while especially since K8s makes it easier to port to the cloud. In my enterprise, the only other language that comes close in usage numbers is Python, so I think a lot of enterprise folks will opt for that over Go.

As someone who works on Kubernetes in the enterprise I would agree - there’s lots of go, but it’s newer and organized around the teams who were early adopters. And even the early adopters have massive Java, .NET, and increasingly Node footprints.

However I think the rule of enterprise software is that it’s increasingly fragmented and diverse - that’s partially why Kubernetes and containers were so attractive because it allows operations to unify footprint on prem and have a path to cloud.

Nobody in an enterprise ever stopped using a piece of technology. It lives on forever (and public cloud just gives it new places to live).

Go is really not a language to recommend for enterprise business applications. It's a niche and will likely stay this way unless they add tons of features, which they have been reluctant to do. Because otherwise they'll end up with Java, or something very similar, is what you end up with.

> If anything, easy containerization negates one of Go's strongest selling points (i.e. standalone executables with no need for a runtime environment).

I don't know about that, I think that is still a strong selling point for Go, even in a containerized environment. Somewhere I saw a statistic that says over 90% of container images in the wild contain unpatched CVE vulnerabilities and (searching...) [1] here's an article that shows just how bad the problem is, according to this article in just the top 10 docker images, there are over 8000 known vulnerable paths.

The reason is probably not because those 10 products are simply nightmarish from a security perspective and expose the lions share of the vulnerabilities in their own code paths, it's because of unchecked dependencies. If someone took a tree shaker to those images and removed all of the unnecessary packages that aren't real dependencies, you see that number going down by probably about 30% if not more.

Even then, you're still seeing lots of potential issues caused by far-away dependencies that we do actually need, but don't really care about. There's something to be said for a development stack that is geared toward automatically pruning out packages you've included when the compiler can prove you're not even using them, and helping you reduce the scope and size of your external, far-away dependencies.

From an InfoSec perspective that's the biggest problem I see in containerized environments, (and true that just not using containers won't really make it much better) so correct me if I'm wrong, but I think that Go does all of that for us.

[1]: https://snyk.io/blog/top-ten-docker-images-contain-over-8000...

I'm working with customers now that are running Kubernetes to host Java applications and microservices. I'm not a huge fan of Java or the ecosystem, or the fact you can build a Kubernetes cluster using maven, but to claim its dying is outright absurd.

As a consultant, I see Java widespread. Every organization is either writing Java or running an application dependent on Java that is also mission/business critical. Most of my work happens on the backend, but we see lots of Java upstream with mobile apps, big data, ETL, etc...

Go is a good language for developing middleware and automation tools, but it's not, at any rate, a replacement for Object-Oriented languages. Java, C#, Python, Ruby etc are much more suited to business-oriented apps, data science and so on.

There are many uggly things on Go language that can be considered nice features for system programming. Even though, if you go too much on the low-level (such as for operating system, drivers or embedded devices) it's still a issue to use go instead of a more hardcore systems language such as C++ or C. It is, at most, a niche language today. And probably will stay this way unless it goes into a major redesign.

Better to talk about Rust or Kotlin, which are languages that have much more potential and can be a real threat to the dominant languages/platforms today. But right now, they are too unknown to be taken in consideration just as many other good languages that never came to be.

I've heard that attitude before. C++ developers working in finance around 2000. They were damn sure that no-one was going to switch to any other language because reasons.

I'm sure there's still a bunch of C++ devs working in finance, and making decent money, but I think the industry has moved on now.

The industry always moves on

HFT gigs I’ve looked at were all C++, some even Rust now - because they don’t want the risk of a long GC pause messing up a trade (which means Java, .NET, and Go are right-out).

You are right, but HFT is a tiny subset (headcount-wise) of the Financial industry.

Go uses tri-color mark-and-sweep gc that runs concurrently and its latency is extremely short compared to .net and java (probably still not short enough to be put in the critical path of hft order processor tho).

Edit: I'm also confident you can ensure Go’s gc doesn’t run when you don’t want it to so there’s that.

This may be true but conventional wisdom against using anything GC'ed for real-time applications (like HFT or aerospace stuff) is going to mean even if go's gc is good enough, using any gc'ed language for these apps is going to be extremely rare for years if not decades. Seems far more likely that rust will chisel away at that market than golang or any other gc'ed language.

Many HFT firms have used Java for ages. If you know what you’re doing you can avoid GC. Also, not everything needs to be realtime.

For arbitrage that must happen really fast, FPGAs is the way to go, and for complex code that needs to be rewritten often and quickly, Java is probably a better fit than C++.

There are active ongoing efforts to push wasm beyond the web client. Which makes perfect sense, since it could, in theory, deliver JVM's "compile once, run everywhere", but with a lot more flexibility for the languages on top.

As far as Node.js being the only JVM alternatively to take seriously, I don't even know what to say. There are lots of enterprises with mature .NET (not Core) business apps, doing all that very stuff that you list - EAI, ETL etc.

And then there's the evil implication of this aging, entrenched ecosystem. Companies who wrote their Java development process documentation did so in the 90's, with guidance from IBM or a "big 3," and now treat EVERY project in the business as though it was the same scale and complexity as the mainframe projects they were trying to supplement. Which is why it takes 6 months for me (on the FAST TRACK!) to even get a development environment for a simple CRUD web app designed to replace a terrible Excel spreadsheet with 5 users -- so that I can submit my feature list and test plan to review boards -- so that I can START writing my application.

No wonder it takes the IT group 2 years to write an application I can have in production in 3 months! I don't need a reverse proxy! I don't need redundancy! I don't need an encrypted file store! It's a shared, specialized to-do list application! I don't need the overhead of a global financial application running on Sun E10K's!

Nothing personal, but there are a lot of us out here who can't WAIT for people who have based their careers on "enterprise" Java to get out of the way already, and retire. When computers were as powerful as smart watches, we NEEDED all that distributed processing and faffing about with off-line data. Now? Not so much.

"Hype trains" Rust, .NET, Go, etc.? Maybe you, too, think that Rails is too "new" and "unproven" to use for anything.

LOL... someone woke up in the wrong side of the bed this morning.

Please don't do this here.

I'm one of those Node devs who've mostly worked for companies who have never made a profit, and I've recently been exploring Go, Java and C# (.NET Core) given I'm starting to work on more "serious" (or difficult) backends (distributed systems) and am hitting the limits of the language and ecosystem I know. Genuinely curious - why do you think I should give Java my attention over C# or Go?

ETL is the bread and butter of the company where I work and you can be sure Java is not even allowed near our systems.

We have thousands if not dozens of thousands of different data providers and it is mostly financial data.

Everything important is PHP and Python. It was Perl 10 years ago. There is some Java, but not in the ETL subsystems.

I didn't know Java had so much mindshare for ETL. Can you explain further?

The JVM, Java and Scala have a huge ecosystem with Hadoop, Spark, many databases, etcetera. Go to any company that does a lot of data-intensive processing, and chances are very likely it's powered by the JVM in at least some of the components.

I said LLVM and webassembly.

LLVM has replaced JVM as a programming language target bytecode in the last 10 years (except Kotlin no new JVM language). JVM has lost web to JS 20-15 years ago, and Webassembly is now taking shape as proper web bytecode.

I do not know what will be the most dominant language + bytecode in 25 years, but I would bet $10000 that it isn't Java and JVM.

> except Kotlin no new JVM language

Java's never going to be on the bleeding-edge of trendiness (thank goodness). But there have been fewer JVM-targeting alternative languages over the past decade, because Java itself started leaning in a functional direction. It became "good enough" to negate the purpose for most of them.

At any rate, counting compile targets for hobbyist toy languages is barely one step beyond measuring GitHub stars.

> I do not know what will be the most dominant language + bytecode in 25 years

In 25 years, I'll be long gone and you can have it. By then, the industry will be pushing to automate most programming jobs out of existence altogether, and you can be the old guard arguing against that.

> except Kotlin no new JVM language.

What about Clojure?

I 100% agree with you on Java. Some of these people who compare Java to Cobol have no idea. It’s hard for anyone to predict the future in tech but at this point Java is so widely used in the enterprise that it’s foolhardy to think that Java will disappear anytime soon.

To the credit of the Java community they keep the language relevant and refreshed.

I agree it’s always about 1-2 years behind other languages in terms of features but most enterprises don’t give a damn. Most enterprises just want to get work done. They don’t care about functional or OO.

In the last 3 years I have seen maybe 40% of developers use the latest features from java 8.

So while java might be slow to catch up that’s what it’s customers want.

Spring and Vert.x and similar Java frameworks will always keep Java relevant that it will be hard to ignore

> Some of these people who compare Java to Cobol have no idea....at this point Java is so widely used in the enterprise that it’s foolhardy to think that Java will disappear anytime soon.

Isn't that PART of the Java to Cobol comparison? Someone making that comparison wouldn't be saying that Java will disappear anytime soon.

COBOL is a valid comparison in terms of its space occupied and the verbosity the language is. The difference is cobol is really mainframe era and java is mini / unix era. Its client side except via phone is largely gone. But like cobol still in mainframe apps, so would be java. We do not see that gone as mini/unix not dying.

The windows server running java is an area I am not sure and not much encountered. But windows and Microsoft languages are the only competitor here.

I’ve actually seen enterprise apps on Java deployed on a Windows server in some big banks.

Client-side is gone on most languages. While there's still native mobile apps (and some rare desktop apps), the only language available on the client-side for the web is javascript or languages that can be transpiled to javascript. Flash, cold fusion and other stuff are gone. It's not a "Java is dead" thing.

Clojure doesn't fit in the original poster's "last 10 years" qualifier. It's older than that.

>LLVM has replaced JVM as a programming language target bytecode in the last 10 years (except Kotlin no new JVM language)

LLVM only emerged as a major target in the "last 10 years", so there's that.

And JVM already had so many major languages it didn't really have much space for others (Scala, Clojure, Groovy, and so on, including fully working clones of Ruby and Python).

Still, 4 major new languages: Scala, Clojure, Groovy, Kotlin -- all in the TIOBE top 50, from a single platform (which wasn't designed to be a language neutral target in the first place, it just happened because of it being too successful), plus the number one TIOBE index spot (Java), sounds like enough.

llvm is not a vm. describing llvm as something that is replacing the jvm doesn't really make sense.

mentioning javascript or webassembly is also a bit strange and would seem to demonstrate some kind of misunderstanding.

In 1995-2005, JVM was a serious competitor for the web, it's why JavaScript was named JavaScript.

javascript is named javascript for marketing purposes. your example is an almost stereotypical misunderstanding by people unfamiliar with java.

Those marketing purposes are exactly what dtech is referring to.

marketing purposes being a non-technical thing, which isn't a very meaningful support to saying something like js/webassembly are replacing the jvm.

Kotlin runs on JVM and needs Java to even bootstrap.

And the idea that corporate developers or even frankly any developers are switching to LLVM and WebAssembly en masse is pretty ridiculous.

Java as a language may be getting less developer interest but Scala, Clojure and Kotlin are as strong as ever.

Kotlin can run on the JVM and, Kotlin-on-the-JVM needs Java to even bootstrap. Also it seems that most of the interest for Kotlin comes from the JVM community and this aspect of the language. That is certainly the case for Android programmers any how. Backend JVM application server programmers use it as well.

However Kotlin can be targeted to other platforms as well. Kotlin can target JavaScript ( https://kotlinlang.org/docs/reference/js-overview.html ).

Also the Kotlin compiler has a LLVM based backend which can compile native binaries, without use of any VM ( https://kotlinlang.org/docs/reference/native-overview.html ).

My main non-JVM use of Kotlin is that when I want to use some arcane aspect of Kotlin, which I may not be too familiar with, I might write and test a small toy function on the command line using it and then copying it over to a big Android Kotlin project, as opposed to trying to work out how to use the arcane feature in the middle of a big Android project.

To me two things about Kotlin stand out over all other Java alternatives: 1) fantastic IDE support and 2) it does not add too much rope to hang oneself with (see re: Scala).

> I highly doubt that (5-year-old) Valhalla will deliver even one of the promised features (value types) in the next 3 years.

I'll gladly take that bet. People said the same about lambdas.

> Java/JVM was in the ideal position to dominate the software world for the whole 21th century 15 years ago. Instead they did an IE6 and stagnated for so long that their competitors became plain better.

I don't see any competitor coming anywhere near Java on technical merits. Not only is there no stagnation, but true breakthroughs -- in GC, compilation and observability are being made in Java and almost nowhere else in the past few years. That's not to say that Java doesn't have some glaring deficiencies but they're being addressed.

Are they being addressed too slowly? Perhaps, but that's something we've heard about Java for a long time, and the perception has usually turned out wrong. I think this is because such complaints are made by HN readership that misunderstand the industry's priorities.

> LLVM and webassembly are eating JVM's cake, and a multitude of languages like Kotlin, C#, Go, Rust and even Javascript and Python are chipping away at Java's market share.

Java's short-lived complete domination was a fluke. Now its market share represents a more normal one for a technological leader.

LLVM and webassembly are eating the JVM's cake only on HN. Kotlin shares well over 90% of its code with Java, and is a part of the Java ecosystem. C# has always been a big competitor, and Rust is not really chipping much away from Java as it's optimized for different domains. Go certainly took a bite, but its rise has stalled. This leaves JS and Python. JS has truly been a remarkable success due to its ubiquity on the browser, and it has taken a big bite out of all languages. Python is the most interesting one in the bunch. It is nowhere near as technologically advanced as Java, but it has other important benefits that many companies now care about.

> Too little too late, and I highly doubt that (5-year-old) Valhalla will deliver even one of the promised features (value types) in the next 3 years

I never understood the purpose of Valhalla. They should just introduce a 128-bit scalar type and call it a day. Nobody actually cares about automagically storing value types in HashMap — all interested parties (HFT, computing) have already written dedicated collection libraries for working with primitives, and those libraries have little in common with object-based ones.

> LLVM and webassembly are eating JVM's cake

pffft, hahahaha, no they don't.

JVM and LLVM don't even share same market niche — one is a feature-complete runtime, another is a "make-your-own-language" build kit. Webassembly? What webassembly?

> Nobody actually cares about automagically storing value types in HashMap

I agree. When I look at the allocation profiles and heaps of our Java applications (which I assume to be fairly typical Java enterprise applications) boxed types do not show up. What really matters are Strings, both in the heap and the allocations.

Kotlin is a JVM language, sold as a better Java, and the JVM is really the thing that is the echo system gathers around, not necessarily the language Java.

Other interesting languages you have on the JVM is Scala (multi-paradigm), Clojure (Lisp), EtaLang (Haskell)

- https://eta-lang.org

- https://www.scala-lang.org

- https://kotlinlang.org

- https://clojure.org

Notice how I separately addressed JVM and Java.

Java is already losing market share to JVM competitor languages.

JVM is in a stronger position than Java, but imagine a world were 15-10 years ago native compilation for JVM bytecode became available instead of 1 year ago. LLVM wouldn't have stood a chance.

Kotlin and Scala (I'm not too familiar with Clojure and others) are hedging their bets and making JS/Webassembly and LLVM versions.

LLVM would have been created even if free/open source, SubstrateVM style tech existed back then because LLVM was designed as a competitor to GCC for compiling C and C++. The JVM can run C/C++ code these days 'natively' (by JIT compiling LLVM bitcode using Sulong) but that's not what it was created to do.

Also bear in mind LLVM is not really a JVM competitor despite the name. LLVM is a toolkit for building compilers, primarily, C/C++ compilers. Other languages that targeted it have had to do a lot of work to change LLVM for that language. It's not actually a "VM" in the JVM or V8 sense, for instance, it doesn't provide a garbage collector and LLVM bitcode is neither platform neutral nor a stable format.

> Also bear in mind LLVM is not really a JVM competitor despite the name. LLVM is a toolkit for building compilers

It started out as a (lower-level than JVM) VM and evolved into what it is now, mainly because of Apple's requirements and funding.

JVM native compilation exists since 2000 for anyone willing to pay for it.

Do you mean with Excelsior JET? I tried to compile an application totaling 157MB in jars to native with it just now. After compiling for 2 hours it was still only 15% done. I had aggressive optimizations disabled.

Excelsior JET is only one among many.

As for your problem, it looks very strange to me, only similar to compiling C and C++ on underpowered hardware.

Which are the other ones? I know of GCJ, which is dead, and Graal, which from what I hear takes hours to compile small programs.

Most commercial JVMs for embedded development.

For example, PTC, Aicas, Aonix (now also owned by PTC), IBM RealTime WebSphere, some variants of J9, Android since version 5 (although it isn't technically a JVM), RobotVM, Codename ONE, GluonVM, IBM i JVM (uses OS/400 TIMI), JRockit.

I know for a fact that in the case of Clojure (and I assume the reasoning is similar for Kotlin and Scala) that targeting other ecosystems has nothing to do with "hedging", and everything to do with reaching other platforms and mediums.

>Java is already losing market share to JVM competitor languages.

Really, any examples? And not Go and Rust (down 30+ places in the TIOBE index compared to Java, and as insignificant as to not even exist in the global job market).

> even Javascript and Python are chipping away at Java's market share.

The GraalVM team is working to run a bunch of stuff all together on the JVM

"LLVM and webassembly are eating JVM's cake,"

> webassembly is not eating any cake.

And C++ is still around, and one of the top choices, despite 25 years of other languages chipping away at it.

Java is very mature, it doesn't need to evolve a whole lot - and most everything you need is there.

Oracle is definitely a risk to this, but I don't see TS/JS/Node taking over.

Kotlin is a strategic choice by Google due to Oracle woes, otherwise it would be a very rare language: consider that it really hasn't made a big roar outside of Android, i.e. it's not really anywhere on server side.

Java isn't going anywhere for a while yet.

There will need to be some kind of tectonic shift for this to happen.

If Google or AWS for example fully embrace some new thing, that might do it - but I don't see what the candidate is.

Kotlin for JVM has a lot of potential. It takes a lot of the pointless busywork out of Java (this is Go's problem), yet the median hiring candidate can probably handle it (this is Scala's problem) and you don't sacrifice decades of library coverage.

Kotlin is nice, but to me it's mostly just 'different', not necessarily an 'advantage'.

Without Android adoption (and G did this specifically because of Oracle issues) I don't think anyone would really be using it. Outside of Android, it's not a big thing.

I've gone Java to Kotlin and back again simply because the few advantages to Kotlin just aren't worth the phase shift. FYI almost every single code example in Android has Kotlin and Java the same length. It's not really any shorter or more concise in the end.

I wish Kotlin well, and it's a great example of how the JVM can be leveraged.

The JVM is probably Java's greatest foundational asset, which is why Graal has such potential, if Oracle doesn't screw it up ...

>webassembly are eating JVM's cake

Nobody seriously uses webassembly outside of the web broswer.

So much for hyperbole.

Reality is subjective and local.

At any given time most developers will neither have much real choice when it comes to technology nor have a longer term perspective. Hence most developers will stick to what they know and what organizational inertia seems the path of least resistance.

The comparison to COBOL is good for several reasons.

My first bit of production Java code was an applet that used cobra to talk with COBOL in the Java 1.0 days. When I'm bridging new languages to Java codebases, I always wonder if this is the 'new hotness' I'll be driving next.

Similar position. Corba overhead too high and we use a middleware to handle it. But the aim is to migrate away those we can from mainframe. And use java in lieu of cobol.

CORBA?

> Working in the JVM world I'm always surprised to hear that its dying

So how is this "JVM world" escaping the grip of Oracle? E.g. graalvm is directly Oracle's, or am I missing something? Specifically, what is preventing any of the Java-related things people use now (including those that you mention) to end like the OP is describing?

Asking as somebody outside of that world, but interested "how much it's worth considering" under the given circumstances (Oracle being Oracle, demanding a lot of money for everything Oracle's that some company could use, and owning a lot of that "world"). Where are the boundaries? What is safe and outside of reach of Oracle? E.g. what is safe for a small company to use?

Graal Community Edition is licensed under GPL, there is a Enterprise Edition that has additional features that is licensed differently.

OpenJDK does not need commercial licensing, but Oracle JDK which is built from OpenJDK needs.

Then there are plenty of other vendors to chose from if you absolutely does not want to interact with Oracle.

IBM and now Eclipse foundation OpenJ9 is a very interesting TCK compliant JVM, then you have Azul Systems that innovates a lot with Zulu/Zing.

GPL is not usable for any small company which doesn't want to publish its own sources.

What can be used only using BSD, MIT, Apache licenses? And what from the GPL-licensed products is safe to use to produce and sell own closed source products (e.g. where the exception to GPL exists for just linking the libraries or similar)?

Edit1: Long term dangers/costs of depending on the technologies that need commercial licenses like Oracle’s are also important.

Edit2: And additionally, just as an old example, once I’ve considered using Berkeley DB in the closed source product (before some of the current alternatives were available), and my interaction with Oracle proved that only a bigger corporation could fund that. For a library which was already open source, but owned by Oracle. It's not that I'm in the "I don't want to pay for anything" camp -- I'm simply having a perspective of a small player. And about small players Oracle couldn't care less. However, the significant changes very often come at that level of cheapness and overhead, most of technologies would be still not widely accepted otherwise.

You probably use Linux today, that fact does not require you to publish the source for your program running on Linux.

> GPL is not usable for any small company which doesn't want to publish its own sources.

Maybe I'm missing something, but AFAIU you have to publish any changes to that library, not your sources.

There are different levels of what’s allowed for different GPL based licenses. To use a library as a library with another license a GPL library exception has to exist for the library etc. If you step on only one of such mines your whole product has to be GPL-ed.

It the context of my questions here, and as an example, my guess is that I can't use graalvm to produce a binary which I can sell without either open sourcing everything I've made or paying too much to Oracle. But I don't know for sure and for each of the mentioned technologies, that's why I'm asking very specific questions.

> my guess is that I can't use graalvm to produce a binary which I can sell without either open sourcing everything I've made or paying too much to Oracle.

GraalVM CE is licensed under GPL 2 with Classpath exception (https://github.com/oracle/graal/blob/master/LICENSE), specifically so that binaries created with GraalVM (which contain the GraalVM runtime) don't fall under the GPL.

As far as I can tell the GPL in the Graal source repo includes a classpath exception. So the license wont affect a program distributed with it.

> So how is this "JVM world" escaping the grip of Oracle?

Why would you? What is the point of "escaping"? It is like asking, "how would Go world escape the grip of Google?" — no one cares to, because nobody asks Oracle for permission to make software for JVM.

Java EE has been in maintenance mode for a long time, but Spring and Dropwizard are alive and well despite that. Incidentally, Nginx Unit has recently implemented Servlet spec — a cornerstone of JEE! — but they are stuck at it's initial version, without asynchronous Servlet support. Maybe Oracle should give Nginx a couple of decades to catch up before drafting next JEE version...

Oracle seems hell-bent on undoing the openness around Java that SUN was allowing. What I'm reading between the lines of this report from the Oracle-Eclipse negotiations is that Oracle wants to roll back the world to a "thou shall not have a JVM besides mine" state with a hefty price tag on commercial usage of their VM.

I'm sorry, but as bad as Oracle's sales and legal behavior has been, I don't see how the evidence supports your claims.

Oracle has open sourced (or deprecated and removed) the remaining commercial elements in the JDK -- OpenJDK now is truly the complete open reference implementation of the JDK, JRE, and JVM.

OpenJDK is an open distribution and preinstalled on all major operating systems and is now the standard JVM for most developers. We even have open distributions of it e.g. Amazon Coretto.

GraalVM isn't even at version 1.0 so nothing at all to worry about.

> OpenJDK is an open distribution and preinstalled on all major operating systems

My understanding is that it is preinstalled on chrome os and android, but is not preinstalled for any major linux distribution, is a separate third-party download for windows and Mac, and is unavailable for iOS.

On the contrary, Linux distributions ship only OpenJDK.

They ship it, but it doesn't come pre-installed.

I don't see how this is an argument though, there is no Java in a standard desktop/server installation, but it's trivial to install if needed.

Since when OpenJDK is preinstalled on Windows?

... and iOS? And I’ve only done upgrades, but I don’t believe any JVM is preinstalled on MacOS.

Apple used to have its own JVM implementation.

As for iOS, RoboVM, Codename ONE, GluonVM are three possible AOT compilers to native code.

Apple's JVM was MRJ, the Macintosh Runtime for Java. It became obsolete around 2004, during the transition to Mac OS X.

Last time I used MacOS, it prompted me to install Java and then it did the install. I was in the Terminal, I am not sure what the interaction would look like if I had double-clicked a JAR file.

I believe Apple donated their customizations (Swing L&F, launcher code, etc.) to OpenJDK.

This is Apple's old build of Java 6, and is currently downloaded as needed for backward compatibility. Anything newer than that the third party is expected to bundle into their application.

Yes, Graal is the evolution of Maxime, started by Sun Research Labs, which Oracle kept alive.

All good alternatives to the JVM are commercial.

The free ones are generally just repackaging Oracle's work on the OpenJDK, with zero contribution to Java's research and respective improvements.

Hence why it is always ironic to see the crys to use OpenJDK and forget about Oracle.

Java the language is slightly different than JVM but nevertheless the future is not very bright IMO. So far there are a few areas Java/JVM still holds a strong position but if you take a look at GitHub trending there is little or now new blood coming in.

- Android. No serious competitor to Java yet (JVM is irrelevant). But the Google lawsuit could have some complication.

- Spring stuff. I won't be surprised if they will be replaced by golang and nodejs (along with react/angular/vue etc). Same path for RoR.

- Data processing: Spark stuff, PrestoDB, Flink, Kafka, Hive, HBase, Lucene/Elastic etc. Java/JVM is still dominant but golang could be a future contender. A few new application databases/KV stores are implemented in golang.

The problem for Java is that the last category is mostly services (instead of libraries/frameworks) so you can potentially use any language to work with them, and the industry probably won't create many jobs for building generic services especially in the cloud era. So having the dominance doesn't provide a lot of protection.

Golang, at least in its current incarnation, has no chance of replacing Java in its core use case - business processing. Golang is replacing infrastructure that used to be written in C, which makes sense considering that's what it was designed for.

It's weird that you put Spring and react/angular/vue in the same sentence, because there is no overlap in these problem domains.

Just take a look around to check out new enterprise MIS projects being implemented with a simple golang backend + reactjs etc frontend. The adoption of intereactive/responsive and single page web UI, and the more iterative development practices are certainly driving to a different direction compared to Spring (and RoR etc). I think the main force is from the frontend tech here and that is why you see them in the same sentence.

Perhaps Golang was designed to replace C, but from what I've seen that doesn't seem to be happening. Most converts seems to come from the other direction, from Python and server side Javascript.

There is a clear trend there to grow static features, and I think a lot of people ask themselves why they shouldn't go directly to a more traditionally compiled language then.

Spring is really nice, but all the flexibility comes at a cost. Annotation meta-programming, runtime reflection, constructing proxies, classpath scanning... all contribute to a perception of slow JVM startup times that makes something like Spring Boot unsuitable for really small services or utilities.

I know there are other Java frameworks out there that are more optimized for smaller modular projects, but there's also the cost of operationalizing the JVM in something like Docker. Fat JAR deployments are relatively simple, but tuning the JVM isn't always straightforward. I'm definitely jealous of the simplicity of producing a single binary as your deployment artifact.

I can see you're a Go fan but I think .NETcore has potential to start eating away at Java in a big way if Microsoft continues on its current path. They can actually provide the enterprise level support big corps want.

.NET's developer community is in no place comparable Golang's or Javascript's. Just take a look at GitHub's trending page by programming languages. Javascript is really bad for server side applications, and yet here we are with so many nodejs server apps. It doesn't matter much how good a tech is. What matters more is what the new generation is using, which you can get a sense from the trending page on GitHub.

Lol, go has nowhere near the mind/marketshare of .net

I've hated Java for years, but recently I think it has become usable again. I've looked at GoLang and Node, but I've kind of given up on them, too. GoLang I would consider for specific use cases. NodeJS just seems to insecure and "wild".

Was hoping that Kotlin+Spring could be a good alternative to GoLang for realtime apps, but haven't tried it yet.

Reply on news.ycombinator.com