Hi, Vinay. This looks good, but I think we'll need to revert the AclEntry portion of the change. There are various unit tests that rely on assertEquals or assertArrayEquals to check that the correct ACL was applied to a file. With this change, those assertEquals calls would pass even if the permissions inside the ACL entries were incorrect. Even putting aside tests, this is a public user-facing class, and callers likely would find it surprising if "user:bruce:rwx" and "user:bruce:---" were considered equal.
With this reason only I have earlier included permissions also from command line for -x.
But in this case, say permissions are not passed from the commandline, but the ACLEntries contain ACL for same user/group with some permissions. In this case, permissions will differ and objects also will differ.
In general, there will be only one ACL entry per user/group in each type no matter what are the permissions. I agree that we cannot consider "user:bruce:rwx" and "user:bruce:---" as equal, but also both these entries cannot be present in list of ACL entries right?
So my preference is that we need to check for permissions separately whenever necessary, instead of including in equals() and hashCode().
What you say?