To this list we could also add Cassandra, ANTLR, Spring Framework, JUnit, Jetty, Tomcat, Android etc. The list continues. The beauty of Java is not Java/Programming language - but JVM. It inspired people to make other languages such as Scala or Kotlin.
Yeah, but is the JVM worth it? It seems like VMs are now out of style, after decades of trying to make them performant at the cost of staggering complexity. VMs are still not more performant than native code and with the advent of SaaS, portability isn't a big issue anymore.
I don't think anyone doubts that the JVM is an astounding and amazing piece of tech. But what is in doubt is whether we need such a thing in the first place.
Most new languages (Rust, Nim, Zig, etc) advertise their native code generation prominently. People are tired of the shitty start-up times, inscrutable performance profile, and ginormous memory usage.
Even Oracle realizes this, with the recent push towards GraalVM.
And I say this as someone who would probably choose the JVM, Scala specifically, for any new SaaS project.
I personally haven't really used any desktop JVM app that I was happy with. If Intellij was native, I'm sure it would be 10x better, at least performance-wise.
This industry isn't a monolith, you have Javascript still chugging along, things like Lua as well. Microsft has the CLR as well.
Of course some stuff is conflating the language and the VM (which gets you to things like asm.js) but I think people acknowledge the value of what the JVM provides even in projects you cite (Zig has a whole thing about cross-compilation, for example).
And honestly? targetting a VM is _way easier_ than targetting native code generation. Perf-wise it might suck to try and then engineer good performance out of it (though you can get shared improvements with things like the JVM), but "staggering complexity" feels like a misqualification for something that got us a lot further down the "write once run everywhere" path than C ended up doing.
I would say that writing a rudimentary VM is about as hard as generating LLVM IR. The difference is that the VM will have terrible performance and the LLVM IR will have pretty good performance.
But will it provide introspection, garbage collection, and low-level niceties the JVM provides?
Will I be able to interface with all the huge amount of available java libraries? I could interface with C/C++ but there's already a ffi story (as ugly as it is) with the jvm.
I think part of the appeal of rust and go and new languages is the ability to leave a mark, rewrite or port or rethink an existing library in the new language...
It's a kind of progress but it feels like a lot of waste sometimes. And I say that as an avid Ada developer.
I have also reached a point of wondering whether I care about portability. I like the JVM ecosystem but I generally do not give a damn that the JVM abstracts the underlying OS to me since I have to go install it on the target somehow anyway.
If, tomorrow, I could generate native binaries and still leverage the excellent libraries that I can today, I wouldn't be missing anything at all.
Theoretically. It's been reported to have lower total performance than the JVM, and a lot of libraries don't work with it yet. In any case, if GraalVM accomplishes its mission without the amount of handholding it requires today, sure.
I don’t know if I’d celebrate Spring... and Oracle would rather Android use “real” Java, not Dalvik.
The JVM was nice at the time, but I feel that languages like Scalia and Kotlin exist because Java was too conservative - and many of Kotlin’s great features had to be implemented using hacks and tricks to work-around the JVM’s now-primitive type-system. Also note that Kotlin can now target other platforms besides the JVM.
I think we can all agree the JVM is lagging behind the CLR, and the CLR is behind where we should be (when looking at the things that Clang is capable of)
That other popular Java-platform languages exist indeed shows that the Java language is too conservative for some, but that 90% use the Java language shows that its design is in line with what most people want.
And the CLR is about, oh, ten-fifteen years behind OpenJDK in compilation, GC and low-overhead deep profiling and observability. OpenJDK's C2 compiler is pretty much on par with clang in terms of optimisation [1] -- ahead on some, behind on others -- and in terms of sheer innovation and potential, its Graal compiler is probably the biggest breakthrough in compilation of the decade.
I would just say that usage isn't equivalent to want. I certainly can't put a number on it, but there is definitely quite a few of us that use Java because we are required to, not because it is what we want or the best tool for the job.
Its "language-enabling" feature set sucks. Reified generics for reference types force C#'s variance model on any CLR language that wants good code and data interop, and there is no portable good lightweight concurrency primitive. Sure Java is missing some important stuff like value types and tail call elimination (I don't think the CLR has the latter, either), both being addressed, but the CLR suffers from some early decisions that are nearly impossible to fix even if MS did show it had the inclination to fix them. Overall, Java is a more compelling compilation target than .NET, and Truffle is making it so much more so.
I've used SpringBoot recently on several projects after being in the Rails and Django and PHP world for a long time and I must say its super great.
I never could have imagined that I would praise a web framework based on Java 5 years ago.
Its lightweight, super fast (compared to Rails or Django), mature (its been around more that 15 years) and very stable.
It also supports Kotlin development
The more I learn about the Spring eco system the more I am suprised by how much stuff it covers everything from Spring Security to Spring Batch to Spring Reactive to Spring Cloud Task. Its mind blowing how much ground it covers.
Also, I hear the latest version will support Graal VM making start up times equivalent to native.
I strongly suggest spending time with it for those interested.
I've been beating this drum for a while. Spring has lots of legacy as it is 17 years old and has been through a series of technology waves over the years. That has both benefits and drawbacks.
With Spring Boot and Kotlin support it is now a modern framework that has straightforward solutions for most current problems. Built on a solid battle tested foundation (JVM + Core Spring)
Spring Boot (+ Kotlin) has been my goto stack for most problems for years now. There is a learning curve like most non-trivial software but once it clicks it's hard to go back to something else.
