The javadocs for the class java.security.BasicPermission says, that the naming convention for BasicPermission names follows the hierarchical property naming convention with possible wildcards. AFAIU, *hierarchical property naming convention* assumes that you specify either a simple identifier like *user*, or a sequence of dot-separated identifiers like *user.group.id <http://user.group.id> - *so what is the purpose for names like *user. *with a dot at the end? It seems like it contradicts the documentation and has no purpose.
On Fri, Nov 29, 2013 at 8:16 PM, Tom Hawtin <tom.haw...@oracle.com> wrote: > On 29/11/2013 15:46, Alex Yursha wrote: > > // make sure ap.path is longer so a.b.* doesn't imply a.b >> > ^. > Somebody has removed the full stop from the sentence fragment. I'll give > you that this class API docs should be better. > > > return (that.path.length() > this.path.length()) && >> that.path.startsWith(this.path); >> > > As the highlighted comment states, the length comparison check is >> performed in order to prevent such cases where "a.b.*" would imply >> "a.b". But the contract for java.lang.String.startsWith() is such that >> if the prefix length is greater than the string length than that test >> will fail. So it seems like java.security.BasicPermission.implies() >> tries to duplicate the check that is performed by >> java.lang.String.startswith() out of the box. >> > > So, suppose we had permissions with names "a.b.*" and "a.b.". These have > paths "a.b." and "a.b." (respectively, or not). startsWith will return > true, but the length comparison false. > > So > > - the check is not redundant > - a.b. is not implied by a.b.* > - BasicPermission does not correctly specify behaviour of wildcards > (should probably have a CR) > > Tom >
