Deduplicating code in BsdUserDefinedFileAttributeView and LinuxUserDefinedFileAttributeView
Sebastian Stenzel
sebastian.stenzel at gmail.com
Thu Jan 21 05:18:08 UTC 2021
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?
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?).
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?
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.
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.
Cheers,
Sebastian
More information about the nio-dev
mailing list