8030048: (fs) Support UserDefinedFileAttributeView/extended attributes on OS X / HFS+

[Alan Bateman]

On 08/01/2021 13:45, JaniruTEC wrote:
>
> My employer wrote a proof of concept that heavily utilizes the 
> existing linux code to create a BSD implementation, which can be found 
> here: 
> https://urldefense.com/v3/__https://github.com/skymatic/jdk/tree/feature/macos-xattr__;!!GqivPVa7Brio!L6gpaYGumU5fAqlD9-_hNfdJmKqmm7A-bNPr8wRolGyrMcK0m2CIYGz9g3TTKra8sg$ 
>
> We have a few questions now:
> - Since BSD and Linux share so much code, we believe deduplication 
> could be a reasonable matter. Should this be part of this PR or a 
> second one? Is deduplication even a matter you wish us to pursue?
> - The Linux implementation doesn't utilize newer java features. Which 
> is the latest java version the BSD Implementation should utilize 
> features of? Should the Linux version be updated as well? How does 
> backporting affect this decision?
> - At what point in time should the PR be created? Is communication 
> over Mail or over the PR preferred?
If this is mostly a clone of the implementation from src/java.base/linux 
then it may make sense to move it to src/java.base/unix and then have it 
conditionally compiled in on the platforms that support it. We haven't 
needed to do anything significant on that attribute view is a long time 
so modernizing make sense too. My personal preference is to have the 
changes be as easy to review as possible. If we can't see the diffs in 
the files change and/or webrev view then it will awkward to review. So 
if you can split into 2 or 3 patches then it might be easier. If the 
patches are small then starting with a PR is okay. If the changes are 
large then it's better to discuss and get agreement on the mailing lists 
before trying to get detailed reviews.

I don't think I understand your question about the BSD port as it is 
maintained in a downstream project. We just maintain the macOS port here.

-Alan