search

eclipse-equinox / equinox

equinox
Eclipse Public License 2.0
31 stars 65 forks source link

Move more launcher functionalities from native code to Java #623

Open HannesWell opened 4 months ago

HannesWell commented 4 months ago

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: https://github.com/eclipse-equinox/equinox/blob/296576b291fd3208b81b22d50984d2ad99682bee/bundles/org.eclipse.equinox.launcher/src/org/eclipse/equinox/launcher/JNIBridge.java#L25-L41

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

@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 commented 4 months ago

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 commented 4 months ago

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

Phillipus commented 4 months ago

For the splash I once traced (as part of another issue) where the native splash appeared and then the Eclipse one appeared - https://github.com/eclipse-platform/eclipse.platform.swt/issues/772#issuecomment-1685219019

laeubi commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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

https://github.com/eclipse-equinox/equinox/blob/99a85789ed29f87d4ed04d15bb640de325f4750f/features/org.eclipse.equinox.executable.feature/library/cocoa/eclipseCocoa.c#L666-L670

@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 https://github.com/eclipse-equinox/equinox/pull/624

vogella commented 4 months ago

@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 commented 4 months ago

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 commented 4 months ago

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.