FULL PRODUCT VERSION :
java version "10" 2018-03-20
Java(TM) SE Runtime Environment 18.3 (build 10+46)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+46, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Linux phillip-desktop.local.schich.tel 4.16.0-1-mainline #1 SMP PREEMPT Thu Mar 29 04:10:46 CEST 2018 x86_64 GNU/Linux

EXTRA RELEVANT SYSTEM CONFIGURATION :
Archlinux with Mainline kernel.


A DESCRIPTION OF THE PROBLEM :
Java supports user_xattr since version 7 in the form of a file attribute view: https://docs.oracle.com/javase/7/docs/api/java/nio/file/attribute/UserDefinedFileAttributeView.html
Support for this view can be tested using Files.getFileStore(Paths.get("/path")).supportsFileAttributeView(UserDefinedFileAttributeView.class).
This function will internally extract the mount options from /proc/mounts and check for the user_xattr option. On recent kernels the user_xattr option is the default and there now only exists nouser_xattr. The implementation in LinuxFileStore also special cases ext3 and ext4 explicitly as "does not support extended attributes by default", so the function directly terminates with "no support" instead of going on with probing the file system for support by calling fgetxattr. I guess this implementation is from a time when this was actually true, though I don't understand why the special case was added when the fgetxattr call would have yielded the exact same result.

Taken from downstream report: https://bugs.archlinux.org/task/58057

REGRESSION. Last worked in version 8u162

ADDITIONAL REGRESSION INFORMATION:
openjdk version "1.8.0_162"
OpenJDK Runtime Environment (build 1.8.0_162-b12)
OpenJDK 64-Bit Server VM (build 25.162-b12, mixed mode)


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Call Files.getFileStore(Paths.get("/path")).supportsFileAttributeView(UserDefinedFileAttributeView.class) with a path on an ext4 file system with user_xattr enabled by default.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Expected result would be true for filesystems like ext4 that support user_xattr.
ACTUAL -
Result is false on ext4 filesystems even though it is supported and enabled.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
No crash occurs, just a wrong result.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.nio.file.*;
import java.nio.file.attribute.UserDefinedFileAttributeView;

public class Ext4XattrTest {
    public static void main(String[] args) throws Exception {
        if (args.length == 0) {
            System.out.println("No path provided");
            System.exit(1);
        }
        Path path = Paths.get(args[0]);
        FileStore store = Files.getFileStore(path);
        if (store.supportsFileAttributeView(UserDefinedFileAttributeView.class)) {
            System.out.println("user_xattr is supported!");
        } else {
            System.err.println("user_xattr is NOT supported!");
            System.exit(1);
        }
    }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Two possible workarounds:

1) Using reflection to cirumvent the LinuxFileStore class and directly instantiate the view. Example can be seen here from my project: https://github.com/pschichtel/ConvertedSync/blob/ac8bdbf852160375e0b4e2a075a7c0b765b11a02/src/main/scala/tel/schich/convertedsync/io/Ext4AttrAccess.java

2) Creating a file at "${java.home}/lib/fstypes.properties" with the following content:
ext4=user_xattr