Jeroen, > Would you like to work with me to try to refactor the way system > properties are handled to untangle the initialization dependencies and > to allow you to use more Classpath code as-is?
I'd like to use more of Classpath as-is but I don't think the particular dependencies we have can be solved other than by doing the changes we did. Basically we can't do any string actions until we initialize the EncodingManager and alias properties, and that requires the System properties to function straight away. Only if all these changes were moved into the new system property class would it work for us. And while I'd like to help with the general problem I frankly don't have the time available to do so - sorry. > Whenenever code tries to access a package and a security manager is > installed, SecurityManager.checkPackageAccess() is called, so all we > need to do is all the gnu.classpath package to the package.access system > property. Isn't that test in reflection only? For normal accesses wouldn't you be relying on the class resolution process to identify access control errors - and in this case wouldn't a public class with public methods pass VM access control checks regardless (unless an internal VM access control hook is used)? I'm confused again about what is being proposed: a public API with some kind of runtime check to deny access, or a private API with a runtime check to allow access (doPrivileged?) ? The former still seems to need VM magic, while the latter would require too much security infrastructure to be in place too early in the initialization process. David Holmes _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
