Re: Newbie Joe-E questions

David Wagner wrote:
> 2) Currently, the Joe-E taming database is very minimalistic.  The policy
> is "deny-by-default", meaning that if we haven't gotten around to taming
> a particular portion of the Java library, then that portion of the
> library will be inaccessible to Joe-E code by default -- and we haven't
> gotten around to taming more than a tiny fraction of the Java library.
> You might encounter this in other cases, where Joe-E code would like to
> access some field/method of the Java libraries and where providing
> access to that field/method would be OK (it wouldn't contradict any
> capability principles) but because we haven't provided a taming database
> for that portion of the Java libraries, you can't.  In those cases, the
> only way to proceed would be to extend the taming database yourself.
> You may be hitting this issue as well (e.g., in the warnings regarding
> Scanner and PrintStream, which indeed have no taming policy specified
> for them yet).
>
>
> Let me comment on 1) above some more.  The obvious question is:
> If Joe-E code is never allowed to gain any capabilities on its own
> (only to receive capabilities passed to it), where does Joe-E code
> get interesting capabilities from in the first place?  This is the
> bootstrapping problem.  The canonical way to deal with this right
> now is probably to build your application as a combination of Java and
> Joe-E code.  The startup code (e.g., the implementation of main()) might
> be written in Java.  Java code is unconstrained by the Joe-E verifier,
> so it can directly access System.in and System.out.  The startup code
> would then instantiate some Joe-E classes and invoke them, passing them
> any capabilities they need to do their job.  Thus you might write the
> bulk of your application in Joe-E.  Those Joe-E application classes
> might expect you to pass them an InputStream and an OutputStream.
> Your Java startup code could then just instantiate those classes and
> pass System.in/System.out as an argument to their constructors.
>
> I realize this may be a bit confusing; I'm not sure if that made
> sense.  Sorry about that.
>
>
>   
I understand the explanation, but I'm still not sure how to go about the 
solution.  I don't actually want to pass an entire Scanner object to my 
UI code, so let's say I do a quick and dirty tame: ScannerWrapper, that 
only allows one or two methods. Then in the constructor for my UI code I 
would say something like:

public exampleUI(ScannerWrapper s){
    myWrapper = s;
}

However even this would cause the verifier to complain, because now the 
import declaration would be something like:

import mypackage.ScannerWrapper;

which,  of course isn't in the taming database.  So how do I go about 
modifying the database to allow my own tamed classes?

Thanks again for your help,
Jimmy Wylie