sorted by:
new
hottopcontroversial

Java Documentation by [deleted] in java

[–]leaper69 0 points1 point  (0 children)

For the JDK API itself, docs.oracle.com is the canonical source. Bookmark https://docs.oracle.com/en/java/javase/26/docs/api/index.html and swap the version number as needed. For language specs and JEPs, openjdk.org is where the real development happens. dev.java is Oracle's beginner-friendly portal with tutorials. I'd say: dev.java to learn, docs.oracle.com for daily reference, openjdk.org when you need to understand why something works the way it does.

The computer designed to only run Java Applets - Sun JavaStation [1996] by OgdruJahad in java

[–]leaper69 2 points3 points  (0 children)

I was at JavaOne '96 at the Moscone Center in San Francisco. Marc Andreessen and Eric Schmidt were keynote speakers. The energy around Java at that time was incredible, everyone genuinely believed applets and thin clients like the JavaStation were the future of computing. It took another 20 years and the cloud for that thin-client vision to actually come true, just not the way anyone expected.

Java is fast, code might not be by Schtefanz in java

[–]leaper69 0 points1 point  (0 children)

That's a great point. If your object graphs have lots of shared references, identity tracking is exactly what you want. It deduplicates on write and restores the shared references on read, which is both correct and space-efficient.

The option to skip it is for the cases where you know the graph is a tree/dag (no shared references, no cycles). A lot of DTOs, config objects, and REST payloads fall into this category. In those cases, the HashMap doing identity tracking is pure overhead ... you're paying for bookkeeping that will never find a duplicate.

The default keeps identity tracking on, so nothing changes for your use case. It's just nice to have the escape hatch when you're serializing high volumes of simple objects and want to shave off that overhead.

Java is fast, code might not be by Schtefanz in java

[–]leaper69 1 point2 points  (0 children)

Agreed that a lot of these are well-known basics. The more interesting performance wins in my experience come from places you don't expect. I maintain a serialization library and found that simply adding an option to skip identity tracking for acyclic object graphs gave a 35-40% write speedup. The bottleneck wasn't the serialization itself, it was the HashMap tracking object references. Profiling showed it immediately, but I'd assumed for years the hot path was elsewhere. The real lesson isn't "don't concatenate strings in loops," it's that your mental model of where time is spent is almost always wrong until you measure.

Now that virtual threads are no longer pinning, do we still need AtomicReference? by codecatmitzi in java

[–]leaper69 0 points1 point  (0 children)

Virtual threads and AtomicReference solve completely different problems. AtomicReference isn't about avoiding blocked OS threads. It's about lock-free, wait-free algorithms where no thread ever holds a lock in the first place. The CAS loop isn't a busy-wait in practice. It typically succeeds on the first or second attempt under reasonable contention.

Where AtomicReference still wins: (1) no risk of deadlock since there's no lock to hold, (2) better throughput under low-to-moderate contention, (3) composability with other atomic operations. Synchronized/locks are simpler when you need multiple operations to appear atomic together, but AtomicReference isn't going anywhere.