Move more launcher functionalities from native code to Java

[HannesWell]

Currently the Equinox launcher library performs multiple operations in native code via the JNIBridge class and I wonder if at least some of these tasks can be implemented in Java instead or are maybe obsolete:

equinox/bundles/org.eclipse.equinox.launcher/src/org/eclipse/equinox/launcher/JNIBridge.java

Lines 25 to 41 in 296576b

	private native void _set_exit_data(String sharedId, String data);
	private native void _set_launcher_info(String launcher, String name);
	private native void _update_splash();
	private native long _get_splash_handle();
	private native void _show_splash(String bitmap);
	private native void _takedown_splash();
	private native String _get_os_recommended_folder();
	private native int OleInitialize(int reserved);
	private native void OleUninitialize();

AFAICT the launcher library, i.e. the JNIBridge is used for the following tasks

• pop-up and take down the splash-screen
• Get the OS recommended folder on Mac
• Initialize and uninitialize OLE in a WPF context
  Is that even relevant at all anymore?

@tjwatson told that the splash-screen was implemented in native code in order to have it up in milli-seconds and because back when it was introduced the JVMs started too slow. With the enhancements of JVM start-up in the past years I think it is worth to re-evaluate if that's still the case. Implementing it in java would also make it more accessible for Java developers that are not so much familiar with developing in C (like myself).

@Phillipus or @HeikoKlare maybe you can tell if the recommended folder on Mac can this be obtained differently? Maybe there is now a Java way to get that information or maybe a quick process call provides it and is fast enough?

[Phillipus]

maybe you can tell if the recommended folder on Mac can this be obtained differently?

Which folder?

Edit: I'm not sure if this can be computed any other way.

[akurtakov]

@vogella There was an effort to replace native splashscreen, right? If yes please share the link.

[Phillipus]

For the splash I once traced (as part of another issue) where the native splash appeared and then the Eclipse one appeared - eclipse-platform/eclipse.platform.swt#772 (comment)

[laeubi]

The problem is not java but the time until the application can take over the splash (e.g. startup the OSGi framework), due to sometimes undesired behavior this could take more than one minute (!) in the worst case.

[tjwatson]

The problem is not java but the time until the application can take over the splash (e.g. startup the OSGi framework), due to sometimes undesired behavior this could take more than one minute (!) in the worst case.

There is Java launcher code running before OSGi Framework. That is the code that launches the Equinox framework itself.

[laeubi]

There is Java launcher code running before OSGi Framework. That is the code that launches the Equinox framework itself.

Okay I thought we where talking about the "Application Splash Screen" that shows the progressbar.

[tjwatson]

Okay I thought we where talking about the "Application Splash Screen" that shows the progressbar.

We are talking about the splash screen. The native launcher first displays a "static" splash screen. Then later it hands off a handle to the splash screen window so it can be animated by SWT code later, after all the bundles are loaded.

[HannesWell]

maybe you can tell if the recommended folder on Mac can this be obtained differently?

Which folder?

Edit: I'm not sure if this can be computed any other way.

Just for completes: the folder returned by the following method

equinox/features/org.eclipse.equinox.executable.feature/library/cocoa/eclipseCocoa.c

Lines 666 to 670 in 99a8578

	_TCHAR* getFolderForApplicationData() {
	NSString* bundleId = getCFBundleIdentifier();
	NSString* appSupport = getApplicationSupport();
	return (_TCHAR*)[[NSString stringWithFormat:@"%@/%@_%s", appSupport, bundleId, getUUID()] UTF8String];
	}

@vogella There was an effort to replace native splashscreen, right? If yes please share the link.

That would be great.

Since Java-1.6 there is the java.awt.SplashScreen class that allows the JVM to do the splash-screen handling. One has to specify the splash path as VM argument but can change it later, draw on it and close it explicitly. There is a tutorial about it at:
https://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.html

But it has to be checked if its association with AWT is a problem or that a path has to be specified as VM argument or if anything else that can currently be specified cannot be done with that.
However the advantage would be besides less code that the SplashScreen class has for example support for High-DPI and IIRC the Eclipse splash screen has issues with that.

• Initialize and uninitialize OLE in a WPF context
  Is that even relevant at all anymore?

That's totally obsolete for some time already, see #624

[vogella]

@wimjongman worked on using the native Java splash for equinox in the past. I think it was done in https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/169562

[vogella]

Would be great if native Java could be used for the splash screen. IIRC from the discussion in https://bugs.eclipse.org/bugs/show_bug.cgi?id=114567 is that the splash code is hard to change and maintain.

[laeubi]

Last time I tried to use the BufferedImage in SWT (what also requires AWT indirectly) it was mentioned that in some setups there is interference between SWT+AWT possible.

[github-actions]

This issue has been inactive for 180 days and is therefore labeled as stale.
If this issue became irrelevant in the meantime please close it as completed. If it is still relevant and you think it should be fixed some possibilities are listed below.
Please read https://github.com/eclipse-equinox/.github/blob/main/CONTRIBUTING.md#contributing-to-eclipse-equinox for ways to influence development.