Re: Re: Visibility

On Thu, 24 Mar 2005, Daniel Bonniot said:
 >> Interesting!  In that case there's special protection in the JVM from
 >> "package injection" so external malicious code will still be thwarted.

 > Can you give a reference about this?

from JVM spec v2

    5.4.4 Access Control
    (http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#75929)
    
    A class or interface C is accessible to a class or interface D if
    and only if either of the following conditions are true: ...
        * C and D are members of the same runtime package (§5.3). 
    
    A field or method R is accessible to a class or interface D if and
    only if any of the following conditions is true: ...
        * R is either protected or package private (that is, neither
          public nor protected nor private), and is declared by a
          class in the same runtime package as D.

    ----------------------------------------
    5.3 Creation and Loading
    (http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#72007)

    At run time, a class or interface is determined not by its name
    alone, but by a pair: its fully qualified name and its defining
    class loader. Each such class or interface belongs to a single
    runtime package. The runtime package of a class or interface is
    determined by the package name and defining class loader of the
    class or interface.

So, to defeat package injection attacks make sure to load untrusted
jars/classes with a different classloader.  This probably can't be
enforced by the Nice runtime itself unfortunately.

 > Doesn't this mean that if we need to turn some private into package we could
 > get the same protection?

Yes

 >> There's still a disjoint between fields, scoped to the class, and
 >> methods, scoped to the module - perhaps the 'private' keyword
 >> should be replaced by 'module' or some other term to avoid
 >> confusing existing Java programmers.

 > No, my idea is that private would always be scoped to the module,
 > for fields as well.  It would be somewhat contrary to the Nice feel
 > to assign such meaning to classes, and in particular to make a
 > difference between methods defined inside and outside the class (in
 > the same module).

That's what I thought you meant.  Fields are, however, definitely
attached to classes and are defined that way.  The obvious (for me at
least) semantics for private in that situation is to restrict
visibility to the enclosing scope.

  package A;
  // module A1;     // new keyword for header?
  class a {
    private int i;  // enclosing scope is the class
  }

For simplicity perhaps the more radical suggestion of having each
package definition in a single file and only public and package
visibility.

 >> Is this ambiguity detected?  I tried a similar diamond inheritance
 >> problem and found that one of the implementations was chosen (at
 >> random at compile time).

 > In what language? In Nice all ambiguities are detected. I just tried this
 > situation, you get the following error:

Ah, I see that I did have a default implementation... 

  package diamond;
  
  interface top {
    int diamond() = 1;
  }
  
  interface left implements top {
    diamond() = 2;
  }
  interface right implements top {
    diamond() = 3;
  }
  
  class bottom implements right, left {}
  
  void _testDiamond() {
    let b = new bottom();
    println(b.diamond());
  }

This doesn't raise an error in 0.9.11 prerelease (build 2005.03.24,
17:47:57 UTC) and happily prints "2".  Not what I'd expect.

 > I don't think there is a problem here. Dispatch on interfaces is
 > not allowed at all in most languages (even with single dispatch).

A clarification please: are you suggesting removing interface-typed
parameters from the dispatch calculation or disallowing method
definitions which involve any interface-typed parameters?

 > Thanks for the discussion, it helps a lot figuring out what the
 > design space is. I think a quite satisfactory solution is emerging.

My pleasure.

Rohan



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click