MacOS 14.3 M2: RCP application blank screen with Temurin 17.0.10

[ivy-lli]

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:

Temurin 17.0.9:

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]

Could you please try with latest 4.31 nightly build?

[ivy-lli]

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:

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]

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]

Note that this works on Windows:

Are there any clues in the console?

[HeikoKlare]

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

Plain SWT applications work fine:

Log is empty.

[ivy-lli]

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]

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]

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]

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?

[HeikoKlare]

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]

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]

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]

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:

[Phillipus]

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

• macOS Sonoma
• Temurin JDK 17.0.10+7
• Launching child Eclipse/RCP app

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

[Phillipus]

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

[iloveeclipse]

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

[Phillipus]

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]

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]

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:

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]

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]

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

Divide and conquer.

Possible issues could be in

• e4 css code (the one that renders seem not work)
• SWT Mac code (the one that draws)
• PDE code (the one that prepares target/ dependencies before start)
• Equinox code (the one that resolves dependencies at runtime)
• Platform runtime code (may be some exceptions are swallowed)
• JVM code (some weird security fix that breaks rendering by not running some "dangerous" part of the code)
• Btw, there was earlier a fix in JVM that introduced some stack limits for xml parsing - so if now the stack is longer, we may hit that limit. Try to start with -Djdk.xml.xpathExprGrpLimit=0 -Djdk.xml.xpathExprOpLimit=0 -Djdk.xml.xpathTotalOpLimit=0
• whatever else

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

• Reduce to simplest possible example code and debug that part that causes example to not render
• Disable css by disabling themes support in Eclipse
• Start with the JVM arguments I've given above
• Check JDK fixed bugs for a good candidate (similar to xpath above)
• Debug with breakpoint created on "Exception" that might be swallowed
• Profile with Yourkit or ny other profiler and check for exceptions / problems reported there
• Enable tracing, etc

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

[merks]

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:

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

I wish I could help more effectively. 😢

[Phillipus]

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]

• 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:

• Btw, there was earlier a fix in JVM that introduced some stack limits for xml parsing - so if now the stack is longer, we may hit that limit. Try to start with -Djdk.xml.xpathExprGrpLimit=0 -Djdk.xml.xpathExprOpLimit=0 -Djdk.xml.xpathTotalOpLimit=0

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]

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]

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

[Phillipus]

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]

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.

• This problem only manifests on macOS Sonoma (14). It's OK on Ventura (13).
• It only manifests on launching a child Eclipse or RCP instance because that is launched with the java binary in the command line
• It does not manifest when launching native Eclipse because that is launched with the eclipse launcher executable which has been created using an earlier macOS SDK
• Why this change of SDK should cause the problem in SWT/Equinox/Whatever is unknown
• Today this means that Mac developers cannot target the latest Temurin JDK if they want to debug Eclipse or RCP apps
• If ever the Eclipse Mac launcher is built using macOS SDK 14 the same problem will occur when launching native Eclipse and Eclipse will be unusable on Mac Sonoma with the latest JDK

Worthy of investigation is why SWT Snippets are running OK.

[Phillipus]

@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]

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?