Alternative surrogate bundle implementation for com.sun.jna

[deepika-u]

As suggested from #2894 (reply in thread)

This pr is result of attempt for the suggested -> option 2

Also I think the surrogate name may be org.eclipse.ui.jnasurrogate , as opposed to com.sun.jna.surrogate - so that the naming convention in the project is maintained.

[eclipse-platform-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

bundles/org.eclipse.urischeme/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From 16de4aebf95f0f57404a21fab2b3660f0ea09cb9 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <[email protected]>
Date: Fri, 11 Apr 2025 13:52:24 +0000
Subject: [PATCH] Version bump(s) for 4.36 stream


diff --git a/bundles/org.eclipse.urischeme/META-INF/MANIFEST.MF b/bundles/org.eclipse.urischeme/META-INF/MANIFEST.MF
index 4568e02626..13ccbc5663 100644
--- a/bundles/org.eclipse.urischeme/META-INF/MANIFEST.MF
+++ b/bundles/org.eclipse.urischeme/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %Plugin.name
 Bundle-SymbolicName: org.eclipse.urischeme;singleton:=true
-Bundle-Version: 1.3.500.qualifier
+Bundle-Version: 1.3.600.qualifier
 Automatic-Module-Name: org.eclipse.urischeme
 Bundle-RequiredExecutionEnvironment: JavaSE-17
 Require-Bundle: org.eclipse.equinox.common;bundle-version="[3.8.0,4.0.0)",
-- 
2.49.0

Further information are available in Common Build Issues - Missing version increments.

[github-actions]

Test Results

0 tests   0 ✅  0s ⏱️
0 suites  0 💤
0 files    0 ❌

Results for commit a62bb7d.

♻️ This comment has been updated with latest results.

[merks]

I'm literally baffled what problem is being solved and how this actually solves that problem.

Searching the workspace for com.sun.jna.platform.win32 with this PR pulled in I find these occurrences:

The one bundle that's been changed to use package imports still appears to bind to the existing real bundles in the workspace:

What is the basis for the package versions in the surrogate?

Why does it have requirements on jface and swt?

Indeed I thing it's really bad to use com.sun in the namespace of the bundle and to make the vendor someone else...

But, as I said, I don't see what problem this is solving.

If something is going to function when the things in the required packages are missing, i.e., the actual imported classes we see in the *.java files, that could (and should) be handled by making the package import optional.

[merks]

I don't think "we" should push a new bundle into the code base to solve a problem that we don't have on the Platform's officially supported architectures. It's fine to switch dependencies to package imports versus bundle imports, but an alternative bundle for whatever purpose it's needed outside of our supported architectures should not be the common code base.

[HannesWell]

It's fine to switch dependencies to package imports versus bundle imports, but an alternative bundle for whatever purpose it's needed outside of our supported architectures should not be the common code base.

I fully agree with both statements. It would be better if you keep such a workaround in your own code, where you build the Eclipse based products from.

[deepika-u]

The one bundle that's been changed to use package imports still appears to bind to the existing real bundles in the workspace:

The bundle in question i.e., urischeme is binding to the real com.sun.jna bundle in windows because its full implementation is available on windows. This will bind to the surrogate where the implementation is unavailable.

What is the basis for the package versions in the surrogate?

In platforms such as windows, where both the packages will be available, we need the package with higher version to be resolved. Where as in platforms where only surrogate is available, we need a version that matches with import package versions of consuming bundles. This is our package versioning strategy. Please suggest if you have better solution.

Why does it have requirements on jface and swt?

We created a template bundle using pde. I'll make an empty bundle with no dependencies.

Indeed I think it's really bad to use com.sun in the namespace of the bundle and to make the vendor someone else...

Agree, we'll follow the eclipse package naming convention.

If something is going to function when the things in the required packages are missing, i.e., the actual imported classes we see in the *.java files, that could (and should) be handled by making the package import optional.

Thanks for the suggestion we are trying that and hence kept it in as draft.

I don't think "we" should push a new bundle into the code base to solve a problem that we don't have on the Platform's officially supported architectures.

I searched but could not find the officially supported platforms link, would you be able to share the link please.

It's fine to switch dependencies to package imports versus bundle imports, but an alternative bundle for whatever purpose it's needed outside of our supported architectures should not be the common code base.

I fully agree with both statements. It would be better if you keep such a workaround in your own code, where you build the Eclipse based products from.

We were trying to implement suggestion given by laeubi as recommended in -> #2894 (reply in thread)

[merks]

I think I just need to be really blunt up front. I am 100% opposed to introducing a new fake bundle. This introduces yet another split package which causes so many problems we should avoid it all costs. I really, really think we should not go down this dark path.

You still fail to explain (and probably haven't tested) how all these places will function when they bind to the empty placeholder that does not provide the classes being imported and used:

Moreover, you fail to explain how p2 will decide/choose which thing to install? Probably both because they're split packages and then OSGi will need to decide how to link these, which you recognize is a problem, in fact a problem on all platforms. As such, you are creating new problems to solve problems that don't exist on our supported platforms. This is just not a good path...

Again, sorry for being so blunt...