Community
Participate
Working Groups
eclipse-SDK-I20181128-0130-win32-x86_64. Java 11. 1. Start new workspace 2. Open preferences 3. Select the 'Link Handlers' preference page ==> error dialog, page does not open Log: !ENTRY org.eclipse.jface 4 2 2018-11-28 19:29:44.664 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jface". !STACK 0 java.lang.ExceptionInInitializerError at org.eclipse.urischeme.internal.registration.RegistryWriter.<init>(RegistryWriter.java:47) at org.eclipse.urischeme.internal.registration.RegistrationWindows.<init>(RegistrationWindows.java:32) at org.eclipse.urischeme.IOperatingSystemRegistration.getInstance(IOperatingSystemRegistration.java:41) at org.eclipse.ui.internal.ide.application.dialogs.UriSchemeHandlerPreferencePage.init(UriSchemeHandlerPreferencePage.java:84) at org.eclipse.ui.internal.dialogs.WorkbenchPreferenceNode.createPage(WorkbenchPreferenceNode.java:61) at org.eclipse.jface.preference.PreferenceDialog.createPage(PreferenceDialog.java:1279) at org.eclipse.ui.internal.dialogs.FilteredPreferenceDialog.createPage(FilteredPreferenceDialog.java:361) at org.eclipse.jface.preference.PreferenceDialog.showPage(PreferenceDialog.java:1166) at org.eclipse.ui.internal.dialogs.FilteredPreferenceDialog.showPage(FilteredPreferenceDialog.java:675) at org.eclipse.jface.preference.PreferenceDialog$5.lambda$0(PreferenceDialog.java:660) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:72) at org.eclipse.jface.preference.PreferenceDialog$5.selectionChanged(PreferenceDialog.java:657) at org.eclipse.jface.viewers.StructuredViewer$3.run(StructuredViewer.java:874) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at org.eclipse.ui.internal.JFaceUtil.lambda$0(JFaceUtil.java:47) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:176) at org.eclipse.jface.viewers.StructuredViewer.firePostSelectionChanged(StructuredViewer.java:871) at org.eclipse.jface.viewers.StructuredViewer.handlePostSelect(StructuredViewer.java:1240) at org.eclipse.jface.viewers.StructuredViewer.lambda$0(StructuredViewer.java:1263) at org.eclipse.swt.events.SelectionListener$1.widgetSelected(SelectionListener.java:84) at org.eclipse.jface.util.OpenStrategy.firePostSelectionEvent(OpenStrategy.java:264) at org.eclipse.jface.util.OpenStrategy.access$5(OpenStrategy.java:259) at org.eclipse.jface.util.OpenStrategy$1.lambda$1(OpenStrategy.java:429) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3919) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3550) at org.eclipse.jface.window.Window.runEventLoop(Window.java:822) at org.eclipse.jface.window.Window.open(Window.java:798) at org.eclipse.ui.internal.dialogs.WorkbenchPreferenceDialog.open(WorkbenchPreferenceDialog.java:214) at org.eclipse.ui.internal.OpenPreferencesAction.run(OpenPreferencesAction.java:66) at org.eclipse.jface.action.Action.runWithEvent(Action.java:476) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:568) at org.eclipse.jface.action.ActionContributionItem.lambda$4(ActionContributionItem.java:400) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4131) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1055) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3944) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3547) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1173) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1062) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:636) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:563) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:151) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:155) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:137) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:107) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:659) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:595) at org.eclipse.equinox.launcher.Main.run(Main.java:1501) at org.eclipse.equinox.launcher.Main.main(Main.java:1474) Caused by: java.lang.IllegalStateException: java.util.prefs.WindowsPreferences.closeKey(int) at org.eclipse.urischeme.internal.registration.WinRegistry.<clinit>(WinRegistry.java:61) ... 61 more Caused by: java.lang.NoSuchMethodException: java.util.prefs.WindowsPreferences.closeKey(int) at java.base/java.lang.Class.getDeclaredMethod(Class.java:2476) at org.eclipse.urischeme.internal.registration.WinRegistry.<clinit>(WinRegistry.java:52) ... 61 more
Looks like reflection is used. I also get the following warnings from Java 11: WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.eclipse.urischeme.internal.registration.WinRegistry (file:/C:/eclipse/drops/eclipse-SDK-I20181128-0130-win32-x86_64/pl ugins/org.eclipse.urischeme_1.0.100.v20181119-0838.jar) to method java.util.prefs.WindowsPreferences.stringToByteArray(java.lang.String) WARNING: Please consider reporting this to the maintainers of org.eclipse.urischeme.internal.registration.WinRegistry 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
Could not reproduce with Eclipse SDK Version: 2018-12 (4.10) Build id: I20181128-1800 Nothing in error log and Preference page opens up.
(In reply to Sarika Sinha from comment #2) > Could not reproduce with > Eclipse SDK > > Version: 2018-12 (4.10) > Build id: I20181128-1800 > > Nothing in error log and Preference page opens up. This was when I launched with Java 8. I could reproduce the problem when launched with Java 11.
(In reply to Sarika Sinha from comment #3) > I could reproduce the problem when launched with Java 11. Same here.
(In reply to Dani Megert from comment #1) > Looks like reflection is used. I also get the following warnings from Java > 11: > > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > org.eclipse.urischeme.internal.registration.WinRegistry > (file:/C:/eclipse/drops/eclipse-SDK-I20181128-0130-win32-x86_64/pl > ugins/org.eclipse.urischeme_1.0.100.v20181119-0838.jar) to method > java.util.prefs.WindowsPreferences.stringToByteArray(java.lang.String) > WARNING: Please consider reporting this to the maintainers of > org.eclipse.urischeme.internal.registration.WinRegistry > 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 Yes. We use reflection on windows. On macOS and Linux no reflection is used. We always where transparent about this. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=530835#c1 https://bugs.eclipse.org/bugs/show_bug.cgi?id=530835#c4 We tested on JDKs 8,9 and 10. Really bad luck :-( Does Eclipse 2018-12 officially support java 11? Regarding the warning: Will reflection be no longer possible in future releases?
(In reply to Matthias Becker from comment #5) > (In reply to Dani Megert from comment #1) > > Looks like reflection is used. I also get the following warnings from Java > > 11: > > > > WARNING: An illegal reflective access operation has occurred > > WARNING: Illegal reflective access by > > org.eclipse.urischeme.internal.registration.WinRegistry > > (file:/C:/eclipse/drops/eclipse-SDK-I20181128-0130-win32-x86_64/pl > > ugins/org.eclipse.urischeme_1.0.100.v20181119-0838.jar) to method > > java.util.prefs.WindowsPreferences.stringToByteArray(java.lang.String) > > WARNING: Please consider reporting this to the maintainers of > > org.eclipse.urischeme.internal.registration.WinRegistry > > 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 > > Yes. We use reflection on windows. On macOS and Linux no reflection is used. > We always where transparent about this. See: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=530835#c1 > https://bugs.eclipse.org/bugs/show_bug.cgi?id=530835#c4 > > We tested on JDKs 8,9 and 10. Really bad luck :-( > > Does Eclipse 2018-12 officially support java 11? Java 11 is the one to use. Java 10 is already out of service and hence not supported by Eclipse. Java 8 is supported but pretty old. > Regarding the warning: Will reflection be no longer possible in future > releases? Yes, in some future release. However somethings else seems to go wrong here. Those are only warnings and those calls should actually work. Even when I run with --illegal-access=permit it fails. So, you either need to figure out what's going wrong or remove the feature and work on it for 4.11.
(In reply to Dani Megert from comment #6) > Yes, in some future release. Releases of Eclipse of JDK? > However somethings else seems to go wrong here. Those are only warnings and > those calls should actually work. Even when I run with > --illegal-access=permit > it fails. Can you please explain the semantic of this switch? what exactly is an illegal access and what is a legal access? >So, you either need to figure out what's going wrong or remove the > feature and work on it for 4.11. We will check. But pls. note: Currently eclipse platform does not provide any link handlers. This only affects windows and only users on Java 11. I would prefer to keep the feature in 4.10. We will provide a fix a soon as we can.
(In reply to Matthias Becker from comment #7) > (In reply to Dani Megert from comment #6) > > Yes, in some future release. > Releases of Eclipse of JDK? Yes. Those warnings come form there. Initially, it was planned to deny access when modules were introduced with Java 9. But there were massive objections from the users. > > However somethings else seems to go wrong here. Those are only warnings and > > those calls should actually work. Even when I run with > > --illegal-access=permit > > it fails. > > Can you please explain the semantic of this switch? what exactly is an > illegal access and what is a legal access? http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html > >So, you either need to figure out what's going wrong or remove the > > feature and work on it for 4.11. > We will check. But pls. note: Currently eclipse platform does not provide > any link handlers. This only affects windows and only users on Java 11. I > would prefer to keep the feature in 4.10. We will provide a fix a soon as > we can. I would vote against that because Java 11 is the latest and most people are using that. If you can't fix this please ask the PMC (eclipse-pmc@eclipse.org) for approval of your plan. Even if approved, you will have to fix the experience on Windows. Shipping a preference page that greets the user with errors is a no go.
(In reply to Dani Megert from comment #8) > I would vote against that because Java 11 is the latest and most people are > using that. If you can't fix this please ask the PMC > (eclipse-pmc@eclipse.org) for approval of your plan. Even if approved, you > will have to fix the experience on Windows. Shipping a preference page that > greets the user with errors is a no go. How would you vote when we check the os and java version in set the pref-page to inactive when on windows on java 11 as a work-around in 2018-12. For sure we will provide a fix for the functional issue.
(In reply to Matthias Becker from comment #9) > (In reply to Dani Megert from comment #8) > > I would vote against that because Java 11 is the latest and most people are > > using that. If you can't fix this please ask the PMC > > (eclipse-pmc@eclipse.org) for approval of your plan. Even if approved, you > > will have to fix the experience on Windows. Shipping a preference page that > > greets the user with errors is a no go. > > How would you vote when we check the os and java version in set the > pref-page to inactive when on windows on java 11 as a work-around in 2018-12. > For sure we will provide a fix for the functional issue. Did you start to debug the problem? Maybe it's something simple.
(In reply to Dani Megert from comment #10) > (In reply to Matthias Becker from comment #9) > > (In reply to Dani Megert from comment #8) > > > I would vote against that because Java 11 is the latest and most people are > > > using that. If you can't fix this please ask the PMC > > > (eclipse-pmc@eclipse.org) for approval of your plan. Even if approved, you > > > will have to fix the experience on Windows. Shipping a preference page that > > > greets the user with errors is a no go. > > > > How would you vote when we check the os and java version in set the > > pref-page to inactive when on windows on java 11 as a work-around in 2018-12. > > For sure we will provide a fix for the functional issue. > > Did you start to debug the problem? Maybe it's something simple. I am on it. I just asked as fall-back option.
(In reply to Matthias Becker from comment #11) > (In reply to Dani Megert from comment #10) > > (In reply to Matthias Becker from comment #9) > > > (In reply to Dani Megert from comment #8) > > > > I would vote against that because Java 11 is the latest and most people are > > > > using that. If you can't fix this please ask the PMC > > > > (eclipse-pmc@eclipse.org) for approval of your plan. Even if approved, you > > > > will have to fix the experience on Windows. Shipping a preference page that > > > > greets the user with errors is a no go. > > > > > > How would you vote when we check the os and java version in set the > > > pref-page to inactive when on windows on java 11 as a work-around in 2018-12. > > > For sure we will provide a fix for the functional issue. > > > > Did you start to debug the problem? Maybe it's something simple. > > I am on it. I just asked as fall-back option. :-) If other PMC members would accept it, I would not vote it down. As mentioned, you should send a note to the PMC list. Note that we don't have much time left.
(In reply to Dani Megert from comment #12) > (In reply to Matthias Becker from comment #11) > > (In reply to Dani Megert from comment #10) > > > (In reply to Matthias Becker from comment #9) > > > > (In reply to Dani Megert from comment #8) > > > > > I would vote against that because Java 11 is the latest and most people are > > > > > using that. If you can't fix this please ask the PMC > > > > > (eclipse-pmc@eclipse.org) for approval of your plan. Even if approved, you > > > > > will have to fix the experience on Windows. Shipping a preference page that > > > > > greets the user with errors is a no go. > > > > > > > > How would you vote when we check the os and java version in set the > > > > pref-page to inactive when on windows on java 11 as a work-around in 2018-12. > > > > For sure we will provide a fix for the functional issue. > > > > > > Did you start to debug the problem? Maybe it's something simple. > > > > I am on it. I just asked as fall-back option. > :-) > > If other PMC members would accept it, I would not vote it down. As > mentioned, you should send a note to the PMC list. Note that we don't have > much time left. How do I send a not the the PMC list?
(In reply to Matthias Becker from comment #13) > (In reply to Dani Megert from comment #12) > > (In reply to Matthias Becker from comment #11) > How do I send a note to the PMC list? It is an email list for which you must register. Link: https://accounts.eclipse.org/mailing-list/eclipse-pmc
(In reply to Lars Vogel from comment #14) > (In reply to Matthias Becker from comment #13) > > (In reply to Dani Megert from comment #12) > > > (In reply to Matthias Becker from comment #11) > > > > How do I send a note to the PMC list? > > It is an email list for which you must register. Link: > https://accounts.eclipse.org/mailing-list/eclipse-pmc mail sent
New Gerrit change created: https://git.eclipse.org/r/133258
(In reply to Eclipse Genie from comment #16) > New Gerrit change created: https://git.eclipse.org/r/133258 Dani, can you please test with this patch. It should run on java 8,9,10 and now also on java 11. To have demo link handlers import the org.eclipse.ui.examples.uriSchemeHandler plugin into your workspace. This plugin provides 3 demo handlers. You should be able to open the page. Setting / unsetting checkboxes and pressing apply should not cause any issues. Best to test is to: - set the checkbox, apply, - reopen the pref page, check that the checkbox is still checked - delete the checkbox, apply, - reopen the pref page, check that the checkbox is still unchecked
(In reply to Matthias Becker from comment #17) > (In reply to Eclipse Genie from comment #16) > > New Gerrit change created: https://git.eclipse.org/r/133258 > > Dani, > > can you please test with this patch. Done. I've added a comment to the Gerrit change that it works for me.
(In reply to Dani Megert from comment #18) > (In reply to Matthias Becker from comment #17) > > (In reply to Eclipse Genie from comment #16) > > > New Gerrit change created: https://git.eclipse.org/r/133258 > > > > Dani, > > > > can you please test with this patch. > > Done. I've added a comment to the Gerrit change that it works for me. Dani, I tried to reproduce the AssertionFailedException but could not. What do I need to do that the launcher is null?
(In reply to Matthias Becker from comment #19) > Dani, I tried to reproduce the AssertionFailedException but could not. What > do I need to do that the launcher is null? I have a setup which most people don't use. I have source and imported binary plug-ins and don't use anything from the target platform. In that setup it does not have the launcher property set. Just removing the assert fixes the problem since the #getLauncher can handle 'null'.
New Gerrit change created: https://git.eclipse.org/r/133287
(In reply to Dani Megert from comment #20) > (In reply to Matthias Becker from comment #19) > > Dani, I tried to reproduce the AssertionFailedException but could not. What > > do I need to do that the launcher is null? > > I have a setup which most people don't use. I have source and imported > binary plug-ins and don't use anything from the target platform. In that > setup it does not have the launcher property set. Just removing the assert > fixes the problem since the #getLauncher can handle 'null'. I uploaded a revised version of my patch. We tested on windows with java 8 and java 11. Dani: Can you do a quick re-test on it. I also fixed the assertion issue. Does this change need a re-approval?
(In reply to Matthias Becker from comment #22) > (In reply to Dani Megert from comment #20) > Does this change need a re-approval? Fix is still in line with the original request, so I would say the existing PMC approval is still valid.
(In reply to Matthias Becker from comment #22) > (In reply to Dani Megert from comment #20) > > (In reply to Matthias Becker from comment #19) > > > Dani, I tried to reproduce the AssertionFailedException but could not. What > > > do I need to do that the launcher is null? > > > > I have a setup which most people don't use. I have source and imported > > binary plug-ins and don't use anything from the target platform. In that > > setup it does not have the launcher property set. Just removing the assert > > fixes the problem since the #getLauncher can handle 'null'. > > I uploaded a revised version of my patch. We tested on windows with java 8 > and java 11. > > Dani: Can you do a quick re-test on it. I also fixed the assertion issue. Done. Worked fine. > Does this change need a re-approval? No, I approve to fix it for RC2, but someone needs to do a code review. Tom, could you do that?
Gerrit change https://git.eclipse.org/r/133258 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=74d4e827d0c5052420cfea9fd08429b902abd487
Thanks everyone!
(In reply to Dani Megert from comment #26) > Thanks everyone! Thanks also from my side.
(In reply to Dani Megert from comment #8) > (In reply to Matthias Becker from comment #7) > > (In reply to Dani Megert from comment #6) > > > Yes, in some future release. > > Releases of Eclipse of JDK? > > Yes. Those warnings come form there. Initially, it was planned to deny > access when modules were introduced with Java 9. But there were massive > objections from the users. > With --illegal-access=warn I could find out what the illegal accesses are: WARNING: Illegal reflective access by org.eclipse.urischeme.internal.registration.WinRegistry (file:/C:/EclipseIDE/target/eclipse/../../../git/eclipse.platform.ui/bundles/org.eclipse.urischeme/) to method java.util.prefs.WindowsPreferences.stringToByteArray(java.lang.String) WARNING: Illegal reflective access by org.eclipse.urischeme.internal.registration.WinRegistry (file:/C:/EclipseIDE/target/eclipse/../../../git/eclipse.platform.ui/bundles/org.eclipse.urischeme/) to method java.util.prefs.WindowsPreferences.toJavaValueString(byte[]) WARNING: Illegal reflective access by org.eclipse.urischeme.internal.registration.WinRegistry (file:/C:/EclipseIDE/target/eclipse/../../../git/eclipse.platform.ui/bundles/org.eclipse.urischeme/) to method java.util.prefs.WindowsPreferences.openKey(byte[],int,int) WARNING: Illegal reflective access by org.eclipse.urischeme.internal.registration.WinRegistry (file:/C:/EclipseIDE/target/eclipse/../../../git/eclipse.platform.ui/bundles/org.eclipse.urischeme/) to method java.util.prefs.WindowsPreferences.closeKey(long) WARNING: Illegal reflective access by org.eclipse.urischeme.internal.registration.WinRegistry (file:/C:/EclipseIDE/target/eclipse/../../../git/eclipse.platform.ui/bundles/org.eclipse.urischeme/) to method java.util.prefs.WindowsPreferences.WindowsRegQueryValueEx(long,byte[]) WARNING: Illegal reflective access by org.eclipse.urischeme.internal.registration.WinRegistry (file:/C:/EclipseIDE/target/eclipse/../../../git/eclipse.platform.ui/bundles/org.eclipse.urischeme/) to method java.util.prefs.WindowsPreferences.WindowsRegSetValueEx1(long,byte[],byte[]) WARNING: Illegal reflective access by org.eclipse.urischeme.internal.registration.WinRegistry (file:/C:/EclipseIDE/target/eclipse/../../../git/eclipse.platform.ui/bundles/org.eclipse.urischeme/) to method java.util.prefs.WindowsPreferences.WindowsRegDeleteKey(long,byte[] Adding --add-opens java.prefs/java.util.prefs=ALL-UNNAMED does silence the warnings. Do we already know a timeline when these accesses will no longer be possible?
(In reply to Matthias Becker from comment #28) > Do we already know a timeline when these accesses will no longer be possible? No. So far no date/release has been specified, and I have not seen any announcement for Java 12 (March 2019). So, I presume at least not before Java 13 (September 2019).
(In reply to Dani Megert from comment #29) > (In reply to Matthias Becker from comment #28) > > Do we already know a timeline when these accesses will no longer be possible? > > No. So far no date/release has been specified, and I have not seen any > announcement for Java 12 (March 2019). So, I presume at least not before > Java 13 (September 2019). Do we have other places in platform where "Illegal reflective access" is done? That needs to be reworked once they are no longer possible?
(In reply to Matthias Becker from comment #30) > (In reply to Dani Megert from comment #29) > > (In reply to Matthias Becker from comment #28) > > > Do we already know a timeline when these accesses will no longer be possible? > > > > No. So far no date/release has been specified, and I have not seen any > > announcement for Java 12 (March 2019). So, I presume at least not before > > Java 13 (September 2019). > > Do we have other places in platform where "Illegal reflective access" is > done? That needs to be reworked once they are no longer possible? Some got fixed a while ago. I haven't seen anything lately except the one reported in this bug report.
(In reply to Dani Megert from comment #31) > (In reply to Matthias Becker from comment #30) > > (In reply to Dani Megert from comment #29) > > > (In reply to Matthias Becker from comment #28) > > > > Do we already know a timeline when these accesses will no longer be possible? > > > > > > No. So far no date/release has been specified, and I have not seen any > > > announcement for Java 12 (March 2019). So, I presume at least not before > > > Java 13 (September 2019). > > > > Do we have other places in platform where "Illegal reflective access" is > > done? That needs to be reworked once they are no longer possible? > > Some got fixed a while ago. I haven't seen anything lately except the one > reported in this bug report. So I will set fixing this on my todo list.
Gerrit change https://git.eclipse.org/r/133287 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=c6ee3fcc6ae6ce51c7ce2fca1751e86876bfdc7d
