Hacker News Reader

JanecekPetron JEP draft: Prepare to make final mean final

- It doesn't work with ErrorProne (https://github.com/google/error-prone/issues?q=sort%3Aupdate...) - you need a special plugin in your IDE for the generated classes to be visible and/or the code to be parsable - it does not work with many other tools, usually there is a bridge to fix that, e.g. with MapStruct: https://mapstruct.org/faq/#Can-I-use-MapStruct-together-with...

Other tools and libraries generally do not interact in such an errorprone manner.

That said, when you know how it works, what it needs, and you know how to iron all of those tiny wrinkles, it works fine and saves you some code and/or sanity. It's not the devil, it's a powerful tool with some downsides.

JanecekPetron JEP draft: Prepare to make final mean final

https://github.com/Randgalt/record-builder

The upsides are: - it generates code and does not do anything funky with internals, - it has a lot of knobs if you need something a little different.

The downside is that it does not provide you with the other Lombok annotations. In practice that has been OK!

JanecekPetron Analyzing the codebase of Caffeine, a high performance caching library

That's kind of the idea of Caffeine, it has admission buffers, and it adapts automatically between LRU and LFU. The original algorithm is called Windiw TinyLFU (design https://github.com/ben-manes/caffeine/wiki/Design), see it in action e.g. here: https://github.com/ben-manes/caffeine/wiki/Efficiency

JanecekPetron JEP Draft: Integrity and Strong Encapsulation

> "will not work with no recourse"

No, the CLI `--add-opens` CLI option will stay. In other words, applications will need to consciously enable the encapsulation-breaking stuff. Is that bad? Modern software moved to public APIs quite a bit ago. That said, if old applications want to use new JDKs, they will require quite some developement, yes.

JanecekPetron Java 20: A Sneak Peek on the Panama FFM API

I take issue with the thing being a part of HexFormat. It should use hexformat, optionally. What if I want to dump the memory to binary or octal instead? The hexformat class itself could have been an adjustable BaseNFormatter :(.

Sorry for the tangent, it had to get out somewhere and I did not think it was worthy of an email in the actual review thread : - )

JanecekPetron JEP draft: 64 bit object headers

Not Caffeine, that's the caching library. You probably meant one of FastUtil, Eclipse Collections, Koloboke, HPPC(-RT), they all provide primitive specializations of Maps and Collections. For off-heap maps, now that's more interesting! I know about Chronicle Map, MapDB, https://github.com/snazy/ohc and https://github.com/RuedigerMoeller/fast-serialization/wiki/O....

JanecekPetron SQL: The difference between WHERE and HAVING

For me the aha moment was to understand the logical order of SQL operations: https://blog.jooq.org/a-beginners-guide-to-the-true-order-of.... Never had a problem since.

JanecekPetron Log4j RCE Found

Interestingly, no, the tag doesn't have to be in the formatting string. See https://news.ycombinator.com/item?id=29507511.

JanecekPetron Log4j RCE Found

No, this is about log4j2 which is kinda new (2.0.0 was released 2014). Otherwise, yeah, this is terrible, especially since the tag doesn't even have to be in the formatting string.

JanecekPetron GC progress from JDK 8 to JDK 17

For native binaries, we now have https://www.graalvm.org/reference-manual/native-image/, but it probably doesn't yet work nicely with game frameworks? Not sure.

There are some engines, frameworks: https://jmonkeyengine.org/, https://litiengine.com/, https://libgdx.com/, https://www.lwjgl.org/.

But I have no real experience with any of those.

JanecekPetron GC progress from JDK 8 to JDK 17

...and they're missing out, that's exactly the message. By the way, I'd be shocked if Java 8 was still more than half of the running server-side JVMs. There's a lot of them for sure, but I'd be willing to bet it's gonna be less than a half now, and declining.

JanecekPetron A Tale of Java Hash Tables

It's simply a completely different implementation. Some of the optimiization passes are the same, obviously, but overall it simply performs ... differently.

JanecekPetron A Tale of Java Hash Tables

Correct! Inlining obviously costs CPU, code cache space, and makes the receiver method bigger so that it's less likely it will be inlined itself. If there ever is a decompilation occuring, the inlining efforts were pretty much wasted.

JanecekPetron A Tale of Java Hash Tables

Nice. Thanks. (For other viewers, all the non-standard maps I'm aware of are trying to avoid allocating those pesky Map.Entry objects, that's why they generally take up much less memory.)

JanecekPetron A Tale of Java Hash Tables

That's because they used primitives, no? In that case also look at some other options: https://www.reddit.com/r/java/comments/r0b9o9/a_tale_of_java.... While I still think Koloboke in general is the fastest, I do agree that the difference between it and fastutil will not be very big.

