Compile and run java9 module program: part2

In the previous post we saw baiscs about java 9 modules like, what is module, how to create module project, module descriptor file and so on. In this blog we will learn how to compile and run java9 module program.

Recommended read: Java 9 module details: part 1

Java9 Module example for hello world

Before going further let’s take an example of hello world module,

Let’s dive deeper with an example, for better understanding we will create two modules. We will put the modules under the folder ‘project’.

First module, we will create is ‘com.module.util’ module. In this module we will create module-info.java and Greeting.java files.

Second module will be ‘com.module.app’ module. In this module we will create module-info.java and Main.java files.

Let’s create two folders for modules as ‘com.module.util’ and ‘com.module.app’ in the ‘project’ folder. These modules contain files Greeting.java and Main.java respectively. Both modules will have module-info.java at top level as shown below.

D:.

├───project

│   ├───com.module.app

│   │   │   module-info.java

│   │   └───com

│   │       └───module

│   │           └───app

│   │                  Main.java

│   │

│   └───com.module.util

│       │   module-info.java

│       └───com

│           └───module

│               └───util

│                      Greeting.java

Note: com.module.util and com.module.app are the folder names

Code for the ‘Greeting.java’ in ‘com.module.util’ module is as below,

Code for the ‘Main.java’ in ‘com.module.app’ module is as below,

How to compile and run module java program

Now we will see how to run and compile module program. Even if some of the commands look complex don’t worry, once you understand they will be easy and simple.

How to compile and run java program without modules

Before looking into how to run java modular program, let’s understand how to run java package program without using module-info.java file.

To separate out our source files and class files we will use ‘–d’ option to set the destination directory for class files.

Let’s assume we want to run the above Greeting class which is present in the package ‘com.module.util’. And we will put the .class files under the ‘libs’ directory.

D:\project>javac -d libs com.module.util\com\module\util\Greeting.java

Once we execute the above command, we can see that the .class file is created under libs\com\module\util\Greeting.class

Now if we would like to run the main class created by above command, we have to specify path where jvm can find class files. Since our classes are present under libs folder we can specify path using –cp or -classpath.

D:\project>java -cp libs com.module.util.Greeting

OUTPUT

Greeting class is working

Compile and run java 9 module program

Now we have seen how to run java package program and put the classes into separate folder, to avoid mixing .java and .class files. We will use -d option for modular program as well.

Most important thing to remember is that, while compiling module, we have to compile .java source files and module descriptor file(module-info.java) .

In windows path are separated by semi-colon(;) and in Linux and mac using colons(:)

Most important new argument options

There are few new parameters/argument types introduced in java 9 for running the modular program that we must know.

1. module-path: Module-path option is used to specify where the modules are located. It is used at compile and run time.

- At compile time it is used with javac option to specify path where the dependent modules can be found.

Syntax : javac –module-path path1;path2

- At runtime it is used to specify dependent module and module which is to run

Syntax : java -module-path pathslist

Note: we can use -p path as shortcut for –module-path path.

2. module: The –module argument is used to compile list of modules or run a module.

- Syntax : javac –module path1;path2

- Syntax : java –module module/class

Note: we can use -m as shortcut for –module.

3. module-source-path: the argument –module-source-path us used to specify the root directory where the source files or packages are placed.

Sometimes the projects are organized in such a way that the code is placed in special folder.

For example src/main/java

Note: when we are using –module or –m option it is mandatory to use –module-source-path option, even if the source files are in same folder. 

  – – module-path == >  -p 

 – – module       == >  -m 

Example

D:\project> javac -d libs –module-source-path ./ –module com.module.app 

D:\project> java –module-path libs –module com.module.app/com.module.app.Main 

OUTPUT

Have a nice day

Different ways to compile and run java modules

1) We can specify all the files separated by space in javac command:

Warning: If you are using this option don’t compile multiple modules in same folder. Otherwise it will override module-info.class files

Syntax to compile:

javac –d outputDir --module-path requiredModulesPath moduleDir\module-info.java moduleDir\package\File1.java moduleDir\package1\package2\File2.java

Syntax to run:

