Well-grounded Java Developer : transitioning to higher version

[satya Priya Sundar]

Often time when we see a lot of enterprise projects that are still stuck with the Java8 version and developers working on it. Now we are talking about Java version 19
What are all the challenges one would face if tomorrow someone is pushed into 18 or 19 and expected to get up and running?
Any advice or roadmap you have on this topic in your book?

Thanks
Sathya

[Ben Evans]

satya Priya Sundar wrote:Often time when we see a lot of enterprise projects that are still stuck with the Java8 version and developers working on it. Now we are talking about Java version 19
What are all the challenges one would face if tomorrow someone is pushed into 18 or 19 and expected to get up and running?
Any advice or roadmap you have on this topic in your book?

So in practice, the market does not really adopt anything other than the LTS releases (which are currently 11 & 17). This is because the other releases are only supported for 6 months - and then you have to upgrade or you won't get any security or other updates. Most development managers are not happy with a JDK upgrade every 6 months and so stick to LTS versions only.

The book covers Java 17, which is the highest version that most developers will be using. The updates from 8 to 11 to 17 are not so big - with Java modules (& the changes to access control) and the new Sealed Types and Records probably being the most important features.

We spend quite a lot of time in the book talking about the upgrade path to the new versions.

[Jason Clark]

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]

Agree that modules was the biggest change since Java8. Why migrate your code to records? Does that violate the

If it ain't broke, don't fix it.

principle? But records are nice and easy to use in new code.

[satya Priya Sundar]

Ben Evans wrote:

satya Priya Sundar wrote:Often time when we see a lot of enterprise projects that are still stuck with the Java8 version and developers working on it. Now we are talking about Java version 19
What are all the challenges one would face if tomorrow someone is pushed into 18 or 19 and expected to get up and running?
Any advice or roadmap you have on this topic in your book?

We spend quite a lot of time in the book talking about the upgrade path to the new versions.[/quote wrote:

Thanks, it makes sense

[Jason Clark]

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!

[Campbell Ritchie]

Can you really not hand‑code immutable classes to provide all the safeguards you require? Can't a record be mis‑written to have a mutable reference type as a field without taking defensive copies wheneve it is used? I would have thought that latter would be an easy mistake to make.
But I do like records

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

// This won't compile
record CantChangeThis(int immutable) {
  private int mutable;
}

CantChangeThis.java:2: error: field declaration must be static
  private int mutable;
              ^
  (consider replacing field with record component)
1 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.

[Campbell Ritchie]

Thank you

Jason Clark wrote:. . . What you can't protect against is change over time . . .

No, you can't. That is one of the things developers need to learn: find out the code's original authors' intentions and stick with them.

. . . a hole in enforcing immutability . . .

Or maybe it goes back to earlier days of object orientation when objects were regarded as mutable by default. Because of that tradition, even though we now know how much better immutability is, there is no way to prevent mutable objects from changing their state.

[Martijn Verburg]

Late to the thread but in case folks need more ammunition to persuade their bosses and a handy guide here is some material by Microsoft (yes, really :-)).

Reasons to move from Java 8 to 11
Transition from Java 8 to Java 11