RE: Moving system properties to gnu.classpath.*

[David Holmes]

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