Deduplicating code in BsdUserDefinedFileAttributeView and LinuxUserDefinedFileAttributeView

[Alan Bateman]

On 21/01/2021 05:18, Sebastian Stenzel wrote:
> Hi all,
>
> since we decided to keep the scope of JDK-8030048 (UserDefinedFileAttributeView for macOS) as small as possible, there is still some potential for cleanup. Most importantly: Remove duplications that I introduced by adding BsdUserDefinedFileAttributeView.
>
> I'm writing this to get discussions on a yet to be defined issue started, that sets the scope of said cleanup. So here is a number of questions and suggestions:
>
> 1. Since I'm new to OpenJDK: Is it common to always use the latest language features or should I restrain myself in favour of backports?
It's okay to use the latest languages features. There are periodically 
limitations, for example it wasn't possible until very recently to use 
the  pattern matching with the instanceof operator due to the bootstrap 
JDK being used to create reference docs. There is a long history where 
it wasn't possible to use newer languages features until very late in a 
release or even the next release.

> 2. The main goal is, obviously, deduplication. I.e. a lot of code from the Linux* and Bsd* classes can be moved to their parent: Unix*. We have to keep in mind though, that their sibling Aix* doesn't support UserDefinedAttributeView. Since there are minor differences between BsdNativeDispatcher and LinuxNativeDispatcher, I'd like to know if it's ok to make UnixNativeDispatcher abstract or whether there is a reason why they shouldn't be (any problems with JNI and abstract classes?).
That would be disruptive change. UnixNativeDispatcher.c already has to 
deal with issues like this and it's okay if the it compiles to 
JNU_ThrowInternalError on AIX. In modules/java.base/Java.gmk you'll seen 
a few examples where specific classes are included/excluded. In this 
case, I assume you will include UnixUserDefinedFileAttributeView in the 
Linux and macOS builds.

>
> 3. NativeBuffer gets used a lot. Is this future proof? Or is it soon to be replaced by the Foreign-Memory Access API? How about using ByteBuffers in conjunction with JNI's GetDirectBufferAddress and GetDirectBufferCapacity instead?
This code uses the internal Unsafe for off-heap memory, it may be that 
further down the road we will replace it with memory segments. I don't 
think this should have any impact on the disucssion here.


> 4. If question (1.) can be answered with "yes" and the answer to question (3.) is "stick with NativeBuffer": Can we have NativeBuffer implement AutoCloseable? There are plenty occurrence that would benefit from a try-with-resource statement.
Yes, this is a good idea.

> 5. Can I somehow convince GitHub Actions to run a specific test case that is not usually included in tier 1 tests? I'm asking because the area that needs rework relies on such a test.
I think there is some configuration needed, maybe someone else can help 
on this.

-Alan.