Re: [doc] What should be improved in DRLVM Doxygen documentation?
Alexei,
Metric is simply the number of Doxygen warnings for file. Sorry for
not mentioning this in my letter.
If some file doesn't have Doxygen comments at all then metric can show
only one problem, like in your examples:
vm/gc_cc/src/timer.h:27: Warning: Compound Timer is not documented.
vm/include/slot.h:48: Warning: Compound Slot is not documented.
All warning need attention I think. If doc is generated without
warning, then file is not presented in this list. So this metric
separates bad documented files. Yours estimates quality of good
documented files.
I consider this as some king of QA for documentation. The more tests -
the better. :)
Thanks
Andrey
On 11/16/06, Alexei Fedotov [EMAIL PROTECTED] wrote:
Andrey,
I'm trying to understand your metric and have got a question about
your it. Conssider the following file:
drlvm/trunk/vm/vmcore/include/Class.h. It has metric of 126. Does it
mean that this file has worse documentation than one of the folloiwng
files?
vm/gc_cc/src/timer.h (1) or vm/gc_cc/src/slot.h (1)
Seems like this metric likes big narrative text.
So do I :-)
Thanks!
On 11/16/06, Morozova, Nadezhda [EMAIL PROTECTED] wrote:
Andrey,
I personally like the metric. It does not always reflect the
proportional amount of documentation, but the files at the top of the
list (the worst files) indeed require attention :)
I guess the metric shows both undocumented files and those that are
pretty verbose but require more attention.
Suggestion: in addition to the big metric, have a more refined listing -
which ignores some warnings of minor importance. For example, a metric
that only reports undocumented members. What do you say?
Thank you,
Nadya Morozova
-Original Message-
From: Andrey Yakushev [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 16, 2006 7:46 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [doc] What should be improved in DRLVM Doxygen
documentation?
Alexei's metric is interesting, but sometimes shows strange results
for pretty good docs, like for quite commented files:
0 verifier_8h.html
0 structVerifier_1_1vf__Graph.html
Seems like this metric likes big narrative text.
I also agree that comments quality could be estimated through Doxygen
warnings. I attempted to use such a metric for DRLVM.
I used generated DoxygenDrlvmLog.txt file and parser string:
---8--
cat DoxygenDrlvmLog.txt | grep Warning | awk -F : '{print $1}'
~/tmp/r ; for f in `cat ~/tmp/r | sort | uniq` ; do ( echo `cat
~/tmp/r | grep $f | wc -l` $f ) ; done | sort -n -r
---8--
The result is placed at
http://wiki.apache.org/harmony/DRLVM_Documentation_Quality_Doxygen_Warn
ing_
Rating
If it suits our needs we can think about regular testing.
Thanks,
Andrey
On 07 Nov 2006 14:23:20 +0600, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x216 day of Apache Harmony Alexei A. Fedotov wrote:
Nadya wrote,
we could check for required Doxygen tags in certain elements.
I wasn't asked, but cannot resist, sorry. You may achieve this
right
now
without additional coding. Doxygen warns about many problems you
describe, when you have the following option set.
# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate
warnings
# for undocumented members. If EXTRACT_ALL is set to YES then this
flag
will
# automatically be disabled.
WARN_IF_UNDOCUMENTED = YES
The resulting log consists of warning messages about different
problems.
My DoxygenDrlvmLog.txt, for example, contains the following one:
drlvm/trunk/vm/MMTk/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk
/
Scanning.java:47: Warning: The following parameters of
org::apache::HarmonyDRLVM::mm::mmtk::Scanning::precopyChildren(TraceLoc
a
l trace, ObjectReference object) are not documented:
parameter trace
does it make sense to convert warnings to quality metrics and put on
harmonytest.org (or even Wiki) regularly? It should encourage people
(like me) to document sources better. Or it is too much effort?
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED]
Sent: Friday, November 03, 2006 6:26 PM
To: harmony-dev@incubator.apache.org
Subject: RE: Re: [doc] What should be improved in DRLVM Doxygen
documentation?
Egor,
I agree with you on the idea of simplicity: documented vs.
non-documented.
An additional point: do you think we need/want to evaluate quality
of
comments? we could check for required Doxygen tags in certain
elements.
For example, a function is almost certain to include @param and
@return.
Surely, this is heuristics and does not solve all our problems.
But
the
Doxygen quality check sometimes shows that the file does have
comments
Re: [doc] What should be improved in DRLVM Doxygen documentation?
Alexei already mentioned this peculiarities:
# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings
# for undocumented members. If EXTRACT_ALL is set to YES then this flag will
# automatically be disabled.
Thanks,
Andrey
On 11/16/06, Morozova, Nadezhda [EMAIL PROTECTED] wrote:
He-he.
There's truth in what you say. But I ran the same metric with
EXTRACT_ALL option enabled, and class.h had ~10 warnings instead of 126
:) that's why I think the warning about undocumented members that
directly relies on EXTRALL_ALL setting should be considered with care.
Thank you,
Nadya Morozova
-Original Message-
From: Alexei Fedotov [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 16, 2006 8:48 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [doc] What should be improved in DRLVM Doxygen
documentation?
Andrey,
I'm trying to understand your metric and have got a question about
your it. Conssider the following file:
drlvm/trunk/vm/vmcore/include/Class.h. It has metric of 126. Does it
mean that this file has worse documentation than one of the folloiwng
files?
vm/gc_cc/src/timer.h (1) or vm/gc_cc/src/slot.h (1)
Seems like this metric likes big narrative text.
So do I :-)
Thanks!
On 11/16/06, Morozova, Nadezhda [EMAIL PROTECTED] wrote:
Andrey,
I personally like the metric. It does not always reflect the
proportional amount of documentation, but the files at the top of the
list (the worst files) indeed require attention :)
I guess the metric shows both undocumented files and those that are
pretty verbose but require more attention.
Suggestion: in addition to the big metric, have a more refined
listing -
which ignores some warnings of minor importance. For example, a
metric
that only reports undocumented members. What do you say?
Thank you,
Nadya Morozova
-Original Message-
From: Andrey Yakushev [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 16, 2006 7:46 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [doc] What should be improved in DRLVM Doxygen
documentation?
Alexei's metric is interesting, but sometimes shows strange results
for pretty good docs, like for quite commented files:
0 verifier_8h.html
0 structVerifier_1_1vf__Graph.html
Seems like this metric likes big narrative text.
I also agree that comments quality could be estimated through
Doxygen
warnings. I attempted to use such a metric for DRLVM.
I used generated DoxygenDrlvmLog.txt file and parser string:
---8--
cat DoxygenDrlvmLog.txt | grep Warning | awk -F : '{print $1}'
~/tmp/r ; for f in `cat ~/tmp/r | sort | uniq` ; do ( echo `cat
~/tmp/r | grep $f | wc -l` $f ) ; done | sort -n -r
---8--
The result is placed at
http://wiki.apache.org/harmony/DRLVM_Documentation_Quality_Doxygen_Warn
ing_
Rating
If it suits our needs we can think about regular testing.
Thanks,
Andrey
On 07 Nov 2006 14:23:20 +0600, Egor Pasko [EMAIL PROTECTED]
wrote:
On the 0x216 day of Apache Harmony Alexei A. Fedotov wrote:
Nadya wrote,
we could check for required Doxygen tags in certain elements.
I wasn't asked, but cannot resist, sorry. You may achieve this
right
now
without additional coding. Doxygen warns about many problems you
describe, when you have the following option set.
# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will
generate
warnings
# for undocumented members. If EXTRACT_ALL is set to YES then
this
flag
will
# automatically be disabled.
WARN_IF_UNDOCUMENTED = YES
The resulting log consists of warning messages about different
problems.
My DoxygenDrlvmLog.txt, for example, contains the following one:
drlvm/trunk/vm/MMTk/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk
/
Scanning.java:47: Warning: The following parameters of
org::apache::HarmonyDRLVM::mm::mmtk::Scanning::precopyChildren(TraceLoc
a
l trace, ObjectReference object) are not documented:
parameter trace
does it make sense to convert warnings to quality metrics and put
on
harmonytest.org (or even Wiki) regularly? It should encourage
people
(like me) to document sources better. Or it is too much effort?
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED]
Sent: Friday, November 03, 2006 6:26 PM
To: harmony-dev@incubator.apache.org
Subject: RE: Re: [doc] What should be improved in DRLVM Doxygen
documentation?
Egor,
I agree with you on the idea of simplicity: documented vs.
non-documented.
An additional point: do you think we need/want to evaluate
quality
of
comments? we could check for required Doxygen tags in certain
elements.
For example, a function is almost certain to include @param and
@return.
Surely, this is heuristics and does
Re: [doc] What should be improved in DRLVM Doxygen documentation?
Alexei's metric is interesting, but sometimes shows strange results
for pretty good docs, like for quite commented files:
0 verifier_8h.html
0 structVerifier_1_1vf__Graph.html
Seems like this metric likes big narrative text.
I also agree that comments quality could be estimated through Doxygen
warnings. I attempted to use such a metric for DRLVM.
I used generated DoxygenDrlvmLog.txt file and parser string:
---8--
cat DoxygenDrlvmLog.txt | grep Warning | awk -F : '{print $1}'
~/tmp/r ; for f in `cat ~/tmp/r | sort | uniq` ; do ( echo `cat
~/tmp/r | grep $f | wc -l` $f ) ; done | sort -n -r
---8--
The result is placed at
http://wiki.apache.org/harmony/DRLVM_Documentation_Quality_Doxygen_Warning_Rating
If it suits our needs we can think about regular testing.
Thanks,
Andrey
On 07 Nov 2006 14:23:20 +0600, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x216 day of Apache Harmony Alexei A. Fedotov wrote:
Nadya wrote,
we could check for required Doxygen tags in certain elements.
I wasn't asked, but cannot resist, sorry. You may achieve this right now
without additional coding. Doxygen warns about many problems you
describe, when you have the following option set.
# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate
warnings
# for undocumented members. If EXTRACT_ALL is set to YES then this flag
will
# automatically be disabled.
WARN_IF_UNDOCUMENTED = YES
The resulting log consists of warning messages about different problems.
My DoxygenDrlvmLog.txt, for example, contains the following one:
drlvm/trunk/vm/MMTk/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk/
Scanning.java:47: Warning: The following parameters of
org::apache::HarmonyDRLVM::mm::mmtk::Scanning::precopyChildren(TraceLoca
l trace, ObjectReference object) are not documented:
parameter trace
does it make sense to convert warnings to quality metrics and put on
harmonytest.org (or even Wiki) regularly? It should encourage people
(like me) to document sources better. Or it is too much effort?
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED]
Sent: Friday, November 03, 2006 6:26 PM
To: harmony-dev@incubator.apache.org
Subject: RE: Re: [doc] What should be improved in DRLVM Doxygen
documentation?
Egor,
I agree with you on the idea of simplicity: documented vs.
non-documented.
An additional point: do you think we need/want to evaluate quality of
comments? we could check for required Doxygen tags in certain elements.
For example, a function is almost certain to include @param and
@return.
Surely, this is heuristics and does not solve all our problems. But the
Doxygen quality check sometimes shows that the file does have comments,
but they are not processed properly by Doxygen - which results in a low
rating for an html file. Maybe this is a crazy idea - I'd be glad to
know your opinion.
Thank you,
Nadya Morozova
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
Sent: Friday, November 03, 2006 12:18 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [doc] What should be improved in DRLVM Doxygen
documentation?
On the 0x216 day of Apache Harmony Alexei Fedotov wrote:
Egor,
Thank you for your interest.
We definitely need to improve our documentation. Necessity is not a
real interest :)
Here is an algorithm:
1. Create a list of words from HTML files.
2. Merge a dictionary of all words used in documentation.
3. Remove a half of the most frequently used words from the
dictionary
- I believe they do not add much sense.
4. Remove misspelled words (including identifiers) from the
dictionary.
5. Give a page +1 for each rare, correctly spelled word according to
the dictionary.
6. Divide to the total number of words on the page.
hm, strange heuristic. More unique correctly spelled words is
beneficial. It does not give a clue on the overall quality of
documentation, which is rather confusing..
I thought of something more natural. Number of documented items
vs. number of non-documented. Plus a penalty to the relative number of
misspelled words.
I've collected nice RFEs from your letter. Most of them make me think
and I like them.
a. Update an ASF block comment
b. Improve readability. Some things are really easy - like removing
awk and rewriting most things in perl. Others are a bit more complex
-
I targeted script performance when created auto-generated perl
script.
Also, initial algorithm was a bit more complex - different words had
a
different cost based on their popularity.
c. Use junit test output format to integrate with
http://harmonytest.org. I believe I need a feature request for that
site as well - we need some way to import performance-like rankings
to
the
Re: [doc] What should be improved in DRLVM Doxygen documentation?
On 11/16/06, Morozova, Nadezhda [EMAIL PROTECTED] wrote:
Suggestion: in addition to the big metric, have a more refined listing -
which ignores some warnings of minor importance. For example, a metric
that only reports undocumented members. What do you say?
Probably it could be done by means of warning type filtering. For
example, like this:
-8
cat DoxygenDrlvmLog.txt | grep Warning | grep Member | grep not
documented | awk -F : '{print $1}' /tmp/r ; for f in `cat /tmp/r
| sort | uniq` ; do ( echo `cat /tmp/r | grep $f | wc -l` $f ) ;
done | sort -n -r
-8
The result is:
-8
235 vm/jitrino/src/codegenerator/ia32/Ia32InstCodeSelector.h
133
vm/vmcore/src/kernel_classes/javasrc/org/apache/harmony/lang/reflect/parser/SignatureParser.java
127 vm/jitrino/src/codegenerator/ia32/Ia32IRManager.h
122 vm/jitrino/src/codegenerator/ia32/Ia32Inst.h
110 vm/port/src/encoder/ia32_em64t/encoder.h
102 vm/jitrino/src/shared/Stl.h
81 vm/vmcore/include/Class.h
72 vm/jitrino/src/codegenerator/ia32/Ia32Printer.h
57 vm/jitrino/src/codegenerator/ia32/Ia32CodeSelector.h
...
-8
Not too clean solution, of course. Really some kind of egrep should be used.
Let's collect real misfire first.
Thanks,
Andrey
On 11/16/06, Morozova, Nadezhda [EMAIL PROTECTED] wrote:
Andrey,
I personally like the metric. It does not always reflect the
proportional amount of documentation, but the files at the top of the
list (the worst files) indeed require attention :)
I guess the metric shows both undocumented files and those that are
pretty verbose but require more attention.
Suggestion: in addition to the big metric, have a more refined listing -
which ignores some warnings of minor importance. For example, a metric
that only reports undocumented members. What do you say?
Thank you,
Nadya Morozova
-Original Message-
From: Andrey Yakushev [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 16, 2006 7:46 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [doc] What should be improved in DRLVM Doxygen
documentation?
Alexei's metric is interesting, but sometimes shows strange results
for pretty good docs, like for quite commented files:
0 verifier_8h.html
0 structVerifier_1_1vf__Graph.html
Seems like this metric likes big narrative text.
I also agree that comments quality could be estimated through Doxygen
warnings. I attempted to use such a metric for DRLVM.
I used generated DoxygenDrlvmLog.txt file and parser string:
---8--
cat DoxygenDrlvmLog.txt | grep Warning | awk -F : '{print $1}'
~/tmp/r ; for f in `cat ~/tmp/r | sort | uniq` ; do ( echo `cat
~/tmp/r | grep $f | wc -l` $f ) ; done | sort -n -r
---8--
The result is placed at
http://wiki.apache.org/harmony/DRLVM_Documentation_Quality_Doxygen_Warn
ing_
Rating
If it suits our needs we can think about regular testing.
Thanks,
Andrey
On 07 Nov 2006 14:23:20 +0600, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x216 day of Apache Harmony Alexei A. Fedotov wrote:
Nadya wrote,
we could check for required Doxygen tags in certain elements.
I wasn't asked, but cannot resist, sorry. You may achieve this
right
now
without additional coding. Doxygen warns about many problems you
describe, when you have the following option set.
# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate
warnings
# for undocumented members. If EXTRACT_ALL is set to YES then this
flag
will
# automatically be disabled.
WARN_IF_UNDOCUMENTED = YES
The resulting log consists of warning messages about different
problems.
My DoxygenDrlvmLog.txt, for example, contains the following one:
drlvm/trunk/vm/MMTk/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk
/
Scanning.java:47: Warning: The following parameters of
org::apache::HarmonyDRLVM::mm::mmtk::Scanning::precopyChildren(TraceLoc
a
l trace, ObjectReference object) are not documented:
parameter trace
does it make sense to convert warnings to quality metrics and put on
harmonytest.org (or even Wiki) regularly? It should encourage people
(like me) to document sources better. Or it is too much effort?
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED]
Sent: Friday, November 03, 2006 6:26 PM
To: harmony-dev@incubator.apache.org
Subject: RE: Re: [doc] What should be improved in DRLVM Doxygen
documentation?
Egor,
I agree with you on the idea of simplicity: documented vs.
non-documented.
An additional point: do you think we need/want to evaluate quality
of
comments? we could check for required Doxygen tags in certain
elements.
For example, a function is almost certain to include
Re: HARMONY-1407: Contribution of Java code for package java.lang.management
Why not write LogManager.getLoggingMXBean like this:
return com.ibm.lang.management.ManagementUtils.getLoggingBean();
Yes, it also possible, but tightly binds logging module to
lang-managment implementation.
I found the problem about StackTraceElement when I used luni-kernel.jar
(in jre/bin/default) in build-path of project, it could not compile; and
when I replaced it with luni-kernel-stubs.jar (in jre/lib/boot), it was
OK. Maybe your problem is not exactly as mine.
Yes, you are right. Deeper investigation showed that problem was in
CompositeDataSupport constructor and exists not only for
StackTraceElement class. This is minimal test that fails on DRLVM but
works well on J9:
---8--
import javax.management.openmbean.*;
class CompositeDataTest {
public static void main(String[] args) throws Exception {
String[] names = { goodName };
OpenType[] te = { SimpleType.STRING };
CompositeType ct = new CompositeType(goodName, goodName,
names, names, te);
CompositeData[] cda = { new CompositeDataSupport(ct, names, names) };
Object[] values = { cda };
OpenType[] typeTypes = { new ArrayType(1, ct) };
CompositeType ct2 = new CompositeType(goodName, goodName,
names, names, typeTypes);
new CompositeDataSupport(ct2, names, values);
System.out.println(Passed);
}
}
---8-
I think the vote is coming, we'd best move on after voting, :-)
It's a pity but I've already created
http://issues.apache.org/jira/browse/HARMONY-1821 :-)
Thanks,
Andrey
On 10/11/06, Rui Hu [EMAIL PROTECTED] wrote:
On 10/5/06, Andrey Yakushev [EMAIL PROTECTED] wrote:
I've tried to follow you suggestions. The result:
1. The fix for unimplemented
java.util.logging.LogManager.getLoggingMXBean could be simple, like:
return LoggingMXBeanImpl.getInstance()
But it bind logging module to LoggingMXBean implementation.
Probably more clean solution would be:
ObjectName loggingMXBeanName = new
ObjectName(LOGGING_MXBEAN_NAME);
MBeanServer platformBeanServer =
ManagementFactory.getPlatformMBeanServer();
Set loggingMXBeanSet =
platformBeanServer.queryMBeans(loggingMXBeanName, null);
if(loggingMXBeanSet.size() != 1) {
throw new AssertionError(There Can Be Only One
logging MX bean.);
}
Iterator i = loggingMXBeanSet.iterator();
ObjectInstance loggingMXBeanOI = (ObjectInstance) i.next();
String lmxbcn = loggingMXBeanOI.getClassName();
Class lmxbc = Class.forName(lmxbcn);
Method giMethod = lmxbc.getDeclaredMethod(getInstance);
giMethod.setAccessible(true);
LoggingMXBean lmxb = (LoggingMXBean) giMethod.invoke(null,
new Object[] {});
return lmxb;
But this approach also supposes that implementation contains
getInstance method, which is not always true as far as I know.
Probably some other solution exists?
Sorry for reply so late.
Why not write LogManager.getLoggingMXBean like this:
return com.ibm.lang.management.ManagementUtils.getLoggingBean();
The similar implementation can be found in some public methods in
java.lang.management.ManagementFactory
2. One more problem fount is that
\management\src\main\java\org\apache\harmony\lang\management\CompilationMXBeanImpl.java
uses System.getProperty(java.compiler) which is not defined and it
lead to NullPointerException in
testGetAttribute(
tests.org.apache.harmony.lang.management.CompilationMXBeanImplTest)
Running tests with -Djava.compiler=jitrino removes this test error.
It is interest that test_getProperty_Str from
inincubator\harmony\enhanced\drlvm\trunk\vm\tests\kernel\java\lang\SystemExtensionTest
tries to check that but couldn't due to error in test (using ||
instead of ).
3. As to StackTraceElement problem, I obtain the fail:
javax.management.openmbean.OpenDataException: itemValue at index 12 is
not a valid value for itemName stackTrace and itemType
javax.management.openmbean.CompositeData(typename=[
Ljavax.management.openmbean.CompositeData;,dimension=1,elementType=
javax.management.openmbean.CompositeData
TypeName: java.lang.StackTraceElement contains data:
ItemName: className OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.String)
ItemName: fileName OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.String)
ItemName: lineNumber OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.Integer)
ItemName: methodName OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.String)
ItemName: nativeMethod OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.Boolean)
)
at javax.management.openmbean.CompositeDataSupport.validateContents
(CompositeDataSupport.java:104
Re: HARMONY-1407: Contribution of Java code for package java.lang.management
I've tried to follow you suggestions. The result:
1. The fix for unimplemented
java.util.logging.LogManager.getLoggingMXBean could be simple, like:
return LoggingMXBeanImpl.getInstance()
But it bind logging module to LoggingMXBean implementation.
Probably more clean solution would be:
ObjectName loggingMXBeanName = new ObjectName(LOGGING_MXBEAN_NAME);
MBeanServer platformBeanServer =
ManagementFactory.getPlatformMBeanServer();
Set loggingMXBeanSet =
platformBeanServer.queryMBeans(loggingMXBeanName, null);
if(loggingMXBeanSet.size() != 1) {
throw new AssertionError(There Can Be Only One
logging MX bean.);
}
Iterator i = loggingMXBeanSet.iterator();
ObjectInstance loggingMXBeanOI = (ObjectInstance) i.next();
String lmxbcn = loggingMXBeanOI.getClassName();
Class lmxbc = Class.forName(lmxbcn);
Method giMethod = lmxbc.getDeclaredMethod(getInstance);
giMethod.setAccessible(true);
LoggingMXBean lmxb = (LoggingMXBean) giMethod.invoke(null,
new Object[] {});
return lmxb;
But this approach also supposes that implementation contains
getInstance method, which is not always true as far as I know.
Probably some other solution exists?
2. One more problem fount is that
\management\src\main\java\org\apache\harmony\lang\management\CompilationMXBeanImpl.java
uses System.getProperty(java.compiler) which is not defined and it
lead to NullPointerException in
testGetAttribute(tests.org.apache.harmony.lang.management.CompilationMXBeanImplTest)
Running tests with -Djava.compiler=jitrino removes this test error.
It is interest that test_getProperty_Str from
inincubator\harmony\enhanced\drlvm\trunk\vm\tests\kernel\java\lang\SystemExtensionTest
tries to check that but couldn't due to error in test (using ||
instead of ).
3. As to StackTraceElement problem, I obtain the fail:
javax.management.openmbean.OpenDataException: itemValue at index 12 is
not a valid value for itemName stackTrace and itemType
javax.management.openmbean.CompositeData(typename=[Ljavax.management.openmbean.CompositeData;,dimension=1,elementType=javax.management.openmbean.CompositeData
TypeName: java.lang.StackTraceElement contains data:
ItemName: className OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.String)
ItemName: fileName OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.String)
ItemName: lineNumber OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.Integer)
ItemName: methodName OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.String)
ItemName: nativeMethod OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.Boolean)
)
at
javax.management.openmbean.CompositeDataSupport.validateContents(CompositeDataSupport.java:104)
at
javax.management.openmbean.CompositeDataSupport.init(CompositeDataSupport.java:81)
at
javax.management.openmbean.CompositeDataSupport.init(CompositeDataSupport.java:28)
at
tests.org.apache.harmony.lang.management.threads.ThreadInfoTest.createGoodCompositeData(ThreadInfoTest.java:124)
at
tests.org.apache.harmony.lang.management.threads.ThreadInfoTest.setUp(ThreadInfoTest.java:96)
...[skip]...
First look at CompositeData for java.lang.StackTraceElement shows that
names, types and values are Ok. This error appears even if
StackTraceElement array length is equal to zero, so probably problem
in CompositeData implementation. I will try to continue investigation,
but any help is welcome.
4. Final note (Is anybody still continue reading such a long text? :)
I'm going to donate the written native method stubs but because they
suppose some renaming in HARMONY-1407 they may demand some correction
in future. Should I wait until HARMONY-1407 voting and committing?
Thanks,
Andrey
On 9/20/06, Rui Hu [EMAIL PROTECTED] wrote:
On 9/20/06, Andrey Yakushev [EMAIL PROTECTED] wrote:
Do I understand correctly, that j.l.management support could be
implemented for DRLVM as follows:
1. Integrate HARMONY-1407 into classlib and obtain
UnsatisfiedLinkError on DRLVM.
2. Implement native methods in kernel classes as stubs returning some
realistic values. It could allow test and jconsole running.
3. Replace these stabs one by one with possible adding of the
interface functions in DRLVM modules like GC and TM.
Great. It's a good plan.
Really I have tried to go through this plan ahead of time :)
Currently I wrote native methods stubs and made run for the tests from
HARMONY-1407. The result is:
Tests run: 90, Failures: 15, Errors: 9
13 failures is StackTraceElement similar as Rui mentioned.
It's easy to fix.
8 errors due to not implemented method
at java.util.logging.LogManager.getLoggingMXBean(LogManager.java
:154)
It's easy to fix too. Just add one simple method to LogManager.
Other 3 problems needs additional
Re: HARMONY-1407: Contribution of Java code for package java.lang.management
Do I understand correctly, that j.l.management support could be implemented for DRLVM as follows: 1. Integrate HARMONY-1407 into classlib and obtain UnsatisfiedLinkError on DRLVM. 2. Implement native methods in kernel classes as stubs returning some realistic values. It could allow test and jconsole running. 3. Replace these stabs one by one with possible adding of the interface functions in DRLVM modules like GC and TM. Really I have tried to go through this plan ahead of time :) Currently I wrote native methods stubs and made run for the tests from HARMONY-1407. The result is: Tests run: 90, Failures: 15, Errors: 9 13 failures is StackTraceElement similar as Rui mentioned. 8 errors due to not implemented method at java.util.logging.LogManager.getLoggingMXBean(LogManager.java:154) Other 3 problems needs additional investigation Is my activity helpful? Nathan, do you have similar or different plan for HARMONY-1407 integration? Thanks, Andrey On 9/18/06, Rui Hu [EMAIL PROTECTED] wrote: As I know so far, there is only java code in HARMONY-1407 So, you can build the code on RI, Harmony(only fail on a signal bug of java.lang.StackTraceElement in luni-kernel.jar), and IBM JDK successfully. But the native code of j.l.management is not available now, so you'll fail if you run the tests on Harmony, and got an UnsatisfiedLinkError. On 9/18/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Yes. I have some docs that need to be put in SVN - I hope to do that today. Once we do that, we need to simply vote to accept the code. If you start working with it ahead of time, that will be good :) geir Nathan Beyer wrote: Are there any documents or anything that needs to be resolved before I can start working on the code in HARMONY-1407? http://issues.apache.org/jira/browse/HARMONY-1407 -Nathan - 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: OPEN Specification
Etienne, Some words about your example. OPEN doesn't rely on any particular object layout, but tries to define functional interface for object access purposes. Open_Managed_Object_Handle is used to access this functionality from the components other than VM Core. In order to eliminate performance degradation in such overhead, OPEN defines: - Functions that JIT-compiled code calls during its execution (So called Helpers in OPEN) for quick access to objects from the managed code, - Java methods that interact with the managed code of Java class libraries (ObjectAccessors) for quick access from Java API They could be even inlined in managed code thus eliminating any modularization influence. So, any reasonable object layout could be used in OPEN compatible VM implementation, including bidirectional one. Thanks, Andrey On 5/29/06, Etienne Gagnon [EMAIL PROTECTED] wrote: Hi Anton, Are you proposing that all Harmony JVMs must abide by the OPEN proposal? If yes, I think that some process has to be put in place to present and discuss each of this proposal's part, and dedicate time to do so. IMO, I don't think that everyone (in the JVM sub-communityof Harmony) can simply read through this proposal and be able to make an enlightened decision about it. I think that each point would gain much from being presented along the motivation behind it. For example, would your OPEN proposal work with a bidirectional object layout, without incurring prohivitive performance costs? [Just asking, I didn't have time to read through all of it...] Of course, this is only an opinion. :-) Etienne - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
