Re: [drlvm] “java.compiler” property
The patch is in JIRA: http://issues.apache.org/jira/browse/HARMONY-1902 Please review it. Note: we will have interpreter.emconf file if the patch is accepted. On 10/17/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/10/17, Mikhail Fursov [EMAIL PROTECTED]: On 10/17/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Seemingly default Java properties are not significant for components loading and should be set after all components init, no overriding. I'm agree if we are speaking only about default Java properties. VM can set them up right before execution of the first Java method. Sure, I thought I stressed that enough. Apparently VM-intrinsic properties drive component loading and must be set up early. -- Mikhail Fursov - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mikhail Fursov
Re: [drlvm] “java.compiler” property
thanks! Mikhail Fursov wrote: The patch is in JIRA: http://issues.apache.org/jira/browse/HARMONY-1902 Please review it. Note: we will have interpreter.emconf file if the patch is accepted. On 10/17/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/10/17, Mikhail Fursov [EMAIL PROTECTED]: On 10/17/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Seemingly default Java properties are not significant for components loading and should be set after all components init, no overriding. I'm agree if we are speaking only about default Java properties. VM can set them up right before execution of the first Java method. Sure, I thought I stressed that enough. Apparently VM-intrinsic properties drive component loading and must be set up early. -- Mikhail Fursov - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] “java.compiler” property
2006/10/17, Mikhail Fursov [EMAIL PROTECTED]: On 10/17/06, Pavel Pervov [EMAIL PROTECTED] wrote: Mikhail, EM, as I see it, is interchangeable component. Should we require defining java.compiler for interpreted mode from all EMs? EM does not know the semantic of options it adds to the system properties. See client.emconf file to see how options are passed to JIT and EM knows nothing about their meaning. EM configuration is very convenient place to put all options that affect the current execution mode. And if you want to have meaningful java.compiler option a EM configuration file is the only place. My idea is to initialize java.compiler to some default value (none?) in VM, and then overwrite it with actual value wherever actual information is available (in EM in our case). EM does not override system options that are already set. Such a behaviour allows to make cmd-line option to have higher priority then those in EM configuration file. I would vote to keep the behaviour. This behaviour is fairly reasonable and I agree we should keep it. To solve Pavel's concerns, VM could set this property after EM init if needed. Though this might feel like a hack, this is a matter of when and how VM initializes Java properties (aka public in a recent thread) with default values. Seemingly default Java properties are not significant for components loading and should be set after all components init, no overriding. And one question follows: what if we have three different JITs defined in EM configuration file? :) What value java.compiler will contain in this case? client.emconf already has 3 JITS configured inside. The common name for the configuration is 'client mode' -- Mikhail Fursov - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] “java.compiler” property
On 10/17/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Seemingly default Java properties are not significant for components loading and should be set after all components init, no overriding. I'm agree if we are speaking only about default Java properties. VM can set them up right before execution of the first Java method. -- Mikhail Fursov
Re: [drlvm] “java.compiler” property
since it's apparently undefined by spec, then putting something informational like none or interpreter-only would do no harm? geir Tim Ellison wrote: FWIW in the IBM VM we set to java.compiler= if the JIT is disabled. and the Sun 1.5.0_06 build doesn't set it at all! Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] “java.compiler” property
Moreover, the spec obliges us to do so. The real question is: is it RI bug or bug in spec? Personally I am for returning non-null values in all cases. Regards, 2006/10/16, Geir Magnusson Jr. [EMAIL PROTECTED]: since it's apparently undefined by spec, then putting something informational like none or interpreter-only would do no harm? geir Tim Ellison wrote: FWIW in the IBM VM we set to java.compiler= if the JIT is disabled. and the Sun 1.5.0_06 build doesn't set it at all! Regards, Tim -- Alexei Zakharov, Intel Enterprise Solutions Software Division, Russia - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] “java.compiler” property
On 10/16/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Moreover, the spec obliges us to do so. The real question is: is it RI bug or bug in spec? Personally I am for returning non-null values in all cases. I agree. Just tell me and I will commit the patch for EM(interpreter) and JIT modes. BTW I think that we should create interpreter.emconf file and place all VM properties needed for interpreter into this file. So, in future, when we need to add more interpreter-mode option, we will not affect the EM C++ code. -- Mikhail Fursov
Re: [drlvm] “java.compiler” property
Alexei Zakharov wrote: Moreover, the spec obliges us to do so. The real question is: is it RI bug or bug in spec? Personally I am for returning non-null values in all cases. Sure, and I don't think anyone cares too much what value you choose. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] “java.compiler” property
+1 Mikhail Fursov wrote: On 10/16/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Moreover, the spec obliges us to do so. The real question is: is it RI bug or bug in spec? Personally I am for returning non-null values in all cases. I agree. Just tell me and I will commit the patch for EM(interpreter) and JIT modes. BTW I think that we should create interpreter.emconf file and place all VM properties needed for interpreter into this file. So, in future, when we need to add more interpreter-mode option, we will not affect the EM C++ code. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] “java.compiler” property
I agree. Just tell me and I will commit the patch for EM(interpreter) and JIT modes. I agree it will be better if you do this since I'm not very familiar with DRLVM code yet. So +1 for you to go ahead. Regards, 2006/10/16, Mikhail Fursov [EMAIL PROTECTED]: On 10/16/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Moreover, the spec obliges us to do so. The real question is: is it RI bug or bug in spec? Personally I am for returning non-null values in all cases. I agree. Just tell me and I will commit the patch for EM(interpreter) and JIT modes. BTW I think that we should create interpreter.emconf file and place all VM properties needed for interpreter into this file. So, in future, when we need to add more interpreter-mode option, we will not affect the EM C++ code. -- Alexei Zakharov, Intel Enterprise Solutions Software Division, Russia - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] “java.compiler” property
Ok, if nobody minds I take this task and will provide the patch in a day or two. On 10/16/06, Alexei Zakharov [EMAIL PROTECTED] wrote: I agree. Just tell me and I will commit the patch for EM(interpreter) and JIT modes. I agree it will be better if you do this since I'm not very familiar with DRLVM code yet. So +1 for you to go ahead. Regards, 2006/10/16, Mikhail Fursov [EMAIL PROTECTED]: On 10/16/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Moreover, the spec obliges us to do so. The real question is: is it RI bug or bug in spec? Personally I am for returning non-null values in all cases. I agree. Just tell me and I will commit the patch for EM(interpreter) and JIT modes. BTW I think that we should create interpreter.emconf file and place all VM properties needed for interpreter into this file. So, in future, when we need to add more interpreter-mode option, we will not affect the EM C++ code. -- Alexei Zakharov, Intel Enterprise Solutions Software Division, Russia - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mikhail Fursov
Re: [drlvm] “java.compiler” property
Mikhail, EM, as I see it, is interchangeable component. Should we require defining java.compiler for interpreted mode from all EMs? My idea is to initialize java.compiler to some default value (none?) in VM, and then overwrite it with actual value wherever actual information is available (in EM in our case). And one question follows: what if we have three different JITs defined in EM configuration file? :) What value java.compiler will contain in this case? Regards, Pavel. On 10/16/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/16/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Moreover, the spec obliges us to do so. The real question is: is it RI bug or bug in spec? Personally I am for returning non-null values in all cases. I agree. Just tell me and I will commit the patch for EM(interpreter) and JIT modes. BTW I think that we should create interpreter.emconf file and place all VM properties needed for interpreter into this file. So, in future, when we need to add more interpreter-mode option, we will not affect the EM C++ code. -- Mikhail Fursov
Re: [drlvm] “java.compiler” property
On 10/17/06, Pavel Pervov [EMAIL PROTECTED] wrote: Mikhail, EM, as I see it, is interchangeable component. Should we require defining java.compiler for interpreted mode from all EMs? EM does not know the semantic of options it adds to the system properties. See client.emconf file to see how options are passed to JIT and EM knows nothing about their meaning. EM configuration is very convenient place to put all options that affect the current execution mode. And if you want to have meaningful java.compiler option a EM configuration file is the only place. My idea is to initialize java.compiler to some default value (none?) in VM, and then overwrite it with actual value wherever actual information is available (in EM in our case). EM does not override system options that are already set. Such a behaviour allows to make cmd-line option to have higher priority then those in EM configuration file. I would vote to keep the behaviour. And one question follows: what if we have three different JITs defined in EM configuration file? :) What value java.compiler will contain in this case? client.emconf already has 3 JITS configured inside. The common name for the configuration is 'client mode' -- Mikhail Fursov
Re: [drlvm] “java.compiler” property
The most simple fix: put it into all EM configuration files if you want it
to depend on JIT configuration is used.
On 10/13/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Hi all,
I found that we have some problems with system properties in DRLVM. In
the javadoc for java.lang.System class the particular list of
mandatory properties that should be returned by the getProperties()
method is described. However, DRLVM does not provide the value for the
mandatory java.compiler property. This leads to some problems
including the test failure from the java.lang.management test suite
(HY-1407). This problem was mentioned by Andrey Yakushev [1]. Below
is the small test that checks all mandatory properties:
--
import java.util.*;
public class TestVMProps {
static String[] mandatoryProps = new String[] {
java.version,
java.vendor,
java.vendor.url,
java.home,
java.vm.specification.version,
java.vm.specification.vendor,
java.vm.specification.name,
java.vm.version,
java.vm.vendor,
java.vm.name,
java.specification.version,
java.specification.vendor,
java.specification.name,
java.class.version,
java.class.path,
java.library.path,
java.io.tmpdir,
java.compiler,
java.ext.dirs,
os.name,
os.arch,
os.version,
file.separator,
path.separator,
line.separator,
user.name,
user.home,
user.dir
};
public static void main(String argv[]) {
VectorString missed = new VectorString();
Properties props = System.getProperties();
for (String mandProp: mandatoryProps) {
boolean found = false;
EnumerationString propEnum = (EnumerationString)
props.propertyNames();
while (propEnum.hasMoreElements()) {
String prop = propEnum.nextElement();
if (mandProp.equals(prop)) {
found = true;
break;
}
}
if (!found) {
missed.add(mandProp);
}
}
System.out.println(Number of missed props: + missed.size());
System.out.println(Missed props: + missed);
}
}
--
If invoked on DRLVM:
C:\mydoc\projects\testsC:\Java\harmony-hdk-r450941\jdk\jre\bin\java.exe
TestVMProps
Number of missed props: 1
Missed props: [java.compiler]
On IBM VME:
C:\mydoc\projects\testsC:\Java\harmony-bin\bin\java.exe TestVMProps
Number of missed props: 0
Missed props: []
On RI:
C:\mydoc\projects\testsC:\Java\jdk1.5.0\bin\java.exe TestVMProps
Number of missed props: 1
Missed props: [java.compiler]
You may notice that RI also does not provide the value for
java.compiler. BTW, we have a test in the DRLVM test suite that
should check all mandatory properties –
java.lang.SystemExtensionTest.test_getProperty_Str(). But it seems the
author of the test makes a muddle of logical operators – puts OR
instead of AND. So the test now checks if at least one of mandatory
property is set.
IMHO we should return something for the java.compiler property name.
Any thoughts?
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200610.mbox/[EMAIL
PROTECTED]
(problem 2)
Thanks,
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mikhail Fursov
Re: [drlvm] “java.compiler” property
Mikhail,
Yes, but I think we should have it by default. Another problem is that
we should return something even if we are in the interpreter mode.
Since this property is *mandatory* for all configs. I suggest using
something like none or etc.
Regards,
2006/10/13, Mikhail Fursov [EMAIL PROTECTED]:
The most simple fix: put it into all EM configuration files if you want it
to depend on JIT configuration is used.
On 10/13/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Hi all,
I found that we have some problems with system properties in DRLVM. In
the javadoc for java.lang.System class the particular list of
mandatory properties that should be returned by the getProperties()
method is described. However, DRLVM does not provide the value for the
mandatory java.compiler property. This leads to some problems
including the test failure from the java.lang.management test suite
(HY-1407). This problem was mentioned by Andrey Yakushev [1]. Below
is the small test that checks all mandatory properties:
--
import java.util.*;
public class TestVMProps {
static String[] mandatoryProps = new String[] {
java.version,
java.vendor,
java.vendor.url,
java.home,
java.vm.specification.version,
java.vm.specification.vendor,
java.vm.specification.name,
java.vm.version,
java.vm.vendor,
java.vm.name,
java.specification.version,
java.specification.vendor,
java.specification.name,
java.class.version,
java.class.path,
java.library.path,
java.io.tmpdir,
java.compiler,
java.ext.dirs,
os.name,
os.arch,
os.version,
file.separator,
path.separator,
line.separator,
user.name,
user.home,
user.dir
};
public static void main(String argv[]) {
VectorString missed = new VectorString();
Properties props = System.getProperties();
for (String mandProp: mandatoryProps) {
boolean found = false;
EnumerationString propEnum = (EnumerationString)
props.propertyNames();
while (propEnum.hasMoreElements()) {
String prop = propEnum.nextElement();
if (mandProp.equals(prop)) {
found = true;
break;
}
}
if (!found) {
missed.add(mandProp);
}
}
System.out.println(Number of missed props: + missed.size());
System.out.println(Missed props: + missed);
}
}
--
If invoked on DRLVM:
C:\mydoc\projects\testsC:\Java\harmony-hdk-r450941\jdk\jre\bin\java.exe
TestVMProps
Number of missed props: 1
Missed props: [java.compiler]
On IBM VME:
C:\mydoc\projects\testsC:\Java\harmony-bin\bin\java.exe TestVMProps
Number of missed props: 0
Missed props: []
On RI:
C:\mydoc\projects\testsC:\Java\jdk1.5.0\bin\java.exe TestVMProps
Number of missed props: 1
Missed props: [java.compiler]
You may notice that RI also does not provide the value for
java.compiler. BTW, we have a test in the DRLVM test suite that
should check all mandatory properties –
java.lang.SystemExtensionTest.test_getProperty_Str(). But it seems the
author of the test makes a muddle of logical operators – puts OR
instead of AND. So the test now checks if at least one of mandatory
property is set.
IMHO we should return something for the java.compiler property name.
Any thoughts?
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200610.mbox/[EMAIL
PROTECTED]
(problem 2)
--
Alexei Zakharov,
Intel Enterprise Solution Software Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] “java.compiler” property
none is OK. But if you want a real JIT info the EM config file is the only
valid place to put it.
On 10/13/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Mikhail,
Yes, but I think we should have it by default. Another problem is that
we should return something even if we are in the interpreter mode.
Since this property is *mandatory* for all configs. I suggest using
something like none or etc.
Regards,
2006/10/13, Mikhail Fursov [EMAIL PROTECTED]:
The most simple fix: put it into all EM configuration files if you want
it
to depend on JIT configuration is used.
On 10/13/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Hi all,
I found that we have some problems with system properties in DRLVM. In
the javadoc for java.lang.System class the particular list of
mandatory properties that should be returned by the getProperties()
method is described. However, DRLVM does not provide the value for the
mandatory java.compiler property. This leads to some problems
including the test failure from the java.lang.management test suite
(HY-1407). This problem was mentioned by Andrey Yakushev [1]. Below
is the small test that checks all mandatory properties:
--
import java.util.*;
public class TestVMProps {
static String[] mandatoryProps = new String[] {
java.version,
java.vendor,
java.vendor.url,
java.home,
java.vm.specification.version,
java.vm.specification.vendor,
java.vm.specification.name,
java.vm.version,
java.vm.vendor,
java.vm.name,
java.specification.version,
java.specification.vendor,
java.specification.name,
java.class.version,
java.class.path,
java.library.path,
java.io.tmpdir,
java.compiler,
java.ext.dirs,
os.name,
os.arch,
os.version,
file.separator,
path.separator,
line.separator,
user.name,
user.home,
user.dir
};
public static void main(String argv[]) {
VectorString missed = new VectorString();
Properties props = System.getProperties();
for (String mandProp: mandatoryProps) {
boolean found = false;
EnumerationString propEnum = (EnumerationString)
props.propertyNames();
while (propEnum.hasMoreElements()) {
String prop = propEnum.nextElement();
if (mandProp.equals(prop)) {
found = true;
break;
}
}
if (!found) {
missed.add(mandProp);
}
}
System.out.println(Number of missed props: + missed.size
());
System.out.println(Missed props: + missed);
}
}
--
If invoked on DRLVM:
C:\mydoc\projects\testsC:\Java\harmony-hdk-r450941\jdk\jre\bin\java.exe
TestVMProps
Number of missed props: 1
Missed props: [java.compiler]
On IBM VME:
C:\mydoc\projects\testsC:\Java\harmony-bin\bin\java.exe TestVMProps
Number of missed props: 0
Missed props: []
On RI:
C:\mydoc\projects\testsC:\Java\jdk1.5.0\bin\java.exe TestVMProps
Number of missed props: 1
Missed props: [java.compiler]
You may notice that RI also does not provide the value for
java.compiler. BTW, we have a test in the DRLVM test suite that
should check all mandatory properties –
java.lang.SystemExtensionTest.test_getProperty_Str(). But it seems the
author of the test makes a muddle of logical operators – puts OR
instead of AND. So the test now checks if at least one of mandatory
property is set.
IMHO we should return something for the java.compiler property name.
Any thoughts?
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200610.mbox/[EMAIL
PROTECTED]
(problem 2)
--
Alexei Zakharov,
Intel Enterprise Solution Software Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mikhail Fursov
Re: [drlvm] “java.compiler” property
I agree. I meant the interpreter mode to be tagged with none.
What do others think?
Regards,
2006/10/13, Mikhail Fursov [EMAIL PROTECTED]:
none is OK. But if you want a real JIT info the EM config file is the only
valid place to put it.
On 10/13/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Mikhail,
Yes, but I think we should have it by default. Another problem is that
we should return something even if we are in the interpreter mode.
Since this property is *mandatory* for all configs. I suggest using
something like none or etc.
Regards,
2006/10/13, Mikhail Fursov [EMAIL PROTECTED]:
The most simple fix: put it into all EM configuration files if you want
it
to depend on JIT configuration is used.
On 10/13/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Hi all,
I found that we have some problems with system properties in DRLVM. In
the javadoc for java.lang.System class the particular list of
mandatory properties that should be returned by the getProperties()
method is described. However, DRLVM does not provide the value for the
mandatory java.compiler property. This leads to some problems
including the test failure from the java.lang.management test suite
(HY-1407). This problem was mentioned by Andrey Yakushev [1]. Below
is the small test that checks all mandatory properties:
--
import java.util.*;
public class TestVMProps {
static String[] mandatoryProps = new String[] {
java.version,
java.vendor,
java.vendor.url,
java.home,
java.vm.specification.version,
java.vm.specification.vendor,
java.vm.specification.name,
java.vm.version,
java.vm.vendor,
java.vm.name,
java.specification.version,
java.specification.vendor,
java.specification.name,
java.class.version,
java.class.path,
java.library.path,
java.io.tmpdir,
java.compiler,
java.ext.dirs,
os.name,
os.arch,
os.version,
file.separator,
path.separator,
line.separator,
user.name,
user.home,
user.dir
};
public static void main(String argv[]) {
VectorString missed = new VectorString();
Properties props = System.getProperties();
for (String mandProp: mandatoryProps) {
boolean found = false;
EnumerationString propEnum = (EnumerationString)
props.propertyNames();
while (propEnum.hasMoreElements()) {
String prop = propEnum.nextElement();
if (mandProp.equals(prop)) {
found = true;
break;
}
}
if (!found) {
missed.add(mandProp);
}
}
System.out.println(Number of missed props: + missed.size
());
System.out.println(Missed props: + missed);
}
}
--
If invoked on DRLVM:
C:\mydoc\projects\testsC:\Java\harmony-hdk-r450941\jdk\jre\bin\java.exe
TestVMProps
Number of missed props: 1
Missed props: [java.compiler]
On IBM VME:
C:\mydoc\projects\testsC:\Java\harmony-bin\bin\java.exe TestVMProps
Number of missed props: 0
Missed props: []
On RI:
C:\mydoc\projects\testsC:\Java\jdk1.5.0\bin\java.exe TestVMProps
Number of missed props: 1
Missed props: [java.compiler]
You may notice that RI also does not provide the value for
java.compiler. BTW, we have a test in the DRLVM test suite that
should check all mandatory properties –
java.lang.SystemExtensionTest.test_getProperty_Str(). But it seems the
author of the test makes a muddle of logical operators – puts OR
instead of AND. So the test now checks if at least one of mandatory
property is set.
IMHO we should return something for the java.compiler property name.
Any thoughts?
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200610.mbox/[EMAIL
PROTECTED]
(problem 2)
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] “java.compiler” property
Once EM runs interpreter it can set up this option by itself. ?
On 10/13/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
I agree. I meant the interpreter mode to be tagged with none.
What do others think?
Regards,
2006/10/13, Mikhail Fursov [EMAIL PROTECTED]:
none is OK. But if you want a real JIT info the EM config file is the
only
valid place to put it.
On 10/13/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Mikhail,
Yes, but I think we should have it by default. Another problem is that
we should return something even if we are in the interpreter mode.
Since this property is *mandatory* for all configs. I suggest using
something like none or etc.
Regards,
2006/10/13, Mikhail Fursov [EMAIL PROTECTED]:
The most simple fix: put it into all EM configuration files if you
want
it
to depend on JIT configuration is used.
On 10/13/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Hi all,
I found that we have some problems with system properties in
DRLVM. In
the javadoc for java.lang.System class the particular list of
mandatory properties that should be returned by the
getProperties()
method is described. However, DRLVM does not provide the value for
the
mandatory java.compiler property. This leads to some problems
including the test failure from the java.lang.management test
suite
(HY-1407). This problem was mentioned by Andrey Yakushev
[1]. Below
is the small test that checks all mandatory properties:
--
import java.util.*;
public class TestVMProps {
static String[] mandatoryProps = new String[] {
java.version,
java.vendor,
java.vendor.url,
java.home,
java.vm.specification.version,
java.vm.specification.vendor,
java.vm.specification.name,
java.vm.version,
java.vm.vendor,
java.vm.name,
java.specification.version,
java.specification.vendor,
java.specification.name,
java.class.version,
java.class.path,
java.library.path,
java.io.tmpdir,
java.compiler,
java.ext.dirs,
os.name,
os.arch,
os.version,
file.separator,
path.separator,
line.separator,
user.name,
user.home,
user.dir
};
public static void main(String argv[]) {
VectorString missed = new VectorString();
Properties props = System.getProperties();
for (String mandProp: mandatoryProps) {
boolean found = false;
EnumerationString propEnum = (EnumerationString)
props.propertyNames();
while (propEnum.hasMoreElements()) {
String prop = propEnum.nextElement();
if (mandProp.equals(prop)) {
found = true;
break;
}
}
if (!found) {
missed.add(mandProp);
}
}
System.out.println(Number of missed props: +
missed.size
());
System.out.println(Missed props: + missed);
}
}
--
If invoked on DRLVM:
C:\mydoc\projects\testsC:\Java\harmony-hdk-r450941\jdk\jre\bin\java.exe
TestVMProps
Number of missed props: 1
Missed props: [java.compiler]
On IBM VME:
C:\mydoc\projects\testsC:\Java\harmony-bin\bin\java.exe
TestVMProps
Number of missed props: 0
Missed props: []
On RI:
C:\mydoc\projects\testsC:\Java\jdk1.5.0\bin\java.exe TestVMProps
Number of missed props: 1
Missed props: [java.compiler]
You may notice that RI also does not provide the value for
java.compiler. BTW, we have a test in the DRLVM test suite that
should check all mandatory properties –
java.lang.SystemExtensionTest.test_getProperty_Str(). But it seems
the
author of the test makes a muddle of logical operators – puts OR
instead of AND. So the test now checks if at least one of
mandatory
property is set.
IMHO we should return something for the java.compiler property
name.
Any thoughts?
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200610.mbox/[EMAIL
PROTECTED]
(problem 2)
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mikhail Fursov
Re: [drlvm] “java.compiler” property
sounds good :)
Alexei Zakharov wrote:
I agree. I meant the interpreter mode to be tagged with none.
What do others think?
Regards,
2006/10/13, Mikhail Fursov [EMAIL PROTECTED]:
none is OK. But if you want a real JIT info the EM config file is
the only
valid place to put it.
On 10/13/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Mikhail,
Yes, but I think we should have it by default. Another problem is that
we should return something even if we are in the interpreter mode.
Since this property is *mandatory* for all configs. I suggest using
something like none or etc.
Regards,
2006/10/13, Mikhail Fursov [EMAIL PROTECTED]:
The most simple fix: put it into all EM configuration files if you
want
it
to depend on JIT configuration is used.
On 10/13/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Hi all,
I found that we have some problems with system properties in
DRLVM. In
the javadoc for java.lang.System class the particular list of
mandatory properties that should be returned by the getProperties()
method is described. However, DRLVM does not provide the value
for the
mandatory java.compiler property. This leads to some problems
including the test failure from the java.lang.management test suite
(HY-1407). This problem was mentioned by Andrey Yakushev [1].
Below
is the small test that checks all mandatory properties:
--
import java.util.*;
public class TestVMProps {
static String[] mandatoryProps = new String[] {
java.version,
java.vendor,
java.vendor.url,
java.home,
java.vm.specification.version,
java.vm.specification.vendor,
java.vm.specification.name,
java.vm.version,
java.vm.vendor,
java.vm.name,
java.specification.version,
java.specification.vendor,
java.specification.name,
java.class.version,
java.class.path,
java.library.path,
java.io.tmpdir,
java.compiler,
java.ext.dirs,
os.name,
os.arch,
os.version,
file.separator,
path.separator,
line.separator,
user.name,
user.home,
user.dir
};
public static void main(String argv[]) {
VectorString missed = new VectorString();
Properties props = System.getProperties();
for (String mandProp: mandatoryProps) {
boolean found = false;
EnumerationString propEnum = (EnumerationString)
props.propertyNames();
while (propEnum.hasMoreElements()) {
String prop = propEnum.nextElement();
if (mandProp.equals(prop)) {
found = true;
break;
}
}
if (!found) {
missed.add(mandProp);
}
}
System.out.println(Number of missed props: +
missed.size
());
System.out.println(Missed props: + missed);
}
}
--
If invoked on DRLVM:
C:\mydoc\projects\testsC:\Java\harmony-hdk-r450941\jdk\jre\bin\java.exe
TestVMProps
Number of missed props: 1
Missed props: [java.compiler]
On IBM VME:
C:\mydoc\projects\testsC:\Java\harmony-bin\bin\java.exe
TestVMProps
Number of missed props: 0
Missed props: []
On RI:
C:\mydoc\projects\testsC:\Java\jdk1.5.0\bin\java.exe TestVMProps
Number of missed props: 1
Missed props: [java.compiler]
You may notice that RI also does not provide the value for
java.compiler. BTW, we have a test in the DRLVM test suite that
should check all mandatory properties –
java.lang.SystemExtensionTest.test_getProperty_Str(). But it
seems the
author of the test makes a muddle of logical operators – puts OR
instead of AND. So the test now checks if at least one of mandatory
property is set.
IMHO we should return something for the java.compiler property
name.
Any thoughts?
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200610.mbox/[EMAIL PROTECTED]
(problem 2)
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
