This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Illegal Package-Private Accesses in 3.4


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?
It seems that StackTrace really belongs to java.lang since not only
VmThrowable, but probably also Class, ClassLoader and SecurityManager
can use its funtionality.

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]