Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How is Java 9 running code compiled with Java 8 that is using a non-exported package

I compiled following code using Java-8 compiler:

package pack;
import sun.util.calendar.CalendarUtils;
public class A {
    public static void main(String[] args) {
        System.out.println(CalendarUtils.isGregorianLeapYear(2018));
    }
}

I compiled the above code using Java-8 compiler as:

gyan@gyan-pc:~/codes/java$ ~/Documents/softwares/Linux/jdk1.8.0_131/bin/javac -d . a.java
a.java:2: warning: CalendarUtils is internal proprietary API and may be removed in a future release
import sun.util.calendar.CalendarUtils;
                        ^
a.java:9: warning: CalendarUtils is internal proprietary API and may be removed in a future release
        System.out.println(CalendarUtils.isGregorianLeapYear(2018));
                           ^
2 warnings

Version of my default Java Interpreter:

gyan@gyan-pc:~/codes/java$ java -version
java version "9.0.1"
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)

And I can run the compiled code using Java-9 interpreter without any error.

gyan@gyan-pc:~/codes/java$ java pack.a
false

According to my knowledge: At runtime the package "pack" will be contained inside a special module called "Unnamed module". The "Unnamed module" requires all the modules from Java platform module. But only that package can be used by the "Unnamed module" which are exported by the corresponding module.

My question is: Here the module java.base is not exporting the package "sun.util.calendar". Then how the "Unnamed module" is using it?

like image 308
my name is GYAN Avatar asked Jan 24 '18 11:01

my name is GYAN


People also ask

What is the difference between Java 8 and 9?

Java 8 applications use packages as a top-level component whereas Java 9 applications use modules as a top-level component. Each Java 9 module has only one module with one module descriptor whereas Java 8 package doesn't build multiple modules into a single module.

How do I use Java 9 modules?

To set up a module, we need to put a special file at the root of our packages named module-info. java. This file is known as the module descriptor and contains all of the data needed to build and use our new module. We start the module declaration with the module keyword, and we follow that with the name of the module.

Should I use Java 9 modules?

There is no need to switch to modules. There has never been a need to switch to modules. Java 9 and later releases support traditional JAR files on the traditional class path, via the concept of the unnamed module, and will likely do so until the heat death of the universe.


1 Answers

As pointed by Alan, the section Relaxed strong encapsulation states the following in this respect :-

--illegal-access=permit opens each package in each module in the run-time image to code in all unnamed modules, i.e., to code on the class path, if that package existed in JDK 8. This enables both static access, i.e., by compiled bytecode, and deep reflective access, via the platform's various reflection APIs.

The first reflective-access operation to any such package causes a warning to be issued, but no warnings are issued after that point. This single warning describes how to enable further warnings. This warning cannot be suppressed.

This mode is the default in JDK 9. It will be phased out in a future release and, eventually, removed.

Also, if you try to execute the compiled code with

.../jdk-9.0.1.jdk/Contents/Home/bin/java --illegal-access=deny pack.Some

using the future default flag, you wouldn't be able to execute the code as expected with the following trace :

Exception in thread "main" java.lang.IllegalAccessError: class
pack.Some (in unnamed module @0x1055e4af) cannot access class
sun.util.calendar.CalendarUtils (in module java.base) because module
java.base does not export sun.util.calendar to unnamed module
@0x1055e4af    at pack.Some.main(Some.java:7)
like image 181
Naman Avatar answered Oct 10 '22 13:10

Naman