2

I've got a class that uses jdk.internal.misc.Signal. In module-info.java there is requires jdk.unsupported.

If I try to compile this I get:

[ERROR] MyClass.java:[28,20] package jdk.internal.misc is not visible
[ERROR]   (package jdk.internal.misc is declared in module java.base, which does not export it to module MyModule)

Then if I add <arg>--add-exports</arg><arg>java.base/jdk.internal.misc=MyModule</arg> to maven-compiler-plugin:3.8.1 I get:

[ERROR] exporting a package from system module java.base is not allowed with --release

Then if I remove <release>11</release> I get:

Fatal error compiling: warning: source release 11 requires target release 11

I've the feeling that I'm missing something important or maybe it is just a bug? I'm using maven 3.6.3 and openjdk 11.0.2.

dfa
  • 114,442
  • 31
  • 189
  • 228
  • 1
    duplicate of https://stackoverflow.com/questions/45370178/exporting-a-package-from-system-module-is-not-allowed-with-release – Sean F Feb 10 '20 at 21:35
  • Where is it getting source release from? Just avoid screwing around with release altogether. – Sean F Feb 10 '20 at 21:37
  • thanks @SeanF looks like I should use source/target instead of release – dfa Feb 10 '20 at 21:42
  • When you removed but kept maven defaulted to 1.6. I assume you had source=11 hence the error: It's not possible to compile java11 sources to java6 bytecode. – MeTTeO Feb 11 '20 at 15:37
  • 1
    @SeanF it's not a duplicate. The question you linked is about java.nio and this one is about Signal and SignalHandler – MeTTeO Feb 11 '20 at 15:39

2 Answers2

2

fixed by changing <release>11</release> into <target>11</target> in my pom.xml:

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                <configuration>
                    <source>11</source>
                    <target>11</target>
dfa
  • 114,442
  • 31
  • 189
  • 228
  • For reference here's a [JDK-8178152](https://bugs.openjdk.org/browse/JDK-8178152) explaining the rationale. So _the intent of `--release M` is to only have **public supported API of release `M`**_, meaning any modifications like `--add-exports`, `-add-reads`, `--patch-module`, `--upgrade-module-path` are unsupported, and as such raise the error if modifications and `--release` flags are used together. – bric3 Apr 20 '23 at 19:24
1

jdk.internal.misc.Signal is in java.base module. If you take a look inside its module-info.java file you will notice this:

    exports jdk.internal.misc to
        (...)
        jdk.unsupported;

However jdk.unsupported contains sun.misc.Signal which is the original pre-Java 9 class for handling signals.

In general usage of classes in .internal. packages is a bad practice because they are not part of public API.

Instead I would suggest to use sun.misc.Signal with requires jdk.unsupported module clause until there is a @Deprecated annotation with information which API should be used instead.

BTW. This is a great example how JPMS helps with hiding internal implementation details of a library (in this case JDK) from un/intended usage.

MeTTeO
  • 2,088
  • 16
  • 19