Hi Alexey, I believe the current implementation for "java.compiler" follows specification for j.l.System.getProperties() which mandates this property. And there is a bug against documentation [1], which in particular says: "As far as I know, the "java.compiler" property was only meaningful in our earlier JDK releases (pre-1.4) which included the Classic VM (now EOL'd); it could be used to specify a JIT compiler that works with the Classic VM. However, when we switched to the HotSpot VM, this property was being maintained just for compatibility reasons; the HotSpot VM simply ignores it."
Your assert about java.lang.Compiler seems valid, feel free to file a JIRA. Yet, there is a suggestion to deprecate it [2], and probably it should fall into "non-bug difference" category. So until we have real-life necessity for the java.lang.Compiler API, I don't think it will be fixed. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5043991 [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4285505 -- thanks, Alexey 2007/5/25, Aleksey Ignatenko <[EMAIL PROTECTED]>:
Hi all, I want to ask about future of j.l.Compiler class in Harmony. I see in drlvm kernel classes that most j.l.Compiler functions are implemented with minimum spec requirements and do not provide any JIT related functionality. My question is if drlvm needs to support alternative JIT compiler using j.l.Compiler functionality in future. The only way to effect JIT I know is options like -Xem:opt, -Xem:jet and so on. Also I found that property java.compiler is set to "client" value by default in Harmony (but not set in RI). Spec says that it is assumed to be the name of a JIT library which is to be loaded by JVM with loadLibrary method. After it was loaded java_lang_Compiler_start() is called to start JIT. Can we consider this to be a bug in Harmony and file JIRA?
Thanks, Aleksey Ignatenko.
