[e-lang] Newbie Joe-E questions

[Adrian Mettler]

Thanks for your interest in Joe-E!

The taming database is defined using .safej files.  Placing a file in 
mypackage/ScannerWrapper.safej that lists the constructors, methods, and 
fields from ScannerWrapper class that are safe to use will allow them to 
be used by Joe-E code.  I don't currently have good documentation on the 
format of .safej files, but it shouldn't be hard to infer by looking at 
the existing .safej files that are provided for some of the Joe-E 
library classes.  There exists code to generate the safej file, but 
unfortunately it isn't currently exposed with a UI -- I may add one for 
the upcoming release.

-Adrian

Jimmy Wylie wrote:
> 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
> _______________________________________________
> e-lang mailing list
> e-lang at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang