Community
Participate
Working Groups
(Originally discovered in bug 540357#c1, some background is in 540357#c2) While this should only happen when linking against 10.14 SDK, it also happens when setting <key>NSRequiresAquaSystemAppearance</key><false/> in the Info.plist and maybe other situations (users have reported it in 540160#c12 and 540081#c2)
[repeated with clickable comment references:] (Originally discovered in bug 540357 comment 1, some background is in 540357 comment 2) While this should only happen when linking against 10.14 SDK, it also happens when setting <key>NSRequiresAquaSystemAppearance</key><false/> in the Info.plist and maybe other situations (users have reported it in 540160 comment 12 and 540081 comment 2)
[repeated with clickable comment references:] (Originally discovered in bug 540357 comment 1, some background is in bug 540357 comment 2) While this should only happen when linking against 10.14 SDK, it also happens when setting <key>NSRequiresAquaSystemAppearance</key><false/> in the Info.plist and maybe other situations (users have reported it in bug 540160 comment 12 and bug 540081 comment 2)
Some notes about the linked Gerrit https://git.eclipse.org/r/132638 are in bug 540357 comment 2
Some notes about the linked Gerrit https://git.eclipse.org/r/132638 are in bug 540357 comment 7
*** Bug 542076 has been marked as a duplicate of this bug. ***
Also reported in Bug 487922 comment 9
*** Bug 543648 has been marked as a duplicate of this bug. ***
@Till, Thanks for creating a separate bug for this. Had a couple of questions. When window.graphicsContext() returns null, graphics context from ImageRep is created. Is GC drawing expected to work with this context? I tried this with a Snippet by setting the context to null, but nothing was drawn. Is it the right way to test?
(In reply to Lakshmi Shanmugam from comment #8) > @Till, > Thanks for creating a separate bug for this. > Had a couple of questions. When window.graphicsContext() returns null, > graphics context from ImageRep is created. Is GC drawing expected to work > with this context? I tried this with a Snippet by setting the context to > null, but nothing was drawn. Is it the right way to test? No, this is only useful outside drawing operations, e.g. to compute text width (IIRC this is for example needed for computing the width of view tabs)
Gerrit change https://git.eclipse.org/r/132638 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=0daa8702b7a82e99f264cd1ef41f61438541bad1
(In reply to Eclipse Genie from comment #10) > Gerrit change https://git.eclipse.org/r/132638 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=0daa8702b7a82e99f264cd1ef41f61438541bad1 Released for 4.12M3 (Again I'd like to point out that this is not a complete solutions to run linked against 10.14 SDK because of the redrawing problems mentioned bug 540357 comment 7)
Verified by code inspection in I20190520-1805.
Hi Till, After using latest SWT 4.12 M3, NPE issue is not there but I am getting below issue while opening composite component org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.NoClassDefFoundError: org/eclipse/swt/custom/TableTreeItem) at org.eclipse.swt.SWT.error(SWT.java:4699) at org.eclipse.swt.SWT.error(SWT.java:4614) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:188) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4103) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3770) at org.eclipse.jface.window.Window.runEventLoop(Window.java:825) at org.eclipse.jface.window.Window.open(Window.java:801) at com.sap.mcm.gui.login.LoginController.showLoginPage(LoginController.java:375) at com.sap.mcm.gui.login.LoginController.access$500(LoginController.java:95) at com.sap.mcm.gui.login.LoginController$1$2.run(LoginController.java:225) 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:4103) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3770) at com.sap.mcm.gui.login.LoginController.stopWaitCursor(LoginController.java:951) at com.sap.mcm.gui.login.LoginController.startLogin(LoginController.java:235) at com.sap.mcm.gui.login.LoginController.startLogin(LoginController.java:154) at com.sap.mcm.gui.SAPMobileDocumentsClient.handleClientArgumentsAndLogin(SAPMobileDocumentsClient.java:249) at com.sap.mcm.gui.SAPMobileDocumentsClient.main(SAPMobileDocumentsClient.java:126) Caused by: java.lang.NoClassDefFoundError: org/eclipse/swt/custom/TableTreeItem at org.eclipse.jface.util.OpenStrategy.initializeHandler(OpenStrategy.java:281) at org.eclipse.jface.util.OpenStrategy.<init>(OpenStrategy.java:119) at org.eclipse.jface.viewers.StructuredViewer.hookControl(StructuredViewer.java:1234) at org.eclipse.jface.viewers.ComboViewer.<init>(ComboViewer.java:88) at com.sap.mcm.swt.sync.configuration.LogOnModesLayout.addCertificateMode(LogOnModesLayout.java:268) at com.sap.mcm.swt.sync.configuration.LogOnModesLayout.createLayout(LogOnModesLayout.java:113) at com.sap.mcm.swt.sync.configuration.LoginPanel.changeToLogonModesLayout(LoginPanel.java:423) at com.sap.mcm.swt.sync.configuration.LoginPanel.access$1100(LoginPanel.java:54) at com.sap.mcm.swt.sync.configuration.LoginPanel$5$1$1.run(LoginPanel.java:328) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185) ... 16 more Caused by: java.lang.ClassNotFoundException: org.eclipse.swt.custom.TableTreeItem at java.net.URLClassLoader.findClass(URLClassLoader.java:444) at java.lang.ClassLoader.loadClass(ClassLoader.java:486) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:378) at java.lang.ClassLoader.loadClass(ClassLoader.java:419) ... 27 more We use jFace as well, do I need to update it as well? Or any idea why I am getting this issue.
(In reply to Dinesh Vijay from comment #13) > Hi Till, > > After using latest SWT 4.12 M3, NPE issue is not there but I am getting > below issue while opening composite component > > org.eclipse.swt.SWTException: Failed to execute runnable > (java.lang.NoClassDefFoundError: org/eclipse/swt/custom/TableTreeItem) > at org.eclipse.swt.SWT.error(SWT.java:4699) > at org.eclipse.swt.SWT.error(SWT.java:4614) Adding @Lars as cc, has it has removed that in Bug 475833. I guess that yes, you need top update jface as well.
(In reply to Till Brychcy from comment #14) > Adding @Lars as cc, has it has removed that in Bug 475833. should have been: ...as he removed that....
(In reply to Till Brychcy from comment #15) > (In reply to Till Brychcy from comment #14) > > Adding @Lars as cc, has it has removed that in Bug 475833. > should have been: > ...as he removed that.... SAPMobileDocumentsClient indicates that it is customer code. SAP needs to adjust their coding. @Dinesh, please contact the SAP development team to fix that.
(In reply to Lars Vogel from comment #16) > (In reply to Till Brychcy from comment #15) > > (In reply to Till Brychcy from comment #14) > > > Adding @Lars as cc, has it has removed that in Bug 475833. > > should have been: > > ...as he removed that.... > > SAPMobileDocumentsClient indicates that it is customer code. SAP needs to > adjust their coding. > > @Dinesh, please contact the SAP development team to fix that. Look closely, I think this CAN be solved by upgrading jface: Caused by: java.lang.NoClassDefFoundError: org/eclipse/swt/custom/TableTreeItem at org.eclipse.jface.util.OpenStrategy.initializeHandler(OpenStrategy.java:281) at org.eclipse.jface.util.OpenStrategy.<init>(OpenStrategy.java:119) at org.eclipse.jface.viewers.StructuredViewer.hookControl(StructuredViewer.java:1234) at org.eclipse.jface.viewers.ComboViewer.<init>(ComboViewer.java:8
(In reply to Till Brychcy from comment #17) > Look closely, I think this CAN be solved by upgrading jface: > > Caused by: java.lang.NoClassDefFoundError: > org/eclipse/swt/custom/TableTreeItem > at > org.eclipse.jface.util.OpenStrategy.initializeHandler(OpenStrategy.java:281) > at org.eclipse.jface.util.OpenStrategy.<init>(OpenStrategy.java:119) > at > org.eclipse.jface.viewers.StructuredViewer.hookControl(StructuredViewer.java: > 1234) > at org.eclipse.jface.viewers.ComboViewer.<init>(ComboViewer.java:8 Do you mean that we should catch that this NoClassDefFoundError in JFace? I don't think this will make SAPMobileDocumentsClient work, so I not in favor of this.
Adding Sebastian from the SAP ABAP team. He may know the right person to contact.
(In reply to Lars Vogel from comment #18) > > Do you mean that we should catch that this NoClassDefFoundError in JFace? I > don't think this will make SAPMobileDocumentsClient work, so I not in favor > of this. No I meant if he upgrades SWT, he needs to upgrade JFace, too.
(In reply to Till Brychcy from comment #20) > (In reply to Lars Vogel from comment #18) > > > > Do you mean that we should catch that this NoClassDefFoundError in JFace? I > > don't think this will make SAPMobileDocumentsClient work, so I not in favor > > of this. > > No I meant if he upgrades SWT, he needs to upgrade JFace, too. I guess we need update lovest version range for SWT in JFace, so that one can't update only JFace.
(In reply to Andrey Loskutov from comment #21) > (In reply to Till Brychcy from comment #20) > > (In reply to Lars Vogel from comment #18) > > > > > > Do you mean that we should catch that this NoClassDefFoundError in JFace? I > > > don't think this will make SAPMobileDocumentsClient work, so I not in favor > > > of this. > > > > No I meant if he upgrades SWT, he needs to upgrade JFace, too. > > I guess we need update lovest version range for SWT in JFace, so that one > can't update only JFace. The problem is that the *newer* SWT is not compatible with the old jface, which is pretty bad, given that users may want to try to just updated swt in an older installation to make it run with new operation system version. Maybe it would be better to revert Bug 475833 (or at least restore some stub classes for the removed swt classes so old usages that are guarded by "instanceof" continue to work, because this will never be true)
(In reply to Till Brychcy from comment #22) > (In reply to Andrey Loskutov from comment #21) > > (In reply to Till Brychcy from comment #20) > > > (In reply to Lars Vogel from comment #18) > > > > > > > > Do you mean that we should catch that this NoClassDefFoundError in JFace? I > > > > don't think this will make SAPMobileDocumentsClient work, so I not in favor > > > > of this. > > > > > > No I meant if he upgrades SWT, he needs to upgrade JFace, too. > > > > I guess we need update lovest version range for SWT in JFace, so that one > > can't update only JFace. > > The problem is that the *newer* SWT is not compatible with the old jface, > which is pretty bad, given that users may want to try to just updated swt in > an older installation to make it run with new operation system version. > Maybe it would be better to revert Bug 475833 (or at least restore some stub > classes for the removed swt classes so old usages that are guarded by > "instanceof" continue to work, because this will never be true) -1 for stub classes as this still will not make client code work. -1 for revert as we have a clearly defined api removal process and in this case we even waited a few years longer.
(In reply to Lars Vogel from comment #23) > -1 for stub classes as this still will not make client code work. -1 for Why do you think it will not work IF NO INSTANCES OF THE DEPRECATED CLASSES CAN ACTUALLY BE CREATED? > revert as we have a clearly defined api removal process and in this case we > even waited a few years longer. Then I guess the process should be improved. I think in this specific case we should first remove all references outside swt and in a later remove remove the actual classes from swt.
(In reply to Till Brychcy from comment #24) > Then I guess the process should be improved. > I think in this specific case we should first remove all references > outside swt and in a later remove remove the actual classes from swt. The bad client still could try to use incompatible JFace / SWT versions, so what is the point? I have no IDE yet, but if JFace manifest does not enforce new SWT we should fix this for RC1. We had already similar problems with other "connected" bundles where Oomph/p2 decided to allow to update only one and caused CNF errrors at runtime. Lars, please check this and provide a patch if the new JFace allows to be used with old SWT.
Andrey, will do tomorrow.
(In reply to Andrey Loskutov from comment #25) > (In reply to Till Brychcy from comment #24) > > Then I guess the process should be improved. > > I think in this specific case we should first remove all references > > outside swt and in a later remove remove the actual classes from swt. > > The bad client still could try to use incompatible JFace / SWT versions, so > what is the point? The bad client here is a good client that doesn't use the deprecated classes at all but simply a previous jface version that is broken by the newer swt version.
Till, IIRC JFace re-exports SWT so if we enforce the correct minimum range in JFace, it should work correctly. Or do you see more problems?
(In reply to Lars Vogel from comment #28) > Till, IIRC JFace re-exports SWT so if we enforce the correct minimum range > in JFace, it should work correctly. Or do you see more problems? Again, the problem is that we're (probably unnecessarily) making SWT incompatible with older JFace, not the other way around. So users with new SWT also need new JFace. Are we at least sure that users can upgrade just SWT + JFace or does the updated JFace possibly depend on other updated components?
For 4.13 we could restrict JFace to only exact SWT minor version to avoid such fails later, if it is not done already.
The correct way would have been to upgrade the major version of SWT but this was rejected by the community and the PMC.
(In reply to Lars Vogel from comment #16) > (In reply to Till Brychcy from comment #15) > > (In reply to Till Brychcy from comment #14) > > > Adding @Lars as cc, has it has removed that in Bug 475833. > > should have been: > > ...as he removed that.... > > SAPMobileDocumentsClient indicates that it is customer code. SAP needs to > adjust their coding. > > @Dinesh, please contact the SAP development team to fix that. Hi Lars, SAPMobileDocumentClient is our main class from where we are loading SWT+JFACE component. There is no custom code involve here. Please ignore that class. Can you please let me know the exact version of jFace which will be compatible with new SWT Or should I wait for patch release?
Hi, The above error I got when I run my application using eclipse which uses(SWT 4.12 M3 and Jface 3.7.0 as dependency). Thanks, Dinesh Vijay
(In reply to Lars Vogel from comment #26) > Andrey, will do tomorrow. Done via Bug 547720 as it does not closely relate to this issue.
(In reply to Andrey Loskutov from comment #30) > For 4.13 we could restrict JFace to only exact SWT minor version to avoid > such fails later, if it is not done already. That would prevent customer to use compatible versions of future SWT with older JFace version and would also be wrong.
(In reply to Dinesh Vijay from comment #33) > Hi, > > The above error I got when I run my application using eclipse which uses(SWT > 4.12 M3 and Jface 3.7.0 as dependency). > > Thanks, > Dinesh Vijay Hi Dinesh, to use the SWT from the 4.12 stream, you need to also use JFace from the same stream, as we removed API in SWT via Bug 475833. So to use latest SWT (currently version 3.110.100) you need to use JFace in version 3.16.0 or higher. The removal of API is a breaking change and older plug-ins which use SWT are not guaranteed to continue to work with it. Following the semantic versioning we could have increased the major version of SWT and plug-ins which reexports SWT like JFace, but it was decided that this would do even more harm. If you check Bug 475833 you will see that several other plug-ins are also affected as well as downstream plug-ins as EMF, so best is to upgrade all your platform and EMF plug-ins. P.S. Sorry Till for not getting your point earlier. Reading bugs on a mobile device after work hours turned out not to optimal.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/175281
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/175281 was merged to [R4_6_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=42ca99853e2e6ec872b4a40a1d22ef8a6fb9a538
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/178518
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/178518 was merged to [R4_8_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=edc5377c5e0e73916fdfbffb3dd14ca40cee93f9
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/183780
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/183780 was merged to [R4_7_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=466ea05266b8141cd1d79569883ad34204237ef2
