Live data from Hacker News

Java is fast, code might not be

jvogel.me

171–180 of 259 posts

Re: Java is fast, code might not be

#171

Earlier quoted context omitted.

I really hate how completely clueless people on hn are about java. This is not, and has not been an issue for many many years in Java and even the most junior of developers know how to avoid it. But oh no, go and rust is alwaayssss the solution sure.

Can you provide any examples or evidence of Java apps that prove this? Because in my experience as of 2026, Java programs are consistently among the most painful or unpleasant to interact with.

IntelliJ IDEA is reasonably fast, but of course its hard to make a big desktop app in java be fast.

Re: Java is fast, code might not be

#172
post #32
post #22

Earlier quoted context omitted.

Not knowing what's going on in Java is a personal problem. The language and jvm have its own quirks but it's no less knowable than any other compiler optimized code. The debugging and introspection tooling in Java is also best in class so I would say it's one of the more understandable run times. Gradle does suck and maven is ok but a bit ugly.

LLMs take the whole argument away. Yes, maven/gradle/sbt suck to work with. But now you can just generate it.

I've been using maven for 20+ years, gradle for 10? ant for 5 before that. sbt for 15. I've written custom plugins for all of them. I know them quite well, unfortunately.

I use LLMs to maintain them now. I keep the build files simple. It was an inconvenience before, but a trifle now.

Re: Java is fast, code might not be

#173
post #136

Earlier quoted context omitted.

I've always found ORMs to be performance killers. It always worked out better to write the SQL directly. The idea that you should have a one-to-one correspondence between your data objects and your database objects is disastrous unless your data storage is trivial.

I worked with ORM (EclipseLink) and used SQL just fine. When using JDBC I found myself quickly in implementing a poor mans ORM.

EclipseLink never received enough love.

Re: Java is fast, code might not be

#174

Earlier quoted context omitted.

It does not. If you need to parse a number, you use standard library and you will be fine. The described case with huge impact on hot path is the demonstration why using brains is important. The developer that will get into this mess is the one who will find the way to suffocate his code with performance bottlenecks in thousand other ways. It’s not a language or library problem.

Yes, parseInt et al work very fast for good inputs. What percentage of your inputs are invalid numbers and why ?

> What percentage of your inputs are invalid numbers and why ?

This is a wrong question to ask in this context. The right question to ask is when actually exceptional flow becomes a performance bottleneck. Because, obviously, in a desktop or even in a server app validating single user input even 99% of wrong inputs won’t cause any trouble. It may become a problem with bulk processing, but then, and I have to repeat myself here, it is no longer a number parsing problem, it’s a problem of not understanding what your input is.

Re: Java is fast, code might not be

#175

Earlier quoted context omitted.

> a lot of real world performance comes down to how efficiently you are calling external services (including the database) Apart from that my experience over the last 20 years was that a lot of performance is lost because of memory allocation (in GCed languages like Java or JavaScript). Removing allocation in hot loops really goes a long way and leads to 10 or 100 fold runtime improvements.

This applies to non-GC languages as well. Memory management is slow. Even with manual memory management I have been able to dramatically speed up code simply by modifying how memory is allocated. Parts of the GC language crowd in particular have come to hold some false optimistic beliefs about how well a GC can handle allocations. Also, Java and C# can sneak in silly heap allocations in the wrong places (e.g. autobox…

Autoboxing is more a Java problem mainly because of type erasure with generics. C# has "proper" generics and no hidden boxing is occuring there.

Re: Java is fast, code might not be

#176
post #157
post #70

When you're using a programming language that naturally steers you to write slow code you can't only blame the programmer. I was listening to someone say they write fast code in Java by avoiding allocations with a PoolAllocator that would "cache" small objects with poolAllocator.alloc(), poolAllocator.release(). So just manual memory management with extra steps. At that point why not use a better language for the tas…

I saw something like that being suggested when working with GIS data with many points as classes in Java, the object overhead for storing XYZ doubles is quite crazy. The optimization was to build a global double array and use "pointers" to get and set the number in the array. Even JavaScript is much better for this, much, much better.

JavaScript has the exact same issue - objects are on the heap and require allocation and pointer dereferencing. For huge collections of numbers, arrays might be better.

