[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Class methods
From: |
Archie Cobbs |
Subject: |
Re: Class methods |
Date: |
Thu, 20 Feb 2003 20:58:39 -0800 (PST) |
Tom Tromey wrote:
> Archie> It seems from a first look that these java.lang.Class methods
> Archie> which are currently native:
> Archie> Class.getClasses()
> Archie> [ ... ]
>
> Archie> could be implemented entirely in Java, by relying on these methods:
> Archie> Class.getDeclaredClasses()
> Archie> [ ... ]
>
> Archie> Would this work? It would save a lot of native code writing
> Archie> for JVM implementors.
>
> I took a quick look at this. The various methods make different
> SecurityManager calls. So a straightforward implementation wouldn't
> be correct.
Hmmm, maybe I'm confused. I was thinking something along these lines...
public Field[] getFields() {
// Do security manager check
// call getFieldsNoSecurityCheck()
}
public Field[] getDeclaredFields() {
// Do security manager check
// call getDeclaredFieldsNoSecurityCheck()
}
private Field[] getFieldsNoSecurityCheck() {
// call getDeclaredFieldsNoSecurityCheck()
if (this.isInterface())
// recurse: superclass.getFieldsNoSecurityCheck()
else {
// recurse: superinterface.getFieldsNoSecurityCheck()
// for all superinterfaces
}
// return combined array
}
private native Field[] getDeclaredFieldsNoSecurityCheck();
// same idea for getMethods(), getConstructors(), and getClasses()
I was planning on doing this whether or not it was merged into Classpath.
Is there a fundamental problem with this approach I'm not seeing?
Thanks for taking the time to look at this.
Cheers,
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com