Geir Magnusson Jr. wrote:
Dan> That includes the language protection features like Geir's
Dan> example of package private,
...
Sorry for not following up on some of my previous remarks on
such things. But briefly, here's a trick that works,
without any need for language-based module support (which would
be much nicer, and will surely come for J2SE7, but isn't
strictly needed in this case.)
If you have functionality that should only be used
across the packages inside the JDK library,
and never by users, define it as (non-static) public method of a
class (defined outside of java.* packages) that has no public
constructors, but does have a factory method.
That factory method includes the one bit of pure VM magic: It
must only allow creation (or return a singleton) if the calling class
is in bootclasspath, otherwise throwing some kind of exception.
(The implementation of this check is just a specialization of
other kinds of security checks JVMs must do.)
Of course all JDK classes using such functionality should never pass
around references to such classes. (This is one of the places where
language support is needed).
You'd like to define as few such classes as possible.
It would be nice to standardize these across JVMs, but
as I mentioned before, this is hard because JVM implementors
want these internal APIs to remain flexible.
This is probably the best way to handle all of those aspects
of required Java APIs that cannot be described as bytecodes and/or
require close Java<->JVM coupling for the sake of efficiency.
This scheme also applies to replacements for "native" in those
cases where the implementation is not a call to native code,
but is instead "intrinsified", causing a JIT to produce custom
instructions, as in the JikesRVM "magic" classes.
I believe that the lack of such a facility might be one
reason for some JVMs not yet supporting java.util.concurrent,
which requires something like this to support compareAndSet
instructions etc which must be intrinsified for performance
to be acceptable.
-Doug