java --module-path paths --module module/package.MainClass

Note: even in windows in java ‘/’ is used as separator for module and class

Example to compile com.module.util module

D:\project> javac -d libs com.module.util\com\module\util\Greeting.java com.module.util\module-info.java

After this command we should see module-info.class and Greeting.class files are created

project

├───libs

│   │   module-info.class

│   └───com 

│       └───module 

│           └───util 

│                  Greeting.class

Now we can run and check our module using following command

D:\project> java --module-path libs --module com.module.util/com.module.util.Greeting

Greeting class is working

Now lets run the Main class from app module which is dependent on util module which is compiled in libs path.

D:\project> javac --module-path libs -d app com.module.app\com\module\app\Main.java com.module.app\module-info.java

D:\project>java –module-path app;libs –module com.module.app/com.module.app.Main

Have a nice day

2) We can specify module names instead of java files:

This is recommended option to compile the applications. If we use this option, we can compile multiple modules in single directory as separate folder for each module with module name is created.

Also if required modules are in the same folder, they are automatically compiled even if they are not specified

Syntax to compile:

javac –d outputDir --module-path requiredModulesPath --module-source-path rootOfSOurceFiles --module modulesToBeCompiles

Example

D:\project>javac -d libs --module-source-path ./ --module com.module.util,com.module.app

After executing above command, following classes are created

project 

├───libs 

│   ├───com.module.app 

│   │   │   module-info.class

│   │   └───com 

│   │       └───module 

│   │           └───app 

│   │                   Main.class

│   └───com.module.util 

│       │   module-info.class

│       └───com 

│           └───module 

│               └───util 

│                       Greeting.class

Syntax to run:

java --module-path requiredModulesPath --module module/package.MainClass

Example

D:\project>java --module-path libs --module com.module.app/com.module.app.Main

Have a nice day

Common mistakes in running modules

Let’s assume we would like to run Main class from com.module.app module.

Com.module.app module is dependent on com.module.util module.

Com.module.util module is compiled in libs folder

Com.module.app module is compiled in app folder.

When required modules is not specified in module path

java --module-path app -m com.module.app/com.module.app.Main

Error java.lang.module.FindException: Module com.module.util not found, required by com.module.app

When module path of the module which is to be run is not specified in module path

java --module-path libs-m com.module.app/com.module.app.Main

Error: java.lang.module.FindException Module com.module.app not found

When we use the wrong slash(\) to run –correct way is module/class

java --module-path libs;app -m com.module.app\com.module.app.Main

Fast track reading

◉ module-path: used to specify where the modules are located

◉ module: used to specify modules list for compile or module to run

◉ module-source-path: used to specify the root directroy where the source files or packages are places

◉ If we use –-module or –m option it is mandatory to use –-module-source-path option

◉ short codes -p can be used for –-module-path and -m for –module

◉ Syntax to compile javac –d outputDir -p requiredModulesPath –module-source-path rootOfSOurceFiles -m modulesToBeCompiles

◉ Run syntax: java -p requiredModulesPath -m module/package.MainClass

Frequently asked question FAQ:

What is Module resolution process?

When we run the module program, at start jvm checks for all required modules. This process of finding all modules at start is call as Module resolution process.

We can print modules scanning process log by using command –-show-module-resolution in the run command.

Note: in module resolution process first main module is searched then it keep adding required module in tree form.

What are the java restricted keyword or contextual keyword?

Newly added 10 keywords, which are considered as keyword only in case of Module descriptor file(module-info.java), are called as restricted keywords.

This keywords are open, module, requires, transitive, exports, opens, to, uses, provides, and with.

For backward compatibility in every other cases it is considered as identifiers. Unlike other keywords we can use this keywords is variables or method name.

What is module descriptor file?

From java 9, special file with name module-info.java is requied in root folder of module, which specifies the metadata of module, this file is called as module desciptor file.

Can we export multiple package in one line?

No, To export multiple packages separate exports keyword is required.

Can we add multiple modules dependancy using single requries keyword?

No for separate module new requires keyword is required.

Continue reading

Java 9 Modules: part 1

