Re: native methods and ClassLoaders

gback@cs.utah.edu
Mon, 13 Apr 1998 16:32:45 -0600 (MDT)

From: gback@cs.utah.edu
Message-Id: <199804132232.QAA00498@lal.cs.utah.edu>
Subject: Re: native methods and ClassLoaders
To: gong@games.eng.sun.com (Li Gong)
Date: Mon, 13 Apr 1998 16:32:45 -0600 (MDT)
In-Reply-To: <199804132226.PAA09416@games.eng.sun.com> from "Li Gong" at Apr 13, 98 03:26:23 pm

Thanks for the quick reply!

What about the first part of the question: does the presence
of native methods prevent me from redefining classes?

Or can I parse your answer such that "having native methods" is synonymous
to being "core/system" or "present on CLASSPATH"?

Thanks,

Godmar

>
>
> All core/system classes are not supposed to be redefined. In other
> words, in 1.1.5, everything present on CLASSPATH cannot be redefined.
>
> Li
>
> Godmar Back writes:
> >
> > Hi,
> >
> > this is a question concerning JDK 1.1.5.
> >
> > * Can a class defined by a class loader via defineClass have any
> > native methods?
> >
> > * Clearly, some classes cannot be redefined(*): calling defineClass for
> > java/lang/Object, for instance, will cause an "UnknownError" be thrown.
> > Other classes, such as java.lang.Throwable cannot be redefined because
> > then the verifier will find an athrow instruction doesn't throw a
> > Throwable. I strongly suspect that java.lang.Class can't be
> > redefined, either. Here's my question:
> >
> > Even though I read the JDK documentation, the language specification
> > and the VM specification I could not find any statement telling me just
> > exactly *what* classes can or cannot be redefined. Is this an oversight,
> > or is this intentionally vague and left to the implementation?
> >
> > Thank you,
> >
> > Godmar (gback@cs.utah.edu)
> >
> > ps: please cc: me on the reply.
> >
> > (*) By "redefined" I mean to call defineClass with the bytes read from
> > classes.zip.
> >
>