Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JVM Options Explorer

chriswhocodes.com

Post reply on HN
Print view View original

111–120 of 122 posts

Re: JVM Options Explorer

#111

Post by Geezus_42 »

gf000 wrote: post #90
Geezus_42 wrote: post #17

Earlier quoted context omitted.

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 " 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.

Did you mistype Go? Java has proper error messages with a full stack trace that tells the whole story. Of course individual developers may lazy out on writing useful error messages, but that's hardly a Java issue. Meanwhile in Go you can be happy to have any error message at all. And then you can hope it's a unique string you can grep in a codebase. Where you only may find a line of code you could have arrived from m…

See my other comments about how stack traces are un-ergonomic for sysadmins. I'm sure they are great for developers.

Re: JVM Options Explorer

#112

Post by Geezus_42 »

well_ackshually wrote: post #41
Geezus_42 wrote: post #17

Earlier quoted context omitted.

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 " 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.

So your issue isn't with Java, just with shit error messages and devs clearing the exception stack.

Then I've never seen anyone write good Java. Either way, same issue.

Re: JVM Options Explorer

#113

Post by gf000 »

Geezus_42 wrote: post #109
gf000 wrote: post #103

Earlier quoted context omitted.

grep "caused by" Here you are.

Why not just make your errors more readable and not have to use an extra tool?

Well, just write more readable error messages?

How do you make this more readable:

ExceptionName: Dev-given message at Class(line number) at Class(line number) caused by AnotherCauseException: Dev-given message at Class(line number)

It's only the dev given message that may or may not be of good quality, the exact same way as it is in go. It's a plus that you can't accidentally ignore error cases, and even if a dev was lazy, you still have a pretty good record for where a given error case could originate from.

Re: JVM Options Explorer

#114

Post by gf000 »

iamcalledrob wrote: post #104
gf000 wrote: post #103

Earlier quoted context omitted.

grep "caused by" Here you are.

Don't have to grep my go errors :)

Especially when they forget to properly handle an error case among the litany of if err line noise, and you get erroneous code execution with no record of it!

Re: JVM Options Explorer

#115

Post by rafaelgoncalves »

molticrystal wrote: post #54

Chrome has 1496 [0] known options as of today, maybe after a few more pushes they'll catch up to the 1843 of JVM. An interface like above to sort things would probably be quite helpful as well. [0] https://peter.sh/experiments/chromium-command-line-switches/

the link throws an error 500, "There has been a critical error on this website.":

archived on 2026-04-12: https://web.archive.org/web/20260412085953/https://peter.sh/...

Re: JVM Options Explorer

#116

Post by funcDropShadow »

Geezus_42 wrote: post #97
well_ackshually wrote: post #41

Earlier quoted context omitted.

So your issue isn't with Java, just with shit error messages and devs clearing the exception stack.

I would believe you, except that it is a problem with every Java app I have supported, and there are people in this very thread defending it. I do not want a stack trace unless I specifically request it. I am not a Java developer, 10 pages in less showing names of packages I don't even know what they are is not useful. It just muddies the water so that it's much harder to make sense of and spot the relevant line; ass…

When you are administrating so many Java applications, you should investigate an hour or ask your favorite AI how to configure the logging library used in your application of interest. They allow you to remove stack traces and lots more.

Re: JVM Options Explorer

#117

Post by deepsun »

Geezus_42 wrote: post #99
appplication wrote: post #33

Earlier quoted context omitted.

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.

A stack trace that is >10 pages in less is not what I would call minimal.

And that's why you should have multiple appenders. So in code you write "log.error("...", exception)" once, but logging writes it in parallel to:

   1. STDOUT for quick and easy look, short format.
   2. File as JSON for node-local collectors.
   3. Proper logging storage like VictoriaLogs/Traces for distributed logging.
Each appender has its own format, some print only short messages, others full stacktraces for all causes (and with extra context information like trace id, customer id etc). I really think STDOUT-only logging is trying to squeeze different purposes into one unformatted stream. (And Go writing everything to STDERR was a really strange choice).

https://www.baeldung.com/logback#bd-appenders

Re: JVM Options Explorer

#118

Post by kitd »

gf000 wrote: post #92
kitd wrote: post #32

Earlier quoted context omitted.

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 3a…

This couldn't be further from the truth. There is no ecosystem I would choose over Java when it comes to observability and it's not even close. Good luck finding your segfault, oom, race condition or just simply lazy logging culture bug with a C/go codebase at 3am. I will happily see my proper stack trace, heap dump, or connect directly to prod with a debugger with basically no performance penalty.

Your stack trace tells you where in the code the error occurred, but doesn't tell you what it was doing with what data. For that you need to pass context for the error up the chain of calls, adding to it as you go up. Exceptions are not a great way of doing it as you only have the local context, which isn't a great help when you're catching N levels up.

And if you're not catching N levels up but catching at each level, then you are emulating error values but with try/catch blocks.

Re: JVM Options Explorer

#119

Post by cyberpunk »

dpratt wrote: post #64
cyberpunk wrote: post #55

Earlier quoted context omitted.

You can get into difficulty with kubernetes here, as your jvm will detect all cores on the node but you may have set a resources limit on the pod/whatever, so it’ll assume it can spend more time doing stuff than it actually can, so often times it’s quite necessary to tune some things to prevent excessive switching etc.

Modern JVMs will detect orchestrator-set cgroup limits and size themselves accordingly. If you, for example, set a cpu limit for a pod to “1”, the JVM will size itself as if it was running on a single core machine.

TIL, this is great. Thanks, saved me some yaml :}

Re: JVM Options Explorer

#120

Post by Geezus_42 »

deepsun wrote: post #117
Geezus_42 wrote: post #99

Earlier quoted context omitted.

A stack trace that is >10 pages in less is not what I would call minimal.

And that's why you should have multiple appenders. So in code you write "log.error("...", exception)" once, but logging writes it in parallel to: 1. STDOUT for quick and easy look, short format. 2. File as JSON for node-local collectors. 3. Proper logging storage like VictoriaLogs/Traces for distributed logging. Each appender has its own format, some print only short messages, others full stacktraces for all causes (…

Cool. Convince your fellow Java developers to do that and I'll quit complaining about the awful errors every Java app produces.
Post reply on HN