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
