Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix illegal reflective access operations (Java 9) #110

Open
jeremydlawrence opened this issue Oct 13, 2017 · 7 comments
Open

Fix illegal reflective access operations (Java 9) #110

jeremydlawrence opened this issue Oct 13, 2017 · 7 comments
Milestone

Comments

@jeremydlawrence
Copy link

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper to method sun.nio.ch.SelChImpl.getFD()
WARNING: Please consider reporting this to the maintainers of jnr.posix.JavaLibCHelper
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

@jeremydlawrence jeremydlawrence changed the title Fix illegal reflective access operations Fix illegal reflective access operations (Java 9) Oct 13, 2017
@huntc
Copy link

huntc commented Nov 25, 2017

Just wondering how this is going to be fixable without either lobbying for the JDK to provide a supported SelChImpl or moving away from sun.nio.ch entirely... any thoughts out there?

@Zhuinden
Copy link

Hey, this project is an example for Java 8->9 migration and that this code here will break after Java 9 by default: https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-7BB28E4D-99B3-4078-BDC4-FC24180CE82B

@headius headius added this to the 3.0.46 milestone May 16, 2018
@PaulSandoz
Copy link

Could you bring this use-case to OpenJDK either by mailing nio-dev@openjdk.java.net and/or logging an issue here https://bugreport.java.com/bugreport/ (which will eventually end up at https://bugs.openjdk.java.net/secure/Dashboard.jspa).

Note that JNR will continue to still work on Java 11. Illegal access operations will be denied in a future release to be determined.

@ohumbel
Copy link

ohumbel commented Jul 29, 2018

@PaulSandoz Are you aware of a discussion on nio-dev or of a bug report we could follow?
I searched the nio-dev archives from June on, and I believe I haven't found a matching topic (but I might be wrong).

@charleskorn
Copy link

This doesn't fix the root cause of the problem, but if you want to suppress the warnings, adding --add-opens java.base/sun.nio.ch=ALL-UNNAMED --add-opens java.base/java.io=ALL-UNNAMED to your java command line will hide them.

charleskorn added a commit to batect/batect that referenced this issue Jan 11, 2019
@schaumb
Copy link

schaumb commented Jan 12, 2019

I running into the same problem with the following code:

    int i = JavaLibCHelper.getfdFromDescriptor(new FileDescriptor());

One possible solution can be hacking with JNI, because there isn't any check when native code wants to access private field.

Test.java

import java.io.FileDescriptor;

public class Test {
    public static native int getFD(FileDescriptor oth);

    public static void main(String[] args) {
        System.load(new File("Test").getAbsolutePath()); // load compiled shared lib 
        int fd = getFD(new FileDescriptor());
    }
}

~Test.h

/*
 * Class:     Test
 * Method:    getFD
 * Signature: (Ljava/io/FileDescriptor;)I
 */
JNIEXPORT jint JNICALL Java_Test_getFD
  (JNIEnv *, jclass, jobject);

~Test.cpp

jint Java_Test_getFD(JNIEnv * env, jclass, jobject o) {
    jclass clazz = env->GetObjectClass(o);
    jfieldID fd = env->GetFieldID(clazz,"fd","I");
    jint res = (jint)env->GetIntField(o, fd);

    env->DeleteLocalRef(clazz);

    return res;
}

It can be write the same logic for SelChImpl class too.

@schaumb
Copy link

schaumb commented Dec 13, 2021

For FILE_DESCRIPTOR_FD it can be used
sun.nio.ch.IOUtil.fdVal and sun.nio.ch.IOUtil.newFD.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants