Re: HARMONY-1407: Contribution of Java code for package java.lang.management
Geir Magnusson Jr. 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 Are we ready to vote yet? I can't hold my breath much longer :-) Regards, Tim > 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 -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
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.v
Re: HARMONY-1407: Contribution of Java code for package java.lang.management
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)
at javax.management.openmbean.CompositeDataSupport.init(
CompositeDataSupport.java:81)
at javax.management.openmbean.CompositeDataSupport.(
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.
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.
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?
I think the vote is coming, we'd best move on after voting, :-)
Thanks.
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.
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.(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 pro
Re: HARMONY-1407: Contribution of Java code for package java.lang.management
Andrey Yakushev 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. > > 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. Can you give details of the problems in StackTraceElement and we can fix them -- raise a JIRA and let us know the number. Thanks Tim >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] > > -- 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: HARMONY-1407: Contribution of Java code for package java.lang.management
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 investigation Can you list out them? I found that most native methods of this component are related with VM platform, and some Java methods are called by native code(e.g. [1]) . Maybe some of them are hard to replaced by simple stubs. Is my activity helpful? Ya, so helpful, I have more faith on this contribution now. [1] MemoryMXBeanImpl.createMemoryManagerHelper(String name, int internalID, boolean isGC) 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] -- Robert Hu China Software Development Lab, IBM
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: HARMONY-1407: Contribution of Java code for package java.lang.management
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]
Re: HARMONY-1407: Contribution of Java code for package java.lang.management
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, Nathan Beyer <[EMAIL PROTECTED]> 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 -- Robert Hu China Software Development Lab, IBM
HARMONY-1407: Contribution of Java code for package java.lang.management
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
Re: [jira] Created: (HARMONY-1407) Contribution of Java code for package java.lang.management
Great! With java.lang.management and java.lang.instrument it looks like the VM supporting side is JVMTI for the most part of the functionality. This is the code I am trying to improve in DRLVM. On Friday 08 September 2006 14:58 Mikhail Loenko wrote: > Cool! > > 2006/9/8, George Harley (JIRA) <[EMAIL PROTECTED]>: > > Contribution of Java code for package java.lang.management > > -- > > > > Key: HARMONY-1407 > > URL: http://issues.apache.org/jira/browse/HARMONY-1407 > > Project: Harmony > > Issue Type: New Feature > > Components: Contributions > > Environment: Win32 and Linux > >Reporter: George Harley > >Priority: Minor > > > > > > An implementation of the java.lang.management package at the Java 5.0 > > level complete with unit test cases. This contribution contains only > > class library code written in Java; it does *not* include any > > platform-specific C/C++ code required to implement the native end of the > > numberous JNI calls. > > > > In the doc folder of the contribution zip the text file > > NativeInterface.txt lists all of the native calls made by this version of > > the package. It is envisaged that implementations for these will be > > developed inside the Harmony project. -- Gregory Shimansky, Intel Middleware Products 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: [jira] Created: (HARMONY-1407) Contribution of Java code for package java.lang.management
George Harley (JIRA) wrote: > Contribution of Java code for package java.lang.management > -- > > Key: HARMONY-1407 > URL: http://issues.apache.org/jira/browse/HARMONY-1407 > Project: Harmony > Issue Type: New Feature > Components: Contributions > Environment: Win32 and Linux > Reporter: George Harley > Priority: Minor > > > An implementation of the java.lang.management package at the Java 5.0 level > complete with unit test cases. This contribution contains only class library > code written in Java; it does *not* include any platform-specific C/C++ code > required to implement the native end of the numberous JNI calls. > > In the doc folder of the contribution zip the text file NativeInterface.txt > lists all of the native calls made by this version of the package. It is > envisaged that implementations for these will be developed inside the Harmony > project. > > Best regards, > George Harley > IBM UK Awesome! -- Stefano. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-1407) Contribution of Java code for package java.lang.management
Yeah! It seems we will have something to manage with our management console soon. :-) With Best Regards, 2006/9/8, Mikhail Loenko <[EMAIL PROTECTED]>: Cool! 2006/9/8, George Harley (JIRA) <[EMAIL PROTECTED]>: > Contribution of Java code for package java.lang.management > -- > > Key: HARMONY-1407 > URL: http://issues.apache.org/jira/browse/HARMONY-1407 > Project: Harmony > Issue Type: New Feature > Components: Contributions > Environment: Win32 and Linux >Reporter: George Harley >Priority: Minor > > > An implementation of the java.lang.management package at the Java 5.0 level complete with unit test cases. This contribution contains only class library code written in Java; it does *not* include any platform-specific C/C++ code required to implement the native end of the numberous JNI calls. > > In the doc folder of the contribution zip the text file NativeInterface.txt lists all of the native calls made by this version of the package. It is envisaged that implementations for these will be developed inside the Harmony project. > > Best regards, > George Harley > IBM UK > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: http://www.atlassian.com/software/jira -- Alexei Zakharov, Intel Middleware Product 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: [jira] Created: (HARMONY-1407) Contribution of Java code for package java.lang.management
Cool! 2006/9/8, George Harley (JIRA) <[EMAIL PROTECTED]>: Contribution of Java code for package java.lang.management -- Key: HARMONY-1407 URL: http://issues.apache.org/jira/browse/HARMONY-1407 Project: Harmony Issue Type: New Feature Components: Contributions Environment: Win32 and Linux Reporter: George Harley Priority: Minor An implementation of the java.lang.management package at the Java 5.0 level complete with unit test cases. This contribution contains only class library code written in Java; it does *not* include any platform-specific C/C++ code required to implement the native end of the numberous JNI calls. In the doc folder of the contribution zip the text file NativeInterface.txt lists all of the native calls made by this version of the package. It is envisaged that implementations for these will be developed inside the Harmony project. Best regards, George Harley IBM UK -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
