A DESCRIPTION OF THE PROBLEM :
When working with hard links it can be useful to know the underlying inode number for e.g. disk space usage calculations. The current Java API allows you to test if two files are the same, but, doesn't let you get access to the underlying ID for use in things like hashmaps.

On UNIX the inode and link counts are in fact exposed via NIO attributes, it just isn't a documented part of the spec.

Windows assigns every file on a volume a unique 128-bit GUID, which is the equivalent of an inode number. When combined with the volume ID it's actually a true GUID that should be unique for every file in the world (neat!). The Windows NIO provider reads this value, and stores it in the WindowsFileAttributes structure, but doesn't expose it in the API.

To aid with writing apps that use hard links, it'd be good to expose these numbers in an API stable way. The implementation cost is low because the data is already being read - the work is in defining what the API looks like.

Alternatively, I'd also take an OpenJDK specific attribute for the Windows ID, like nlinks and ino are today.