classpath
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]