Community
Participate
Working Groups
I'm using the Neon M2 drop of the SDK on Windows 8 (64-bit) along with the most recent drop (b86) of the JDK 1.9 EA with Jigsaw. The jdeps tool reported a dependency on internal API within the SWT_AWT code, so I tested/confirmed using snippet135. Here's the top of the stack trace: Exception in thread "main" org.eclipse.swt.SWTError: Not implemented (java.lang.IllegalAccessException: class org.eclipse.swt.awt.SWT_AWT$1 cannot access class sun.awt.windows.WEmbeddedFrame (in module java.desktop) because module java.desktop does not export package sun.awt.windows to <unnamed module @4680db8c>) at org.eclipse.swt.SWT.error(SWT.java:4529) at org.eclipse.swt.SWT.error(SWT.java:4418) at org.eclipse.swt.awt.SWT_AWT.new_Frame(SWT_AWT.java:225) at org.eclipse.swt.snippets.Snippet135.main(Snippet135.java:155) Caused by: java.lang.IllegalAccessException: class org.eclipse.swt.awt.SWT_AWT$1 cannot access class sun.awt.windows.WEmbeddedFrame (in module java.desktop) because module java.desktop does not export package sun.awt.windows to <unnamed module @4680db8c> at sun.reflect.Reflection.throwIllegalAccessException(java.base@9.0/Reflection.java:455) at sun.reflect.Reflection.ensureMemberAccess(java.base@9.0/Reflection.java:130) at java.lang.reflect.AccessibleObject.slowCheckMemberAccess(java.base@9.0/AccessibleObject.java:370) at java.lang.reflect.AccessibleObject.checkAccess(java.base@9.0/AccessibleObject.java:362) at java.lang.reflect.Constructor.newInstance(java.base@9.0/Constructor.java:435) at org.eclipse.swt.awt.SWT_AWT$1.run(SWT_AWT.java:172) For completeness: C:\Users\Wayne\jigsaw-jdk-bin-windows-x64\jdk1.9.0\bin>java -version java version "1.9.0-ea" Java(TM) SE Runtime Environment (build 1.9.0-ea-jigsaw-nightly-h3660-20151022-b86) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-jigsaw-nightly-h3660-20151022-b86, mixed mode)
I'm also seeing it on Fedora 22 (GTK3). Exception in thread "main" org.eclipse.swt.SWTError: Not implemented (java.lang.IllegalAccessException: class org.eclipse.swt.awt.SWT_AWT cannot access class sun.awt.X11.XEmbeddedFrame (in module java.desktop) because module java.desktop does not export package sun.awt.X11 to <unnamed module @309e345f>) at org.eclipse.swt.SWT.error(SWT.java:4517) at org.eclipse.swt.SWT.error(SWT.java:4406) at org.eclipse.swt.awt.SWT_AWT.new_Frame(SWT_AWT.java:179) at org.eclipse.swt.snippets.Snippet135.main(Snippet135.java:155) Caused by: java.lang.IllegalAccessException: class org.eclipse.swt.awt.SWT_AWT cannot access class sun.awt.X11.XEmbeddedFrame (in module java.desktop) because module java.desktop does not export package sun.awt.X11 to <unnamed module @309e345f> at sun.reflect.Reflection.throwIllegalAccessException(java.base@9.0/Reflection.java:455) at sun.reflect.Reflection.ensureMemberAccess(java.base@9.0/Reflection.java:130) at java.lang.reflect.AccessibleObject.slowCheckMemberAccess(java.base@9.0/AccessibleObject.java:370) at java.lang.reflect.AccessibleObject.checkAccess(java.base@9.0/AccessibleObject.java:362) at java.lang.reflect.Constructor.newInstance(java.base@9.0/Constructor.java:435) at org.eclipse.swt.awt.SWT_AWT.new_Frame(SWT_AWT.java:177)
The SWT_AWT bridge code requires access to sun.awt.windows.WEmbeddedFrame on Windows, sun.awt.X11.XEmbeddedFrame on GTK and sun.lwawt.macosx.CViewEmbeddedFrame on Mac-Cocoa According to the JEP 260 (http://openjdk.java.net/jeps/260), the classes in sun.* packages are internal APIs and will not be accessible in Java 9. These have not been identified as critical APIs in the JEP and no exception has been provided for them. I think these classes didn't show up on the search as we are calling them through reflection. Running jdeps on swt.jar doesn't catch these internal API usages. Dani, can you please advice on what to do? Should we request for marking them as critical APIs or provide replacement APIs?
(In reply to Lakshmi Shanmugam from comment #2) > The SWT_AWT bridge code requires access to > sun.awt.windows.WEmbeddedFrame on Windows, > sun.awt.X11.XEmbeddedFrame on GTK and > sun.lwawt.macosx.CViewEmbeddedFrame on Mac-Cocoa > > According to the JEP 260 (http://openjdk.java.net/jeps/260), the classes in > sun.* packages are internal APIs and will not be accessible in Java 9. These > have not been identified as critical APIs in the JEP and no exception has > been provided for them. > I think these classes didn't show up on the search as we are calling them > through reflection. Running jdeps on swt.jar doesn't catch these internal > API usages. > > Dani, can you please advice on what to do? Should we request for marking > them as critical APIs or provide replacement APIs? You mean *use* official APIs? You also have to go through the code and check whether there are other places where reflection is used.
(In reply to Dani Megert from comment #3) > (In reply to Lakshmi Shanmugam from comment #2) > > The SWT_AWT bridge code requires access to > > sun.awt.windows.WEmbeddedFrame on Windows, > > sun.awt.X11.XEmbeddedFrame on GTK and > > sun.lwawt.macosx.CViewEmbeddedFrame on Mac-Cocoa > > > > According to the JEP 260 (http://openjdk.java.net/jeps/260), the classes in > > sun.* packages are internal APIs and will not be accessible in Java 9. These > > have not been identified as critical APIs in the JEP and no exception has > > been provided for them. > > I think these classes didn't show up on the search as we are calling them > > through reflection. Running jdeps on swt.jar doesn't catch these internal > > API usages. > > > > Dani, can you please advice on what to do? Should we request for marking > > them as critical APIs or provide replacement APIs? > > You mean *use* official APIs? If there are no such APIs yet, then we have to ask them to provide this and in the meantime put them on the critical API list.
See https://bugs.openjdk.java.net/browse/JDK-8148109
There is a workaround. The jigsaw bounds checking does not work inside a jni, since the swt library already have a libswt-awt native library it is possible to wrap the calls to sun.** classes via jni. I proved this on OSX(where I wrapped the calls to CViewEmbeddedFrame.init/synthesizeWindowActivation/validateWithBounds). Note that this solution will work in case of jdk7/8/9. Please confirm that you will be able to resolve this error "something does not export".
(In reply to Sergey Bylokhov from comment #6) > Please confirm that you will be able to resolve this error "something does > not export". Sorry I didn't follow, can you please explain what has to be confirmed?
In JDK 9 reflection is not able to access the internal classes(which were not exported). I suggest to change the code inside an SWT libary, and use the native code , instead of access via Reflection"java->native->EmbeddedFrame(and other sun.awt clases)". I need a confirmation that it will work for you, after that I will close JDK-8148109 which was mentioned before. The code will look like this: Java: ============================== + static native final void validateWithBounds(Frame frame, int x, int y, int w, int h); ============================== + validateWithBounds(frame, clientArea.x,clientArea.y, + clientArea.width,clientArea.height); +// Method method = frame.getClass().getMethod( +// "validateWithBounds", int.class, int.class, +// int.class, int.class); +// if (method != null) +// method.invoke(frame, Integer.valueOf(clientArea.x), +// Integer.valueOf(clientArea.y), +// Integer.valueOf(clientArea.width), +// Integer.valueOf(clientArea.height)); ============================== Native: +JNIEXPORT void JNICALL Java_org_eclipse_swt_awt_SWT_1AWT_validateWithBounds +(JNIEnv *env, jclass that, jobject frame, jint x,jint y,jint w,jint h) +{ + jclass cls = (*env)->FindClass(env, "sun/lwawt/macosx/CViewEmbeddedFrame"); + if (NULL == cls) return; + jmethodID midInit = (*env)->GetMethodID(env, cls, "validateWithBounds", "(IIII)V"); + (*env)->CallVoidMethod(env, frame, midInit, x,y,w,h); +}
(In reply to Sergey Bylokhov from comment #8) I'll look into the proposed solution and get back on this in a week's time.
(In reply to Lakshmi Shanmugam from comment #9) > I'll look into the proposed solution and get back on this in a week's time. Hi, Do you have any update?
(In reply to Sergey Bylokhov from comment #10) > (In reply to Lakshmi Shanmugam from comment #9) > > I'll look into the proposed solution and get back on this in a week's time. > > Hi, Do you have any update? Hi, sorry for the delayed response. We are in the Eclipse 4.6 endgame and I was held up with other last minute work for the release. I've started working on this. I should be able to provide an update in a day or two.
Created attachment 261894 [details] patch I tried the changes suggested in comment 8 and ran couple of example Snippets 154, 155 on Java 9 build (jdk-9-ea+112_osx-x64). There were no errors or exceptions, but the AWT frame doesn't appear. I debugged the code and confirmed that I get a Frame object from initFrame. But, not sure if something else is failing here. I've attached the changes here for reference. The same code runs fine with Java 8. I'm running Java 9 on OSX 10.11.
> I tried the changes suggested in comment 8 and ran couple of example > Snippets 154, 155 on Java 9 build (jdk-9-ea+112_osx-x64). > There were no errors or exceptions, but the AWT frame doesn't appear. I > debugged the code and confirmed that I get a Frame object from initFrame. > But, not sure if something else is failing here. > I've attached the changes here for reference. The same code runs fine with > Java 8. > I'm running Java 9 on OSX 10.11. There was a bug which was fixed in jdk9b117: https://bugs.openjdk.java.net/browse/JDK-8154088 You need to use >= jdk9b177
Note that it is not necessary to move all methods to the native, only inaccessible methods. For example it is not necessary to move addNotify(), dispatchEvent(). Also FYI, I'll provide a set of new methods in jawt library which will encapsulate a knowledge about the internal names. And these new methods will be used in your native code: For example this: + jclass cls = (*env)->FindClass(env, "sun/lwawt/macosx/CViewEmbeddedFrame"); + if (NULL == cls) return NULL; + constructor = (*env)->GetMethodID(env, cls, "<init>", "(J)V"); + object = (*env)->NewObject(env, cls, constructor, handle); Will be replaced by something like this: +{ + awt_CreateEmbeddedComponent(env, handle); +} I have a prototype on OSX on top of your patch, but do you have some update for windows and linux?
(In reply to Sergey Bylokhov from comment #14) > I have a prototype on OSX on top of your patch, but do you have some update > for windows and linux? For linux (Ubuntu 14.04), only the constructor had to be replaced with initFrame native code. I tried it and the change works fine. I'll upload the patch after some code cleanup. I'll be trying out Windows next.
New Gerrit change created: https://git.eclipse.org/r/75211
The gerrit patch has the required changes for all 3 platforms. I've cleaned up the code that was required only for older versions of java. Tested the patch with jdk9+121 build and it works fine on Mac OSX and Linux-gtk. I've still not been able to verify the patch on Windows due to some build issues, we are looking into it.
(In reply to Sergey Bylokhov from comment #14) > Note that it is not necessary to move all methods to the native, only > inaccessible methods. For example it is not necessary to move addNotify(), > dispatchEvent(). I've removed the unnecessary changes for all platforms. > > Also FYI, I'll provide a set of new methods in jawt library which will > encapsulate a knowledge about the internal names. And these new methods will > be used in your native code: > > For example this: > + jclass cls = (*env)->FindClass(env, "sun/lwawt/macosx/CViewEmbeddedFrame"); > + if (NULL == cls) return NULL; > + constructor = (*env)->GetMethodID(env, cls, "<init>", "(J)V"); > + object = (*env)->NewObject(env, cls, constructor, handle); > > Will be replaced by something like this: > +{ > + awt_CreateEmbeddedComponent(env, handle); > +} > I had missed this before, the SWT_AWT class has a public String member "embeddedFrameClass" that can set by the user/program. If it is null then the default class name for the platform will be used. So, even if the internal names are encapsulated, we still need to use the above mechanism to use the user specified name in the native code.
The latest gerrit patch works on all 3 platforms with JDK 9.
Does this patch was released as a beta version or something like that?
(In reply to Sergey Bylokhov from comment #20) > Does this patch was released as a beta version or something like that? The patch is not yet released to the repository. Does the patch work with your Java changes? I plan to put it in the BETA_JAVA9 branch so that it can be tried out in the Y-builds.
The BETA_JAVA9 branches and the Y-build are only meant for adding support for development/compilation of Java 9 code in the IDE. I-builds for Oxygen are expected to run on Java 8 and Java 9 (notwithstanding the breaking change in JDK9 that requires the addition of "-addmods java.se.ee" to the vmargs). These changes should go directly into the master branch/I-builds. Guard them with a version check if necessary to make sure they don't break running on Java 8.
I released the patch to master -> http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=2214fda883b89bb4f8ad39483d2e3f9ae1a89294 This I-build has the patch, please try it out -> http://download.eclipse.org/eclipse/downloads/drops4/I20160809-1300/
(In reply to Lakshmi Shanmugam from comment #23) > I released the patch to master -> > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=2214fda883b89bb4f8ad39483d2e3f9ae1a89294 > > This I-build has the patch, please try it out -> > http://download.eclipse.org/eclipse/downloads/drops4/I20160809-1300/ Above fix is not working on Windows, reason being a linking error during native compilation, see bug 499545.
(In reply to Niraj Modi from comment #24) > (In reply to Lakshmi Shanmugam from comment #23) > > I released the patch to master -> > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > > ?id=2214fda883b89bb4f8ad39483d2e3f9ae1a89294 > > > > This I-build has the patch, please try it out -> > > http://download.eclipse.org/eclipse/downloads/drops4/I20160809-1300/ > > Above fix is not working on Windows, reason being a linking error during > native compilation, see bug 499545. Fix for bug 499545 has successfully unblocked this issue, so fixes made in comment 23 working now in latest IBuild: I20160824-1429 on Win7.
*** Bug 492087 has been marked as a duplicate of this bug. ***
This bug should have been resolved for 4.7M2. Marking as fixed.
