Community
Participate
Working Groups
Created attachment 265385 [details] Log file Steps to reproduce: 1) Run Eclipse Installer (using JDK 1.8 64-bit) in Advanced Mode 2) Choose "Eclipse IDE for Eclipse Committers" 3) Produce Version Latest (Oxygen) -- same with Neon AFAICT 4) On Projects, choose SWT 5) Next until Finish 6) Eclipse downloads and runs 7) While splash screen still showing, and progress bar about 1/3rd, Eclipse dies with the log as attached (snippets below). Now on further investigation, If I skip out step 4 above (don't provision SWT) then Eclipse runs fine. Withing the running Eclipse I: 1) have nearly nothing in the log (see attachment to follow) 2) do File | Import | Projects into Workspace 3) Choose SWT, Next, Next, Finish 4) Opem Oomph progress, Wait until install needs to restart (captured log at this point, attachment to follow) 5) Press Finish 6) Eclipse fails to start with the same errors as the case above. I am able to provision, for example, Platform UI with the above methods (in a new Eclipse install). Some (I think) key snippets from the log: !ENTRY org.eclipse.ui 4 0 2016-11-16 19:02:46.240 !MESSAGE Unhandled event loop exception !STACK 0 org.eclipse.core.runtime.AssertionFailedException: null argument: at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:85) at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:73) at org.eclipse.jface.resource.ColorRegistry.put(ColorRegistry.java:293) at org.eclipse.jface.resource.ColorRegistry.put(ColorRegistry.java:272) at org.eclipse.ui.internal.themes.ThemeElementHelper.installColor(ThemeElementHelper.java:332) at org.eclipse.ui.internal.themes.ThemeElementHelper.populateRegistry(ThemeElementHelper.java:193) at org.eclipse.ui.internal.Workbench$28.runWithException(Workbench.java:1794) at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:32) at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:233) at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:144) at org.eclipse.swt.widgets.Display.syncExec(Display.java:4892) at org.eclipse.ui.internal.StartupThreading.runWithoutExceptions(StartupThreading.java:95) at org.eclipse.ui.internal.Workbench.initializeApplicationColors(Workbench.java:1788) at org.eclipse.ui.internal.Workbench.init(Workbench.java:1682) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2945) at org.eclipse.ui.internal.Workbench.access$9(Workbench.java:2876) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:685) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:610) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:138) 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:388) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243) 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:498) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:673) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:610) at org.eclipse.equinox.launcher.Main.run(Main.java:1519) !ENTRY org.eclipse.core.jobs 2 2 2016-11-16 19:02:47.698 !MESSAGE Job found still running after platform shutdown. Jobs should be canceled by the plugin that scheduled them during shutdown: org.eclipse.ui.internal.activities.MutableActivityManager$3$1
Created attachment 265386 [details] Log file from before installing SWT with Oomph
Created attachment 265387 [details] Log of what Oomph did when I imported SWT project
Starting the now broken Eclipse installation but selecting a new workspace causes the problem too. That implies the problem is not corruption of the workspace.
(In reply to Jonah Graham from comment #3) > Starting the now broken Eclipse installation but selecting a new workspace > causes the problem too. That implies the problem is not corruption of the > workspace. Jahan, can you attach the log with the error happening at startup?
(In reply to Andrey Loskutov from comment #4) > Jahan I'm sorry Jonah, this was keyboard word completon, not me
Created attachment 265388 [details] log on clean workspace with broken eclipse (In reply to Andrey Loskutov from comment #4) > (In reply to Jonah Graham from comment #3) > > Starting the now broken Eclipse installation but selecting a new workspace > > causes the problem too. That implies the problem is not corruption of the > > workspace. > > Jahan, can you attach the log with the error happening at startup? Attached.
As far as I can tell the log looks the same with the same exception.
Created attachment 265389 [details] Log file on linux showing the same thing. OK, I have tried on Linux (XUbuntu 16.04) and the same thing happens, so not Windows specific (edited summary to reflect). I have attached the log file on Linux.
I experienced the same behavior on Windows 7. I did some experiments with installing in previous releases: - Installing on Neon.1 gives errors, and fails to start. - Installing on Mars.2 seems to work fine.
ThemeElementHelper.installColor looks like it may be missing a null check. One of the branches calls this: prefColor = registry.getRGB(definition.getDefaultsTo()); ...which returns a @Nullable. It then passes the result directly to registry.put, which can't accept null.
New Gerrit change created: https://git.eclipse.org/r/85186
I've attached a possible fix. I call it a possible fix since I can't reproduce the problem and only wrote this patch using static code analysis. If any of you have the ability to reproduce the issue, could you kindly let me know if this patch addresses it?
The critical problem, Eclipse does not start up, is resolved by Stefan's patch. However, the NPE was simply exposing very visibly the underlying problem. I ended up with incompatible versions of JDT and Platfor by using SWT Oomph's setup, m. When I provision Eclipse for Committers I end up with these two key bundle versions: org.eclipse.jdt.ui [3.13.0.v20161018-1320] org.eclipse.ui [3.109.0.v20161017-1617] However, after provisioning SWT development with Oomph, oomph upgrades o.e.jdt.ui, but not o.e.ui. So I end up with: org.eclipse.jdt.ui [3.13.0.v20161111-1334] org.eclipse.ui [3.109.0.v20161017-1617] One of the changes in JDT UI between those two versions was done by Bug 501742 which changed the defaultsTo for org.eclipse.jdt.ui.Javadoc.backgroundColor to org.eclipse.ui.workbench.HOVER_BACKGROUND (the next iteration through the loop does the same for foreground) The problem is that org.eclipse.ui.workbench.HOVER_BACKGROUND was introduced in Bug 505738 and after org.eclipse.ui [3.109.0.v20161017-1617] was created. Therefore the NPE is exposed because the color's default color does not exist. The fix is to use the default-default color of black. Now with the NPE resolved, what I end up with in the UI is completely broken Javadoc hovers as both foreground and background are black. This leaves me with a few questions that need resolving: 1) Why does SWT oomph setup install a newer JDT version? 2) Should the newer JDT version have caused o.e.ui to be updated too? 3) Should o.e.ui have a minor version bump because of the introduction of new color defintions? 4) Should JDT be dependent on the newer version?
Gerrit change https://git.eclipse.org/r/85186 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=df4ae3de868779fcdf44049b1662ece3ba11fa12
> When I provision Eclipse for Committers I end up with these two key Yes, we observed a lot of problems using Eclipse for Committers with the weekly integration update site (see bug 500481). This is why I updated the setup instructions to recommend the use of Eclipse Platform rather than Eclipse for Committers: http://wiki.eclipse.org/Platform_UI/How_to_Contribute Personally, I wish we could remove the page that lets you select an Eclipse product and just have the project script select the correct product (which, in this case, is Eclipse Platform).
I think I understand better, there appears to be a bug in Oomph/p2/swt setup that it fails to upgrade o.e.ui when Committers is used, but does upgrade when Platform is used. IMHO there is also still some dependency problem related to o.e.jdt.ui requiring a newer o.e.ui, but that dependency is not reflected in Bundle version/requires. Finally, as you had mentioned in https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg31346.html I was trying to follow your suggestion of not reconfiguring my development IDE to be able to provision SWT.
(In reply to Jonah Graham from comment #16) > IMHO there is also still some dependency problem related to o.e.jdt.ui > requiring a newer o.e.ui, but that dependency is not reflected in Bundle > version/requires. Actually Sergey already said that: (In reply to Sergey Prigogin from Bug 505738 comment #42) > (In reply to Leo Ufimtsev from Bug 505738 comment #41) > > Do you think it would have been more appropriate > > to raise version dependency to ensure that both modules had correct minimum > > versions? > > Yes.
Jonah, if you understand what's wrong with the dependencies, can you fix them?
(In reply to Stefan Xenos from comment #18) > Jonah, if you understand what's wrong with the dependencies, can you fix > them? Leo is looking at that now AFAIK. I will monitor that and contribute where I can.
(In reply to Jonah Graham from comment #19) > (In reply to Stefan Xenos from comment #18) > > Jonah, if you understand what's wrong with the dependencies, can you fix > > them? > > Leo is looking at that now AFAIK. I will monitor that and contribute where I > can. I usually work on SWT, don't know much about platform or plugin dependencies. (If someone is knows their way around those and wants to work on those, by all means...). But I could investigate also. Should I try to bump org.eclipse.ui to 3.10 and make org.eclipse.jdt depend on 3.10 to fix this?
(In reply to Leo Ufimtsev from comment #20) > (In reply to Jonah Graham from comment #19) > > (In reply to Stefan Xenos from comment #18) > > > Jonah, if you understand what's wrong with the dependencies, can you fix > > > them? > > > > Leo is looking at that now AFAIK. I will monitor that and contribute where I > > can. > > I usually work on SWT, don't know much about platform or plugin > dependencies. (If someone is knows their way around those and wants to work > on those, by all means...). But I could investigate also. > Should I try to bump org.eclipse.ui to 3.10 and make org.eclipse.jdt depend > on 3.10 to fix this? As it turns out org.eclipse.ui had version incremented already in Oxygen, so a per Bug 507823 (https://git.eclipse.org/r/#/c/85351/) it cannot be upgraded again. I have submitted for consideration increment of dependency on the new API in Bug 507824. However, that still means that different milestones can go wrong, with no indication as to the version problem as that is not expressible with current versioning rules.
(In reply to Jonah Graham from comment #13) > This leaves me with a few questions that need resolving: > 1) Why does SWT oomph setup install a newer JDT version? So the above is the only open question that there seems to be a resolution for. It should be noted that if Platform UI is provisioned, you get latest Milestone JDT, but if SWT is provisioned you get I-build JDT.
(In reply to Jonah Graham from comment #21) > I have submitted for consideration increment of dependency on the new API in Thank you for that patch. If I understand correctly, then no further version changes or dependencies need to be done in platform.ui or JDT.
(In reply to Leo Ufimtsev from comment #23) > (In reply to Jonah Graham from comment #21) > > > I have submitted for consideration increment of dependency on the new API in > > Thank you for that patch. If I understand correctly, then no further version > changes or dependencies need to be done in platform.ui or JDT. AFAIK that is correct. What is unfortunate is that there is no valid way of representing this dependency with the current versioning rules. i.e. 2 new APIs introduced in Oxygen dev cycle only allows (logically) one increment of minor version number. But that means that plug-ins that depend on the second introduced API have no way of representing that dependency. If anyone knows if there is a solution to the above, then please inform me (e.g. can we increment the patch version of the plug-in for each new API introduced during one development cycle?)
(In reply to Jonah Graham from comment #24) > If anyone knows if there is a solution to the above, then please inform me > (e.g. can we increment the patch version of the plug-in for each new API > introduced during one development cycle?) The Semantic Versioning Specification, https://semver.org/, defines an versioning element 'pre-release'. This is defined to handle version changes while developing the next release. Incorporating this kind of schema while developing, and removing the pre-release version elements in the specifications and dependencies when the API is frozen, might work. However, the OSGi versioning specification does not define pre-release version element. So this will way of working will break OSGi compatibility. Though, p2 might be able to handle the pre-release elements as it uses Omni-Version, https://wiki.eclipse.org/Equinox/p2/Omni_Version. A way to reduce the changes you run into this issue is moving to versioning based on packages instead of bundles. Due to the smaller granularity in elements it is less likely that two API changes will happen within the same unit. Obviously, this will have major impact on how dependencies are handled now within eclipse.
(In reply to Rolf Theunissen from comment #25) > However, the OSGi versioning specification does not define pre-release > version element. See https://blog.osgi.org/2012/03/what-happened-to-pre-release-versions.html
Jonah, I'm relatively sure that this one does not happen anymore with recent releases (otherwise no one could use Oomph). If you agree, please close this bug. If not, please let Ed (cc) know.
(In reply to Lars Vogel from comment #27) > Jonah, I'm relatively sure that this one does not happen anymore with recent > releases (otherwise no one could use Oomph). > > If you agree, please close this bug. If not, please let Ed (cc) know. Ed has nothing to do with this as I don't believe he maintains the setup files, I assume the various platform teams maintain their own. The problem here isn't a bug in Oomph. I don't know if this problem still potentially exists. We'll find out the next time API is updated twice in one release cycle and someone tries to provision during the window between when the first API has been promoted as an M build, after the second API is committed and before the second API is itself promoted as an M build. In that case you end up with a broken IDE. How bad this broken IDE depends on where the conflict is. The Comment 0 case was pretty bad as it happened during startup of the IDE. Anyway I don't think anyone plans on addressing this or adding pre-release API versioning so I will close as WONTFIX. Hopefully this will be in your arsenal of knowledge if it comes up again.
(In reply to Jonah Graham from comment #28) > (In reply to Lars Vogel from comment #27) > > Jonah, I'm relatively sure that this one does not happen anymore with recent > > releases (otherwise no one could use Oomph). > > > > If you agree, please close this bug. If not, please let Ed (cc) know. > > Ed has nothing to do with this as I don't believe he maintains the setup > files, I assume the various platform teams maintain their own. The problem > here isn't a bug in Oomph. > Actually, Ed maintains them all, though I see sometimes others step in as well, so that's very nice. It is intentional that the platform's setups install from their own IBuilds, i.e., eat your own dog food. But the overall SDK setup is designed to install not the committers package, but the platform's own SDK product which is also available in the catalog, the "latest" version for which is always the current IBuild...
(In reply to Ed Merks from comment #29) > > Ed has nothing to do with this as I don't believe he maintains the setup > > files, I assume the various platform teams maintain their own. The problem > > here isn't a bug in Oomph. > > > > Actually, Ed maintains them all, though I see sometimes others step in as > well, so that's very nice. Sorry Ed - I didn't realize you did that work too. You are indeed everywhere!
