Maybe he means in browser Java Applets. But they are pretty much dead anyways.

They aren't supported in Java 9.

Yes they are. They're deprecated, but not gone.

Not that it much matters, since Chrome doesn't support the NPAPI plugin, and FireFox is expected to drop support early in the new year, leaving Applets an essentially IE only thing.

Hopefully Java WebStart doesn't go anytime soon, I still rely on that for OOB management on my servers without needing to boot Windows and use IE + the .Net consoles.

Java Webstart is the official way for applet alternatives, according to the Java blog.

And in Java, anything deprecated is never really removed.

Not paying attention to the JEPs?

http://openjdk.java.net/jeps/277

There was a session at Java ONE about a set of API that will be gone in Java 10 after this gets introduced in Java 9.

Good. It was one thing we always disabled in our deployment of JRE. One less vulnerable entry point for those who needed it on their workstations.

The JVM is great, Java, not so much. At least we have Clojure, Scala, Groovy and Kotlin.

Those languages complement Java on the JVM to varying degrees. Kotlin and Scala were built to progressively replace Java in a codebase. Clojure was built for the JVM as its first target architecture. Apache Groovy was originally to script Java code, e.g. tests and glue code. (Although Groovy was later repurposed as a Java replacement in Groovy 2, not many people use it for that.)

Agree with your assessment of Groovy. It made the JVM easy to use for simple scripting and served a really good purpose as glue language between big monolithic JVM software systems.

I haven't used it for awhile now, but I used to work on a serious Groovy code base. It's out of it's league now. Once Kotlin's scripting story gets rolling it should eat the rest of Groovy's lunch.

It is unnecessarily resource hungry.

There was an article the other day on HN about Golang compiler and work on its GC. (Garbage Collection)

As the article goes on, it becomes clear that a modern GC managed system is no simple thing. As you start to add all the choices and tuning you end up re-inventing the JVM runtime.

Any program of sufficient complexity eventually ends up having GC.

Java may be too resource hungry for trivial programs. For large programs Java is an industrial strength runtime platform. Or I should say the JVM is. You don't have to use the Java language. You can use a number of languages that compile to JVM bytecode.

How so?