Please take a review at
http://cr.openjdk.java.net/~weijun/8170364/webrev.00/
The compatibility layer introduced in the new FilePermission implementation
requires one FilePermission to imply another with either a relative path or an
absolute path. This is solved with a private field npath2 inside. When this
field is set, the permission's name is modified a little (JDK-8168127) so that
when adding to a FilePermissionCollection, it is not confused with one without
the field. Unfortunately, this modified name is reused in the merge to create a
new "merged" FilePermission which contains a malformed path now.
This fix creates a new non-public method to create this "merged" FilePermission.
I checked other places and seems the name is not used to create a new
FilePermission.
Thanks
Max