What baggage is specific to Java? You'd want some experts for the language your critical services are written in, regardless of it being java or C or Rust or whatever. Likewise, a java shop wouldn't want to use a critical service written in C.
For Java you need people in operations who are good at things like JVM tuning working. Just a fact of life, speaking from experience working on teams that do that.
Languages like C and Rust do not have any equivalent to JVM tuning.
> For Java you need people in operations who are good at things like JVM tuning working. Just a fact of life, speaking from experience working on teams that do that.
You really don't. Anything you could do it, say, Go, you can do in Java without doing any JVM flags. The only time you need to do JVM tuning is when you have performance requirements that are simply impossible in most languages.
Yes, Oracle changed the JDK's licensing model from part-proprietary/part-open, part-free/part-paid to 100% open and free (as of JDK 11). What confused some people is that the old website for the semi-free JDK is now for Oracle support customers who pay for support (even though that page directs non-customers to the free version) and Oracle provides the free JDK over at http://jdk.java.net/
Hi Ron. If you're still employed by Oracle, it might not be a bad idea to disclose that, either in the specific comments where you may be talking (semi-)authoritatively about Java and its licensing / commercial model, or within your HN profile. I recall the last talk I saw from you was an AMA at QCon London in 2019 about Java, where you were with Oracle.
I found the comments really clueful but also appreciate when others like e.g. @_msw_ are very overt with disclosure of their employment and interests whilst talking about $employer's stuff on HN (and in his case that'd be AWS and EC2).
Hey Alex! Yes I am with Oracle, and indeed I always make sure to disclose my affiliation: I do so on HN every couple of months or whenever it's relevant (when saying something that could be biased/controversial). It's not just a nice thing to do, but it's also company policy.
Plus, ZGC, the low-latency collector (which gives a ~1-2ms max pause times on heaps of up to 16TB in JDK 16) was introduced in 11 and made production-ready in 15.
You would do that even with a GC language like Java. The serious performance code paths in Java also do meticulous memory management to minimize allocations, GC costs, and utilize off-heap memory (Netty comes immediately to mind).
In my opinion it’s the worst of both worlds at that point—you’ve got to manually manage memory and tip toe around the runtime.
You're not wrong, but that's a bit of an unfair comparison.
You're likely talking about work on custom memory allocators and impact on real time performance. In the hosted services domain this isn't so much an issue. Nobody's doing that in Java, and you likewise wouldn't care much if writing the same type of service in Rust.
Rust very much enables you to write high level, Java-style code. It's not bad code, nor is it difficult to write.
I've been staring down compiler flags for two weeks straight, now, since I've been working on cross-compilation toolchains, but that kind of narrative doesn't fit your current level of snark, I guess.
I have run operations for programs written in Java, C++, and Go. I've done it both at small companies and large companies, for everywhere from a rack of dedicated servers running Apache Tomcat to thousands of virtual machines running a mixture of C++ and Go microservices.
The constant thread is... over the last ten years... the people running JVMs complain about tuning the JVM, and always have stories to tell about it. The JVM is fantastically tuneable, and when people online complain about GC pauses or memory problems, there's often some way to tune the JVM to fix those problems. The JVM is amazing, it's a marvelous piece of technology.
But there's also a bunch of people who don't know how to do it and just turn knobs. Like, oh, customers are calling in to complain about latency, so I'll increase the size of the Java heap. (Which, for those not familiar with GC, will make throughput better but make latency worse.) Running services on the JVM means that "working with the JVM" is now a skill you need to select for whatever operations team you have, and if you're a company running a mix of different services (like, I don't know, some databases, memcache, load balancers, etc) then "knowing how to tune the JVM" competes with several other skills you'd like your team to learn.
Just like there are whole conference talks on how to use PGO data properly and optimization flags on AOT compilation toolchains, naturally one needs to spend the effort to learn how to use them and not just type -O2 and go home.
Or those that complain about RDBMS queries being slow, without having normalized their data or written proper indexes.
There is always bunch of people that don't know how to do things, and then there are those among them, that care to improve their skill set and get to know how to turn those knobs.
Sure, but it’s only at large scale that you care about stuff like PGO. My experience is that even small shops care about JVM tuning.
It’s not a question of whether there are knobs to turn. It’s about the typical experience of an actual person running a JVM app versus, say, C or Go, and those experiences are quite different.
And we’re also talking about running someone else’s app. If your database queries are slow, that’s a conversation between the DBA and the devs. If you’re running some Apache app, you’re probably not talking to the devs.
Yeah, I've been a C/C++ programmer for 15+ years with heavy focus on performance, and have not once run PGO. I think it's quite often the case for C/C++ programs that you -O2 and walk away, at least for codebases that your team doesn't specifically own.
Unlike C/C++ you do have to care about tuning at a minimum to set the memory sizes.
That said you probably can’t get very far in c/c++ without worrying about memory the whole way through. So, you only worry about tuning when writing your code.
Well, it's a trade-off. If someone compiled the C++ app for your architecture, sure – if not, you need to figure out how to compile it and depending on the compiler and set of headers you have installed, it's not always easy. When I say, not always easy I'm being generous, there have been cases when the function signature was different between the sets of headers the author had and what I had...
In Java's case if you have all the class files, all you need is the JVM for your architecture. You don't need the program's author to compile it for your architecture.
And finally, JVM tuning does not need to be performed by the user, but can be performed by the user. The most frequent tuning needed to be done by the user was the maximum memory that the JVM could allocate, but that hasn't been needed for a long time (since Java 8, I think). Now the JVM, by default, has the sensible behavior to allocate as much memory as the OS will let it, when asked by the application.
But you can use 99% of C/C++ applications without any compiler flag trickery.
My experience is not that you can run 99% of Java applications without running out of memory or something like that. That's why I avoid Java these days when I have the option. I don't think things would have changed much that much in recent years, making my experience no longer valid.
I've been using Java daily for years at this point. The only time I've had that sort of issue is when the program I was writing dealt with large files in memory, and it was solved with a simple -Xmx16G.
Hah, I still use laptops with 2G and 4G :) They work perfectly fine when you know what you are doing. But running Java with 16GB pool does not fall in that category. The same holds for small cloud instances.
Admittedly even with a C program the size of a problem requiring 16GB might not run well in a 2GB machine, but the fact remains that Java applications are often much more memory hungry than comparable C/C++ implementations. And if you have the memory they will just use it without any Xmx. That sounds really like computing in the 1960/70s that you need to allocate memory in advance. (I'm old enough to have seen such stuff, although not when it was new.)
ZGC, the low-latency collector (which gives a ~1-2ms max pause times on heaps of up to 16TB in JDK 16) was introduced in 11 and made production-ready in 15.
In general, the way the GCs work is just very different from 8.
The JVM that Java shop is using is likely written in C, which should make you question the straight equivalence you’re setting up. There is an operational difference between getting a native executable and having something that sits on top of Java (or any other managed platform).
Not sure what you mean by "managed platform". Java being written in C doesn't mean you need to know C to run Java. You hardly deal with any native code at all unless you write your own JNI interface or do some obscure tuning, which is pretty rare.
I don’t see how it does at all - the point isn’t C versus Java, it’s native versus managed. Any reasonably proficient team running managed services needs to know how to deal with native dependencies, but the reverse is not true.
not in my view, a person who knows neither java nor c. but i think the counterargument from the people in this thread would make would be something like:
i can write my C programs without ever thinking about java. it is irrelevant to me. however, C is very important for java since the JVM it is running on top of is written in C.
i think, personally, the outcome this type of thinking is that “therefore every java program is in fact just cruft on top of C” which personally as someone who does 80% of their job in SQL i am ill-equipped to object on java’s behalf.
You’ll note the word “likely” in my comment. And there’s nothing special about C in my argument - I was responding to a comment which used it as an example. The point is simply that one way or another any given team likely knows how to tune, monitor and/or diagnose issues in native bits - in fact even a Java focussed team likely has these skills. But the reverse is clearly not true.
For me, at this point, the biggest baggage is dealing with Oracle and funneling them money if you want an LTS JVM, alongside the shifting sands of their licensing rules. Unfortunately it can still be a bit of a wheel of fortune as to how well (if at all) something runs on OpenJDK.
Between the open-world assumption the classloader uses, and the lack of a performant, general purpose garbage collector, you can’t seriously consider deploying Java at scale without having experts on hand.
I’ve deployed things written in many languages at extremely large scale. They’ve been written in Java, C, C++, python, go, sh, perl, and other languages I’ve forgotten. Java is, by far, the least operable of those languages.
I’m an expert Java developer, along with most of those other languages (where expert is defined by me as “over 10 years experience”).
In fairness to java, it’s not my least favorite language on the list.
