# Re: Issue regarding inner classes

William Maddox (maddox@p-1.eng.sun.com)
Fri, 5 Sep 1997 12:02:14 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Dan Rudman: "Security Mechanism Direction Query"
- Previous message: Jan Luehe: "Re: Use of Providers"

    Date: Fri, 5 Sep 1997 12:02:14 -0700 (PDT)

    From: William Maddox <maddox@p-1.eng.sun.com>

    To: SSidi@DeltaCorp.com

    Subject: Re: Issue regarding inner classes

    In-Reply-To: <199709051537.IAA26225@mate.eng.sun.com>

> > From: "Sidi, Shah" <SSidi@DeltaCorp.com>
> > To: "'java-security@java.sun.com'" <java-security@web2.javasoft.com>
> > Subject: Issue regarding inner classes
> > Date: Thu, 4 Sep 1997 19:13:39 -0400
> >
> > Hi,
> >
> > We are considering using Java for one of our development projects &
> > are doing some prototyping with it.
> >
> > We ran into an issue & were wondering if there was a work around for
> > it. It seems like one cannot access even non-private members of the
> > containing class from an inner class when classes are NOT loaded from
> > CLASSPATH. We ran into this issue when we trying to load an applet &
> > related classes from the web server. Please note that one can access
> > non-private members of the containing class from inner classes if
> > classes are loaded locally using CLASSPATH variable. We have been able
> > to re-create this issue on AppletViewer (JDK 1.1.3 & JDK 1.1.2) & Hot
> > Java Browser.
> >
> > We are currently using JDK1.1.3 on Windows 95 platform.
> >
> > This seems to be a significant issue to us & any advice or workaround
> > will be greatly appreciated. Thank you.
> >
> > Regards, Shah

Your message was forwarded to me, as I am currently working on fixing
the inner-class related bugs in javac.

Classes that are loaded from CLASSPATH are not examined by the verifier,
unlike those loaded from the network by a browser. It is a known problem
that accesses to a *private* member of a containing class from within an
inner class will in many circumstances produce code that will not pass the
verifier. The standard workaround is to promote the offending member to
package visibility, and has been used successfully by many users. I am
surprised to hear that you are having problems with *non-private* members
as well. Are you using the "-O" option to javac? It is also a known problem
that the "-O" switch may sometimes result in unverifiable code. I would be
interested in seeing an example that exhibits the failure you describe.

William Maddox

- Next message: Dan Rudman: "Security Mechanism Direction Query"
- Previous message: Jan Luehe: "Re: Use of Providers"