These are all the options that have ever existed, including options that are or were available only in debug builds used during development and diagnostic options. There are still a few hundred non-diagnostic "product" flags at any one time, but most are intentionally undocumented (the list is compiled from the source code [1]) and are similar in spirit to compiler/linker configuration flags (only in Java, compilation and linking are done at runtime) and they're mostly concerned with various resource constants. It is very rare for most of them to ever be set manually, but if there's some unusual environment or condition, they can be helpful.
In what way is gofmt remotely comparable to a JVM?
In reality the number of options is significantly smaller than the 1843 you mentioned. The list contains boatloads of duplicates because they exist for multiple architectures. E.g. BackgroundCompilation is present on 8 lines on the OpenJDK 25 page: aarch64, arm, ppc, riscv, s390, x86 and twice more without an architecture.
gofmt isn’t really comparable to the JVM, but it is a really strong expression of the opinionated tooling GoLang has.
While gofmt is “just” a formatting tool. The interesting part is that go code that doesn’t follow the go formatting standard is rejected by the go compiler. So not only does gofmt not have knobs, you can’t even fork it to add knobs, because the rest of the go ecosystem will outright reject code formatted in any other way.
It’s a rather extreme approach to opinionated tooling. But you can’t argue with the results, nobody writing go on any project ever worries about code formatting.
I don’t believe the Go compiler would reject unformatted code.
The compiler has its own set of rules for what it views as syntactically correct code, but these rules have nothing to do with gofmt’s formatting rules.
For example, it’s the compiler and not gofmt that dictates that you must write a curly brace only on the same line of an “if” statement. If you put it on the next line, you don’t have unformatted code - you have a syntax error.
However, the compiler doesn’t care if you have too much whitespace between tokens or if you write your slice like []int{1, 2,3,4}, but gofmt does.
We could say the rules of the compiler and gofmt don’t even overlap.
They do worry, they just can't do anything about it. Like the fact that error handling code takes at least three lines no matter how trivial it is. I'm sure error handling would not be critisized nearly as much if it didn't consume so much vertical space and could fit in one line, which go compiler does allow.
It's a result of Java being required to run on many different OS environments (Oracle, Redhat, Windows, RISC/ARM/x86), along with user constraints and also business requirements.
In a way you can use this list of JVM options to illustrate how successful Java has become, that everyone needs an option to get it to work how they like it.
As a Java dev, I have maybe used about 10-15 of them in my career.
The weirdest/funnest one I used was for an old Sun Microsystems Solaris server which ran iPlanet, for a Java EE service.
Since this shared resources with some other back of office systems, it was prone to run out of memory.
Luckily there was a JVM option to handle this!
-XX:OnOutOfMemoryError="<run command>"
It wasn't too important so we just used to trigger it to restart the whole machine, and it would come back to life. Sometimes we used to mess about and get it to send funny IRC messages like "Immah eaten all your bytez I ded now, please reboot me"
GC threads are generally often useful on multi-tenant systems or machines with many cores, as Java will default-size its thread pools according to the number of logical cores. If the server has 16 or more cores, that's very rarely something you want, especially if you run multiple JVMs on the same host.
Not JVM options, but these are often also good to tune:
As a sysadmin, not developer, I hate Java almost as much as Windows. The error messages Java apps produce are like coded messages that you have to decipher.
I.E. Instead of "<DOMAIN> TLS Handshake failed" it will be something like "ERROR: PKIX failed". So now I have to figure out that PKIX is referring to PKI and it would make too much sense to provide the domain that failed. Instead I have to play the guessing game.
This is the kind of scenario that is served better by Go/C-style error values than exceptions. Error values facilitate and encourage you to log what you were doing at the precise point when an error occurs. Doing the same with exceptions idiomatically often requires an exception hierarchy or copious amounts of separate try/catches.
The difference really becomes apparent when trying to debug a customer's problem at 3am (IME).
This is why stack traces exist. But I agree Java seems to not really have a culture of “make the error message helpful”, but instead preferring “make the error message minimal and factual”.
For what it’s worth, the rise of helpful error messages seems to be a relatively new phenomenon the last few years.
In the age of LLMs coupled with open source software, option count is unlimited. I fork FOSS projects and modify them for my own use all the time. Sometimes, with an agent, doing so is even easier than finding the "right" knob.
This is going to come very handy for development of CodeBrew, my Java IDE for iPhone/iPad. It runs a full OpenJ9 JVM under the hood, and I had to do a bunch off massaging with the options to get it to run properly. I wish I had known this page sooner!
All of that configuration and it will always be less efficient than Rust, or even Golang.
This is why lots of engineers waste time fiddling with options to tune the JVM and still require hundreds of replicated micro-services to "scale" their backends and losing money on AWS and when they will never admit the issue is the technology they have chosen (Java) and why AWS loves their customers using inefficient and expensive technologies.
Even after that, both Go and Rust continue to run rings around the JVM no matter the combination of options.
Sure, for a very narrow definition of _efficiency_. There's plenty to complain in terms of the JVM and Java but performance, as in units of work per dollar spent, is not one of them - JITs just have too many opportunities for optimizing generated code.
1843 options is too many. You could never even consider all of the possible combinations and interactions, let alone test them.
I have really come to appreciate modern opinionated tooling like gofmt, that does not come with hundreds to thousands of knobs.
These are all the options that have ever existed, including options that are or were available only in debug builds used during development and diagnostic options. There are still a few hundred non-diagnostic "product" flags at any one time, but most are intentionally undocumented (the list is compiled from the source code [1]) and are similar in spirit to compiler/linker configuration flags (only in Java, compilation and linking are done at runtime) and they're mostly concerned with various resource constants. It is very rare for most of them to ever be set manually, but if there's some unusual environment or condition, they can be helpful.
[1]: https://github.com/openjdk/jdk/blob/master/src/hotspot/share...
In what way is gofmt remotely comparable to a JVM?
In reality the number of options is significantly smaller than the 1843 you mentioned. The list contains boatloads of duplicates because they exist for multiple architectures. E.g. BackgroundCompilation is present on 8 lines on the OpenJDK 25 page: aarch64, arm, ppc, riscv, s390, x86 and twice more without an architecture.
gofmt isn’t really comparable to the JVM, but it is a really strong expression of the opinionated tooling GoLang has.
While gofmt is “just” a formatting tool. The interesting part is that go code that doesn’t follow the go formatting standard is rejected by the go compiler. So not only does gofmt not have knobs, you can’t even fork it to add knobs, because the rest of the go ecosystem will outright reject code formatted in any other way.
It’s a rather extreme approach to opinionated tooling. But you can’t argue with the results, nobody writing go on any project ever worries about code formatting.
I don’t believe the Go compiler would reject unformatted code. The compiler has its own set of rules for what it views as syntactically correct code, but these rules have nothing to do with gofmt’s formatting rules.
For example, it’s the compiler and not gofmt that dictates that you must write a curly brace only on the same line of an “if” statement. If you put it on the next line, you don’t have unformatted code - you have a syntax error.
However, the compiler doesn’t care if you have too much whitespace between tokens or if you write your slice like []int{1, 2,3,4}, but gofmt does.
We could say the rules of the compiler and gofmt don’t even overlap.
They do worry, they just can't do anything about it. Like the fact that error handling code takes at least three lines no matter how trivial it is. I'm sure error handling would not be critisized nearly as much if it didn't consume so much vertical space and could fit in one line, which go compiler does allow.
That's all well and good, but entirely irrelevant to the number of options a JVM should reasonably have.
It's a result of Java being required to run on many different OS environments (Oracle, Redhat, Windows, RISC/ARM/x86), along with user constraints and also business requirements.
In a way you can use this list of JVM options to illustrate how successful Java has become, that everyone needs an option to get it to work how they like it.
As a Java dev, I have maybe used about 10-15 of them in my career.
The weirdest/funnest one I used was for an old Sun Microsystems Solaris server which ran iPlanet, for a Java EE service.
Since this shared resources with some other back of office systems, it was prone to run out of memory.
Luckily there was a JVM option to handle this!
-XX:OnOutOfMemoryError="<run command>"
It wasn't too important so we just used to trigger it to restart the whole machine, and it would come back to life. Sometimes we used to mess about and get it to send funny IRC messages like "Immah eaten all your bytez I ded now, please reboot me"
> As a Java dev, I have maybe used about 10-15 of them in my career.
So do we really need multiple thousand? Having all of them also makes finding the few you actually need much more difficult.
Which JVM options do you use the most?
Heap size, GC algorithm.
I suggest most people never touch almost any other options. (Flight recording and heap dumps being the exception).
GC threads are generally often useful on multi-tenant systems or machines with many cores, as Java will default-size its thread pools according to the number of logical cores. If the server has 16 or more cores, that's very rarely something you want, especially if you run multiple JVMs on the same host.
Not JVM options, but these are often also good to tune:
In my experience this often both saves memory and improves performance.> You could never even consider all of the possible combinations and interactions, let alone test them.
Nobody has ever tested all possible inputs to 64 bit multiplication either. You can sample from the space.
Eh that sounds a bit different to me, multiplication should be roughly the same operator on each test, these are wildly different functions.
You forgot about NaNs (all of them), infinities and positive/negative zeros. Tests warranted.
As a sysadmin, not developer, I hate Java almost as much as Windows. The error messages Java apps produce are like coded messages that you have to decipher.
I.E. Instead of "<DOMAIN> TLS Handshake failed" it will be something like "ERROR: PKIX failed". So now I have to figure out that PKIX is referring to PKI and it would make too much sense to provide the domain that failed. Instead I have to play the guessing game.
I hate when tools only produce generic "TLS Handshake failed" instead of saying why exactly it failed, where is the problem.
This is the kind of scenario that is served better by Go/C-style error values than exceptions. Error values facilitate and encourage you to log what you were doing at the precise point when an error occurs. Doing the same with exceptions idiomatically often requires an exception hierarchy or copious amounts of separate try/catches.
The difference really becomes apparent when trying to debug a customer's problem at 3am (IME).
Sounds like you'd both be happy if the tool produced both.
Sounds to me that deepsun and I are in agreement that an error message should tell you what the actual error was.
I.E. ERROR: TLS handshake failed: <DOMAIN> certificate chain unverified
This is why stack traces exist. But I agree Java seems to not really have a culture of “make the error message helpful”, but instead preferring “make the error message minimal and factual”.
For what it’s worth, the rise of helpful error messages seems to be a relatively new phenomenon the last few years.
Just because you have more features and ways to use them. Say I like to use a different garbage collector for a tool.
One of my nerd-quizzes I hade at interviews before was "what letters in what case are NOT flags to GNU ls".
The answer is 'man ls'. And: 'almost all letters of unicode'.
I don't think modernity is a noteworthy factor as to whether tooling is opinionated.
How is this different to system tuning parameters in Linux /proc, FreeBsd, Windows Registry, Firefox about:config, sockopt, ioctl, postgres?
Zillions of options. Some important, some not
In the age of LLMs coupled with open source software, option count is unlimited. I fork FOSS projects and modify them for my own use all the time. Sometimes, with an agent, doing so is even easier than finding the "right" knob.
This is going to come very handy for development of CodeBrew, my Java IDE for iPhone/iPad. It runs a full OpenJ9 JVM under the hood, and I had to do a bunch off massaging with the options to get it to run properly. I wish I had known this page sooner!
For anyone intered, here's the app:
https://apps.apple.com/app/apple-store/id6475267297?pt=11914...
There is a 2nd edition now of the Optimizing Java book you are referring to on your site.
He probably knows, since he is one of the authors.
All of that configuration and it will always be less efficient than Rust, or even Golang.
This is why lots of engineers waste time fiddling with options to tune the JVM and still require hundreds of replicated micro-services to "scale" their backends and losing money on AWS and when they will never admit the issue is the technology they have chosen (Java) and why AWS loves their customers using inefficient and expensive technologies.
Even after that, both Go and Rust continue to run rings around the JVM no matter the combination of options.
Sure, for a very narrow definition of _efficiency_. There's plenty to complain in terms of the JVM and Java but performance, as in units of work per dollar spent, is not one of them - JITs just have too many opportunities for optimizing generated code.
All of that tooling and Rust will always be less efficient than Assembler.
I… didn’t think this makes sense :)