Replace native UnixFileHandler by Java NIO to fetch/put file-info

[HannesWell]

With Java-25 the java.nio.file APIs have similar performance like the native C implementations invoked by the UnixFileHandler.
In order to reduce native code and native fragments, remove the UnixFileHandler in favor of the org.eclipse.core.internal.filesystem.local.PosixHandler.

The native LinuxFileHandler (and consequently the org.eclipse.core.filesystem.linux.x86_64 fragment) remains partially because the native implementation to list directory contents is still significantly faster. But its methods to fetch/put file-infos delegate to PosixHandler and the native code for that is removed.

When this is submitted, the removed fragments should be removed from the org.eclipse.platform feature too:

• https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/0528fb3f471de65cac061921f846a972588ce598/eclipse.platform.releng/features/org.eclipse.platform-feature/feature.xml#L211-L226

Fixes #302

@iloveeclipse could you please review this? It would also be great if you could check if my clean-up of the native code was complete and not too much, since I don't have the native build pipelines set up at the moment.
At the same time I wouldn't update the native binaries since I hope that we can replace it either with FFM bindings or even some standard Java API.

Furthermore it would be great if somebody on macOS could test this change too.

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

resources/bundles/org.eclipse.core.filesystem.linux.x86_64/META-INF/MANIFEST.MF
resources/bundles/org.eclipse.core.filesystem.linux.x86_64/pom.xml

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 9f2454382589788da6e5af4b01f19b1a32980555 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Sat, 12 Sep 2026 14:30:29 +0000
Subject: [PATCH] Version bump(s) for 4.42 stream


diff --git a/resources/bundles/org.eclipse.core.filesystem.linux.x86_64/META-INF/MANIFEST.MF b/resources/bundles/org.eclipse.core.filesystem.linux.x86_64/META-INF/MANIFEST.MF
index c87b4505a5..6931428e8f 100644
--- a/resources/bundles/org.eclipse.core.filesystem.linux.x86_64/META-INF/MANIFEST.MF
+++ b/resources/bundles/org.eclipse.core.filesystem.linux.x86_64/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %fragmentName
 Bundle-SymbolicName: org.eclipse.core.filesystem.linux.x86_64; singleton:=true
-Bundle-Version: 1.2.500.qualifier
+Bundle-Version: 1.2.600.qualifier
 Bundle-Vendor: %providerName
 Fragment-Host: org.eclipse.core.filesystem;bundle-version="[1.11.500,2.0.0)"
 Bundle-Localization: fragment
diff --git a/resources/bundles/org.eclipse.core.filesystem.linux.x86_64/pom.xml b/resources/bundles/org.eclipse.core.filesystem.linux.x86_64/pom.xml
index c44e07f8d4..656c1f6701 100644
--- a/resources/bundles/org.eclipse.core.filesystem.linux.x86_64/pom.xml
+++ b/resources/bundles/org.eclipse.core.filesystem.linux.x86_64/pom.xml
@@ -18,7 +18,7 @@
     <relativePath>../../</relativePath>
   </parent>
   <artifactId>org.eclipse.core.filesystem.linux.x86_64</artifactId>
-  <version>1.2.500-SNAPSHOT</version>
+  <version>1.2.600-SNAPSHOT</version>
   <packaging>eclipse-plugin</packaging>
 
   <profiles>
-- 
2.55.0

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

[iloveeclipse]

Will try next week.
FYI, last time I've experimented with FFM, AI agent (I believe Opus 4.8) was able to replace all JNI handlers here with unified and better looking "C" code (in FFM) for all Unix platforms, which would allow to get rid of native C code parts completely.

[Copilot]

🟡 Changes recommended

The test bundle no longer compiles, the native-disable switch is ignored, and macOS immutable-file support is lost.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Replaces Unix JNI file-info operations with Java NIO while retaining optimized Linux directory listing.

Changes:

• Delegates POSIX metadata operations to PosixHandler.
• Removes Unix native code and obsolete platform fragments.
• Retains and versions the Linux x86_64 fast-listing fragment.

File summaries

