Illegal Package-Private Accesses in 3.4

[Andrew Haley]

Bryce McKinlay writes:
 > On Monday, Aug 11, 2003, at 18:45 Pacific/Auckland, Mark Wielaard wrote:
 > 
 > >> Since NameFinder and StackTrace are both in the same package, wouldn't
 > >> a simpler solution be to pass "trace" itself and have NameFinder call
 > >> the stackTraceAddrs?
 > >
 > > But for not just this, but also for the public access reason (and
 > > because StackTrace does have some nice methods that will be useful for
 > > implementing some of the SecurityManger things) StackTrace and
 > > NameFinder are no longer in the same package (with my patch).
 > 
 > OK, go ahead. I guess StackTrace does conceptually belong in java.lang 
 > due to its close relationship with Throwable. In fact, perhaps 
 > StackTrace and the VMThrowable class should be merged?

VMThrowable is a Classpath compatibility layer.  Its interfaces are
only there for "middleware" purposes, so it's better to keep it
isolated.

 > >> It would be cleaner to keep these things in the same package wherever
 > >> possible. If we're worried about user code calling NameFinder being a
 > >> security risk, we could add a security check to its constructor.
 > >
 > > Then I would vote for moving NameFinder also inside java.lang as 
 > > package
 > > private.
 > 
 > Actually I think its fine where it is.

Me too.  I know that Java encourages the usage of package private, but
the idea of putting all this stuff on java.lang is rather horrible.
I'd rather use native methods and friend where it's necessary to do
some cross-cutting.  That would ensure that only java.lang.VMThrowable
would be able to call StackTrace methods, not all of java.lang.  Much
cleaner, better modularity.

Andrew.