In this blog we will go through one of the most important features of java 9, which is ‘Modules’ aka ‘Java Platform Module System (JPMS)’. We will understand everything about JPMS like, what is module? How it helps to add modules? and How to create and use module? Even if you don’t know anything about module don’t worry we got it covered.

If you are scared of this new word(‘Modules’), don’t worry once you understand it, it will be very easy.

Difference between JDK8 and JDK9

We all know that JRE is the most important part of JDK. But, since java 9, JDK does not contain the JRE folder. Yes! that is true, because from java 9 JRE is converted to multiple small modules and they are present in folder called ‘jmods’.

We can list system modules or the contents of this ‘jmods’ folder by using the command : java –list-modules.

What is a Java 9 Module?

Module system is a part of Jigsaw Project. It adds one more abstraction level above packages. In other words, it is a ‘package of Packages’ that makes our code even more reusable.

It is also fine to say that a module is a group of closely related packages, resources and module descriptor(module-info.java) file.

In Java 9 ‘java.base’ is a base module. It does not depend on any other modules. By default, all modules including user defined modules are dependent on this module.

Even if we do not specify ‘java.base’ module, it will be imported automatically.

Features of java 9 Modules

◉ Increases code reusability: by creating modules we can use them in different projects

◉ Easy and meaningful grouping of packages: if we have many packages in one project it is difficult to manage and organize code, this is where modules come to the rescue

◉ More abstraction to packages: we can decide which packages are allowed to be accessed outside and which are private or for internal use

◉ Separation of resource: each module will have it’s own required resource files like media or configuration files

◉ Internal or secure classes can be hidden from outside world

Steps to create Module

1. Create a folder with module name. Generally company name in reverse with artifact name is used. eg: ‘com.stacktraceguru.util’

2. Add file with name ‘module-info.java’ in module root folder. This file is called as ‘Module Descriptor’ file

3. Create java packages as per requirement

4. Add classes as required under the created packages

What are the rules for creating Module?

◉ Module name must be unique

◉ Each module must have exactly one Module Descriptor file with name ‘module-info.java’

◉ Package names must be unique. Even in the different modules we cannot have same package names

◉ We can add media and other resource files in the module

◉ Each module will create one jar file. For multiple jars we need to create separate modules

◉ One project can have multiple modules

Note: Module name should not end with digits

What are theModule types?

Depending on how the modules are used, they are categorised into 4 types,

◉ System Modules: the modules from JDK and JRE. Can be listed using java ´–list-modules

◉ Application Modules: all the modules created in an application to achieve a functionality

◉ Automatic Modules: existing jar files which are not modules but are added to module path. When we add non module jars to module path, module with jar name is created.

     ◉ By default exports all the packages

     ◉ By default can access classes from all other modules

◉ Unnamed Module: jars and classes added into the classpath. When we add jar or class to the classpath all these classes are added to the unnamed module

     ◉ Only exports to other unnamed module and automatic module. This means, application modules cannot access these classes

     ◉ It can access classes from all the modules

What is Module Descriptor file?

It is a file with name module-info.java, under the root module path. This file contains the module metadata information.

This is also java file which is compileable using javac command.

This file defines following things

◉ Public packages: list of packages that current module exports using ‘exports‘ keyword

◉ Dependencies on other modules: list of other modules on which the current module is dependent on. This is done using ‘requires‘ keyword 

◉ Services offered: list of services that current module provides using ‘provides‘ keyword

◉ Services consumed: list of services that current module consumes using ‘uses‘ keyword

◉ Reflection permission: permission to specify if refection can be used to access private members using ‘open‘ keyword

Note: Module descriptor file needs to export packages as by default all packages are private. Also, we can not use reflection on other module classes. We need to enable reflection in order to use reflection.

module com.module.util{ // module <module.name>

 exports com.module.util;

 requires java.sql;

 }

Exports

By default all the packages are private and we can make them public using exports keyword

Syntax

exports <packageToExport>;

Example

module com.module.util{

    exports com.module.package1;

    exports com.module.package2;

}

Rules to use export keyword:

◉ only exports packages not classes

