Illegal reflective access operation warning with iText PDF FontFactory.registerDirectories() and Java 11

user_2158271 0
Viewed 790

Is it possible to avoid Illegal reflective access operation warning with iText PDF FontFactory.registerDirectories() and Java 11?

Steps for reproducing the problem:

  1. Install OpenJDK 11.
  2. Add iText PDF library v5.5.13.2 to your Java project.
  3. Call com.itextpdf.text.FontFactory.registerDirectories().
  4. See the warning: 
    WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.itextpdf.text.io.ByteBufferRandomAccessSource$1 to method java.nio.DirectByteBuffer.cleaner()
WARNING: Please consider reporting this to the maintainers of com.itextpdf.text.io.ByteBufferRandomAccessSource$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

See the poc with Java 11 & Gradle here.

itext7 java-11 itext warnings
1 Answers

The only clean solution is to switch to a newer version that does not perform this illegal reflective access, once this new version exists.

As a temporary work-around, you could use

package com.example;

import org.junit.Test;

import com.itextpdf.text.FontFactory;
import org.junit.BeforeClass;

public class FontFactoryTest {
    @BeforeClass
    public static void prepare() {
        Module mod = FontFactory.class.getClassLoader().getUnnamedModule();
        if(mod == FontFactory.class.getModule()) {
            Object.class.getModule().addOpens("java.nio", mod);
        }
    }

    @Test
    public void test() {
            FontFactory.registerDirectories();
    }
}

This only work as long as the code is placed in the unnamed module (loaded via class path, rather than module path) and as long as the JDK grants the reflective access by default (this is expected to change in the future).

Otherwise, you would need an -add-opens option at the command line or something similar (assuming that the particular execution environment has such an option) and it still is not guaranteed to work, as it implies an access to a member that doesn’t need to be there at all in a particular implementation.

A module can not add an “opens” edge if it doesn’t have the permission itself. The reason, it works at all, is that the “opens” edge from the java.base module to the unnamed module does already exist, it’s just augmented with this warning. The code above utilizes this permission to add an explicit “opens” edge, which is not linked with the warning. As said, this is only a temporary work-around that will stop working in future versions.

user_27114880
Related