This Bugzilla instance is deprecated, and most Eclipse projects now use GitHub or Eclipse GitLab. Please see the deprecation plan for details.
Bug 435488 - java.lang.NoSuchMethodError: org.eclipse.e4.ui.css.swt.helpers.EclipsePreferencesHelper.getOverriddenPropertyNames(Lorg/eclipse/core/runtime/preferences/IEclipsePreferences;)Ljava/util/List;
Summary: java.lang.NoSuchMethodError: org.eclipse.e4.ui.css.swt.helpers.EclipsePrefere...
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.4   Edit
Hardware: All All
: P3 blocker (vote)
Target Milestone: 4.4 RC2   Edit
Assignee: Daniel Rolka CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 435489 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-05-22 05:32 EDT by Dani Megert CLA
Modified: 2014-05-22 16:09 EDT (History)
6 users (show)

See Also:
daniel_megert: review+
Lars.Vogel: review+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Dani Megert CLA 2014-05-22 05:32:59 EDT 
!ENTRY org.eclipse.osgi 4 0 2014-05-22 11:31:45.580
!MESSAGE Application error
!STACK 1
java.lang.NoSuchMethodError: org.eclipse.e4.ui.css.swt.helpers.EclipsePreferencesHelper.getOverriddenPropertyNames(Lorg/eclipse/core/runtime/preferences/IEclipsePreferences;)Ljava/util/List;
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$StylingPreferencesHandler.getOverriddenPropertyNames(PartRenderingEngine.java:1491)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$StylingPreferencesHandler.resetOverriddenPreferences(PartRenderingEngine.java:1477)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$StylingPreferencesHandler.resetOverriddenPreferences(PartRenderingEngine.java:1471)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$StylingPreferencesHandler$1.handleEvent(PartRenderingEngine.java:1458)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4353)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4346)
	at org.eclipse.swt.widgets.Display.release(Display.java:3807)
	at org.eclipse.swt.graphics.Device.dispose(Device.java:295)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:151)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:379)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:233)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:483)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
Comment 1 Dani Megert CLA 2014-05-22 05:51:41 EDT 
This happens when not using APIs and ignoring discouraged access warnings. And, to make thinggs worse,
org.eclipse.e4.ui.css.swt.helpers.EclipsePreferencesHelper
is give the impression to not be internal, but it currently is:
org.eclipse.e4.ui.css.swt.helpers;x-internal:=true,
and hence no API Tools error was thrown when

org.eclipse.e4.ui.css.swt.helpers.EclipsePreferencesHelper.getOverriddenPropertyNames(IEclipsePreferences)
was changed to:
org.eclipse.e4.ui.css.swt.helpers.EclipsePreferencesHelper.getOverriddenPropertyNames(Preferences)
in a binary incompatible way.

This was done with the fix for bug 434485.
Comment 2 Dani Megert CLA 2014-05-22 05:54:13 EDT 
Steps to reproduce: start new workspace with I20140521-2000.
Comment 3 Arun Thondapu CLA 2014-05-22 06:06:18 EDT 
This is probably causing bug 435489 as well.
Comment 4 Paul Webster CLA 2014-05-22 06:40:30 EDT 
The change to the method signature was source compatible but not binary compatible.

It was done to handle the pref change event in org.eclipse.e4.ui.css.swt.helpers.EclipsePreferencesHelper.PreferenceOverriddenByCssChangeListener.removeOverriddenByCssProperty(PreferenceChangeEvent)

There are 2 options to fix:

1) revert the method signatures in EclipsePreferencesHelper and change removeOverriddenByCssProperty to:

protected void removeOverriddenByCssProperty(PreferenceChangeEvent event) {
	Preferences node = event.getNode();
	if (node instanceof IEclipsePreferences) {
		EclipsePreferencesHelper.removeOverriddenByCssProperty(
				(IEclipsePreferences) node, event.getKey());
	}
}


2) touch the forceContextQualifier in org.eclipse.e4.ui.workbench.swt.  This was the only bundle effected by the change.

Daniel is preparing the patch for option 1.
Comment 5 Paul Webster CLA 2014-05-22 06:46:23 EDT 
(In reply to Paul Webster from comment #4)
> 
> 2) touch the forceContextQualifier in org.eclipse.e4.ui.workbench.swt.  This
> was the only bundle effected by the change.

For option 2, it effects org.eclipse.e4.ui.tests.css.swt as well.