◉ each package requires new exports keyword

Qualified export: Exports … To

This exports packages to only specific modules and not to all. It is also known as qualified export.

Syntax

exports <packageToExport> to <comma-separated module to grant access>;

Example

module com.module.util{

    exports com.module.package1;

    exports com.module.package2 to com.module.app;

    exports com.module.package3 to com.module.app, com.module.help;

}

In above case all modules can access com.module.package1, But only com.module.app can access com.module.package2 as well.

Requires

If a module needs to access packages exported from other modules, then these other modules must be imported using ‘requires’ keyword.

Only after specifying the module dependency using ‘requires’, the other module packages can be used.

Syntax

requires <module-to-access>;

Example

module com.module.app{

    requires java.sql;

    requires com.module.util;

}

Rules to use requires keyword:

◉ only module can be specified for ‘requires’. Packages cannot be specified

◉ dependency of each module must be specified separately, with separate ‘requires’ keyword

Requires Static

Sometimes we need some modules during compile time only and they are optional at runtime. For example, testing or code generation libraries.

If we need compile time dependency that is optional at runtime then this dependency must be specified using ‘requires static’ keyword.

Syntax

requires static <module-to-access>;

Example

module com.module.app{

    requires static java.sql;

    requires com.module.util;

}

In this example java.sql is mandatory at compile time but optional at runtime. 

Requires Transitive

There is a possibility to grant access of the modules, on which our current module depends, to the module that uses our current module. The ‘requires transitive’ keyword helps to achieve this.

This means all the modules that are using our module will get the access to transitive dependency automatically.

Syntax

requires transitive <module-to-access>;

Example

module com.module.app{

    requires transitive com.module.util;

    requires java.sql;

}

So all other modules that are using com.module.app module can access the exported packages from com.module.util.

Uses

Using uses keyword we can specify that our module needs or consumes some service. Service is a interface or abstract class. It should not be an implementation class. 

Syntax

uses <service-required>;

Example

module com.module.util{

    uses com.util.PersonDataService;

}

Note: The most important thing to note here is that ‘requires’ adds a module dependency, whereas ‘uses’ specifies required service class. 

Provides … With

We can specify that our module provides some services that other modules can use.

Syntax

provides <service-provided> with <service-implementation-class> ;

Example

module com.module.util{

  provides com.util.PersonDataService with com.util.DbPersonServiceImpl;

 }

Open

Since java 9 encapsulation and security is improved for the reflection apis. Using reflection we were able to access even the private members of the objects.

From java 9 this is not open by default. We can although grant reflection permission to other modules explicitly.

open module com.module.util{

}

In this case all the packages from util module are accessible using reflection. 

Opens

If we do not want to open all the packages for reflection we can specify packages manually using ‘opens’ keyword.

module com.module.util{

    opens com.module.package1;

}

In this case only classes from package1 are accessible using reflection.

Opens … To

Using ‘opens …to’ keyword we can open reflection permission for specific packages to specific modules only.

module com.module.util{

  opens com.module.package1 to module.a, module.b, org.test.integration;

}

In this case only module.a, module.b, org.test.integration modules can access classes from package1 using reflection.

Note: If we need reflection access to the module, we can gain the access using command line option ‘–add-opens’, even if we are not the owner of the module.

Aggregator Module

First of all, this is not a technical concept. It is just a convenience concept for developers to make there life easier.

Sometimes multiple modules require other multiple modules. Instead of adding these in every module descriptor, we can create one module that will add all the required dependency using ‘transitive’. Then we just need to add dependency of this module wherever needed, this will add all the required modules transitive dependency. This common module is the ‘Aggregator module’.

For example, we have 10 modules, modA to modJ. modP, modQ, modR needs all 10 modules, then we can create one common module as below,

module modulePQR{

  requires transitive modA;

  ....

  ...

  requires transitive modJ;

}

Then modules P, Q and R just need to add require for modulePQR

module modP{

  requires transitive modulePQR;

}

The module modulePQR is the Aggregator module.

Fast track reading

