Detect incompatible libraries

[basilevs]

UI behavior depends on loaded MacOS SDK, which apparently depends on build mode of the root executable (Equinox launcher or Java). There are multiple versions of Equinox launcher and many various JVMs each compiled with random MacOS SDKs making it very hard to select a correct version of SWT for a given root executable or vice-versa.

Please introduce or recommend a way to detect an unsupported loaded MacOS SDK runtime, so that my SWT application or test could refuse to run or show a warning.

I've considered running otool against current executable, but it is complicated, I'm unsure which versions are truly compatible and it would be nice if there was an authoritative solution, preferably built-in and ready to use.

Following issues were hard to investigate because of an unexpected version mismatch:

• Text control should not redraw indefinitely #3260
• Infinite Text redraw eclipse.platform.ui#3920
• [Mac] Title left-alignment on all windows eclipse.platform.ui#3884
• [windows] WebView2 runtime not found #2000

Ideally the feature would be cross-platform - a report of required and loaded runtime components that could be converted to end-user readable form.

To avoid localisation I would suggest to return triplets of "component id", "expected version", "detected version", where component id could be "edge", "mozilla", "MacOSSDK", "webkit", etc... Report should be empty or annotated accordingly (with an additional boolean field?) when all loaded components are compatible.

[basilevs]

Ugh, there are different severities of incompatibility, so report if any, might have to include a severity too. For example, event reordering caused by MacOS SDK is subtle and very annoying but leaves application in a somewhat working state. Browser fallback replaced by a text control is a non-fatal reduced functionality. Incompatible data structures, on the other hand may crash the application.

The feature is more complex than I imagined, but I still think something should be done to prevent hours of debugging without being aware of different SDK versions and launcher-specific loading pattern.

[fedejeanne]

cc @HeikoKlare , @HannesWell since you have been looking into the whole compiling + Mac + SDK issues.

[HeikoKlare]

I'm unsure which versions are truly compatible and it would be nice if there was an authoritative solution, preferably built-in and ready to use.

I think no one knows about which versions are compatible. In fact, Apple does not seem to provide any information about such kinds of changes and incompatibilites in newer SDK versions. The issues that we found when building the Equinox binaries with macOS SDK 26 show differences in SDK behavior that are documented nowhere.

If you want to avoid any kind of such issues, the only chance is probably to define a specific macOS SDK version (at least a specific major, maybe even a minor) that we support and test. But then you will hardly find a JVM for SWT applications or runtime products that is compiled that exact version and can thus be used.

The best solution would be if there was some compatibility mode (as mentioned in eclipse-platform/eclipse.platform.ui#3920 (comment)) that allows us to become independent from what macOS SDK version the used executable was compiled against. If that's not possible, I have no clue how Apple thinks you should be able to support more than one specific macOS SDK version. The minimum version that you can define becomes quite useless with such changes in behavior depending on the version you compile with.

As a final remark in terms of expectation management, I want to mention that I cannot / will not work on this kind of issue. I can support in discussing and testing proposals and do minor work for macOS, but this seems to become a larger topic and since our product is Windows-only, we cannot make larger investments into macOS support.

[Phillipus]

Further to what @HeikoKlare says, Apple can change the API and behaviour between versions of the SDK and even between minor versions of macOS with serious results - see here and here.

As for using macOS 26.x SDK to create Java or Eclipse runtime binaries the issues opened against SWT are only the ones that people found within the first few days (and one only appeared with dark theme) so there could be more problems that might be found later.