File	Description
resources/tests/org.eclipse.core.tests.filesystem.feature/feature.xml	Removes macOS fragment.
resources/bundles/org.eclipse.core.filesystem/src/org/eclipse/core/internal/filesystem/local/unix/UnixFileNatives.java	Removes Unix JNI bridge.
resources/bundles/org.eclipse.core.filesystem/src/org/eclipse/core/internal/filesystem/local/unix/UnixFileHandler.java	Removes Unix handler.
resources/bundles/org.eclipse.core.filesystem/src/org/eclipse/core/internal/filesystem/local/unix/UnixFileFlags.java	Removes native constants.
resources/bundles/org.eclipse.core.filesystem/src/org/eclipse/core/internal/filesystem/local/unix/StructStat.java	Removes Unix stat mapping.
resources/bundles/org.eclipse.core.filesystem/src/org/eclipse/core/internal/filesystem/local/LocalFileNativesManager.java	Selects NIO or fast Linux handling.
resources/bundles/org.eclipse.core.filesystem/src/org/eclipse/core/internal/filesystem/local/linux/LinuxFileNatives.java	Retains only directory-listing JNI.
resources/bundles/org.eclipse.core.filesystem/src/org/eclipse/core/internal/filesystem/local/linux/LinuxFileHandler.java	Delegates metadata operations to NIO.
resources/bundles/org.eclipse.core.filesystem/natives/unix/unixfile.h	Removes Unix JNI declarations.
resources/bundles/org.eclipse.core.filesystem/natives/unix/unixfile.c	Removes Unix JNI implementation.
resources/bundles/org.eclipse.core.filesystem/natives/unix/README.TXT	Removes obsolete build guidance.
resources/bundles/org.eclipse.core.filesystem/natives/unix/macosx/Makefile	Removes macOS native build.
resources/bundles/org.eclipse.core.filesystem/natives/unix/linux/Makefile	Removes legacy Linux build.
resources/bundles/org.eclipse.core.filesystem/natives/unix/fastlinux/fastlinuxfile.h	Removes unused metadata JNI declarations.
resources/bundles/org.eclipse.core.filesystem/natives/unix/fastlinux/fastlinuxfile.c	Removes unused metadata JNI functions.
resources/bundles/org.eclipse.core.filesystem/META-INF/MANIFEST.MF	Stops exporting removed Unix package.
resources/bundles/org.eclipse.core.filesystem.macosx/pom.xml	Removes fragment build definition.
resources/bundles/org.eclipse.core.filesystem.macosx/META-INF/MANIFEST.MF	Removes fragment manifest.
resources/bundles/org.eclipse.core.filesystem.macosx/fragment.properties	Removes fragment metadata.
resources/bundles/org.eclipse.core.filesystem.macosx/build.properties	Removes packaging configuration.
resources/bundles/org.eclipse.core.filesystem.macosx/BUILD_INFO.txt	Removes native build record.
resources/bundles/org.eclipse.core.filesystem.macosx/about.html	Removes fragment legal page.
resources/bundles/org.eclipse.core.filesystem.macosx/.settings/org.eclipse.core.runtime.prefs	Removes project settings.
resources/bundles/org.eclipse.core.filesystem.macosx/.settings/org.eclipse.core.resources.prefs	Removes project encoding setting.
resources/bundles/org.eclipse.core.filesystem.macosx/.project	Removes Eclipse project metadata.
resources/bundles/org.eclipse.core.filesystem.linux.x86_64/pom.xml	Increments fragment version.
resources/bundles/org.eclipse.core.filesystem.linux.x86_64/META-INF/MANIFEST.MF	Increments OSGi version.
resources/bundles/org.eclipse.core.filesystem.linux.ppc64le/pom.xml	Removes fragment build definition.
resources/bundles/org.eclipse.core.filesystem.linux.ppc64le/META-INF/MANIFEST.MF	Removes fragment manifest.
resources/bundles/org.eclipse.core.filesystem.linux.ppc64le/fragment.properties	Removes fragment metadata.
resources/bundles/org.eclipse.core.filesystem.linux.ppc64le/build.properties	Removes packaging configuration.
resources/bundles/org.eclipse.core.filesystem.linux.ppc64le/about.html	Removes fragment legal page.
resources/bundles/org.eclipse.core.filesystem.linux.ppc64le/.settings/org.eclipse.core.runtime.prefs	Removes project settings.
resources/bundles/org.eclipse.core.filesystem.linux.ppc64le/.settings/org.eclipse.core.resources.prefs	Removes project encoding setting.
resources/bundles/org.eclipse.core.filesystem.linux.ppc64le/.project	Removes Eclipse project metadata.
resources/bundles/org.eclipse.core.filesystem.linux.loongarch64/pom.xml	Removes fragment build definition.
resources/bundles/org.eclipse.core.filesystem.linux.loongarch64/META-INF/MANIFEST.MF	Removes fragment manifest.
resources/bundles/org.eclipse.core.filesystem.linux.loongarch64/fragment.properties	Removes fragment metadata.
resources/bundles/org.eclipse.core.filesystem.linux.loongarch64/build.properties	Removes packaging configuration.
resources/bundles/org.eclipse.core.filesystem.linux.loongarch64/about.html	Removes fragment legal page.
resources/bundles/org.eclipse.core.filesystem.linux.loongarch64/.settings/org.eclipse.core.runtime.prefs	Removes project settings.
resources/bundles/org.eclipse.core.filesystem.linux.loongarch64/.settings/org.eclipse.core.resources.prefs	Removes project encoding setting.
resources/bundles/org.eclipse.core.filesystem.linux.loongarch64/.project	Removes Eclipse project metadata.
resources/bundles/org.eclipse.core.filesystem.linux.aarch64/pom.xml	Removes fragment build definition.
resources/bundles/org.eclipse.core.filesystem.linux.aarch64/META-INF/MANIFEST.MF	Removes fragment manifest.
resources/bundles/org.eclipse.core.filesystem.linux.aarch64/fragment.properties	Removes fragment metadata.
resources/bundles/org.eclipse.core.filesystem.linux.aarch64/build.properties	Removes packaging configuration.
resources/bundles/org.eclipse.core.filesystem.linux.aarch64/about.html	Removes fragment legal page.
resources/bundles/org.eclipse.core.filesystem.linux.aarch64/.settings/org.eclipse.core.runtime.prefs	Removes project settings.
resources/bundles/org.eclipse.core.filesystem.linux.aarch64/.settings/org.eclipse.core.resources.prefs	Removes project encoding setting.
resources/bundles/org.eclipse.core.filesystem.linux.aarch64/.project	Removes Eclipse project metadata.