PW
Comment 6 Paul Webster CLA 2014-05-22 06:46:54 EDT 
Dani, do you have a preference?  Option 1 is more correct, but Option 2 is less risky.

PW
Comment 7 Daniel Rolka CLA 2014-05-22 06:49:19 EDT 
The patch for the build issue: https://git.eclipse.org/r/#/c/27100/

Daniel
Comment 8 David Williams CLA 2014-05-22 06:59:57 EDT 
(In reply to Paul Webster from comment #5)
> (In reply to Paul Webster from comment #4)
> > 
> > 2) touch the forceContextQualifier in org.eclipse.e4.ui.workbench.swt.  This
> > was the only bundle effected by the change.
> 
> For option 2, it effects org.eclipse.e4.ui.tests.css.swt as well.
> 
> PW

What makes you think it effects e4.ui.tests.css.swt as well? I ask because it did not show up in "unanticipated comparator errors" log ... so ... wondering if there's something wrong with our "log parser"? 

http://download.eclipse.org/eclipse/downloads/drops4/I20140521-2000/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt
Comment 9 Paul Webster CLA 2014-05-22 07:02:23 EDT 
(In reply to David Williams from comment #8)
> 
> What makes you think it effects e4.ui.tests.css.swt as well? I ask because
> it did not show up in "unanticipated comparator errors" log ... so ...
> wondering if there's something wrong with our "log parser"? 

Only that plugin uses the method in question as well.  It might not have been a problem in the comparator log, if the test plugin changed in the same build.  But if we switch the signature back, then we need to touch all uses of that method or we'd have the same problem with the test plugin :-)


PW
Comment 10 Dani Megert CLA 2014-05-22 07:17:37 EDT 
(In reply to Paul Webster from comment #6)
> Dani, do you have a preference?  Option 1 is more correct, but Option 2 is
> less risky.
> 
> PW

Definitely option 1. And I'd claim that it is the less risky fix given other clients outside the SDK might already (illegally though) use this method (even though it was added after the API freeze).
Comment 11 Daniel Rolka CLA 2014-05-22 07:19:08 EDT 
(In reply to Daniel Rolka from comment #7)
> The patch for the build issue: https://git.eclipse.org/r/#/c/27100/
> 
> Daniel

I'm just wondering why it was build properly by the Gerrit's build. I though that we have both builds synchronized. I agree, we skipped the API tooling warning, but there are plenty of the warnings and the new ones can get ignored accidently.
I think it should be verified by the Gerrit's integration build.

Daniel
Comment 13 Dani Megert CLA 2014-05-22 07:25:31 EDT 
(In reply to Daniel Rolka from comment #11)
> (In reply to Daniel Rolka from comment #7)
> > The patch for the build issue: https://git.eclipse.org/r/#/c/27100/
> > 
> > Daniel
> 
> I'm just wondering why it was build properly by the Gerrit's build. 

Because the build builds all bundles and the change was source compatible. Also our build does that but when the input is the same as in the previous build, it throws away the new build and reports the difference in the comparator log.
Comment 14 Dani Megert CLA 2014-05-22 07:27:29 EDT 
(In reply to Paul Webster from comment #9)
> (In reply to David Williams from comment #8)
> > 
> > What makes you think it effects e4.ui.tests.css.swt as well? I ask because
> > it did not show up in "unanticipated comparator errors" log ... so ...
> > wondering if there's something wrong with our "log parser"? 
> 
> Only that plugin uses the method in question as well.  It might not have
> been a problem in the comparator log, if the test plugin changed in the same
> build.  But if we switch the signature back, then we need to touch all uses
> of that method or we'd have the same problem with the test plugin :-)

Not sure how useful that test plug-in really is, given it didn't cause a single failure. LOL!
Comment 15 Dani Megert CLA 2014-05-22 07:31:02 EDT 
Lars, thanks for reviewing the Gerrit change. Can you please also set the review flag in this bug report? Thanks.
Comment 16 Paul Webster CLA 2014-05-22 08:10:26 EDT 
I've also pushed a forceContextQualifier.txt change as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=2c3a6d99e79bd9adc0ca649cd41ab3161b15e539

org.eclipse.e4.ui.tests.css.swt_0.9.1.v20140521-1754.jar contains the signature change so needs a re-compile.

PW
Comment 17 Paul Webster CLA 2014-05-22 08:31:29 EDT 
*** Bug 435489 has been marked as a duplicate of this bug. ***
Comment 18 Dani Megert CLA 2014-05-22 16:09:10 EDT 
Verified in I20140522-1330.