Re: Re: Visibility

On Thu, 24 Mar 2005, Daniel Bonniot said:
 > Rohan Hart wrote:
 >> Surely JVM visibility must support *all* of the Nice visibility
 >> semantics?  Otherwise there's the danger of Java code subverting,
 >> deliberately or not, Nice visibility.

 > Even Java rules cannot all be enforced by JVM visibility. For instance, try
 > accessing a private member from an inner class. javac creates an accessor
 > method with package visibility, which opens the possibility for such
 > subversion.

Interesting!  In that case there's special protection in the JVM from
"package injection" so external malicious code will still be thwarted.

 > Such rules enforced at the source level only are still useful, not from a
 > security point of view but from a software engineering one.

Agreed.  Perhaps such visibility modifiers should avoid names which
could be misconstrued as strong statements about the security
provided.

 >> Given that Nice methods are associated with packages rather than
 >> classes what meaning are you attributing to "private"?  Private makes
 >> more sense for fields but then there'd be no method which could access
 >> them.

 > private would restrict visibility to a single "module". (Typically
 > a module is a source file

I wonder if the additional complexity is worthwhile.  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.

 > If a module contains only one class, then we could use that class
 > to put the methods of the module, which would also allow to enforce
 > private fields. (we could even reject modules that define several
 > classes with private fields, to guarantee we always enforce privacy
 > at the bytecode level)

Which moves closer to one class plus attendant private-field accessing
methods per module.

 >> Yes.  I see it as corresponding somewhat to Java's "final", so there's
 >> likely a mixture of good and bad points around providing it.  I
 >> mentioned it mostly because it can be enforced with JVM visibilities,
 >> by stopping Java code from sub-classing the method's dispatcher class.

 > What do you mean by "the method's dispatcher class"?

The class in which the method's dispatcher method resides.  Sorry, it
appears that some of my ruminating on avoiding code jumping past the
dispatcher and calling implementations directly (by making the
implementations visible only to the dispatcher) has affected my memory
of the current situation... specifically that dispatcher methods are
static.

 > Could you give some motivations why "local" would be useful? Concrete
 > examples?

Not at present.  Your argument, especially the example where just
importing two packages can cause a compiler error, has convinced me
that this particular suggestion should be dropped.

 >> Sorry, lost me there.  What aspect of (multiple-inheritance based?)
 >> ambiguity here affects the visibility?

 > Here is the potential problem:

 > package p1;
 > interface I {}
 > interface I1 extends I {}
 > interface I2 extends I {}

 > private String foo(I);
 > foo(I1 i1) = ...;
 > foo(I2 i2) = ...;

 > package p2; import p1;
 > class A implements I1,I2 {}

 > // ambiguity about foo(new A())

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).

 > If foo was public, you could solve the ambiguity in p2.

How?  Is there support for specifying which parent branch to search
first?

 > With the restriction of no dispatch on interfaces for non-public
 > methods, this case is ruled out.

Maybe the weaker restriction of no dispatch on *public* interfaces in
non-public methods?

Disallowing diamond inheritance would be another option.  Which is
more useful I don't know.

Rohan



-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click