Review details

Suppressed comments (2)

resources/bundles/org.eclipse.core.filesystem/src/org/eclipse/core/internal/filesystem/local/LocalFileNativesManager.java:52

• Changing this signature leaves BenchFileStore calling setUsingNative(natives, useFastLinuxNatives), so the resources test bundle no longer compiles. Those benchmarks also still expect the removed generic Unix-native mode to be selectable; update or remove those cases together with this API change.
  resources/bundles/org.eclipse.core.filesystem/src/org/eclipse/core/internal/filesystem/local/LocalFileNativesManager.java:54
• Removing the Unix-handler fallback drops macOS support for the public EFS.ATTRIBUTE_IMMUTABLE capability: the old handler fetched and changed UF_IMMUTABLE/SF_IMMUTABLE, while PosixHandler neither advertises nor processes that attribute. This also makes the immutable assertions in Bug_329836 silently skip. Preserve a macOS implementation for this attribute or provide an equivalent NIO-based implementation before removing the fragment.

• Files reviewed: 51/56 changed files
• Comments generated: 1
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[iloveeclipse]

Seeing the readlink native code removed, I believe this would be a problem for this: #2798, because NIO can't recognize broken links if I remember it right.

[HannesWell]

Will try next week.

Thank you, no rush from my side.

FYI, last time I've experimented with FFM, AI agent (I believe Opus 4.8) was able to replace all JNI handlers here with unified and better looking "C" code (in FFM) for all Unix platforms, which would allow to get rid of native C code parts completely.

Yes, in my experience (but only with smaller cases), AI agents can generate native code quite reliable.
But if the performance is on par, I think using plain old Java APIs should still be favored. And to improve determinism I think it would be good to use tools like jextract to generate the FFM bindings.
I used that approach in #2908.
AI agents can certainly help with setting that up too. And I belive that if we start to migrate larger code bases like SWT that would be beneficial for the long term maintenance. Furthermore we might build better integration that allows us to automatically stream-line the generated code and e.g. remove unused elements.

But that's for the future. This PR mostly just removes the native handler that seems not to be beneficial anymore.

[iloveeclipse]

And to improve determinism I think it would be good to use tools like jextract to generate the FFM bindings.

In my experiment, AI agent proposed to use different, better portable and modern Unix API (don't ask me which). jextract would probably just blindly convert JNI to FFM. But I guess AI should be able to optimize jextact generated code too.
But whatever it willbe, getting rid of native build would be great for 4.42.

[github-actions]

Test Results

    51 files   -   3      51 suites   - 3   54m 25s ⏱️ - 4m 1s
 4 810 tests ±  0   4 786 ✅  -   2   22 💤 ±0  2 ❌ +2 
12 061 runs   - 260  11 906 ✅  - 262  153 💤 ±0  2 ❌ +2 

For more details on these failures, see this check.

Results for commit 8665ca1. ± Comparison against base commit 31b3f6a.

♻️ This comment has been updated with latest results.

[HannesWell]

And to improve determinism I think it would be good to use tools like jextract to generate the FFM bindings.

In my experiment, AI agent proposed to use different, better portable and modern Unix API (don't ask me which). jextract would probably just blindly convert JNI to FFM. But I guess AI should be able to optimize jextact generated code too.

In general jextract just generates the FFM binding code for functions, structs and constants, i.e. function descriptors and memory layouts from given C header files. It avoids generating and maintaining these bindings and generates the corresponding java methods for these native functions. But the APIs are still low level and it can make sense to wrap them in 'hand-written' higher level methods.
Jextract doesn't translate JNI code in any way. So the selection of APIs and the logic still has to be implemented manually or by an AI.

But whatever it willbe, getting rid of native build would be great for 4.42.

Yes, that's at least my goal for 4.42 to replace JNI and JNA for everything than SWT (and maybe already some parts of SWT). And until now I believe that's doable.