• Java Platform Module System (JPMS) is a part of Jigsaw Project
• From java 9, jre is converted to multiple small modules and they are present in folder ‘jmods’
• Module is a group of closely related packages, resources and module descriptor(module-info.java) file
• Module names must be unique
• Each module must have exactly one Module Descriptor file with name ‘module-info.java’
• Packages must be unique. Even in the different modules we cannot have same package
• 4 Types of Modules: System Modules , Application Modules, Automatic Modules and Unnamed Module
• Module descriptor file must specify requires modules, exported packages, Services offered, Services Consumed and Reflection permission
• Exports : By default all the packages are private and we can make them public using exports Keyword
• Requires : specify the module dependency
• Only compile time dependency is specified using requires static
• Requires Transitive: Means all the modules who are using our module will get the access to transitive dependency automatically,
• Uses: specifies that our module needs or consumes some service
• Provides … With: specifies that our module provides some services that other modules can use
• Open reflection permission to other modules explicitly
• Aggregator Module:- module which will add all the required dependencies using transitive

Continue reading

Developing a Module with Java 9 in Eclipse IDE, Part 2

In an earlier post, "Developing a Module with Java 9 in Eclipse IDE, Part 1," we introduced modules in Java 9. JSR 376: JavaTM Platform Module System provisions for a module system and Java 9 implements a module system. We defined a module and the associated directives of module, exports, and requires. We also discussed the objectives and benefits of the module system. In this continuation post, we shall introduce using modules in Eclipse IDE. This post has the following sections:

Setting the Environment

Download and install an Eclipse IDE edition that supports Java 9. Eclipse IDE for Java EE Developers (eclipse-jee-photon-M6-win32-x86_64.zip) is used in this tutorial.

Creating a Java Project

To create a Java project, select File>New>Java Project, as shown in Figure 1.

Figure 1: File>New>Java Project

In the New Java Project window, specify the project details, as shown in Figure 2. Specify the Project name (HelloJigsaw) and select the checkbox Use default location. For JRE, select the Use an execution environment JRE radio button and select JavaSE-9. In Project layout, select Create separate folders for sources and class files and click the Configure default link.

Figure 2: New Java Project

We need to set the build path for the source and output folders. In Preferences (Filtered), only Java>Build Path is displayed, as shown in Figure 3. In Source and output folders, select the radio button Folders. Specify the Source folder name as src and Output folder name as modules.hello.jigsaw. Click Apply and Close.

Figure 3: Setting Build Path

Having configured the project details in Create a Java Project, click Next, as shown in Figure 4.

Figure 4: New Java Project>Next

In Java Settings, the Source tab displays the folders src and modules, as shown in Figure 5. In Details, select the Create module-info.java file checkbox. The Default output folders field displays the default output folders. Click Finish.

Figure 5: Java Settings

Configuring a Module Declaration

In this section, we shall create a module declaration in the source code file module-info.java. The module declaration to add is as follows:

module hello.jigsaw {

}

The module does not declare any dependencies and does not export specific packages. By default, all packages in a module are exported. When the option to Create module-info.java file is selected, as shown in Figure 5, a New module-info.java dialog gets displayed (see Figure 6). Specify a module name which, by convention, usually starts with a lowercase letter. Specify a module name in the Module name field, hello.jigsaw as an example.

Figure 6: Specifying Module Name

A new Java project gets created, including the module-info.java source file, as shown in Figure 7.

Figure 7: Java Project HelloJigsaw

Adding the Main Class for the Module

In this section, we shall add the main class for the module. The main class is called Main and should be in a package by the same name as the module name, which is hello.jigsaw. The Main class to add is as follows; the class declares a main method that is invoked when the class is run and outputs a Hello Jigsaw message.

package hello.jigsaw;

public class Main {

   public static void main(String[] args) {

      System.out.println("Hello Jigsaw!");

   }

}

To add the Main class, right-click the HelloJigsaw project in Package Explorer and select New>Class. In the New Java Class window (see Figure 8), the Source folder should be pre-specified as HelloJigsaw/src. Specify the Package as hello.jigsaw, which is the same name as the module name. Specify the class name in the Name field as Main. Select the checkbox for adding the public static void main(String[] args) method, which makes the class a Java application, and click Finish.

