Re: BC-compile java.lang.management

[Andrew Haley <aph at redhat dot com>]

Tom Tromey writes:
 > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
 > 
 > Andrew> 	* java/lang/Thread.java (getStackTrace): Use reflection to call
 > Andrew> 	the ManagementFactory.
 > 
 > Haha, this is so evil.
 > 
 > Andrew> 	* scripts/makemake.tcl: Add new "bcheaders" type.
 > Andrew> 	Move java/lang/management and gnu/classpath/management to "bc".
 > Andrew> 	Move gnu/java/lang/management to "bcheaders".
 > 	
 > Two questions here.
 > 
 > Can't this break sometimes?  Since we'll have CNI code using
 > BC-compiled things?

No: the CNI code is only called, and they're all static functions.

 > Do we need to have javax.management also be BC?

I don't think so.  After this patch, there are no direct references
into javax.management from anywhere in libgcj.  So, as long as there
is some other javax.management implementation installed, the built-in
javax.management will never be called, either by libjava or by
BC-compiled client code.  non-BC client code will work too, as long as
it's compiled against the right set of jars.

 > Andrew> 	* gnu/classpath/management/ListenerData.java: Move here from
 > Andrew> 	gnu/classpath/ListenerData.java.
 > 
 > I don't see why this should be in gnu.classpath at all.  That package
 > is, IMO, reserved for configuration-ish things and for things which
 > user code must really really be prevented from seeing,
 > i.e. security-sensitive stuff.
 > 
 > How about gnu.javax.management?

OK.  I have no idea why it's in gnu.classpath either.

Andrew.