JanecekPetr

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

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!

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

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

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 : - )

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

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.

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

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.

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.

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

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

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.

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

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?

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.

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

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.

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

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

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

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.

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.

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.

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

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.

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

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.

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.

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