Yes, it's OK in Java to extend SecureClassLoader, but I don't think it's going to help you, unless there's a whole lot of magic I don't know about.
The dalvik VM doesn't use Java's standard byte codes. You'd have to post-process them into the stack machine format it does use. I have no idea how feasible that is, but it's definitely going to be harder than just generating Sun's byte codes. Or you could generate them directly -- either way, I expect you have a lot fewer examples and tools to work from. I'm guessing you'd need to work with DexClassLoader somehow. The byte codes themselves are defined in dalvik.bytecode.Opcodes -- but I don't see enough support to make that fact actually useful. Anyway, the package index for the SDK is at: http://developer.android.com/intl/fr/reference/packages.html and javax.tools is not on the list. You might be able to port enough of the tool chain to Android to be able to do the job -- but I can't think of a job that would make it worth it. On Feb 21, 8:37 pm, lordjoe <[email protected]> wrote: > When I try to use code similar to that > inhttp://www.javablogging.com/dynamic-in-memory-compilation/I > find the classes will compile but get a java.lang.VerifyError on > execution - the class uses > javax.tools.JavaCompiler and javax.tools.ToolProvider and one > supporting class uses > javax.tools.ForwardingJavaFileManager and > java.security.SecureClassLoader - > > Any bright ideas - is it OK to use a class loader extending > java.security.SecureClassLoader? > > Are these packages unavailable on the android and if so is there a > list of unavailable packages -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
