search

eclipse-platform / eclipse.platform.swt

Eclipse SWT
https://www.eclipse.org/swt/
Eclipse Public License 2.0
101 stars 123 forks source link

MacOS 14.3 M2: RCP application blank screen with Temurin 17.0.10 #1012

Open ivy-lli opened 5 months ago

ivy-lli commented 5 months ago

Describe the bug Since the update to Temurin 17.0.10 (from Temurin 17.0.9), my started Eclipse RCP application shows only an empty screen.

To Reproduce

  1. Install Eclipse RCP 2023-12 (4.30.0) https://www.eclipse.org/downloads/packages/release/2023-12/r/eclipse-ide-rcp-and-rap-developers
  2. Create a new RCP application, done as described here: https://www.vogella.com/tutorials/EclipseRCP/article.html#generatetemplatewithcontent
  3. Add Temurin 17.0.10 to Eclipse
    • Open Preferences
    • Java > Installed JREs
    • Add...
    • Select it
    • Apply
  4. Start the Eclipse application as described in the tutorial (Step 2) -> Empty application
  5. Close the Eclipse application
  6. Add Temurin 17.0.9 to Eclipse
    • Same as step 3
  7. Make sure the Eclipse application uses Temurin 17.0.9
    • Run
    • Run configurations...
    • Choose our Eclipse Application
    • Java Runtime Environment
    • Runtime JRE: select Temurin 17.0.9
    • Apply
  8. Start the Eclipse application -> Application with sample content

I can also provide the workspace via a GitHub repo, but it is not more than the wizard for new RCP Applications created.

Expected behavior The Eclipse RCP application should also show the sample content

Screenshots Temurin 17.0.10: 299993416-0886d040-5dec-4f6e-8f53-301f224f5484

Temurin 17.0.9: 299993541-2c9b71ae-e0f9-482f-91d9-8df9be20ea8b

Environment:

  1. Select the platform(s) on which the behavior is seen:

      • [ ] All OS
      • [ ] Windows
      • [ ] Linux
      • [x] macOS

  2. Additional OS info (e.g. OS version, Linux Desktop, etc) OS: MacOS Sonoma 14.3 Platform: MacBook Pro M2, 2023

  3. JRE/JDK version Temurin 17.0.10:

    openjdk version "17.0.10" 2024-01-16 
OpenJDK Runtime Environment Temurin-17.0.10+7 (build 17.0.10+7) 
OpenJDK 64-Bit Server VM Temurin-17.0.10+7 (build 17.0.10+7, mixed mode)

    Temurin 17.0.9: 

    openjdk version "17.0.9" 2023-10-17
OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode)

Version since Tested with 4.30

Workaround (or) Additional context I didn't see any log, crash, or something like that. I also already opened an issue at the Temurin site: https://github.com/adoptium/adoptium-support/issues/1008

iloveeclipse commented 5 months ago

Could you please try with latest 4.31 nightly build?

ivy-lli commented 5 months ago

One addition

I quickly wanted to see if this bug is also the case if I use the shipped JDK just j in version 17.0.10. As the Eclipse 4.30 is shipped with the latest JDK v21, I installed the JustJ laster 17 package via the software manager, which then removed the v21 and installed the v17.0.10. After the installation, I restarted Eclipse as said, and now it is not starting at all: image

I'm not sure if it has to do with the same problem, but now I have a log file: 1706519978372.log

I just wanted to mention it, but as said, maybe it has nothing to do with the bug of this issue.

ivy-lli commented 5 months ago

Tried it with Version: 2024-03 M1 (4.31.0 M1) / Build id: 20240111-1612

Same problem, with Temurin 17.0.10 the screen in blank, with Temurin 17.0.9 everything seems to work as expected.

merks commented 5 months ago

Note that this works on Windows:

image

image

Are there any clues in the console?

image

HeikoKlare commented 5 months ago

I just tried with yesterday's I-Build artifacts started from current sources: Version: 2024-03 (4.31) Build id: I20240128-1800

image

Plain SWT applications work fine: image

Log is empty.

ivy-lli commented 5 months ago

I just tried with yesterday's I-Build artifacts started from current sources: Version: 2024-03 (4.31) Build id: I20240128-1800

Yes exaclty the first image I've got with our real RCP application, I just wanted to create an issue on a simple reproducable way, what is the reason why I tried it with a base RCP application too.

I started once again and now I've got a log, but not sure if this has something to do with it, maybe it is also because of some config changes...

eclipse_rcp-startup.log

ivy-lli commented 5 months ago

I think it also works with Linux (latest linux mint 21.3). I have an internal coworker which shortly tried our application with Temurin 17.0.10 at it seems to work fine.

Phillipus commented 5 months ago

I can confirm this. Launching a child Eclipse or an RCP app with Temurin JDK 17.0.10+7 leads to a totally blank app.

MacBook M2 Sonoma 14.3

merks commented 5 months ago

The log just makes it sound like some bundle was not included in the launch configuration. It looks like the leaf cause is this failure:

Unresolved requirement: Import-Package: org.apache.commons.io; version="[1.4.0,2.0.0)"

But how that's related to the JRE version is entirely unclear.

Could you maybe try to add the bundle explicitly?

image

HeikoKlare commented 5 months ago

Note that my screenshot with an empty RCP application is taken without any log errors. After switching back to Temurin 17.0.9 with the exact same workspace setup, the application looks good.

Phillipus commented 5 months ago

Note that my screenshot with an empty RCP application is taken without any log errors. After switching back to Temurin 17.0.9 with the exact same workspace setup, the application looks good.

Same here. I'm using vanilla Eclipse SDK from here.

merks commented 5 months ago

So one very strange thing here is that Eclipse itself works fine, just not an RCP application. There is no clue or theory for how that is possible, and I can't reproduce it because I'm on Windows so I cannot help in this regard. 😱

ivy-lli commented 5 months ago

The log just makes it sound like some bundle was not included in the launch configuration. It looks like the leaf cause is this failure:

Unresolved requirement: Import-Package: org.apache.commons.io; version="[1.4.0,2.0.0)"

But how that's related to the JRE version is entirely unclear.

Could you maybe try to add the bundle explicitly?

Makes no difference: image

Phillipus commented 5 months ago

Tested on macOS Ventura and it's OK. So seems to be a combination of:

Plain SWT Snippets are OK and work as expected when launched from Eclipse.

Phillipus commented 5 months ago

Same problem with Temurin 21.0.2+13 (but OK with 21.0.1+12).

iloveeclipse commented 5 months ago

Is that something related to "signing" of the app, may be some old signing algorithms / keys etc were revoked in new JVM's?

Phillipus commented 5 months ago

Is that something related to "signing" of the app, may be some old signing algorithms / keys etc were revoked in new JVM's?

I don't think so. These JDKs work fine if you use them to run Eclipse or an RCP app directly. The problem is when launching a child Eclipse / RCP app from Eclipse to run/debug it. The menus are rendered but not the app's contents.

Phillipus commented 5 months ago

I don't know how we can proceed to solve this one.

The situation as it stands means that if someone is running macOS Sonoma and has one of these versions of the Temurin JDK installed (currently 17.0.10+7 and 21.0.2+13) they will be able to run Eclipse OK but they will not be able to debug launch a working child instance of Eclipse or an RCP application.

FWIW simple steps to reproduce (on macOS Sonoma):

  1. Install Temurin JDK 17.0.10+7 or 21.0.2+13
  2. Install vanilla Eclipse SDK for macOS here
  3. Add Temurin JDK to Eclipse from Eclipse's Settings - Java -> Installed JREs - Add
  4. Create a new Debug Launch Configuration of product org.eclipse.sdk and Runtime JRE of the Temurin JDK
  5. Launch child Eclipse from this configuration
merks commented 5 months ago

FYI, to reproduce using the installer one can install anything with 17.0.10 or 21.0.2 which will also use that as the JRE in that installed IDE:

image

image

It just seems bizarre that the IDE itself works (does it?) yet something is failing in the launched application (but not in SWT snippets), and nothing is in the log as an indicator...

I assume the failure is in any launch, not just a debug launch but also a run launch?

Phillipus commented 5 months ago

It just seems bizarre that the IDE itself works (does it?) yet something is failing in the launched application (but not in SWT snippets), and nothing is in the log as an indicator...

Yes the IDE itself works. Problem is only the launched app. SWT Snippets are OK too.

I assume the failure is in any launch, not just a debug launch but also a run launch?

Yep, I tried that.

iloveeclipse commented 5 months ago

I don't know how we can proceed to solve this one.

Divide and conquer.

Possible issues could be in

So one should try to reduce the problem to smallest possible example and see which partis responsible here.

Since I don't have Mac, I can't help further ...

merks commented 5 months ago

I'm not sure how on mac java is launched. I think it uses some library in the JDK/JRE rather than like the way java executable is used directly for a launched application:

image

So I guess there is no good way to compare how launched processes might be different...

I wish I could help more effectively. 😢

Phillipus commented 5 months ago

When Eclipse or an RCP app is run from desktop it runs from the launcher binary file (Eclipse.app/Contents/MacOS/eclipse).

On Mac, a child Eclipse launches using the java binary. We can see that in the launch config dialog "Command Line".

The latest Mac Eclipse launcher binary is built using Mac SDK 13 while these versions of Temurin are built using Mac SDK 14. (You can determine this with the command vtool -show /path/to/binary will show this.)

I think this is the problem.

We can rule out the Eclipse IDE by copying the launch config's command line and editing it to get rid of extra stuff. For me:

/Users/phillipus/Desktop/jdk-17.0.10+7/Contents/Home/bin/java \
-XstartOnFirstThread \
-classpath /Users/phillipus/projekts/archi/workspace/.metadata/.plugins/org.eclipse.pde.core/.bundle_pool/plugins/org.eclipse.equinox.launcher_1.6.400.v20210924-0641.jar org.eclipse.equinox.launcher.Main \
-product org.eclipse.sdk.ide \
-data /Users/phillipus/projekts/archi/workspace/../runtime-New_configuration \
-configuration file:/Users/phillipus/projekts/archi/workspace/.metadata/.plugins/org.eclipse.pde.core/New_configuration/ \
-consoleLog

Running the above in Terminal give a blank Eclipse window.

HeikoKlare commented 5 months ago
  • e4 css code (the one that renders seem not work)

One thing that would support this is that actually everything seems to "exist", but is simply not rendered correctly. You can see that the cursor changes on buttons, you can click buttons, open context menus etc. For example, you can open another dialog:

image

I've tried these options, but they did not change anything.

Unfortunately I can currently not invest much into investigating this issue, since I work on Windows and only have Mac for SWT/Platform UI validation tasks.

Phillipus commented 5 months ago

The latest Mac Eclipse launcher binary is built using Mac SDK 13 while these versions of Temurin are built using Mac SDK 14. (You can determine this with the command vtool -show /path/to/binary will show this.)

The current Eclipse launcher binary is built using macOS SDK 13 (vtool -show Eclipse.app/Contents/MacOS/eclipse will show this). It might be that if ever it is built using SDK 14 we will see the same problem.

Phillipus commented 5 months ago

We can rule out e4 css code because I set up child Eclipse to not use themes and same problem.

Phillipus commented 5 months ago

From further testing I'm pretty certain the difference is because the java binary has been built using macOS SDK 14. Why this causes the problem in SWT I don't know.

I replaced just the java binary file with one from an earlier Temurin SDK and it is working OK. This supports my theory.

Phillipus commented 5 months ago

OK, I'm going to summarise the situation based on the assumption that the problem is arising because of Temurin using macOS SDK 14 to create the java binary.

Worthy of investigation is why SWT Snippets are running OK.

Phillipus commented 5 months ago

@SyntevoAlex and @tmssngr I wonder if you could help to test something? The SmartGit app uses its own launcher binary (SmartGit) which has been built against SDK 11.3 (vtool -show SmartGit will show this). Is it possible for you to create this binary file using macOS SDK 14 and launch SmartGit with this?

Phillipus commented 5 months ago

