----- Original Message ----- From: "Peter Donald" <[EMAIL PROTECTED]> To: "Ant Developers List" <[EMAIL PROTECTED]> Sent: Monday, February 11, 2002 12:08 Subject: Re: <javac>, System.exit() and security managers
> On Tue, 12 Feb 2002 04:30, Steve Loughran wrote: > > I dont see significant backwards compatibility issues here, unless there is > > another aspect of the security manager I am missing. (yes I know about 1.1 > > versus 1.2+ issues; we'd have to compile a different SM for each VM and use > > reflection to pick the appropriate one at run time) > > Some code changes behaviour when a SM is present - regardless of what > permissions are assigned or not. In other cases it is a requirement that a SM > be installed (and a Policy) prior to the class being loaded for things to > work gracefully (ie to have correct permissions assigned to codebase). In > other cases the object must be created post policy installation because the > constructor will do things like grab the current AccessControllerContext. > > These things happen for such commonly used classes as URLClassLoader. Which > is why I don't think it is an option in ant1.x because we either have to > break code due to SM changes or change CLassLoader hierarchy and break code > that way ;( > I still think that because this only an issue when we load in-VM with failonerror=true, that we arent going to break functionality for any currently correct configuration of the <java> task. Anyone who has the fork=false, failonerror=true needs to be notified right now that that combination is invalid. Either we stop that combination from being valid (throw BuildException, warn in big letters) or we do what we can to implement the behavior. Also, what do we do about handling exceptions in non-forked java? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