Figure 8: Configuring Main Class

The Main class gets added to the Java project HelloJigsaw, as shown in the Package Explorer in Figure 9.

Figure 9: Main Class added

Copy the code for the Main class, as listed earlier, to the Main class in Eclipse IDE, as shown in Figure 10.

Figure 10: Main Class with Source Code

Configuring VM Args for the Module Path

We have created a module declaration in the module-info.java file and the Main application file. How does the Main application find the module? We need to configure VM args for the Main application to include the module path. Right-click the HelloJigsaw project in Package Explorer and select Properties. In the Properties window, select Run/Debug Settings and select the Main class (see Figure 11). Click Edit…

Figure 11: Run/Debug Settings

In Edit Configuration (see Figure 12), the Main tab is selected by default, with the application name specified in the Name field as Main. The project is specified in the Project field as HelloJigsaw. The Main class is hello.jigsaw.Main.

Figure 12: Edit Configuration

Select the Arguments tab and specify the args in the VM arguments field, as shown in Figure 13, and as listed:

--module-path modules -m hello.jigsaw.Main

The --module-path arg specifies the module path as one or more directories with modules and the -m option specifies the module. Click OK.

Figure 13: VM Arguments

In Run/Debug Settings, click Apply and Close, as shown in Figure 14.

Figure 14: Properties>Run/Debug Settings>Apply and Close

Running the Java Module Application

In this section, we shall run the Java module application. Right-click the Main.java file in Package Explorer and select Run As>Java Application, as shown in Figure 15.

Figure 15: Main.java>Run As>Java Application

The Java module application runs and outputs a Hello Jigsaw message in the Console (see Figure 16).

Figure 16: Output from Module Application

Source: developer.com

Continue reading

Developing a Module with Java 9 in Eclipse IDE, Part 1

The main objectives of Project Jigsaw were as follows:

◉ Make it easier to construct and maintain Java libraries and large applications for Java SE and Java EE platforms.

◉ Improve application performance by enabling scaling down of Java SE platform and JDK.

The JSR 376 specification defines a module system for the following requirements of large Java applications:

◉ Reliable Configuration: One of the problems with the class-path mechanism for making program components available to a Java application is that it does not define the relationships between components, making it difficult to ascertain if all the necessary components have been specified. If a required component is missing, it may not be known and, when the component is made use of or invoked in an application, an error results. With JSR 376, dependency on other components is declared so that all the needed components are available when an application is run. Another issue with the class-path mechanism which is fixed with JSR 376 is that it allows classes in the same package to be loaded from different components, resulting in error.

◉ Strong Encapsulation: JSR 376 has the provision to let a component declare which of its packages or public types are accessible and which are not. Previously, the access-control mechanism allows access to any internal packages of a component.

JSR 376 provides the following additional benefits:

◉ Scalability: Modularized custom configurations may be developed that consist of only the minimum required set of components and define minimum required functionality.

◉ Platform Integrity: The encapsulation provided by the JSR prevents access to the internal APIs of Java libraries, which was not needed to start with but not prevented, either.

◉ With class dependencies clearly defined, program optimization may be applied.

What Is a Module?

A module is a named set of Java packages, resources, and native libraries. A module could depend on other module/s, and a module declares which other modules are required to compile and run the code in the packages in the module. A module also declares which of its packages are exported for use by other modules and which are not. A module declaration is made with module, a new keyword in Java SE 9. A module consists of two source files: the module-info.java file for a module declaration, and the main class file for the Main class declaration. The source code for the two files is in a directory by the same name as the module by convention.

Class-path vs. Module System Class Loading

Unlike the class-path–based class loading which loads all the classes specified in the class path, the module loads only the code of the required modules. Unlike the class-path–based class loading, the module system does not let packages by the same name cause any interference. Only the packages exported by the modules declared a dependency on are loaded for access.

Modular Platform Objectives