Or was this for Object/boxed primitives, too?

JanecekPetron A Tale of Java Hash Tables

Indeed, max bytecode count (FreqInlineSize and MaxInlineSize) and inlining depth (MaxInlineLevel). Your GC choice will also slightly modify the inlining decisions, and then obviously GraalVM will be completely different.

JanecekPetron A Tale of Java Hash Tables

> i couldn't even inline my functions

You could, manually :). Either way if they're hot, they're inlined.

One common trick for open-addressing maps in Java I don't see in your implementations is to have an array of keys zipped with values (or two arrays, one for keys, one for values) instead of array of Entries. This improves locality and indirection a bit. Obviously more is needed for even more speed.

(Mandatory "in the future it will be better": Valhalla is coming in a few years, that's when we'll have much more control over the memory layout.)

JanecekPetron Shenandoah in OpenJDK 17: Sub-millisecond GC pauses

If it's not behind XX:+UnlockExperimentalVMOptions (or a preview/incubator module), it's considered stable and prod-ready, yes. Will there be fixes and improvements? Yes. Should you be afraid to use it for business? No, but obviously test it first.

JanecekPetron Stockfish 14

No, they use 12 on all of my devices. Maybe update your browser or something?

JanecekPetron Obvious and possible software innovations

Automated ffi parser soon (TM) to be in standard Java: https://github.com/openjdk/panama-foreign/blob/foreign-jextr...

JanecekPetron ZGC – What's new in JDK 16

This, exactly. One added issue is that ZGC does NOT support compressed oops at all.

JanecekPetron LZ4 – Extremely fast compression

You misread that. It says that decompression is significantly faster than LZO. In fact, decompression speeds of up to 5 GB/s is one of the reasons LZ4 is so popular.

JanecekPetron On Learning Chess as an Adult – From 650 to 1750 in Two Years

For complete cheers beginners who want to learn and understand the ideas of the game, I highly recommend buying an oldish engine, Chessmaster XI: Grandmaster Edition, as it contains a set of amazing, approachable tutorials by an IM Joshua Waitzkin. You might know him at the author of the Art of Learning book. Some will say that the program is old. It is. Who cares, the engine is strong enough for you, of that I'm sure, and there isn't much else you'd want as a complete beginner.

JanecekPetron Kotlin vs. Java

The I/O example is moot since Java 11 where Java got https://docs.oracle.com/en/java/javase/13/docs/api/java.base..., so we can do `Files.readString(Paths.get(doc.txt))`.

Java 14 is getting an experimental preview of Records (https://openjdk.java.net/jeps/359) which takes care of much (but not all) of ceremony around "data classes".

And Java 13 got a preview of text blocks, https://openjdk.java.net/jeps/355.

Things are coming. That said, I hardly believe those minor syntax improvements are what is so "good" about Kotlin. It has some better defaults (non-null by default, final classes by default), and is a more modern language. Java will stay with us for many years to come, though.

JanecekPetron Java's Original Sin (2009)

Thank you, I updated the link in my post to point to the up-to-date and frequently updated wikui page for Valhalla information.

JanecekPetron Java's Original Sin (2009)

There is the project Valhalla now, https://wiki.openjdk.java.net/display/valhalla/Main, aiming to bring value types and eventually generic specialization and reification.

The work on that project has been impressive, and there is now an experimental EA build called LW2 where you can play with value types: https://wiki.openjdk.java.net/display/valhalla/LW2

Will this solve everything? No. The char type is hosed. But there will be an opportunity to e.g. get a new Character.

JanecekPetron Storm 2.0

That's because they'll be maintaining the 1.1.x and 1.2.x branches...

JanecekPetron XXH3 – a new speed-optimized hash algorithm

Here's the smhasher output for XXH3 on an i9: https://pastebin.com/ryLN24Qy, the wyhash has its output in its readme.

TLDR: XXH3 uses less cycles per key, by about 30%. The real throughput / latency need a more equal and thorough benchmark of both, though.

JanecekPetron Faster hash joiner with vectorized execution

Genetic specialization (List<int>) is coming. See https://openjdk.java.net/projects/valhalla/. Not this year (value types will be first). But they're working in it really hard.

JanecekPetron Lombok makes Java cool again

This, a million times.

In my professional bubble Lombok is completely gone. I'll go as far and say that modern Java does not use Lombok. Smaller, focused libraries like Immutables or AutoValue, solve the problem of boilerplate for data classes.

Lombok tries to do too much across many concerns, in a fairly opaque way, and makes the code and tooling around it more magic than it needs to be.

Skip Lombok. Modern Java is better off without it...