[cap-talk] David Wagner's Google techtalk is now up!

[David Wagner]

Mike Samuel writes:
>Public classes, and classes within the same package are ambiently available,
>but you contradict a lot of people's assumptions if you make private inner
>classes ambiently available.

Oh dear.  Well, in trying to concisely hint at Joe-E stance on this,
my attempt at brevity came with a corresponding loss of accuracy, which
unsurprisingly seems to have caused confusion.  My apologies.

Thanks for following up on this.  Let me try again, this time in a bit
more detail.  Hopefully it will alleviate your concerns.

In Java, one can write
    Class c = Foo.class;
where Foo is any class you can name.  (For instance, you can name a
public class, but you generally cannot name private inner classes.)
Joe-E allows you to write Foo.class in the same cases where Java does.

As for the use of runtime reflection, Joe-E will provide libraries that
act as a wrapper around the Java reflection libraries.  Joe-E's libraries
will include access control checks to enforce our security policy.
The intended security policy is that you can do something at runtime
using reflection only if you could have done it statically by writing it
in the source code.  For instance, if the Java compiler wouldn't let you
write foo.m() (e.g., because m() is a private method of Foo and foo's
static declared type is Foo), then you shouldn't be able to use Joe-E's
reflection libraries to invoke m() on foo at runtime, either.

Hopefully this will be sufficient to avoid violating people's
expectations.

Does this seem like a reasonable stance?

>Proxying allows you to do things with private inner classes and
>package private classes that you can't do statically.

Joe-E's proxy libraries had better not let you do that.
(If they do, it's a bug, but I don't think they do.)

Note that Joe-E does not expose Java reflection libraries directly;
instead, Joe-E provides wrapper classes (written by Tyler) that enforce
the necessary security checks.