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
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