The objectives of the modular platform or system, as defined in the Java 9 specification, include the capability to provide for varied configurations by dividing the Java SE platform into modules that may be combined at build time, compile time, or run time. A configuration could correspond to the complete Java SE platform, or could consist of a specific set of modules. A configuration could also correspond to one of the Compact Profiles in Java SE 8.

Modular Platform Structure or Design

The module system distinguishes between standard modules and non-standard modules. Standard modules have their specification managed by the Java Community Process (JCP) and have module names starting with "java.". Non-standard modules must not have their names start with "java.". At the base of the module structure is the module java.base, which contains essential classes, such as java.lang.Object and java.lang.String. At the top of the module structure is the java.se.ee module, an aggregator module, which contains all the modules of the Java SE Platform.

Exporting Packages

By default, all packages in a module are exported. A module optionally exports specific public types in its packages with the exports directive. A module declaration may contain multiple exports directives and each exports directive must declare only one package. An exports directive provides other modules access at compile and run time to public and protected types in the package and the public and protected members of those types. A non-standard module must not export any standard API packages.

Declaring Dependency on Other Modules

A module may depend on other modules. Dependency on another module is declared with the requires directive in the module declaration. The requiresdirective introduces three new concepts:

◉ Reliable configuration

◉ Readability

◉ Accessibility

As an example, if module A requires module B, it provides reliable configuration for the presence of B. It allows A to read B; this is called readability. It allows code in A to access code B; this is called accessibility.

Implicitly declared dependence on a module is declared with the requires transitive directive. Any module that requires (with requires) a module that contains a requires transitive directive also implicitly requires the module declared in the requires transitive directive. The requires transitive directive introduces implied readability. A standard module may depend on a non-standard module, as declared with a requires directive, but it must not grant implied readability to a non-standard module as declared with requires transitive. A non-standard module may grant implied readability to a standard module.

Source: developer.com

Continue reading

Java 9 - Overview

JAVA 9 (aka jdk 1.9) is a major release of JAVA programming language development. Its initial version was released on 21 Sep 2017. The main goals of Java 9 release are −

◉ To make JDK and Java Standard Edition platform modular based in the sense that it can be scalled down to small computing devices well.

◉ To improve the overall security of the JDK and Java Implementations.

◉ To make build process and maintainance of java code libraries and large applications easy for for JAVA SE and EE platforms.

◉ To design and implement a standard module system for the Java Platform which can be applied on both Platform and JDK easily.

New Features

There are 90+ enhancements added to Java 8, the most significant ones are mentioned below −

Module − A new kind of Java programing component introduced as module, which is a named, self-describing collection of code and data.

REPL (JShell) − Read-Eval-Print Loop (REPL) capability added to the Java platform.

HTTP 2 Client − new HTTPClient API supporting websockets and HTTP 2 streams and server push features.

Improved JavaDocs − Supports HTML5 output generation. Provides a search box to generated API documentation.

Multirelease JAR − Enhances the JAR format so that multiple, Java release-specific versions of class files can coexist in a single archive.

Collection Factory Methods − New static factory methods for List, Set, and Map interfaces to create immutable instances of those collections.

Private Interface Methods − Enhanced interfaces with private and private static methods.

Process API Improvements − Improved API to control and manage operating system processes.

Stream API Improvements − Enhanced security and robustness by allowing incoming streams of object-serialization data to be filtered.

Try With Resources improvement − Now final variables can be used as resources in the try-with-resources statement.

Enhanced @Deprecated Annotation − @Deprecated annotation revamped to provide more information about the status and intended disposition of an API.

Inner Class Diamond Operator − Allow the diamond operator to be used with anonymous classes if the argument type of the inferred type can be denoted.

Optional Class Improvements − New useful methods are added to java.util.Optional class.

Multiresolution Image API − Supports encapsulation of a set of images with different resolutions into a single multiresolution image.

CompletableFuture API improvements − The asynchronous mechanisms of the CompletableFuture class can perform an action when the process exits with ProcessHandle.onExit method.

Lightweight JSON − A lightweight API introduced to consume and generating documents and data streams via json in java 9.

Reactive Streams API − A new Reactive Streams API in Java SE 9 has been introduced to support reactive programming in java 9.

Continue reading