Comment 1 Eric Moffatt 2007-02-26 16:03:31 EST

Kim, I guessing that this is a startup issue...

Comment 2 Kim Horne 2007-02-27 12:53:28 EST

This is very strange.  Nothing has changed on either workbench or SWT sides of the code in ages.

Comment 3 Olivier Thomann 2007-02-27 20:11:12 EST

Reproduced with I20070227-0800.
I am investigating what could cause it.
Reassign to myself.
I'll move it back to Platform/UI once I know what happened.

Comment 4 Olivier Thomann 2007-02-27 21:06:32 EST

The problem might come from PDE/Build.

The ui.workbench plugin is compiled with a 64 bit version of swt before the win32 version of swt.
...
<classpath id="FOLDER" path="/builds/I200702270800/src/plugins/org.eclipse.swt.gtk.linux.x86_64/@dot/"/>
<classpath id="FOLDER" path="/builds/I200702270800/src/plugins/org.eclipse.swt.win32.win32.x86/@dot/"/>
...

The 64 bit version of the internal_new method is:

  public static org.eclipse.swt.widgets.Shell internal_new(org.eclipse.swt.widgets.Display display, long handle);

and the 32 bit version is:
  public static org.eclipse.swt.widgets.Shell internal_new(org.eclipse.swt.widgets.Display display, int handle);

So since the 64 bit version is found first, this is the method that is called. So the splash screen should work fine on a 64 bit platform, but won't work on any 32 bit platform.

The code that calls the internal new is:

String splashHandle = System.getProperty("org.eclipse.equinox.launcher.splash.handle"); //$NON-NLS-1$
if (splashHandle == null) {
	createSplash = false;
	return;
}
// create the splash
getSplash();
if (splash == null) {
	createSplash = false;
	return;
}
				
int handle = new Integer(splashHandle).intValue();
Shell splashShell = Shell.internal_new(display, handle);

this code is platform dependent, but the plugin is not platform dependent.

Something must have changed in the way the classpath is computed by PDE/Build.

The compiler is right in the way it resolves the method invocation. There is nothing we can do to fix this.

Moving to PDE/Build for further investigation.
It looks like this code should be moved to a platform dependent plugin.

Comment 5 Olivier Thomann 2007-02-27 22:01:32 EST

The reflection might also be a way to fix this.

Comment 6 Kim Horne 2007-02-28 08:35:09 EST

I've changed the code in workbench to work reflectively as a fix for bug 173844.  I'm not sure if the PDE build change will hose anyone else but from the workbench perspective this is no longer an issue.

Comment 7 Andrew Niefer 2007-02-28 12:38:42 EST

PDE/Build has not made any changes that should affect this, I think we have just been lucky so far.  There are issues in pde.build (and I raised bug 175864), however, in this particular case we wouldn't really be able to do anything.

The fragments are added to the classpath in the order returned from the osgi resolver. There may or may not have been changes internal to the osgi resolver that changed the order, but there was never any guarantee that they would be returned in any particular order.  With ui.workbench claiming to be platform-independent, the order should not matter.

ui.workbench is using a method Shell.internal_new whose signature depends on the platform.  There are 2 cases here:

1) Shell.internal_new is API.  In this case the signature should be the same on all platforms, I suggest changing it to always be long.

2) Shell.internal_new is not API.  In this case it is caller beware and the workbench must protect itself, which Kim has already done in comment #6.


Moving to SWT to clarify whether or not Shell.internal_new is API.  I suspect not, since it has internal in its name :) 

Comment 8 Steve Northover 2007-02-28 14:57:27 EST

SSQ, should they use reflection?

Comment 9 Silenio Quarti 2007-02-28 15:09:33 EST

I believe so. Shell.internal_new() is not API.

Comment 10 Silenio Quarti 2007-03-13 11:58:27 EDT

Andrew, Kim, is this an issue still? Should I just close as WONTFIX or move to some other component?

Comment 11 Kim Horne 2007-03-13 12:03:21 EDT

This isn't an issue any longer.

Comment 12 Jörg von Frantzius 2007-03-26 06:41:25 EDT

(In reply to comment #11)
> This isn't an issue any longer.
> 

Just in case this matters, I can see this problem with 3.3M6 on gtk-x86_64... 

Comment 13 Kim Horne 2007-03-26 08:12:47 EDT

Eek!  Jörg, can you post a stack trace please?

Steve, do you have a 64 bit GTK machine that we can try this on?

Comment 14 Jörg von Frantzius 2007-03-26 09:32:39 EDT

(In reply to comment #13)
> Eek!  Jörg, can you post a stack trace please?

Here it comes:

eclipse.buildId=I20070323-1616
java.version=1.5.0_10
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=de_DE
Framework arguments:  -startup /home/jfrantzius/apps/eclipse3.3/M6/eclipse/plugins/org.eclipse.equinox.launcher_1.0.0.v20070319.jar
Command-line arguments:  -os linux -ws gtk -arch x86_64 -startup /home/jfrantzius/apps/eclipse3.3/M6/eclipse/plugins/org.eclipse.equinox.launcher_1.0.0.v20070319.jar -clean -data /home/jfrantzius/Documents/eclipse_workspaces/sgw2

Error
Mon Mar 26 12:29:24 CEST 2007
Could not instantiate splash

java.lang.NoSuchMethodException: org.eclipse.swt.widgets.Shell.internal_new(org.eclipse.swt.widgets.Display, int)
at java.lang.Class.getMethod(Class.java:1581)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:542)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.ui.internal.Workbench.createSplashWrapper(Workbench.java:596)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2205)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2176)
at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:463)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:458)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:101)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:146)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:356)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:476)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:416)
at org.eclipse.equinox.launcher.Main.run(Main.java:1141)
at org.eclipse.equinox.launcher.Main.main(Main.java:1116)

Comment 15 Steve Northover 2007-03-26 10:59:27 EDT

Yes, contact Grant or Carolyn.