The role of java.security.acl in Java 2 security

Question

I have been trying to assess the role of the java.security.acl package within the Java 2 Security architecture. I have some questions regarding it.
First where in the JVM are the interfaces of java.security.acl used? Are there any examples out there to guide developers in understanding their proper implementation?
What is the relationship between this package and the core security package? There seems to be a Permission interface in the acl sub-package and an abstract Permission class in the core security package. Why is this the case? Why is the core abstract class not used instead of declaring a new Permission interface within the acl subpackage?
Are not PermissionCollections and Permissions analogous to ACLs? If so then wouldn't that fact make the acl subpackage redundant?
JSR 115 tries to bridge the gap between Java 2 Security in the SDK with security in J2EE. Namely enabling the RBAC-like approach to security in J2EE while using the AccessController of the J2SE to do the evalualtion of J2EE (Servlet/EJB) Permissions. Why are the Group and Owner interfaces defined here not leveraged in both JSR 115 and in general for Role Based Access Control?
Could someone give some background on the vision behind creating the acl subpackage and how it relates to the historical progression of security advances in Java security architectures?
Thanks much,
Alex Karasulu

Answer 1

I see from the defined interfaces that its an attempt at a formal approach to RBAC. However RBAC can be implemented without it all together using existing J2SE and JAAS based constructs. This does not answer the redundancy question. Could you elaborate a little bit more?
Thanks,
Alex