Hacker News Reader

Comment by saosebastiao | Hacker News Reader

It seems like the JVM is here to stay in the same way that COBOL is here to stay. It has become a server-specialized system with a level of overhead that kills it in resource constrained environments. There is room for improvement, no doubt, but it's pretty hard to beat the resource demands of AOT compiled code with a good optimizer and potential PGO.

Go, Swift, Vala, Nim, and Rust are just the start of a trend...it seems most new languages are eschewing the VM model. And many existing VM/JIT languages are moving there: Dart, Julia, Scala, and even the .NET languages are all moving towards AOT capabilities.

View on HN

Java is also AOT compiled and is becoming the favourite language besides C on many embedded platforms.

EDIT: To expand to that remark, although Sun was religiously against AOT, the majority of commercial JDK vendors have always supported AOT compilation to native code, specially the ones in the embedded space.

Also, for how cool all those languages are, there are lots of domains and OSes where Java code lives (AOT or JIT compiled), that they have yet to create backends for.

Examples, embedded controllers on factory plants, Cisco phones, Ricoh printers, Gemalto monitoring devices, Blu-Ray players, car infotainment systems, some GPS devices, military weapon control systems, shopping terminals, Android's fork,...

https://en.wikipedia.org/wiki/List_of_Java_virtual_machines

It is going to take a while to erase Java from the industry.

I was more claiming that the JVM is going obsolete, not Java. The whole idea behind the JVM is platform abstraction...and it worked perfectly fine insofar as the platform being abstracted had a CPU, at least X memory, a disk drive, and at least a basic OS. Which was fine for a while, but now we're seeing an explosion of different platforms with wildly different capabilities, and the JVM is just not up to the task. That isn't to say that Java isn't, but it does mean that you need specialty compilers, libraries, tools, and infrastructure for specialty targets.

Well, actually what we are seeing with the CLR, LLVM, ART is an increase of adapting the mainframe model of JIT/AOT compilation with some form of bytecode as distribution model.

In that regard, what JVM is missing are new ways to adapt to said hardware.

Interesting enough, Java is ahead of Go, Swift, Vala, Nim, and Rust in supporting GPUs, for example.

>resource constrained environments

Like what? Even $40 dev boards these days have 8 core processors and 2GB+ of RAM.

You've got a resource constrained environment in your pocket right now.

And it's running Java. Not the JVM, mind you.

Though I think JVM-as-a-spec is still incredibly powerful, even on Android. I can write Kotlin apps, Groovy apps, Scala apps…

And it takes a lot more resources than a device that doesn't have the overhead of Java....

Depends which Java one is talking about.

http://www.oracle.com/technetwork/java/embedded/embedded-se/...

http://m.ibm.com/http/www-01.ibm.com/software/wireless/wece/...

http://www.ptc.com/developer-tools/perc

There are a few more.

All of them without the hungry requirements of Android and compliant with Java TM license.

Of course Java won't be able to run on Arduino and similar tiny controllers.

The real JVMs, require just a few hundred KBs to run embedded.

There are tons of comercial applications running embedded Java in hardware people might not be aware of.

Google's arguments regarding why they had to fork Java are just smoke and mirrors, only believed by those that only ever used the OpenJDK.

You mean my quad core with 2GB ram phone? That could easily run a JVM.

Can anyone elaborate on how AOT is a beneficial feature?

Reply on news.ycombinator.com