As suggest in https://mail.openjdk.java.net/pipermail/nio-dev/2021-March/008514.html, in a first step to clean up code in UnixUserDefinedFileAttributeView, we will deduplicate code in `list()` and `copyExtendedAttributes()`. Both methods share almost identical chunks of code around the native `flistxattr()` call.
The difference between both methods lies primarily in the filtering of `user:` attributes, as currently done in `asList(...)`. The logic that increases the buffer size in case of `ERANGE` (currently implemented as for-loops in both methods) should be moved to a shared private method.
The filtering for `user:` attributes should be done where it is required, not as a side effect of `asList(...)`.
The `buffer` variable should not longer get re-assigned, so its lifecycle is easy to understand and errors are avoided.
The difference between both methods lies primarily in the filtering of `user:` attributes, as currently done in `asList(...)`. The logic that increases the buffer size in case of `ERANGE` (currently implemented as for-loops in both methods) should be moved to a shared private method.
The filtering for `user:` attributes should be done where it is required, not as a side effect of `asList(...)`.
The `buffer` variable should not longer get re-assigned, so its lifecycle is easy to understand and errors are avoided.
- blocks
-
JDK-8264112 (fs) Reorder methods/constructor/fields in UnixUserDefinedFileAttributeView.java
-
- Resolved
-
- relates to
-
JDK-8264111 (fs) Leaking NativeBuffers in case of errors during UnixUserDefinedFileAttributeView.read/write
-
- Resolved
-
