Java 14 – “Regression and compatibility tests are essential”

Share
  • March 24, 2020

JAXenter: What do you think is the most important new feature in Java 14?

My advice would be to first devote yourself to jumping to an LTS version.

Markus Günther: My personal highlight is the introduction of the record concept (JEP 359). Records are still a preview feature in Java 14 and you have to activate the feature explicitly to use it. But they fit in logically with the established Java type system and offer great potential. With the current release, this means that you no longer have to write excessive boilerplate code for simple data retention classes. Instead, you can encapsulate all relevant attributes in the form of a record and let the compiler generate a useful default constructor, access methods for reading and writing the attributes, a contract for equals and hashCode, etc.

At a second glance, you can see that records pave the way for further interesting features: Records could, for example, work wonderfully with pattern matching (JEP draft: Pattern matching for switch (Preview)) in the form of deconstruction patterns. Records are definitely a concept to keep an eye on.

SEE ALSO: Pattern Matching for instanceof in Java 14

JAXenter: What feature do you think is missing in Java 14?

Markus Günther: This is not explicitly related to Java 14, but I still miss the possibility to declare local variables as immutable by val (analogous to var for mutable variables since Java 10).

JAXenter: Will your customers update right away or is that not worth it?

For a while now, there has been a trend to use good and established features from other programming languages.

Markus Günther: My customers are mostly still working with Java 8. Occasionally, I observe this even when it comes to selecting technology for greenfield projects: Some seize the opportunity and switch to Java 11, others continue using Java 8 as a basis. In the latter group, the application design is usually carried out without thinking of future migrations (e.g. modularization with JPMS). For older systems based on Java 8 with a monolithic structure, a migration is not trivial if the monolith is not already strictly separated into functional modules.

This investment has to be taken at some point, but in my perception, customers shy away from it, especially in existing projects. And if not, then my advice would be to first devote yourself to jumping to an LTS version (Java 11) and only then—if cost/benefit justifies it—to adjust to the shorter release cycles.

JAXenter: What difficulties could it pose to immediately use the new Java version in production?

Markus Günther: Even with releases that have a rather evolutionary character based on their feature set, the behavior of an application can act differently in production after the upgrade. Meaningful regression and compatibility tests during the upgrade are therefore essential.

JAXenter: With features like “JEP 358: Helpful NullPointerExceptions“, is Java approaching “modern” languages like Kotlin?

Markus Günther: For a while now, there has been a trend to use good and established features from other programming languages. Scala in particular has shown that an object-functional programming model certainly has its strengths and has surely been an incubator for the fact that lambda expressions found their way into the language with Java 8.

With Java 14, the trend continues—regardless of where the inspiration is coming from—and reduces the gap to other programming languages by adding JEP 305 (Pattern Matching for instanceof (Preview)), JEP 359 (Records), JEP 361 (Switch Expressions), and JEP 368 (Text Blocks).

SEE ALSO: Java 14 – “A shorter release cycle creates the feeling that the language is constantly evolving”

JAXenter: What wishes/preferences do you have for Java 15, set for release later this year?

I’m excited to see the progress of pattern matching for switch.

Markus Günther: I’m excited to see the progress of pattern matching for switch, which is currently still in JEP draft status. In particular, a sensible combination with records introduced in Java 14 can influence how (think deconstruction patterns) we formulate Java code in the future. But as much as I would like to see this happen, the availability of this feature is rather unrealistic for Java 15, which will be released later this year.

JAXenter: In general, what do you think about the acceleration of Java with the six month release cycle?

Markus Günther: I’m torn. On the one hand, the accelerated release cycle enables the timely release of important features. This gives us the feeling of working with a vibrant and modern language and is absolutely appreciated. On the other hand, I have been noticing that non-LTS releases usually don’t play an important role.

The post Java 14 – “Regression and compatibility tests are essential” appeared first on JAXenter.

Source : JAXenter