Archivo de la categoría: DEBUN_OCJP11

Posts relacionados con Java 11 como LTS y con el contenido necesario para el examen 1Z0-817.

OCP11 – Migration to a Modular Application

Following the introductory post of Java Platform Module System , also known as JPMS, this post exposes different strategies to migrate applications developed in Java as they can make use of it. This covers the cases where original application is based on a non compatible Java version (< Java 9) or it is compatible (>=Java9) but it was not originally implemented, since the use of this mechanism is fully optional.

Migration strategies

The first step to perform in the migration of an application to the module system is to determine which modules / JAR files are present in an application and what dependencies exists between them. A very useful way to do so is through a hierarchical diagram where these dependencies are represented in a layered way. This will help give an overview of the components of the application and of which of them and in which order they can be migrated, identifying those who will not be able to adapt temporarily or definitively. The latter case can be given for example in third parties libraries that have stopped offering support and that will hardly become modules. This overview will help determine the migration strategy that will be carried out. Next, 2 migration mechanisms are exposed that respond to different initial situations.

Seguir leyendo OCP11 – Migration to a Modular Application

OCP 11 – Language Enhancements (Java Fundamentals – Final modifier)


Final modifier can be applied to variables, methods and classes.
Marking a:

  1. Variable final means the value cannot be changed after it is assigned.
  2. Method or a class means it cannot be overridden (for methods) or extended (for classes).

Declaring final local variables

For final variables there are several aspects to consider.

We do not need to assign a value to the final variable when we declare it. What we have to assure is the a value has been assigned to it before this final variable is used. We will get a compilation error in case we don’t follow this rule. Example which illustrates this:

private void printZooInfo(boolean isWeekend) {
    final int giraffe = 5;
    final long lemur;
    if (isWeekend) lemur = 5;
    giraffe = 3; // DOES NOT COMPILE   
    System.out.println(giraffe+" "+lemur); // DOES NOT COMPILE

Here we have two compilation errors:

  1. The giraffe variable has an assigned value so we can’t assign a new value because it has been declared as final. We will get a compilation error.
  2. When attempting to use lemur variable we will get a compilation error. If condition isWeekend is false we can’t assign the value to lemur so we will the error the error compilation because a local variable to has to be declared and assigned before using it (despite the fact of being declared as final or not).

When we mark a variable as final it does not mean that the object associated with it cannot be modified. Example to illustrate this:

final StringBuilder cobra = new StringBuilder();

We have declared the variable as constant but the content of the class can be modified.

Adding final to Instance and static variables

Instance and static class variables can be marked as final too.

When we mark as final a:

  1. Instance variable which it means that it must be assigned a value when it is declared or when the object is instantiated (Remember: We can only assign once, like Local Variables). Example to illustrate this:

    public class PolarBear {
    final int age = 10;
    final int fishEaten;
    final String name;
    { fishEaten = 10; }
    public PolarBear() {
      name = "Robert";
    public PolarBear(int height) {

    Does this code compile? Yes. Everything. Exercise: Explain why.

  2. Static variable which it means they have to use static initializers instead of instance initializers. Example to illustrate this:

    public class Panda {
    // We assign a value when we declare the final variable
    final static String name = "Ronda";
    static final int bamboo;
    static final double height; // DOES NOT COMPILE - Why? Because we do not have assign any value to height variable  
    // It will work because we are initializing a final static variable through an static initializer
    static { bamboo = 5;}}

Writing final methods

Methods marked as final cannot be overriden by a subclass. This avoids polymorphic behavior and always ensures that it is always called the same version method. Be aware because a method can have abstract or final modifier but not both at the same time.

When we combine inheritance with final methods we always get an error compilation.

We cannot declare a method final and abstract at the same time. It is not allowed by the compiler and of course we will get a compilation error.
Example to illustrate this:

abstract class ZooKeeper {   
    public abstract final void openZoo(); // DOES NOT COMPILE

Marking Classes final

A final class is one class that cannot be extended. In fact we will get a compilation error if we tried. Example to illustrate this:

public final class Reptile {}
public class Snake extends Reptile {} // DOES NOT COMPILE

We cannot use abstract and final modifiers at the same time.

public abstract final class Eagle {} // DOES NOT COMPILE

It also happens the same for interfaces.

public final interface Hawk {} // DOES NOT COMPILE

We will get a compilation error in both cases.

OCP11 – Understanding Modules

Java Platform Module System or JPMS was introduced in Java 9 as a form of encapsulation package.

A module is a group of one or more packages and a file that contain its metadata.

In other words it consists in a ‘package of packages’.

Benefits of using modules:

While using modules in a Java 9+ application is optional, there are a series of benefits from using them:

  • Better access control: Creates a fifth level of class access control that restricts packages to be available to outer code. Packages that are not explicitly exposed through module-info will be not available on modules external code. This is useful for encapsulation that allows to have truly internal packages.

  • Clear dependency management: Application’s dependencies will be specified in file. This allows us to clearly identify which are the required modules/libraries.

  • Custom java builds: JPMS allow developers to specify what modules are needed. This makes it possible to create smaller runtime images discarding JRE modules that the application doesn’t need (AWT, JNI, ImageIO…).

  • Performances improvements: Having an static list of required modules and dependencies at start-up allows JVM to reduce load time and memory footprint because it allows the JVM which classes must be loaded from the beginning.

  • Unique package enforcement: A package is allowed to be supplied by only one module. JPMS prevents JAR hell scenarios such as having multiple library versions in the classpath.

The main counterpart is not all libraries have module support and, while possible makes more difficult to switch to a modular code that depends on this kind of libraries. For example, libraries that make an extensive use of reflection will need an extra configuration step because JPMS cannot identify and load classes at runtime.

Seguir leyendo OCP11 – Understanding Modules

OCP11 – Local Variable Type Inference

Working with Local Variable Type Inference

After Java 10 we can use the keyword var instead of the type for local variables (like the primitive or the reference type) under certain conditions within a code block.

public void whatTypeAmI {
    var name = "Hello";
    var size = 7;

The formal name of this feature is local variable type inference but we have to consider two main parts for this feature.

Seguir leyendo OCP11 – Local Variable Type Inference