Interestingly, IBM wrote about compileClass() in http://www.ibmsystemsmag.com/i5/september02/developer/8100p3.aspx
``For most JVMs, the method compileClass isn't implemented. [...] This compileClass method was enabled to assist developers who wish to verify that the JIT is able to compile every method in their jar files. Developers need only write a small Java program, which loads and then requests compilation of each class. Thus developers can prove that the JIT doesn't take any internal errors while processing the code.'' This seems especially useful for coping with JIT compiler probems as long as a JIT compiler is not fully mature, which clearly applies to the (even non-existent) Android JIT compiler. IBM's support for java.lang.Compiler in their JVM is further outlined at http://publib.boulder.ibm.com/infocenter/realtime/v1r0/index.jsp?topic=/com.ibm.rt.doc.10/realtime/rt_jit.html Sun's latest Java SE JDK7 documentation at http://download.java.net/jdk7/docs/api/java/lang/Compiler.html still includes java.lang.Compiler for optional use by a JVM, even though their own JVM may indeed not support it (which does not matter for Android as it has its own JVM). Of course I too would prefer a full-fledged auto-profiling JIT compiler, but the timeline for its availability is totally unclear (there's nothing about JIT on the Android roadmap), which was reason to propose intermediate solutions under the condition that this would indeed not imply much additional effort but rather help scaffold the development process. Dan is in a much better position to properly balance such development trade-offs. Regards --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" 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-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
