Java at 30: Interview with James Gosling
436 comments
·May 16, 2025exabrial
hintymad
> And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc),
Java's tools are really top notch. Using IntelliJ for Java feels a whole new different world from using IDEs for other languages.
Speaking of Go, does anyone know why Go community is not hot on developing containers for concurrent data structures? I see Mutex this and lock that scattering in Go code, while in Java community the #1 advice on writing concurrency code is to use Java's amazing containers. Sometimes, I do miss the java.util.concurrent and JCTools.
shanemhansen
I'll offer a counterpoint to the responses. Until go got generics, concurrent data structures were awkward. The stdlib now does include things like sync.Map.
In fact my experience has been that overuse of channels is a code smell that alot of new go developers fall into and later regret. There's a reason the log package uses a mutex for synchronization.
In general I think channels are great for connecting a few large chunks of your program together. Concurrency is great but also not every function call benefits from being turned into a distributed system.
I think that it would be a great idea to develop more concurrent go data structures with generics and I suspect inertia is what's keeping the community from doing it.
My credentials such as the are: been writing go since 1.0. worked at Google and taught go classes as well as owned some of the original go services (the downloads server aka payload server).
hintymad
Yeah, even with channels and goroutines, I’d imagine we can encapsulate them as primitives in containers like concurrency literatures often advocate. Case in point, it was fun to go through Pike’s talk Go Concurrency Patterns, yet I’m not sure all the patterns he discussed in the talk would be that simple to implement compared to just declaratively using well-packed containers
int_19h
Not just generics, but also a way to generalize iteration (i.e. the equivalent of Java iterators). Which Go has only got even more recently than generics.
eikenberry
It's a core principle.
Don't communicate by sharing memory; share memory by communicating.
fidotron
My experience is a shocking amount of the golang community believe channels are a performance problem for whatever they're doing, and they use mutexes in some misguided effort at optimization.
But then I have also encountered Rust people that will look down on Java but had no idea buffered I/O had higher throughput than unbuffered.
hintymad
Thanks! What about data structure shared by multiple goroutines? Say, an in-memory cache object? Or do we always have multiple goroutines talk to a dedicated goroutine for the shared value? Would the performance be okay for all use cases? A reason that people use JCTools is that it can easily support hundreds of millions of concurrent reads/writes to its data structures on a 10-year old laptop.
zwnow
Just implement concurrency with actors and u save up on some locks and mutexes...
The patterns are available, its up to the community to apply proper concurrency patterns.
PaulDavisThe1st
The only replacement for locks/mutexes is a lock free data structure. Locks are not what make concurrency possible, they are what makes it data-safe.
You can use platform threads, user-space threads, language-provided "green" threads, goroutines, continuations or whatever you wish for concurrency management, but that's almost orthogonal to data safety.
saagarjha
Actors are implemented using locks.
paulddraper
The x86 instruction set is available as well.
null
tootie
The language has/had some rough edges that have been improved over the years, but the developer experience of using a strongly-typed, object-oriented language within a sturdy IDE like Idea is just second to none. The debugging process is so very straightforward. Java became synonymous with enterprisey bloated systems for good reason, but there is no pile of mud Java system that can't be stepped through cleanly with a debugger.
I'd also throw in what was possibly their greatest idea that sped adoption and that's javadoc. I'm not sure it was a 100% original idea, but having inline docs baked into the compiler and generating HTML documentation automatically was a real godsend for building libraries and making them usable very quickly. Strong typing also lined up nicely with making the documents hyper-linkable.
Java was really made to solve problems for large engineering teams moreso than a single developer at a keyboard.
topspin
> javadoc
Indeed. Many languages have something similar to Javadoc, yet somehow I haven't encountered anything quite as good as Javadoc, and I can't explain why or exactly how it's better. I admit I haven't tried that hard either. But I suspect it's down to the nature of the language and how, with well designed libraries at least (and not all are, certainly,) there is a nice decomposition of modules, packages, classes/interfaces and methods that leads to everything somehow having a correct place, and the Javadoc just follows. The strong typing is another contributor, where 90% of the time you can just look and the signature and imply what is intended. Finally, the old-fashioned frames based HTML typically used with Javadoc is a great benefit.
Also, I've found I experience less reluctance to author Javadoc for some reason. Again, part of this is due to strong types, and much of the legwork being correctly generated in nearly every case.
Lombok, when used with moderation, is wonderful. Mockito is magic, of a good kind. Maven still gets it done for me; I've yet to care about any problems Gradle purports to solve, and I think that's down to not creating the problems that Gradle is designed to paper over in the first place.
Today, if I had my choice of one thing I'd like to see in Java that doesn't presently exist it's Python's "yield". Yes, there are several ways to achieve this in Java. I want the totally frictionless generators of Python in Java.
tootie
Indeed Gradle creates more problems than it solves. Maven is still the best build system in any language. Python finally has uv which is the first non-horrible build tool after so many years of being the most popular language.
Terr_
I find these discussions have an interior split between the folks who are more concerned with getting the feature out now versus the folks who have had to keep a thousand ancient features running.
tootie
True, but it's also true that code spends 99% of it's lifetime in maintenance. That's the reason I am never impressed by tools that make it fast and easy to bootstrap.
datavirtue
This. It set the stage for modern enterprise software that we all take for granted now.
brightball
When I got out of college and was still firmly in the "Java is the solution to everything" mentality I didn't realize that my admiration was really for the JVM and the Java App Server tooling that was so much more advanced than anything else at the time. It was basically Docker + K8s for anything running on the JVM more than 2 decades earlier.
Java the language eventually drove me away because the productivity was so poor until it started improving around 2006-2007.
Now I keep an eye on it for other languages that run on the JVM: JRuby, Clojure, Scala, Groovy, Kotlin, etc.
IMO JRuby is the most interesting since you gain access to 2 very mature ecosystems by using it. When Java introduced Project Loom and made it possible to use Ruby's Fibers on the JVM via Virtual Threads it was a win for both.
Charles Nutter really doesn't get anywhere close to enough credit for his work there.
cogman10
Let me extol the virtues of Java the language.
You can take pretty much any code written for Java 1.0 and you can still build and run it on Java 24. There are exceptions (sun.misc.Unsafe usage, for example) but they are few and far between. Moreso than nearly any other language backwards compatibility has been key to java. Heck, there's a pretty good chance you can take a jar compiled for 1.0 and still use it to this day without recompiling it.
Both Ruby and Python, with pedigrees nearly as old as Java's, have made changes to their languages which make things look better, but ultimately break things. Heck, C++ tends to have so many undefined quirks and common compiler extensions that it's not uncommon to see code that only compiles with specific C++ compilers.
fpoling
I have C++ code from 1997 that I occasionally compile. So far it runs. 10 yeas ago compiling with -Wall exposed an inconsequential bug and that was it. I suspect when it stops to compile it will be from an absence of a particular X11 library that I used to parse a config in otherwise command-line utility.
Which also points to another thing where Java compatibility shines. One can have a GUI application that is from nineties and it still runs. It can be very ugly especially on a high DPI screen, but still one can use it.
jsight
Yeah, that and the portability are really incredible and underrated. It is funny, because I constantly hear things like "write once, debug everywhere", but I have yet to see an alternative that has a higher probability of working everywhere.
Although Python is pretty close, if you exclude Windows (and don't we all want to do that?).
cbm-vic-20
I've got a jar that does one small thing and does it well that was compiled in 1998. Still works fine, no reason to update it.
eppp
I know that what you said is supposed to be true. However in my real world experience it is anything but. Cisco java programs are a disaster and require certain JVMs to run.
worik
I have been badly burned, twice, by Python's cavalier attitude to backwards compatibility
KronisLV
> Moreso than nearly any other language backwards compatibility has been key to java.
The Java 8 and 8+ divide very much works against this. It was a needed change (much like Python 2 vs 3) but nowhere near pleasant, especially if some of your dependencies used the old Java packages that were removed in, say, OpenJDK 11.
Furthermore, whenever you get the likes of Lombok or something that has any dynamic compilation (I recall Jaspersoft having issues after version upgrade, even 7 to 8 I think), or sometimes issues with DB drivers (Oracle in particular across JDK versions) or with connection pooling solutions (c3p0 in particular), there's less smooth sailing.
Not to say that the state of the ecosystem damns the language itself and overall the language itself is pretty okay when it comes to backwards compatibility, though it's certainly not ideal for most non-trivial software.
johnisgood
> You can take pretty much any code written for Java 1.0 and you can still build and run it on Java 24.
This is not my experience with Java at all. I very often have to modify $JAVA_HOME.
int_19h
The counter-example to this is C#. Barely younger than Java (by 5 years), and starting its life as mostly a Java clone with a sprinkle of Delphi, it evolved much faster and made many changes which "make things look better" without breaking things. Source-level compatibility goes pretty much all the way back to 1.0, as well.
jbverschoor
Oh yeah. I still don’t understand why we even moved away from the original JEE model, including the different roles (app dev, deployed, etc).
The whole spec was great with the exception of entitybeans.
It provided things that are still not available it anything else.. why do we store configuration/credentials in git (encrypted, but still).
And the context were easy to configure/enter.
Caucho’s resin, highly underrated app server. Maybe not underrated, but at least not very well known
icedchai
Entity Beans were terrible, representing the height of JEE over complexity. I remember editing at least 3 classes, a couple interfaces, and some horrific XML deployment descriptors to represent an "entity." A lot of the tooling was proprietary to the specific app server. On top of that, it was slow.
In the early 2000's, I used to work on JEE stuff for my day job, then go home and build PHP-based web apps. PHP was at least 10x more productive.
brightball
I remember Resin.
I grew to be a big fan of JBoss and was really disappointed when the Torquebox project stopped keeping up (Rubyized version of JBoss).
liveoneggs
resin was okay but I never got what it offered over tomcat
null
ksec
It is unfortunate the whole JRuby doesn't get more attention and it seems Rails community dont use JRuby much.
JRuby could also run on Graal as well.
znpy
> Java memory management seems weird from a Unix Philosophy POV, till you understand whats happening. Again, not perfect, but a good tradeoff.
The GC story is just great, however. Pretty much the best you can get in the entire ecosystem of managed-memory languages.
You have different GC algorithms implemented, and you can pick and tune the one that best fits your use-case.
The elephant in the room is of course ZGC, which has been delivering great improvements in lowering the Stop-the-world GC pauses. I've seen it consistently deliver sub-millisecond pauses whereas other algorithms would usually do 40-60 msec.
Needless to say, you can also write GC-free code, if you need that. It's not really advertised, but it's feasible.
nxobject
> The elephant in the room is of course ZGC, which has been delivering great improvements in lowering the Stop-the-world GC pauses. I've seen it consistently deliver sub-millisecond pauses whereas other algorithms would usually do 40-60 msec.
As someone who's always been interested in gamedev, I genuinely wonder whether that would be good enough to implement cutting-edge combo modern acceleration structures/streaming systems (e.g. UE5's Nanite level-of-detail system.)
I have the ability to understand these modern systems abstractly, and I have the ability to write some high-intensity nearly stutter-free gamedev code that balances memory collection and allocation for predicable latency, but not both, at least without mistakes.
fidotron
> As someone who's always been interested in gamedev, I genuinely wonder whether that would be good enough to implement cutting-edge combo modern acceleration structures/streaming systems (e.g. UE5's Nanite level-of-detail system.)
The GC would be the least of your problems.
Java is neat, but the memory model (on which the GC relies) and lack of operator overloading does mean that for games going for that level of performance would be incredibly tedious. You also have the warm up time, and the various hacks to get around that which exist.
Back when J2ME was a thing there was a mini industry of people cranking out games with no object allocation, everything in primitive arrays and so on. I knew of several studios with C and even C++ to Java translators because it was easier to write such code in a subset of those and automatically translate and optimize than it was to write the Java of the same thing by hand.
astrange
I'm honestly amazed people say this about Java, because the language almost couldn't be worse at giving you tools to use memory efficiently.
There's no value types (outside primitives) and everything is about pointer chasing. And surely if there was less pointer chasing it'd be easier to do the GC work at the same time.
vips7L
When people talk about GC performance they’re not talking about using memory efficiently. They’re talking about how fast the GC can allocate and how long it will stop the world when it needs to collect. In both of these areas you won’t find GCs better than the ones provided by HotSpot. Even with what you mention, pointer chasing and lack of structs, they still outperform other implementations.
neonsunset
> Needless to say, you can also write GC-free code, if you need that. It's not really advertised, but it's feasible.
It is not feasible under the JVM type system. Even once Valhalla gets released it will carry restrictions that will keep that highly impractical.
It's much less needed with ZGC but even the poster child C# from the GC-based language family when it comes to writing allocation-free and zero-cost abstraction code presents challenges the second you need to use code written by someone who does not care as much about performance.
zdragnar
Zero-allocation (obviously different from zero GC) frameworks made a bit of a splash a little while back, but I'm not seeing much about them anymore from a brief search. I would have sworn that quarkus was one of them, but it looks like that's definitely not the case anymore.
The downside is that you sacrifice a lot of the benefits of guard rails of the language and tooling for what may not end up being much savings, depending on your workload.
javier2
> Java syntax isn't perfect, but it is consistent, and predictable
This is something I greatly value with the recent changes to Java. They found a great way to include sealed classes, switch expression, project Loom, records that feels at home in the existing Java syntax.
The tooling with heap dump analyzers, thread dump analyzers, GC analyzers is also top notch.
aardvark179
I think Gavin Bierman is an unsung hero as far as steering the Java language is concerned. I had the privilege to sit next to him in the office when I was working on TruffleRuby, and our conversations on language design were always elucidating, and his ability to gently steer others away from pitfalls was something I wish I could do as well.
Hearing the work he and others did to gradually introduce pattern matching without painting themselves into a corner was fascinating and inspiring.
Thaxll
Java is not ahead of Go, they're on part but often Go is faster while using 2-10x less memory. Value type makes optimization much easier in Go.
The fact that you specifically mention Go explains a lot. btw c# is faster than Java, so not third place, it's more a 5th~
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
999900000999
Doing what?
Benchmarks aren’t all that useful since usually the bottleneck is File IO, external api calls, db calls, user latency or a combo of the 4.
Go’s main advantage in this matchup would be conciseness.
Go code looks so clean and nice, Java doesn’t.
I personally don’t care for Java, but I have bills so it’s always in my back pocket. Things happen , sometimes you need to write Java to eat.
“Fred, you really should just take the job.”
“Martha you don’t understand, it’s Java with an Oracle DB.”
“Fred, I know it’s bad, I know you still have nightmares about the 4 types of string in Java 8, but it’s not just us now.”
With a tear in his eye , fear in his heart.
“Martha, if I must… I’ll open Eclipse once more.”
noisy_boy
> I personally don’t care for Java, but I have bills so it’s always in my back pocket. Things happen , sometimes you need to write Java to eat.
I write Java to pay bills and my eyes and fingers thank me everyday for sparing them from a sea of if err != nil. I won't even go(!) into the iota stupidly compared to Java's enums.
vips7L
Go code is far from concise. Java is more expressive than Go in almost every way.
lelanthran
> Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad.
When Java got popular, around 1999-2001, it was not a close third behind C (or C++).
At that time, on those machines, the gap between programs written in C and programs written in Java was about the same as the gap right now between programs written in Java and programs written in pure Python.
int_19h
I don't think that's accurate. Java at the time you're describing was already JIT-compiled (HotSpot debuted in 1999), which made it drastically faster than any plain bytecode interpreter. OTOH Python was - and remains - notoriously slow because, despite being compiled to bytecode, said bytecode is extremely high level and many opcodes in it represent potential numerous dict lookups etc.
pjmlp
And yet many of us embraced Java, it became the chosen language to teach distributed systems in many Portuguese universities around 1998, because of the pain to write portable C or C++ code across UNIX clones.
A mix of K&R C, C89, C++ARM compilers catching up with WG21 work, POSIX flavours, and lovely autoconf scripts.
lelanthran
> And yet many of us embraced Java,
That was my point - performance was never one of the primary considerations for enterprises. They had more important considerations.
nxobject
Third best consistently used over 3 decades adds up to a great, great deal. Although, to be fair, a great deal has been invested in cutting edge GCs for the JVM – some fresh out of research.
nelup20
I personally appreciate Java (and the JVM) much more after having tried other languages/ecosystems that people kept saying were so much better than Java. Instead, I just felt like it was a "the grass is greener" every time. The only other language that I felt was an actual massive improvement is Rust (which so far has been a joy to work with).
It's a shame imo that it's not seen as a "cool" option for startups, because at this point, the productivity gap compared to other languages is small, if nonexistent.
bsaul
Funny. I've been trying rust for the past 2 months fulltime, and i'm really wondering how you can call it a "joy to work with" when compared to java, at least for server development.
Rust feels like walking on a minefield, praying to never meet any lifetime problem that's going to ruin your afternoon productivity ( recently lost an afternoon on something that could very well be a known compiler bug, but on a method with such a horrible signature that i never can be sure. in the end i recoded the thing with macros instead).
The feeling of typesafety is satisfying , i agree. But calling the overall experience a "joy" ?
asa400
I'm not discounting your experience, or saying you're wrong or anything like that. I've been writing Rust for a while, and for me, that feeling went away. Lifetime/ownership problems used to run me over but it almost never happens anymore. I think Rust has a rather severe "hump" that a lot of people run headlong into, but it does get better, I promise you. You start thinking in ownership/borrowing terms and it just fades into the background at some point. Rust is easily my most productive language now. Again, not discounting your experience at all, it can be rough starting out.
bsaul
i do feel much more comfortable with lifetimes than at the beginning. I get the general concept, and i barely have to explicitely set them (i did start by religiously reading the rust book, of course).
However, at the moment i still feel i'm using a huge amount of layers upon layer of complex type definitions in order to get anything done. Just using an object's reference across async calls in a safe manner leads to insane types and type constraints, which read like ancient egyptian scripture. And at every layer, i feel like changing anything could blow everything up with lifetimes.
The language has this very special feel of something both advanced and extremely raw and low-level at the same time. It's very unique.
debugnik
Not all lifetime problems are just a matter of learning. I've been picking up Rust every few years to catch up, and every single time I've eventually expressed a lifetime that either required unstable Rust at the time or hit a known lifetime bug.
treyd
You eventually learn you leverage lifetimes. You just need to get over that point in the learning curve. I very rarely run into those types of issues, and it's very freeing knowing that I can write libraries that are so hard to misuse because you can leverage the type system.
And macros are a part of that!
rwmj
Why do I need to? Why can't I let the garbage collector deal with it?
Rust's macros on the other hand are excellent, and more languages should have expressive macros like that.
bsaul
i indeed got the feeling that rust style favors macros over complex function signatures.
I'm still unsure if it's a good thing in general, because as a general rule meta programming is always harder to debug. But for simple macros it seems like a nice trick.
null
worik
> I've been trying rust for the past 2 months fulltime
Rust has a horrid learning curve
I've programmed for decades in many languages, and I felt the same as you
Persevere.
Surrender! to compile
Weather the ferocious storm
You will find, true bliss
bsaul
I am keeping up, but honestly i feel like rust dev is a bit like a trap : people like us love challenges and solving technical problems. So whenever we "triumph" over a rust tricky compilation issue, we feel intense gratification in solving it.
However, at some point you have to ask yourself why you're accepting to face all those challenges. Is it worth it ? When was the last time i faced a race condition when developping a backend ?
The reason i started with rust was for a very specific need on building a cross-platform library (including wasm), and that was a good justification, and i'm happy that i did. However now that i'm using it for the server as well and face the same kind of challenges, i seriously question whether this is a wise choice.
mynameisash
> I've been trying rust for the past 2 months fulltime,
> recently lost an afternoon on something that could very well be a known compiler bug
With respect, at two months, you're still in the throes of the learning curve, and it seems highly unlikely you've found a compiler bug. Most folks (myself included) struggled for a few months before we hit the 'joyful' part of Rust.
johnisgood
Okay, but I have hit the joyful part of some other languages long before a few months. What gives?
heavyset_go
IME, new users do weird things that can expose bugs no one ran into because they wouldn't think to do things the weird way.
vips7L
> With respect, at two months, you're still in the throes of the learning curve,
It shouldn’t take 2 months of full time programming to beat the learning curve.
bsaul
i didn't "find" it. As i said, it's a well known one : https://github.com/rust-lang/rust/issues/110338
Simply using axum with code using multiple layers of async was enough.
But then again, it looked like this bug (the error message is the same), however at this point i'm really unsure if it's exactly the same. The error message and the method signature was so atrocious that i just gave up and found a simpler design using macros that dodged the bullet.
kllrnohj
Personally I think C# is miles ahead of Java and in meaningful ways (like a drastically better implementation of generics, not to mention value types have existed for eons at this point and an FFI system that doesn't hate you for using it)
But nobody seems to talk about or care about C# except for Unity. Microsoft really missed the boat on getting mindshare for it back in the day.
bsaul
Problem with C# isn't the language, it's the enterprise ecosystem. You always feel like you're going to have to pay at some point down the road for using the tech.
cgh
Every large company I’ve ever worked at had a strict “no Microsoft on the server” policy and for better or worse, C# is closely identified with Microsoft.
hu3
I don't see Java being any better in this regard.
Microsoft has been historically much less aggressive with lawyers compared to Oracle.
dagw
nobody seems to talk about or care about C# except for Unity
C# is extremely popular in all kinds of 'boring' industries. Having worked in areas like logistics and civil engineering, C# is everywhere.
echelon
That's because the Microsoft of 2000 - 2014, the Ballmer era, was Microsoft-first. It didn't care about other platforms, it didn't care about the web, and it didn't care about open source. C# could be great, but it existed in a bubble.
Java kept growing and wound up everywhere. It played nice with Linux. Enterprise Mac developers didn't have trouble writing it with IntelliJ. It spread faster because it was open.
Satya Nadella fixed a lot of Microsoft's ills, but it was too late for C# to rise to prominence. It's now the Github / TypeScript / AI era, and Satya is killing it.
The one good thing to say about Ballmer is that he kicked off Azure. Microsoft grew from strength to strength after that.
null
fuzztester
>Satya Nadella fixed a lot of Microsoft's ills,
which ones?
astrange
> But nobody seems to talk about or care about C# except for Unity. Microsoft really missed the boat on getting mindshare for it back in the day.
There was this guy Miguel de Icaza. From when I followed the open source ecosystem at the time, it seemed to be his personal mission to promote independent clones of a bunch of Microsoft technologies like C# on his own time even though they didn't ask him to do it.
I don't think I ever understood why someone would do this. It's like in the 2000s where people seemed to think you could solve all technical problems by inventing new kinds of XML.
bitwize
The founding document of GNOME was written by de Icaza. It was called "Let's Make Unix Not Suck", and his proposal for not sucking was basically to import much of the design of Windows and specifically COM into Linux as open source.
https://web.archive.org/web/20000815075927/http://www.helixc...
Miguel de Icaza has been stanning for Microsoft technologies, literally since the nineties.
astura
C# isn't popular in startups for the same reason Java isn't, it's "boring."
It's an extremely common language in "boring" companies doing "boring" (but profitable) work.
throw1235435
Depends where you work. I've seen a lot of Java and .NET jobs around where I am. Having both jobs I find it easier to get performant code in .NET than Java (reified generics, value types, more primitives/less boxing in general, and other constructs not found in Java)
watwut
Definitely not. All the stuff I was used to get for free and advice I that was one google search away ... just dont exist in dotnet. Or is expensive. But most of the time, there is weaker library not doing nearly enough and that is all that exists.
wokkel
It barely works on non MS platforms,has had many slightly incompatible versions so it's a non starter for many projects where I run into that might benefit from c#. I spoke to a manager recently who had invested in silverlight in the past. Based on that alone it was a no MS policy for his development teams.
runjake
AFIACT, either most or at least a significant percentage of dotnet code runs on Linux, depending on the industry.
tester756
>It barely works on non MS platforms
What a bullshit
I've been running C# on Linux on production web apps backends since 2018 and had no issues
blandflakes
We've been running .NET on linux for years, what are you talking about?
neonsunset
Quite a few languages "loved" by "Linux communities" tend to have rather rudimentary integration with Linux kernel's facilities or worse packaging story.
For example, Go does not understand cgroups limits and needs an external package to solve this. .NET can read and accommodate those natively. It also ships with excellent epoll-based socket engine implementation. It's on par with Go (although I'm not sure which one is better, but .NET performs really well on high-throughput workloads).
deepsun
My opinion on that is the projects scale. Typically people came from a 10+ year Java project of 100+ engineers, to a greenfield advanced hello-world -- of course it's going to feel better and more productive.
Also, as open-source folks say, "rewrite is always better". It also serves as a good security review. But companies typically don't have resources to do complete rewrites every so often, I saw it only in Google.
sabellito
I've worked in 3 of the biggest rails codebases in the world (Shopify being the last) and I can say from experience that rails legacy monoliths are infinitely worse to work with than some awful, but harmless, sea of struts XML legacy.
stevoski
I find this really interesting, and meets my (limited) Rails experience and (extensive) Java experience:
I found it hard taking over an existing Rails project - it felt frail to me, that any small change might have unexpected consequences.
Whereas when I've taken over Java projects - or come in late to an existing team - I felt quite confident getting started, even if it is a bit of a mess.
watwut
Same here. I started to really like java after working with js/ts on small to medium project. I started to love java after working in on medium to little big project.
sapiogram
My feelings exactly. Go was particularly disappointing, it promised everything but only felt like a sidegrade from Java. Screw it, a downgrade, until go errors get stack traces.
overfeed
The reason I prefer the Go ecosystem to Java is cultural, rather than technical. Sure, the JVM is very impressive and the language has been evolving, but the culture around Java seems to encourage needless complexity.
Of all the languages I've had to work with trying to get to know unfamiliar code-bases, it's the Go codebases I've been quickest to grok, and yielded the fewest surprises since as the code I'm looking for is almost always where I expect it to be.
skydhash
I think kotlin is what Java should have been like. The same capabilities but with less cumbersome constraints.
whartung
The don't embrace that culture. Embrace a simpler culture. Strive for simplicity. Push for fewer dependencies.
Simple example, JAX-RS running on top of Java SE. I agree, JAX-RS is not what one might call "simple". It IS complex, or I should say, it CAN be complex. But Happy Path, staying in the middle of the road, it's pretty sweet for knocking out HTTP backed services. The Jersey reference implementation will do most anything you need (including stuff not "included" in raw JAX-RS). No need for a container, no need for a lot that stuff and all that hanger-on. The core runtime is pretty broad and powerful.
Consider my current project, it uses the built in Java HTTP server. Which works! It's fast, it's functional, it's free. (Yes, it's in a com.sun.net... package, but it's not going anywhere.) It's awkward to use. It's aggravatingly raw. It follows the tenet "why be difficult, when, with just a little effort, you can be impossible."
So, I wrote a simple "servlet-esque-ish" inspired layer for response and request handling, a better path based regex-y router, and a nicer query parser for queries and forms. 500 lines. Add on a JSON library and I can process JSON-y web request/response, easily. (I also wrote my own Multipart processor -- that was another 500 lines, boy that was fun, but most folks don't need that.)
A little bit of code and the built in server is MUCH easier to use. No tomcat, no deploys, zip. ...and no dependencies (save the JSON library).
Something all of these cool frameworks and such have shown me is what's really nice to have, but at the same time, just what isn't really necessary to get work done. I mean, CDI is really neat. Very cool. But, whoo boy. So I have a single singleton to handle application life cycle and global services. It works great with tests. I have a 50 line Event Bus. I have a 100 line "Workflow Engine". 150 line java.util.Logger wrapper (which is mostly, you know, wrapper). I wrote that way back whenever they introduced varargs to java (Java 5? 6?). The modern Java logging landscape is just...oh boy. I'm content with JUL -- I can make it work.
My current project is "magic free". I think @Overide in the single annotation anywhere in it. But it's comfortable to use, the cognitive load is quite load (outside of the actual application itself, which is NOT low -- sheesh). No swearing at frameworks. It's all my fault :).
Anyway, the point is that "simple Java" lurks in there. It needs a bit of uplifting, but not a lot.
LtWorf
True, but the culture around go isn't any better. In my experience go developers are former java developers so they have the same culture of thinking it's ok to ignore how a unix system works. So you will have awful logging, daemons that never report they're ready, badly handmade command line parsing and so on.
null
arccy
funny. java is known for its stacktraces where you need 3 vertical monitors stacked together to see the whole thing and it still doesn't tell you anything useful about why the app crashed.
marginalia_nu
I think that's a bit unfair. Generally the stacktraces tell you exactly what and where the problem is. Generally shouldn't be more than a dozen lines or so.
The main area they get excessively lengthy is in certain frameworks and testing tools that can add like 100 lines to the trace.
frontfor
Compared to Go where I always have to remember to print the stack trace in every goroutine’s panic handler or use a custom error type that includes the stack trace or I get nothing? And I have to do this very basic thing for every service I spin up? This might not matter for pet projects or CLI applications, but it matters a lot in large scale mission critical servers.
jjav
> stacktraces where you need 3 vertical monitors stacked together
If you wrote code with such deep stacktraces, it's all on you.
There's a performance cost to all that excessive stack depth too, often.
int_19h
This is unfortunately common across most ecosystems today. Such lengthy stack traces are routine in JS, and fairly common in C++.
hu3
as someone who had to deal with Java stack traces the entire week, I feel attacked.
God bless Gemini 2.5 Pro which ate all the traces for breakfast.
bdangubic
same! mid-way through my almost 3 decade career I got bored and thought lets try some non-JVM projects, for 2 years I took projects using other languages etc… worse two years of my career :)
mark_l_watson
Right on, James Gosling's work is amazing, and he and the whole Java ecosystem have my gratitude: I went to the first Java World Tour conference and wrote a little blog article about it that was linked on Sun's home Java page for about a year. I was very lucky, and since I was the first search hit for 'Java consultant' for a very long time that gave my wife and I the freedom to live in a rural area and I could get remote work for a decade.
As long as I am expressing gratitude, I would also like to call out the Clojure team for developing a wonderful ecosystem in top of Java and the JVM.
It must be wonderful to do work that positively affects the lives of millions of people.
jgneff
I am also very grateful to James Gosling. I was working with C++ at Taligent (an Apple, IBM, and HP joint venture) in the fall of 1995 when I first downloaded Java to give it a try. I literally jumped up and down with joy after writing my first "Hello, World" program. It was such a breath of fresh air compared to the Taligent CommonPoint application framework we were building.
I took the severance package when Taligent imploded, dropped everything I was doing at the time, and have been working with Java and its related software ever since.
fidotron
I think it's incredible with hindsight how Java countered many of the mid 90s C++ problems, especially by avoiding multiple inheritance.
It remains a shame that it didn't launch with generics though, and I still think operator overloading would have been good. Had it done so I think a lot more people would have stuck around for when the performance improved with HotSpot.
astrange
> I think it's incredible with hindsight how Java countered many of the mid 90s C++ problems, especially by avoiding multiple inheritance.
This is because Java is based on an older language called Objective-C that doesn't have multiple inheritance :)
It's not based on C++, that's just the other OO language from the era people usually think of.
dragandj
Both James Gosling (Java) and Rich Hickey (Clojure) are amazing creators! Each brought a breath of fresh air to programming at their respective times.
PathOfEclipse
I've been working in .NET/C# for the past few years, and while I'm happy with it, I still think the JVM/Java are the best ecosystem overall I've worked in. It's amazing how many things the Java ecosystem gets right that .NET gets wrong.
For instance, Java introduced the fork/join pool for work stealing and recommended it for short-lived tasks that decomposed into smaller tasks. .NET decided to simply add work-stealing to their global thread pool. The result: sync-over-async code, which is the only way to fold an asynchronous library into a synchronous codebase, frequently results in whole-application deadlocks on .NET, and this issue is well-documented: https://blog.stephencleary.com/2012/07/dont-block-on-async-c...
Notice the solution in this blog is "convert all your sync code to async", which can be infeasible for a large existing codebase.
There are so many other cases like this that I run into. While there have been many mistakes in the Java ecosystem they've mostly been in the library/framework level so it's easier to move on when people finally realize the dead end. However, when you mess up in the standard library, the runtime, or language, it's very hard to fix, and Java seems to have gotten it more right here than anywhere else.
MarkSweep
The thread pool starvation problem in .NET is annoying when you encounter it. Personally I have not bumped into since the .NET framework days.
The thread pool implementation has been tweaked over the years to reduce the impact of this problem. The latest tweak that will be in .NET 10:
https://github.com/dotnet/runtime/pull/112796
I’m not sure a thread pool implementation can immune to misuse (many tasks that synchronously block on the completion of other tasks in the pool). All you can do is add more threads or try to be smarter about the order tasks are run. I’m not a thread pool expert, so I might have no idea what I’m talking about.
deepsun
Interesting. I'm not a .Net programmer, but I always thought .Net takes winning approach from Java ecosystem and adopts it. Java approaches/frameworks are kinda pioneering and competing, while .Net follows and grabs the best. So instead of competing approaches/frameworks (like ORMs for example) .Net has only one, the best one, well adopted and used by everyone there.
But reading your message it doesn't sound like it.
neonsunset
[flagged]
dang
We've banned this account for repeatedly abusing the site guidelines and ignoring our many requests to stop.
https://news.ycombinator.com/item?id=43009383 (Feb 2025)
https://news.ycombinator.com/item?id=43009374 (Feb 2025)
https://news.ycombinator.com/item?id=41121266 (July 2024)
https://news.ycombinator.com/item?id=40979059 (July 2024)
andyjohnson0
HN only works because people are generally respectful and assume good faith. Your post is rather the opposite. I hope that you'll maybe reflect on that.
null
PathOfEclipse
That's a very harsh reply with zero evidence behind it. Based on your response, I am willing to bet I understand the platform better than you do. And the deadlocks I'm referring to are happening in apps written by other people who've been in the .NET ecosystem exclusively for more than a decade, or even two decades.
Here's an article from 5 years ago:
https://medium.com/criteo-engineering/net-threadpool-starvat...
But does citing a more-recent article matter to you? Probably not. A source being 13 years old only matters if something relevant has changed since then, and you certainly couldn't be bothered to point out any relevant change to support your otherwise fallacious and misleading comment.
What actually amazes me most about this is that people in .NET seem to want to blame the person writing sync-over-async code like they are doing something wrong, even going so far as to call it an "anti-pattern", when in reality it is the fault of poor decision-making from the .NET team to fold work-stealing into the global thread queue. The red-blue function coloring problem is real, and you can't make it go away by pretending everyone can just rewrite all their existing synchronous code and no other solution is needed.
If all you know is one ecosystem, then it seems you are susceptible to a form of Stockholm syndrome when that ecosystem abuses you.
neonsunset
[flagged]
w10-1
Java is a great success story. Though, to be fair, James Gosling was the spark but has not been the steward.
Even as early as Java 1.1 and 1.2 he was not particularly involved in making runtime, library, or even language decisions, and later he wasn't the key to generics, etc.
Mark Reinhold has been the hand's-on lead since 1.1, first integrating early JIT's, HotSpot, the 1.2 10X class explosion, and has been running the team all the way through Oracle's purchase, making the JVM suitable for dynamic language like Kotlin and Clojure, open-sourcing, moving to a faster release cadence, pushing JVM method and field handles that form the basis for modern language features, migrating between GC's, and on and on.
As far as I can tell, everything that makes Java great has come down to Mark Reinhold pushing and guiding.
elric
The whole core team is amazing. Gosling wanted a language that was practical from a development POV. Over the years, it's been refined into a language with a fair amount of mechanical sympathy on top of the development experience. Thanks to folks like Mark Reinhold and Brian Goetz.
I have no love for Oracle the big bad company. But I am deeply greatful they've managed to keep that group moving forward.
billmcneale
> dynamic language like Kotlin and Clojure,
Kotlin is not a dynamic language, it's statically typed, just like Java.
selfhoster
> Java is a great success story. Though, to be fair, James Gosling was the spark but has not been the steward.
That's like saying Linus was only the spark for git because he spent two weeks hacking it from scratch.
The whole world uses git now.
toprerules
I admire Java as a success story, but I still have a deeply ingrained aversion to it for many reasons. I will admit that many of the reasons are due to Java's legacy as the language of bloated corporations, and its creation of overly verbose, magic fueled frameworks and poorly written code. Java as a language goes hand in hand with the idea that code is coal to be shoveled into the furnace, and we should all throw our aspirations away and embrace mediocrity.
My other issues with the JVM is how much of a black box it is from a platform perspective, which makes debugging a PITA with standard ops tools like strace, gdb, etc. The JVM's over allocation of memory robs the kernel of real insight as to how the workload is actually performing. When you use the JVM, you are completely locked in and god help you if there isn't a JVM expert to debug your thing and unravel how it translates to a platform implementation.
Then of course there's the weird licensing, it's association with Oracle, managing JDK versions, it's lack of it factor in 2025, and a huge boatload of legacy holding it back (which is not unique to Java).
I have successfully navigated my career with minimal exposure to Java, and nowadays there's a glut of highly performant languages with GC that support minimal runtimes, static compilation, and just look like regular binaries such that the problems solved by something like the Java or Python VMs just aren't as relevant anymore - they just add operational complexity.
To reiterate, I admire JG just like any tech person should. Java's success is clear and apparent, but I'm glad I don't have to use it.
exabrial
>My other issues with the JVM is how much of a black box it is from a platform perspective, which makes debugging a PITA
Java has one the greatest debugging capabilities ever. dynamic breakpoints, conditional breakpoints, hell you can ever restart a stack frame after hot deploying code without a restart. You can overwrite any variable in memory, set uncaught exception breakpoints, and even have the JVM wait for a debugger to connect before starting. There is no equivalent in any other language that does _all_ of these things. And to top this off, there is 0 equivalent to Idea or Eclipse for any other language.
For runtime dynamics, JMX/JConsole is good enough for daily use, Java Flight Recorder gives you deep insight, or in a system you don't have direct access to. Hell even running jstack on a JVM is a good debug tool. If those don't do the trick, there's plain old HPROF (similar to other languages) and Eclipse Memory Analyzer.
>Then of course there's the weird licensing,
The JVM is open source. There are no licensing issues. OpenJDK can be freely downloaded and run in production without restrictions on any use. If you really want to buy a JVM from Oracle... well thats your prerogative.
> it's lack of it factor in 2025,
sdkman
> a huge boatload of legacy holding it back
what legacy code?
marginalia_nu
> what legacy code?
The Java API has its fair deal of baggage due to its extreme backward compatibility. Boolean.getBoolean[1] is one of the more accessible examples of a bad API that exists only because of legacy reasons, but there quite a number of them.
[1] https://docs.oracle.com/javase/8/docs/api/java/lang/Boolean....
exabrial
Ow.
int_19h
> dynamic breakpoints, conditional breakpoints, hell you can ever restart a stack frame after hot deploying code without a restart. You can overwrite any variable in memory, set uncaught exception breakpoints, and even have the JVM wait for a debugger to connect before starting. There is no equivalent in any other language that does _all_ of these things
.NET + C# can do all of these things.
exabrial
I was referring to the entire list above, that's what I was referring to
null
the_overseer
IT factor! Am I on a fashion website now? What kind of argument is that? Also, why on earth would you use strace or gdb for Java? It has enormously performant debugging tools in the JDK. Also, IDE debugging integration is second to none.
bitwize
"It" factor affects talent pool size. If you're planning a large project and want to hire talent to staff it, how popular a language and framework you choose to implement it in has a direct effect on the cost of implementation. Hint: popular languages and frameworks are far easier to hire for than obscure ones, so unless you have a VERY GOOD REASON not to, it's best to choose a popular language.
toprerules
Because if I'm debugging a critical issues and wading through multiple layers of processes and system interactions, I don't want to have to learn a bespoke toolkit and debugging system for every single process.
briankelly
The tooling is pretty easy to learn if scary looking at first and becoming a JVM expert, at least in the context of GC tuning, might take you a week or less. Some of the defaults are surprising though.
And I think there is some parallel with the kernel vs GC and mmap vs buffer pools - the GC simply has better context in the scope of the application. With other processes in the picture, though, yeah there is some provisioning complexity there.
jjav
> My other issues with the JVM is how much of a black box it is from a platform perspective, which makes debugging a PITA
You state how you don't really use java, but the above confirms it.
Java debugging and diagnostic tooling is second to none.
toprerules
That's a really narrow view of the world, and I think another Javaism to think that Java is the entire world. Today's multi-service deployments run tens if not hundreds of auxiliary processes not using Java. They use network overlays that change how processes interact with the network core. A person who is debugging a knock on effect issues has to be able to look through many different layers of processes, many of which are written in C, C++, Go, etc. Having to learn an entire toolset to debug Python or Java is a huge burden and it makes introspection extremely difficult. Java essentially wants to be the entire platform, which isn't how the world works anymore.
vips7L
Don't you think a narrow view of the world is this idea that you should be able to use one tool to debug everything? It seems like you want GDB (and the unix's where it runs) to be the entire platform.
jjav
When you need to debug across the entire system and into the kernel, I'd use dtrace which has had java stack frame support since... I don't remember anymore, but closing in on 20 years.
cgh
Debugging Java is great, as others have mentioned. This includes probably the best remote debugging capabilities available for any platform.
OpenJDK, the de facto standard version used by everyone, is licensed under the GPL version 2 with the classpath exception.
No offence, but you simply aren’t well informed.
throwaway7783
In my 20+ years using java, not once have I used strace or gdb. Java itself has fantastic debugger support, and IDEs have built in step through capabilities.
Mentioning Java and Python in the same way in the context of performance is really odd. Python is nowhere near the JVM when it comes to performance
toprerules
It sounds like you've only ever written code without dealing with it in production. You can't always plug your code into an IDE when your debugging someone else's JVM app on a remote server.
lenkite
Please - you can definitely do this in Java. Its been a standard basic feature of Java tooling for 25 years now. (Its the equivalent of saying that Rust doesn't have a package manager).
I strongly urge reading some elementary tutorials to educate yourself.
See https://www.baeldung.com/java-application-remote-debugging for CLI based remote debugging
But most people use IDE's.
See https://www.jetbrains.com/help/idea/debugging-your-first-jav...
and https://www.jetbrains.com/help/idea/tutorial-remote-debug.ht...
Java's debugging experience is better than any language out there - with the possible exception of Common LISP. I always cry when I need to debug a project written in another language after so much comfort using Java.
vips7L
Except you can. Remote debugging is a huge feature.
throwaway7783
Eh, okay. Sounds like you don't know how to do this in production.
rootbear
When Gosling was at Sun, he was one of two principal architects of the NeWS Window system. The X Window system was designed for "dumb" display devices and so the display elements were all static, not requiring much work from the server. NeWS was designed to run on a (Sun) workstation, where there was a lot of computational power available, so it was based on Postscript. A NeWS client would send a program to the server, not just static commands.
Gosling, unsurprisingly, designed Java with the NeWS model in mind, where web pages were programs, not just static HTML documents. When I got him to sign my copy of "The Java Programming Language", I asked him if Java was the revenge of NeWS. He just smiled.
AStonesThrow
The corollary of this was Display PostScript. At my first job we had a SPARCStation 2 with a SPARCprinter. The SPARCStation was a mighty wonder to behold, with a storage pedestal and a lovely OpenWindows GUI on a luxurious Sun monitor and color framebuffer. The operator sitting at the desk was often just a novice clerical worker, but we ran a few Internet services on the machine as well. However, our department depended on that SPARCprinter to spit out hundreds of sheets of paper daily.
We could not depend on the printer to stay functional, though. Have you heard of a Winmodem? SPARCprinters were essentially that: they were configured as a "dumb display device" where all the imaging logic was contained in the software and run on the server. A page was written in PostScript, rendered on the print server, and dispatched to the printer as if it were a framebuffer/monitor.
Unfortunately, for whatever reason, the server software was not so reliable, or the printer hardware wasn't reliable, and because of this peculiar symbiotic parasitism, whenever our printer wedged, our server was also toast. Every process went into "D" for device wait; load averages spiked and all our work ground to a halt. We would need to pull the worker off the desktop, reboot the whole server, and start over with the printer.
That printer haunted my dreams, all though my transition from clerk, to network operator, to sysadmin, and it wasn't until 2011 when I was able to reconcile with printers in general. I still miss SunOS 4 and the whole SPARC ecosystem, but good riddance to Display PostScript.
bitwize
Just as we have a modern successor to X in Wayland, we also have a modern successor to NeWS: the browser with JavaScript, with PWAs and Electron providing a smoother desktop integration.
I wonder what Gosling thinks of the fact that NeWS ultimately won in the end, even on Microsoft systems.
aabajian
Just going to remind y'all of this: https://www.joelonsoftware.com/2005/12/29/the-perils-of-java...
I went to a Java school. I remember my operating systems class involved writing simulated OS code in Java (for example, round robin for context switching). The argument was that it would be easier to understand the algorithms if the hardware complexities were minimized. I understand that sentiment, but I don't think Java was the right choice. Python would have accomplished the same task even better (understanding algorithms). I think there was a huge influence from industry to teach college students Java from day one. I had taught myself BASIC and some C back in high school, so it was a bit of a step backwards to learn a high-level language just to do simulated low-level OS programming.
briankelly
My school started us off in microcontroller programming in C then Java for intro to data structures and OOP then back to C (and MIPS assembly) for systems/OS/concurrency. One thing I appreciate Java over Python for DS/Algo is the clear delineation between abstract data type and underlying data structure - IMO is easy to get a wrong mental model with Python. But teaching OS concepts in Java seems a little crazy to me.
Koshkin
Hm... Why? Java seems to be a perfect language in which to understand things at a conceptual level!
briankelly
Good to get your hands in the dirt as well.
cbm-vic-20
A lot of the arguments Joel makes in that article also apply to Python, and pretty much any other higher-level language that doesn't make you think about pointers. Ironically, he points out the Google had a great leap over Microsoft with MapReduce, which was built in Java.
telotortium
The original version of MapReduce was written in C++. The successor library, Flume, was however written in Java, but Spolsky would certainly have been referring to the original MapReduce, since the Flume paper wasn't published until 2010.
jonhohle
Back in the early 2000s, I was taught in C, C++, Motorola 68HC11, and MIPs assembly. I can clearly understand how Java works, even if I don’t know its GC is implemented. I can understand how programs were written from the 80s to currently. Had I learned programming in Java or, worse, Python, I doubt I’d have the same understanding. It’s relatively easy to go from low level to high level languages if you’re willing to give up control. My experience is that the opposite is less true. It’s certainly possible, but not as straightforward as understanding some foundational ideas.
snovymgodym
Java, especially modern Java, is a fine language. The JVM is an awesome runtime. I'm tired of pretending it isn't.
tstrimple
The vast majority of Java developers will never touch modern Java and have zero idea of its features or capabilities. I'm in the process of migrating literally thousands of servers and tens of thousands of apps to the cloud and there isn't anything close to modern Java. The absolute majority at this client seems to be Java 8 and there isn't a single Java 17 or newer. So it's one thing to have great modern features. But if you're going to be a Java developer it'll take work / luck to actually be able to use decent versions of it. Very similar story with C++. If you're on a great cutting edge team, you might be able to use the shiny new stuff. But more than likely you'll be relegated to some C++11 at the latest.
I haven't seen things quite so bad on the .NET side at this client. Yes there's a ton of legacy ASP.NET apps. But there are also a lot of .NET Core apps. They haven't quite made it to the post Core versions of .NET, but it's still a healthier state than I see with Java. I guess all of this to say that modern versions of "ancient" programming languages are great and really do improve things. But chances are if you're working with an ancient programming language you'll be stuck maintaining legacy shit and won't ever get to utilize the shiny stuff.
This is keeping in mind that your average programmer will never even try to interview for FAANG never mind grind leetcode and programming language trivia for weeks like seems so common here.
null
vips7L
This just anecdotal evidence of your one client. Every statistic I’ve seen shows that at least half is on a runtime > 8, with most in that half being on 17 or 21. My entire company runs on 21 and will be moving to 25 when it’s out.
dashtiarian
Well to be fair, if you wanted Performance, Linux support, and a framework which was built with dependency injection and async support in mind and not just have them as patched in footguns, you had to migrate to .NET Core. A Java 8 Spring app was just good enough.
LtWorf
If you want linux support, .net is not what you want.
Linux support is an afterthought and it shows. And you never know if it might be dropped next year.
jcadam
Been coding on the JVM for a good chunk of my career. Though the last several years has been in languages other than Java - Scala, Clojure (my personal favorite), and Kotlin.
Finally managed to get a job offer (after being unemployed for a bit) doing Python. It's starting to look like demand for JVM experience is beginning to wane. Might be time to move on anyway :shrug:
I'm old... as long as there's a steady paycheck involved, I'll code in whatever language you say.
Though, currently working on a little personal project in Scala. :)
rr808
Java is completely revitalized now and is my favorite platform.
The main problem is the legacy code and attitude out there, dependency injection, using Spring or Spring Boot etc SUCKS. VertX is/was good but now with virtual threads you dont need all the async complexity.
neom
James Gosling, Robert Pike and Geoffrey Hinton are my top 3 "Canadians who meaningfully changed things in technology" (tho, I should probably make it a top 5, add Brian Kernighan and figure out someone else)
cmrdporcupine
Kenneth Iverson (APL) could be your fifth even if none of us use APL, its reputation and influence is probably deeper than we realize
badcryptobitch
If Robert Pike is on your list, maybe Graydon Hoare should be 5th place!
Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby.
Java syntax isn't perfect, but it is consistent, and predictable. And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), it's just pressing control-space all day and you're fine.
Java memory management seems weird from a Unix Philosophy POV, till you understand whats happening. Again, not perfect, but a good tradeoff.
What do you get for all of these tradeoffs? Speed, memory safety. But with that you still still have dynamic invocation capabilities (making things like interception possible) and hotswap/live redefinition (things that C/CPP cannot do).
Perfect? No, but very practical for the real world use case.