Java 21 Record and Pattern Matching: Master Data-Oriented Programming[Video]

In the ever-evolving world of software development, data plays a central role. Handling and processing data efficiently is a paramount concern for developers. As one of the most widely used programming languages, Java acknowledges the significance of data-oriented programming with its latest enhancements in Java 21. Two significant Java Enhancement Proposals (JEPs) stand out: JEP 440 and JEP 441.

JEP 440: Record Patterns

JEP 440 is all about record patterns, a feature that significantly enhances the Java programming languageā€™s capabilities regarding data manipulation. Record patterns introduce a new way of deconstructing record values, making data navigation and processing more declarative and composable.

Oracle Introduces Java 14

Oracle recently announced Java 14. JDK 14 includes sixteen new features, most targeted at improving developer productivity. Additionally, the release includes three features in preview: Pattern Matching for instance of (JEP 305), Records (JEP 359), and Text Blocks (JEP 368).

Java 11 Nest-Based Access Control Via Reflection

Learn more about nest-based access control via Java 11 reflections.

Among the features of JDK 11, we have several hotspots (changes at the bytecode level). One of these hotspots is known as JEP 181, or nest-based access control (nests).

Basically, the nest term defines a new access control context that allows classes that are logically part of the same code entity, but which are compiled with distinct class files, to access each other's private members without the need for compilers to insert accessibility-broadening bridge methods (Java documentation).

So, in other words, nests allow nested classes to be compiled to different class files that belong to the same enclosing class. These are then allowed to access each other's private classes without the use of synthetic/bridge methods.

26 Items for Dissecting Java Local Variable Type Inference (Var Type)

This article is also part of my book Java Coding Problems.
Image title

The Java Local Variable Type Inference (LVTI), or shortly, the var type (the identifiervaris not a keyword, is a reserved type name), was added in Java 10 via JEP 286: Local-Variable Type Inference. As a 100 percent compile feature, it doesn't affect bytecode, runtime, or performance. Mainly, the compiler will inspect the right-hand side and infer the concrete type. It looks at the right-hand side of the declaration, and if there is an initializer, then it simply uses that type to replacevar. Addtionally, it is useful to reduce verbosity, redundancy, and boilerplate code. It is also meant to speed up the ceremonies involved while writing code. For example, it is very handy to writevar evenAndOdd =...instead of Map <Boolean, List <Integer>> evenAndOdd.... Depending on the use case, it has a trade-off in code readability that is covered in the first item below.

JDK 9/JEP 280: String Concatenations Will Never Be the Same

JEP 280 ("Indify String Concatenation") was implemented in conjunction with JDK 9 and, according to its "Summary" section, "Change[s] the static String-concatenation bytecode sequence generated by javac to use invokedynamic calls to JDK library functions." The impact this has on string concatenation in Java is most easily seen by looking at the javap output of classes using string concatenation that is compiled in pre-JDK 9 and post-JDK 9 JDKs.

The following simple Java class named "HelloWorldStringConcat" will be used for the first demonstration.