[FileSystem] Simplify and modernize NativeHandlers

[HannesWell]

No description provided.

[github-actions]

Test Results

 1 734 files  ±0   1 734 suites  ±0   1h 26m 47s ⏱️ + 2m 2s
 3 971 tests ±0   3 949 ✅ ±0   22 💤 ±0  0 ❌ ±0 
12 510 runs  ±0  12 349 ✅ ±0  161 💤 ±0  0 ❌ ±0 

Results for commit c868e15. ± Comparison against base commit 6f2754b.

[jukzi]

The title "modernize" is to vague. Please explicitly describe what you have done - and why. i don't even get why Path.of() should be any better.
The implicit exists() check seems to be good!

[jukzi]

remove todo

[jukzi]

please add a junit test if this behaves like before for hidden files as the code contains comments that opening hidden files can lead to FileNotFoundException. See uses of org.eclipse.core.filesystem.EFS.ATTRIBUTE_HIDDEN

[jukzi]

you can look at https://github.com/eclipse-platform/eclipse.platform/pull/1444/files#diff-81300c5bdd85b0fca987936ae34590fbf4bbf835119e1efd68698461d230b817R252 how to create a hidden file.
But to me it is not clear how/if the Defaulthandler is tested in CI

[HannesWell]

I'll have a look at the tests.

i don't even get why Path.of() should be any better.

Paths.get() was only introduced because back then static methods on interfaces were not supported. When it was possible Path.of was added, as a method that is easier to discover/remember/read. And since both are technical equal I don't see a reason to not use it.

[jukzi]

And since both are technical equal I don't see a reason to not use it.

I would also use Path for new code, but is it worth to enlarge the git history with rewriting it?

[akurtakov]

I would also use Path for new code, but is it worth to enlarge the git history with rewriting it?

As the PR is not just about that and what is questioned removes one useless method call from the chain - it is worth it.