My latest experiments show that the problem is indeed caused by using macOS SDK 14 to create the runtime launcher binary - this will be java in the case of launching child Eclipse or Eclipse.app/Contents/MacOS/eclipse in the case of launching Eclipse itself.

On my Mac (with Sonoma 14.3) I built a new equinox launcher file from source - see https://github.com/eclipse-equinox/equinox/tree/master/features/org.eclipse.equinox.executable.feature/library/cocoa

I confirmed that the resulting eclipse launcher has been compiled with macOS SDK 14.x by running vtool -show eclipse:

Load command 10
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform MACOS
    minos 11.0
      sdk 14.2
   ntools 1
     tool LD
  version 1022.1
Load command 11
      cmd LC_SOURCE_VERSION
  cmdsize 16
  version 0.0

In a working version of the Eclipse SDK I replaced the Eclipse.app/Contents/MacOS/eclipse launcher file with the newly built one and launched Eclipse. The window was blank as shown above.

So, this leads to the next question - why does this cause the problem in Eclipse but not in SWT Snippets?

Phillipus commented 5 months ago

Attached is the recompiled eclipse launcher if anyone wants to try it (it's aarch64 version)

eclipse.zip

laeubi commented 5 months ago

So, this leads to the next question - why does this cause the problem in Eclipse but not in SWT Snippets?

Running a Workbench does a lot more than running a main class. Maybe just try to start without any theming enabled?

Phillipus commented 5 months ago

Maybe just try to start without any theming enabled?

Done that.

laeubi commented 5 months ago

Maybe just try to start without any theming enabled?

Done that.

I only see "dark mode" screenshots here, so how does it look in "light mode"?

Phillipus commented 5 months ago

so how does it look in "light mode"?

light theme

And with theming off:

no theme

akurtakov commented 5 months ago

@Phillipus Just a guess but look out for some line like https://github.com/eclipse-platform/eclipse.platform.swt/blob/31e1414709ac286cb0d93f4266257bc6a6a27967/bundles/org.eclipse.swt/Eclipse%20SWT/cocoa/org/eclipse/swt/widgets/Display.java#L2539 - a string comparison of versions . I am not saying this line is the case but I have been bitten by such bugs in the past. Edit: As SWT snippets work I would be looking in jdt/pde launching code doing/lacking some such code.

Phillipus commented 5 months ago

For my part, I think I've gone as far as I can to help diagnose this one and can't do any more. But the following should be emphasised:

As it stand today this issue affects launching child Eclipse / RCP apps that target the latest SDK 17 and 21. But if the equinox Mac launcher is ever compiled against the later Mac SDK then Eclipse itself will simply not work on Mac.

Phillipus commented 5 months ago

But if the equinox Mac launcher is ever compiled against the later Mac SDK then Eclipse itself will simply not work on Mac.

Does anyone know how the Equinox build of the Mac launcher is done? I'm assuming it's on a Mac with a given OS (I'm guessing Ventura 13.x). Is there a likelihood in the future that the Mac build machine will be updated to a new OS (Sonoma 14)?

The build artifacts are here: https://github.com/eclipse-equinox/equinox/tree/master/features/org.eclipse.equinox.executable.feature/library

Phillipus commented 5 months ago

I'd like to emphasise the seriousness of this issue, while also acknowledging that I understand how things are regarding lack of resources, committers and time, especially on Mac.

  1. Today, if an Eclipse developer on Mac downloads and installs Eclipse from Oomph they will be asked to install the latest versions of Temurin Java 17 or 21. Or perhaps they have the latest Temurin Java already installed. If they then launch a child Eclipse / RCP app instance they will come across this issue and it will be unusable.

  2. If and when the Mac native launcher is built using a later SDK (see here) then Eclipse and RCP apps on Mac will simply not function.

The first reports we will see will be like the original post here - a Mac Eclipse/RCP developer launching a child instance of Eclipse/RCP app with the latest JDK. (The workaround is to install an older version of the JDK.)

But, as I said, if/when a later version of Eclipse ships with a launcher binary built with a later Mac SDK then Eclipse will be dead in the water on Mac, and there will be no workaround.

I've spent a lot of time diagnosing this, and I can't determine why it causes the SWT rendering issue. But I think at least a heads-up is necessary.

If anyone could help solve this issue it would ensure that Eclipse continues to work on Mac.

merks commented 5 months ago

@jonahgraham @akurtakov

Perhaps this another issue that Planning Council should consider prioritizing...

@Phillipus

The issue is often that even if there is funding to do the work, finding the skilled people can remain a challenge...

Phillipus commented 4 months ago

Apache Hop has the same problem with their Mac version and the latest Temurin JDK 11. A quick look at the source suggests this project uses plain SWT, not the Eclipse Workbench.

See https://github.com/apache/hop/issues/3604

Phillipus commented 4 months ago

It seems that this problem is reproducible with stand-alone SWT code, just not simple examples. Blank parts of the UI can be seen when running some of the SWT Examples.

Ensure you are running macOS Sonoma (14).

  1. Check out the SWT Examples project into your workspace.
  2. Download and install the latest version of Temurin 17.0.10 JDK for Mac and add it as a JDK in Eclipse's Preferences as an installed JDK
  3. "Run As Java Application" the GraphicsExample ensuring that the target JDK is the Temurin one
  4. "Run As Java Application" the TextEditor ensuring that the target JDK is the Temurin one

Here's some screenshots.

GraphicsExample - how it should look:

graphics_normal

GraphicsExample - how it looks with latest Temurin JDK:

graphics_blank

TextEditor - how it should look:

texteditor_normal

TextEditor - how it looks with latest Temurin JDK:

texteditor_blank
Phillipus commented 4 months ago

I think I may have found the underlying cause. It has something to do with how some child controls are laid out.

Take the following snippet:

import org.eclipse.swt.SWT;
import org.eclipse.swt.graphics.Color;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Label;
import org.eclipse.swt.widgets.Shell;

public class JDKTest {

    public static void main(String[] args) {
        Display display = new Display();

        Shell shell = new Shell(display);
        shell.setText("Test");
        shell.setLayout(new GridLayout());
        shell.setSize(200, 150);

        Composite comp = new Composite(shell, SWT.NONE);
        comp.setLayout(new GridLayout());
        comp.setBackground(new Color(255, 128, 128));

        Label label1 = new Label(comp, SWT.NONE);
        label1.setText("Label 1");

        Label label2 = new Label(shell, SWT.NONE);
        label2.setText("Label 2");

        shell.open();

        while(!shell.isDisposed()) {
            if(!display.readAndDispatch()) {
                display.sleep();
            }
        }

        display.dispose();
    }
}

This is how it should look (using an older JDK):

correct

This is how it looks using the latest Temurin JDK on macOS Sonoma:

wrong

The composite fills the whole window.

In my experiments with the SWT Examples (see previous post) I found out that some Composite controls are covering over whole areas of the application leading to blank parts.

iloveeclipse commented 4 months ago

The composite fills the whole window.

Cool. So I guess some native SWT code that calculates or queries composite size is now broken on that Mac version? Or it queries / receives wrong size (not from composite but from the parent or entire shell).

Phillipus commented 4 months ago

@SyntevoAlex @tmssngr You might be interested in this as SmartGit is an SWT-based application that runs on Mac...

SmartGit has its own launcher executable (SmartGit.app/Contents/MacOS/SmartGit) which, because it has been built using macOS SDK 11, does not display this problem.

However, we can launch SmartGit using the latest Temurin Java acting as the launcher with this command:

jdk-17.0.10+7/Contents/Home/bin/java -XstartOnFirstThread -jar SmartGit.app/Contents/Resources/Java/bootloader.jar

And SmartGit looks like this with blank areas:

sg

Again, this shows that this is an SWT issue, not an Eclipse Workbench one.

Note - this only happens running on macOS 14.

Phillipus commented 4 months ago

A better example:

import org.eclipse.swt.SWT;
import org.eclipse.swt.graphics.Color;
import org.eclipse.swt.layout.GridData;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;

public class JDKTest {

    public static void main(String[] args) {
        Display display = new Display();

        Shell shell = new Shell(display);
        shell.setText("Test");
        shell.setLayout(new GridLayout());
        shell.setSize(250, 250);

        GridData gd = new GridData(GridData.FILL_BOTH);
        gd.heightHint = 100;

        Composite comp1 = new Composite(shell, SWT.NONE);
        comp1.setBackground(new Color(255, 128, 128));
        comp1.setLayoutData(gd);

        Composite comp2 = new Composite(shell, SWT.NONE);
        comp2.setBackground(new Color(128, 255, 128));
        comp2.setLayoutData(gd);

        shell.open();

        while(!shell.isDisposed()) {
            if(!display.readAndDispatch()) {
                display.sleep();
            }
        }

        display.dispose();
    }
}

This is how it should look (using an older JDK):

1

This is how it looks using the latest Temurin JDK on macOS Sonoma:

2

So we can see that the first Composite that is declared covers any other Composites, which explains the blank areas when launching child Eclipse.

Phillipus commented 4 months ago

This only seems to be happening if the Composite's style is SWT.NONE. If the style is set to, say, SWT.BORDERor SWT.H_SCROLL or SWT.V_SCROLL it renders correctly.

Also, the same problem if a Label control is used instead of a Composite.

tmssngr commented 4 months ago

I think I may have found the underlying cause. It has something to do with how some child controls are laid out.

Take the following snippet:

import org.eclipse.swt.SWT;
import org.eclipse.swt.graphics.Color;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Label;
import org.eclipse.swt.widgets.Shell;

public class JDKTest {

    public static void main(String[] args) {
        Display display = new Display();

        Shell shell = new Shell(display);
        shell.setText("Test");
        shell.setLayout(new GridLayout());
        shell.setSize(200, 150);

        Composite comp = new Composite(shell, SWT.NONE);
        comp.setLayout(new GridLayout());
        comp.setBackground(new Color(255, 128, 128));

        Label label1 = new Label(comp, SWT.NONE);
        label1.setText("Label 1");

        Label label2 = new Label(shell, SWT.NONE);
        label2.setText("Label 2");

        shell.open();

        while(!shell.isDisposed()) {
            if(!display.readAndDispatch()) {
                display.sleep();
            }
        }

        display.dispose();
    }
}

This is how it should look (using an older JDK):

correct

This is how it looks using the latest Temurin JDK on macOS Sonoma:

wrong

The composite fills the whole window.

In my experiments with the SWT Examples (see previous post) I found out that some Composite controls are covering over whole areas of the application leading to blank parts.

Could you please try to set some fixes locations and log the preferred sizes?

Phillipus commented 4 months ago

Could you please try to set some fixes locations and log the preferred sizes?

Hi, I don't understand what you mean?

tmssngr commented 4 months ago

Currently, the GridLayout sets the sizes. It would be interesting to understand whether they are calculated at the wrong time, whether the size for the container is reported wrong, whether the controls report a wrong preferred size, ... Could you please, instead of setting a layout manager simply set the controls some fixes locations, and lot their preferred sizes:

import org.eclipse.swt.*;
import org.eclipse.swt.graphics.*;
import org.eclipse.swt.widgets.*;

public class JDKTest {

    public static void main(String[] args) {
        Display display = new Display();

        Shell shell = new Shell(display);
        shell.setText("Test");
        shell.setSize(200, 150);

        Composite comp = new Composite(shell, SWT.NONE);
        comp.setBackground(new Color(255, 128, 128));
        comp.setBounds(10, 10, 50, 30);

        Label label1 = new Label(comp, SWT.NONE);
        label1.setText("Label 1");
        label1.setBounds(5, 5, 40, 20);

        Label label2 = new Label(shell, SWT.NONE);
        label2.setText("Label 2");
        label2.setBounds(10, 40, 40, 20);

        System.out.println(label1.computeSize(SWT.DEFAULT, SWT.DEFAULT));
        System.out.println(label2.computeSize(SWT.DEFAULT, SWT.DEFAULT));

        shell.open();

        while(!shell.isDisposed()) {
            if(!display.readAndDispatch()) {
                display.sleep();
            }
        }

        display.dispose();
    }
}