But JS has another problem: there's no way to force a number to be unboxed (no primitive vs boxed types), so the array of doubles might very well be an array of pointers to numbers[1].

But with hidden class optimizations an object might be able to store a float directly in a field, so the array of objects will have one box per (x,y,z), while an array of "numbers" might have one box per number, so 3x as many. My guess is, without benchmarking, is that JS is much worse than Java then, because the "optimization" will end up being worse.

[1]: Most JS engines have an optimization for small ints, called SMIs, that use pointer tagging to support either an int or a references, but I don't think they typically do this optimization for floats.

Re: Java is fast, code might not be

#177
post #124

I'm a bit surprised to see those examples, because there's nothing really new here. These are typical beginner pitfalls and have been there for at least a decade or more. Or maybe it's because I learned java in the late 90s and later used it for J2ME, and then using things like StringBuilder (StringBuffer in the old days) were almost mandatory, and you would be very careful trying to avoid unnecessary object allocati…

I remember writing Java for our introductory programming course at university around 2010. I was already familiar with object oriented programming in PHP at the time, so I just wrote the Java code like I would write PHP. I was absolutely astounded at the poor performance of the Java app. I asked one of our tutors and I can still remember him looking at the code and saying something along the lines of ”oh, you’re inst…

Your tutor misdiagnosed the issue. These allocations in a tight loop would have used bump allocation on Java 6 in 2010, and the young generation would have used a copy collector, which would have freed those objects more cheaply than any unspecialized malloc/free. It would have beaten the pants off of PHP's reference counting GC.

Re: Java is fast, code might not be

#178
I think that the `sychronized` keyword in Java was a mistake.

I've seen classes that are meant to be used by multiple threads where literally every method has `synchronized` because "that was the only way they could get it to work". Of course, if literally every method is synchronized it literally can't actually be used by multiple threads, it just looks like it is.

Generally speaking I work pretty hard to avoid any kind of locks. Locks can be an anti-pattern in my mind: for a lot of problems, if I am reaching for a lock, it's because I haven't actually thought through the problems well enough. They're a bandaid and they create potential choke-points in the app. I also think that they're a crappy fix to try and shoehorn non-concurrent patterns into a concurrent landscape.

I personally think that making something thread-safe and concurrent while also being maintainable and fast is a hard problem, and I think lazily trying to add threads into concurrent applications is a good way to write terrible code that is impossible to debug.

Obviously no accounting for taste, but when I write programs now, I kind of always make them concurrent-first (generally using and/or reinventing the actor model). I try and build my initial algorithm to accept that concurrency is inevitable and start that from the get go. I can't remember the last time I reached for `synchronized`, though every now and then I do have to reach for ReentrantLock, and I always feel dirty doing so.

Re: Java is fast, code might not be

#179
post #162

Earlier quoted context omitted.

You're describing array of structs vs. struct of arrays. Even in JavaScript, you would have to manually do the latter.

V8 automatically optimizes objects with the same shape into efficient structs, making array of objects much more efficient than in Java. And the manually manager int array acts more like system memory, it's not continuous, so you could have point i 0 and 2 and the data would be: [1, 2, 3, x, x,x, 3, 2, 1] (3D points). So I am not describing a struct of arrays.

Hidden class optimizations just make JavaScript objects behave a little more like Java class instances, where the VM knows where to find each field, rather than having to look it up like a map.

It doesn't make JS faster than Java, it makes it almost as fast in some cases.

Re: Java is fast, code might not be

#180
post #147
post #70

When you're using a programming language that naturally steers you to write slow code you can't only blame the programmer. I was listening to someone say they write fast code in Java by avoiding allocations with a PoolAllocator that would "cache" small objects with poolAllocator.alloc(), poolAllocator.release(). So just manual memory management with extra steps. At that point why not use a better language for the tas…

I decompiled Project Zomboid (written in Java) a while back, because I was curious about the performance issues I was having with the game. (Very laggy on my 10 year old laptop, while looking like The Sims 1.) I figured, best case scenario I find some easy bottlenecks and I can patch in a fix. Well, the whole thing was standard Java OOP, except they also had a bunch of functional programming stuff on top of that. I c…

What is the ending of your story!? Did you find and fix some bottlenecks?
Post reply on HN