[E-Lang] Coming Attractions: Java Overload Resolution

[Mark S. Miller]

At 12:10 PM Saturday 3/24/01, Bill Frantz wrote:
>What happens if maintenance to the Java code adds new methods with
>additional subclasses for a parameter.  It may be that E code that worked
>with the old Java code now finds two methods which are "acceptable" and
>gets an exception.

There's no good answer for this I know of, but the following is E's new bad 
answer.  But first...

<background> 
E has long had a "sugaring" mechanism for adding or changing 
the public methods associated with instances of a Class -- from E's 
perspective.  The public methods added to E's view of instances of pkg.Foo 
are provided by static public methods of org.erights.e.meta.pkg.FooSugar.

Unlike Java, E is a world of pure instances.  The public constructors and 
static public methods of pkg.Foo are seen from E as being normal methods of 
Foo's maker object.  An "<import:pkg.Foo>" or "<unsafe:pkg.Foo>" evaluates 
to this maker object.  The methods added to E's view of Foo's maker are 
provided by static public methods of org.erights.e.meta.pkg.FooMakerSugar.

These sugar classes can be seen at the bottom of 
http://www.erights.org/javadoc/overview-summary.html .

These extra methods can either add to new messages to the object's protocol 
or they can override the behavior of an exiting method.  
</background>

Starting with the upcoming 0.8.9t, I finally added a feature that was 
supposed to be there all along -- the ability to explicitly list all the 
Java public methods that should be available from E.  For example, and also 
as an example answer to your question, java.lang.Character has two 
overloadings of "compareTo" with one argument:

    compareTo(Object)
    compareTo(Character)

In the draft 0.8.9t release, CharacterSugar declares the specially 
recognized static public final variable SAFEJ, listing by signatures the 
instance methods of class Character that should be visible from E:

    public class CharacterSugar {

        static public final String[] SAFEJ = {
            //"charValue()", subsumed by asInteger()
            //"compareTo(Character)", would conflict
            "compareTo(Object)" //since nothing coerces to a char, we
                                 //don't need to override this
        };
        ...
    }

The new interim rules for sugaring a class:

The only methods visible to E are be methods inherited from supertypes, also 
according to these
sugaring rules, plus (and overridden by) the public instance methods of the 
class, according to SAFEJ (see below), plus (and overridden by) the methods 
added by the *Sugar class if any.  

If there is no SAFEJ variable, then, for now at least, all the public 
instance methods of the class are included.  If there is a static public 
SAFEJ variable, then only the the public instance methods of the class whose 
signatures are listed will be included.


Four upcoming transitions:

* The SAFEJ feature must also be added to *MakerSugar classes, with the 
obvious corresponding meaning -- it lists the public constructors and public 
static methods to be made available.

* For classes that only need a SAFEJ and not any new methods, a lighter 
weight way of providing this info than a *Sugar and *MakerSugar class per 
class must be found, such as a parseable *.safej file as a resource in the 
classpath.  As part of this task, we should build a tool to generate initial 
candidate *.safej files for the entire JDK 1.3 API, listing all the methods 
as disabled.

* The import__uriGetter should refuse to import Java classes that don't have 
SAFEJ declaration in their corresponding *Sugar and *MakerSugar information.

* The unsafe__uriGetter should likewise refuse.


After these four transitions, we'll finally have a good answer to your 
question.  No Java method will be available from E without a deliberate 
decision by an E-aware Java-level programmer (who is, therefore, a 
programmer within the TCB).  When this E is run on a later version of Java 
with more methods, none of those methods would show up, and therefore they 
can't influence the overload decision.

Obviously, the main motivation for this isn't overload resolution, but 
security.


        Cheers,
        --MarkM