Jason Clark

Campbell Ritchie wrote:Can you really not hand‑code immutable classes to provide all the safeguards you require?

You can properly hand-code a class to be immutable. What you can't protect against is change over time: someone adding a new set..() method or adding a field and forgetting that all important final. The platform doesn't know that this class was meant to be immutable, so it can't check that your correct code remains correct.

Campbell Ritchie wrote:Can't a record be mis‑written to have a mutable reference type as a field without taking defensive copies wheneve it is used?

Actually you can't if we're talking about the mutability of the field itself. If you try to add instance fields on a record type it will give you a compilation error.



If you're meaning that the object referred to by a field can be mutable still, that is sadly a hole in enforcing immutability that Java still has and records don't help you unless you use them consistently everywhere.

Hey there!

This is actually a common enough question we address it directly in chapter 8, the general intro for alternative JVM languages, not just for Scala but for a number of other languages.

While it's undoubtedly true that Scala is more FP than Kotlin, we found the core of what we aimed to say about FP was addressable between Clojure and Kotlin. That combined with the really large surface area Scala presents as a language in general led us to leave it out.

Not gonna lie, this has been the biggest controversial choice we made between the first and second edition. We hope that what we have written will spark further investigation for folks, which for the FP curious may well lead them to Scala.

Campbell Ritchie wrote:Why migrate your code to records?

I totally agree, changing old code shouldn't be done without a solid reason. I called it out largely as an example because people do often conflate upgrading their JDK with the features they can use then.

Records in particular I do see cause for working back into some existing systems. If data was already being modeled for immutability, using records gives you platform safeguards that your hand-coded classes can't provide. Obviously, changing these things isn't a requirement for any upgrade -- just a tantalizing possibility once you're there!

Hello!

We talk a bit in Chapter 10 (Building with Gradle & Maven) about some of the necessary changes moving past Java 8 related to some JAX pieces. We don't talk a lot further about _using_ those libraries and frameworks though.

Similarly Chapter 11 about Running Java in Containers may have some useful grounding about your move from manual deploy, but focuses mostly on the fundamentals of Docker and Kubernetes, so topics like Openshift are beyond the scope.

Great question!

Particularly for a young developer, I find that the material in Part 1 and 2 are really the building blocks for understanding the Java platform. Concurrency they've probably encountered (and there are other great resources) but the fundamentals there are key. Ben's chapter on class files and bytecode is also amazing grounding for understanding a lot about the JVM that you'd be hard pressed to find covered as thoroughly online.

The book does build from part to part. So as you point out, reading the Kotlin and Clojure intros will benefit the later parts where we show examples for FP and concurrency in light of those other languages.

What does the "Beyond Modules" section point to?

This section talks about Jlink and some of the very cool packaging options that modules are starting to make possible on the JVM. We discuss that further too in the Build Tools chapter.

Manuel Loayza wrote:
What is the differentiator of your book in compare with the tons of information in the Internet and other java books?

Echoing Ben a bit, I think what makes this book different than what you can find on the Internet is that we've worked really hard to provide a narrative that builds foundations then introduces new ideas building on them.

The book isn't a traditional reference book at all -- that certainly may be better served by online resources (with the caveats Ben points out!) But hopefully the way we build across the text gives you something that a bunch of individual web pages won't.

Yep, chapter 5 starts pretty close to the level you're showing there. That chapter walks through the basic model, synchronization, and looks at how the pieces show up in the memory model and bytecode.

Chapter 6 steps up to the more sophisticated support we get from `java.util.concurrent` and gives a thorough tour there.

Chapter 16 then pulls together a bunch of threads (hehe) from throughout the book to look at the new Fork/Join, Futures, and some treats from how Kotlin and Clojure look differently at concurrency.

Ben's right highlighting modules as one of the biggest changes between the versions. Depending on what libraries you're using (and how you were minding implicit boundaries before!) that's where I've seen folks bit the most on upgrading from 8 to 11.

Many of the other changes in practice haven't been the stumbling blocks folks expect them to be. Sure, Java 17 has Records, but you don't have to convert your classes over day one!

I'll also call out that we've seen dramatic performance improvements in the newer versions -- often but not exclusively from garbage collection advances. Given the relative ease because of the platform's strong commitment to backwards compatibility, those gains are a nice win, especially for folks running in the cloud where you pay by the minute for compute.

Campbell Ritchie wrote:I haven't looked up the ToC, so what do those three parts say?.

Part 1: From 8 to 11 to 17
Part 2: Under the Hood (bytecode, concurrency fundamentals, performance)
Part 3: Non-Java Languages on the JVM
Part 4: Build and Deployment
Part 5: New Frontiers (advanced functional programming, advanced concurrency)

While it's something of an overview book you could dive into at different spots, lots of the material in Part 5 in particular expects that you've understood Parts 2 and 3. It isn't strictly necessary to read it cover to cover, but there is some flow and connection between the parts that may not be obvious in the ToC.

Howdy all! Unlike Ben and Martijn I haven't spent much time on the ranch before, so looking forward to chatting this week.