This is the mail archive of the
mailing list for the Java project.
Re: Illegal Package-Private Accesses in 3.4
Mark Wielaard writes:
> On Mon, 2003-08-11 at 14:20, Andrew Haley wrote:
> > Bryce McKinlay writes:
> > > On Monday, Aug 11, 2003, at 18:45 Pacific/Auckland, Mark Wielaard wrote:
> > >
> > > OK, go ahead. I guess StackTrace does conceptually belong in java.lang
> > > due to its close relationship with Throwable.
> Thanks. But... (see Andrew his comment below).
> > > 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.
> I agree with Andrew here. StackTrace offers much more functionality then
> what is required by VMThrowable.
> > > >> 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.
> I don't agree with you here though. I like the fact that in
> principle package local classes can be used to shield the user from
> the implementation details. Public classes define the API, the
> package local classes work together to provide the
> implementation. And since packages can be sealed a compiler/VM can
> optimize lots of package local stuff since it knows nothing outside
> the package will override or inherit package local classes/methods.
> So you object to StackTrace moving into java.lang as my patch does?
Not really. I can live with it. But...
> It seems that StackTrace really belongs to java.lang since not only
> VmThrowable, but probably also Class, ClassLoader and
> SecurityManager can use its funtionality.
But that's just a coincidence. It just-so-happens that the classes
that want to use StackTrace are in java.lang. If we define StackTrace
to be package private in java.lang then we will force everyone that
wants to access StackTrace to be in java.lang. But what about
> Then I have to work around the illegal package private accesses in
> another way (and I really would like to get rid of the public
> methods in StackTrace and a security check is probably to heavy for
> this particular class).
Exactly. So define a native helper method, make it a friend of
StackTrace, and you're done.