Re: [classlib] Intention to work on java.lang.instrument
Leo Li wrote: On 7/31/06, Gregory Shimansky [EMAIL PROTECTED] wrote: 2006/7/31, Jimmy, Jing Lv [EMAIL PROTECTED]: Besides, Harmony VM now has actually support the feature of JVMTI on which we can implement instrument. Ah, can it work now? It'll be great convenient if so. Hello. The drlvm does support a subset of JVMTI. Class loading events are supported, ClassFileLoadHook which may be used for load time class instrumentation is supported too. But there is no support for RedefineClasses yet if you need to change classes bytecode after the class was loaded already. After some study on this, I find Java interface classes/interfaces are quite easy, but there should be real implement, both in java and native. And the native code requires JVMTI[2], which is a part of VM 5. Though, luckily we can still study and code according to JVMTI and test on RI. So my goal is : 1.define those simple Java classes/interfaces in Harmony; 2. work out implementation of java/native code according to JVMTI and make it run on RI; 3. wait for Harmony VM5 and then make some integration modification/test. As the main function of instruments is to add and remove transformers to some classes, I suggest implement it as an agent of JVMTI. That is to register callback functions, which actually transform the byte stream of some specified classes, to the events that is relevent to instrument in JVMTI including the class loading. Yes, that's the way. I agree with this approach. Do you know which API functions and events you will need for such agent? Thanks you Gregory :) Refer to JVMTI Functions doc[1], I think functions of Memory Management/Class/Capability is necessary. [1]http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#FunctionIndex Hi, we will need VM Initialization Event to run premain functions and Class File Load Hook Event for agents to instruct the existing class file. As to the jvmti API, we need RedefineClasses,GetObjectSize and Allocate. Besides, AddCapabilities is also required to turn on the capability of the VM, such as can_generate_all_class_hook_events and can_redefine_classes. That's detail, thanks :) Since we have just planned to implement this module, please excuse me if I leave some requirements about it. :) And for VM guys ,the launcher with parameter -javaagent:) -- Gregory Shimansky, Intel Middleware Products Division -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] ldap
Hello Daniel, Glad to know you are working on JNDI. As far as I know, the package is still incomplete (No JNDI-ldap development discussion in mailing list before :-) ). You may want to refer to this wiki page: http://wiki.apache.org/harmony/component_development_status Thanks a lot. Best regards, Richard. Daniel Gandara wrote: Hi all, We are working on the javax.naming.ldap package, we know that there is a contributed ldap 1.4 package which is not complete; so we are thinking about extending it to accomplish the Java 1.5 specification and contribute it to the project. That said, it would be very important for us to get in touch with the contributors of the package, to talk about some issues related to the current state of the package implementation. At this point the most important question we have is related with the implementation of the classes StartTlsRequest and StartTlsResponse what are not implemented in the contributed package (classes are missing in the package). We would like to know if there were any special reason why they were not implemented or if the package is still incomplete or under development. Any other development documentation of the package (if available) would be very useful for us too. Best regards, Daniel -- Richard Liang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general]Snapshot cannot work on Win2K
Hi, it looks like your friend needs to install Microsoft Platform SDK on his PC . Another solution is to download and update version of dbghelp library from msdn site. I didn't check the second solution. If you don't not succeed for some reason, simply modify nt_exception_filter.cpp file excluding lines: #include dbghelp.h, #pragma comment(linker, /defaultlib:dbghelp.lib), print_callstack function. It will disable call stack printing when crash happens. Aleksey. On 7/31/06, Paulex Yang [EMAIL PROTECTED] wrote: Hi, all I tried the latest snapshot[1] today on Win2K server with SP4 and hotfix until 2005-08-23, (actually one friend wanted to use Harmony on his old machines, he also had some experience about Eclipse on Harmony month ago here[2]), but it failed even for java -version, some error thrown as Windows error box with message like Cannot locate SymFromAddr at dbghelp.dll or so, while the latest classlib build with IBM VME works fine on it. He said he also tried to compile DRLVM on the Win2k, but it requires to download Eclipse 3.1.1(I guess only Eclipse compiler is needed?), so he gave up. Any ideas can help me to pull him back to Harmony from Sun JDK? :-D [1] http://people.apache.org/dist/incubator/harmony/snapshots/latest-hdk-windows.zip [2] http://my.donews.com/eclipse/2006/05/10/run-eclipse-32-sdk-under-apache-harmony/ -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] ldap
Hi Daniel, I don't think that there is any special reason for the absence of the classes you mention; the package looks to be incomplete because of lack of time. So far as I am aware there is no one actively working in this area so any contributions you could make would be a terrific help to the project. As for documentation, it looks like the Javadoc comments in the types already implemented is all there is. Best regards, George Daniel Gandara wrote: Hi all, We are working on the javax.naming.ldap package, we know that there is a contributed ldap 1.4 package which is not complete; so we are thinking about extending it to accomplish the Java 1.5 specification and contribute it to the project. That said, it would be very important for us to get in touch with the contributors of the package, to talk about some issues related to the current state of the package implementation. At this point the most important question we have is related with the implementation of the classes StartTlsRequest and StartTlsResponse what are not implemented in the contributed package (classes are missing in the package). We would like to know if there were any special reason why they were not implemented or if the package is still incomplete or under development. Any other development documentation of the package (if available) would be very useful for us too. Best regards, Daniel - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general]Snapshot cannot work on Win2K
I've tried to update dbghelp yesterday, but it didn't work, will try after installing Platform SDK soon. Thank you very much, Aleksey. Aleksey Ignatenko wrote: Hi, it looks like your friend needs to install Microsoft Platform SDK on his PC . Another solution is to download and update version of dbghelp library from msdn site. I didn't check the second solution. If you don't not succeed for some reason, simply modify nt_exception_filter.cpp file excluding lines: #include dbghelp.h, #pragma comment(linker, /defaultlib:dbghelp.lib), print_callstack function. It will disable call stack printing when crash happens. Aleksey. On 7/31/06, Paulex Yang [EMAIL PROTECTED] wrote: Hi, all I tried the latest snapshot[1] today on Win2K server with SP4 and hotfix until 2005-08-23, (actually one friend wanted to use Harmony on his old machines, he also had some experience about Eclipse on Harmony month ago here[2]), but it failed even for java -version, some error thrown as Windows error box with message like Cannot locate SymFromAddr at dbghelp.dll or so, while the latest classlib build with IBM VME works fine on it. He said he also tried to compile DRLVM on the Win2k, but it requires to download Eclipse 3.1.1(I guess only Eclipse compiler is needed?), so he gave up. Any ideas can help me to pull him back to Harmony from Sun JDK? :-D [1] http://people.apache.org/dist/incubator/harmony/snapshots/latest-hdk-windows.zip [2] http://my.donews.com/eclipse/2006/05/10/run-eclipse-32-sdk-under-apache-harmony/ -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][nio-charset] RI is inconsistent with spec when loading charset provider
Andrew Zhang wrote: On 7/31/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 7/31/06, Andrew Zhang [EMAIL PROTECTED] wrote: Shall we follow RI or spec? I'd like to suggest follow RI for this specific case, because: 1. If we follow spec, it may cause legacy applications fail. I do not think that fixing this bug will affect legacy applications badly, because we will add new functionality that is turned on by special configuration files. Old functionality will not be affected. Even with our special configuration, Harmony still behaves differently from RI, right? For some case, RI could load user specified configuration file while harmony could not, and vice versa. So I think legacy applications will be affected if they assume system class loader is used. :) 2. Other service provider in nio module are all loaded by system class loader. Any suggestions and comments? This bug is 4 years old. One or two years more and it will become a 'feature' http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4619777 Anyway, I vote to follow spec but not RI :) (AFAIK as classpath did) I tried to run the test against sun 6.0 pre-rc-b65. The result is the same. Seems SUN doesn't take any action on this problem. As you mentioned, it's already 4 years, and is not solved in jdk6. :( So I still think we should follow RI this time. :) Shall we integrate the spec and RI? That is, 1) Try to load the Charset provider via the current thread's context class loader 2) If fail to load the provider in step 1), try to use system class loader to load the Charset provider. Please correct me if I'm wrong. Thanks a lot. Best regards, Richard Thanks! -- Mikhail Fursov -- Richard Liang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [testing] metadata approach
Hi Alex, some ways we can achieve this. Do we want to finish deciding that before the migration, or are we confident that we will get to a point where a decision is made and we can start transitioning beforehand? Well, IMHO adding some extra javadoc tag will not break anything. There are situations when you need some sticker just to put on test to mark it as implementation specific for example since you will forget everything in a week. I currently use some javadoc text like This test is highly implementation specific or @impl tag to mark such tests. But I would prefer to do it in a more standardized way. ABout finishing deciding: we probably need to engage more people in the discussion ... Lastly, do we have entries (e.g. on the wiki) about how to write new tests that are either (a) compatible with JUnit+TestNG, or (b) use TestNG alone? It seems like this would be a good way to ensure new tests are TestNG-compatible and thus increase the coverage of TestNG tests. I don't think we have anything concerning TestNG on the wiki right now. IMHO we still need everybody to accept the intention of moving to the new harness before starting this activities. We probably also need to have pointers at least for how to run the tests from My Favourite IDE (tm) and/or the build itself. AFAIK there are TestNG plugins for Eclipse and IDEA but I haven't tried it yet. Are there any other systems e.g. JUnitReport that we need to consider for this? Does TestNG's reporting suit what we want to do and/or can we leverage any of the reporting that it does on the web? Basically TestNG built-in reporting system produces all necessary information. But the resulting report doesn't look very nice and I don't know how to customize it. Funny thing: the report looks nicer in Mozilla than in IE. On the other hand, the use of JUnitReport is officially approved by TestNG team - i.e. TestNG produces all necessary input stuff for JUnitReport. JR is more powerfull report-generation system, we may customize it's output with XSL sheets if we like (AFAIK). The default style of reports generated by JUnitReport looks nicer. Regards, 2006/7/28, Alex Blewitt [EMAIL PROTECTED]: The question I'd like to raise now is – aren't we ready for TestNG right now? For example, we could replace our harness from jUnit to TestNG and lazily start converting of some failing and platform dependent tests to javadoc version of TestNG. Thought? Suggestions? Opposite opinions? I think that if the decision is made to go down the TestNG route (and my hope is that we will) then this sounds like a good approach. Of course, everyone would have to be happy at the migration (sounds like we're heading towards a vote on it) and like you say, we can always use the TestNG harness to run the existing set of JUnit tests, so we should still be in the same position. As for the metadata decisions (e.g. platforms) there still seems to be some ways we can achieve this. Do we want to finish deciding that before the migration, or are we confident that we will get to a point where a decision is made and we can start transitioning beforehand? Lastly, do we have entries (e.g. on the wiki) about how to write new tests that are either (a) compatible with JUnit+TestNG, or (b) use TestNG alone? It seems like this would be a good way to ensure new tests are TestNG-compatible and thus increase the coverage of TestNG tests. We probably also need to have pointers at least for how to run the tests from My Favourite IDE (tm) and/or the build itself. Are there any other systems e.g. JUnitReport that we need to consider for this? Does TestNG's reporting suit what we want to do and/or can we leverage any of the reporting that it does on the web? Alex. -- 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: [testing] metadata approach
Alexei Zakharov wrote: Hi, I have created this new thread as a single place for discussions started in Re: [testing] Peace and [classlib] Testing conventions – a proposal threads. What did we have in the previous threads? * Test classification proposed by Vladimir * Test classification and group names proposed by George * Solution for Ant and TestNG scripting issues (still being discussed) Since a lot of people are asking about TestNG and wanting TestNG I decide to put some effort and take a closer look at this piece of software. Thus during the last few days I was playing with TestNG - I tried to run different kind of tests with it, to perform various workloads, generate reports in different ways and etc. The purpose of all this activity was to try TestNG in a real work, understand is TestNG really worth our credits and how expensive can be moving to TestNG from our currently implemented testing infrastructure. Now I have some thoughts and facts I'd like to share with the community. I've put it in the form of list for convenience. * TestNG works ok in normal conditions, no visible bugs * It is possible to define and use various (possibly intersecting) test groups with TestNG * TestNG-style metadata is more convenient than JUnit test suites (now I agree with this statement). IMHO this is the main TestNG benefit. * It is possible to run TestNG from command line * There is also the special ant task for running TestNG * Not everything can be configured with the ant task or command-line params, sometimes extra test suite definition file testng.xml is needed * It is possible to run jUnit tests with TestNG (testng.xml is needed in this case) * It is possible to run junit tests we currently have in Harmony with TestNG without any problems and modifications of the source code. However, we probably should write some number of TestNG test suite definition files testng.xml to be able to run all our junit tests (I have tried tests for bean module and some tests for luni) * We can mix jUnit tests and TestNG tests in the single test suite configuration – i.e. single testng.xml file. We can add TestNG metadata to some test classes and leave other test classes untouched * TestNG generates HTML reports in its own style, not a very convenient one IMHO * It is also possible to generate JUnitReports from the output generated by TestNG * Such reports will have a little bit different structure since TestNG doesn't provider any information about enclosing type for test methods. Names for tests (replacement for JUnit test classes) and test suites should be externally configured in testng.xml * TestNG for Java 5 doesn't work on Harmony because some necessary classes from java.util.concurrent package are missing and it seems that jsr14 target (we are currently using) doesn't support annotations * TestNG for Java 1.4 (javadoc version) currently works on Harmony * I have half-way done script that converts TestNG 1.4 metadata (javadoc) tests to TestNG 1.5 (5.0 annotations) tests. Excellent summary! Thanks a lot The question I'd like to raise now is – aren't we ready for TestNG right now? I suppose we will use Java 5.0 annotations of TestNG, so it seems now we are not ready for TestNG. But we can continue our feasibility study, just like what you have done, to know if TestNG really meets our requirements or if there are any potential problems. Maybe we could list a prerequisite list. e.g, 1) Harmony can fully self-host TestNG with Java5 annotations 2) Test groups are well-defined and agreed in community 3) Guidelines to write TestNG testcases 4) Take one module to run a pilot case Please correct me if I'm wrong For example, we could replace our harness from jUnit to TestNG and lazily start converting of some failing and platform dependent tests to javadoc version of TestNG. The rest of the tests will remain jUnit in fact. And when our VM will be ready to handle annotations we can convert all our TestNG 1.4 tests to TestNG 1.5. I understand that this idea may seem to be too early. But anyway we will need to change things some day since many people are unhappy with the current testing infrastructure (me for example). Not sure if we really want to involve another migration: TestNG javadoc - TestNG annotation. Any comments? Thought? Suggestions? Opposite opinions? With Best Regards, -- Richard Liang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general]Snapshot cannot work on Win2K
Aleksey Ignatenko wrote: Hi, it looks like your friend needs to install Microsoft Platform SDK on his PC . Another solution is to download and update version of dbghelp library from msdn site. I vaguely remember that Microsoft license allows to include dbghelp.dll to binary distributions. Below is a quote from EULA (end user license agreement). May be we could put dbghelp.dll to binary snapshots? --- 8 --- * Distribution Terms. You may reproduce and distribute an unlimited number of copies of the Sample Code and/or Redistributable Code (collectively Redistributable Components) as described above in object code form, provided that (a) you distribute the Redistributable Components only in conjunction with and as a part of your Application solely for use with a Microsoft Operating System Product; (b) your Application adds significant and primary functionality to the Redistributable Components; (c) you distribute your Application containing the Redistributable Components pursuant to an End-User License Agreement (which may be break-the-seal, click-wrap or signed), with terms no less protective than those contained herein; (d) you do not permit further redistribution of the Redistributable Components by your end-user customers; (e) you do not use Microsoft's name, logo, or trademarks to market your Application; (f) you include a valid copyright notice on your Application; and (g) you agree to indemnify, hold harmless, and defend Microsoft from and against any claims or lawsuits, including attorneys' fees, that arise or result from the use or distribution of your Application. Contact Microsoft for the applicable licensing terms for all other uses and/or distribution of the Redistributable Components. --- 8 --- [1] http://www.microsoft.com/downloads/details.aspx?displaylang=enFamilyID=CD1FC4B2-0885-47F4-AF45-7FD5E14DB6C0 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][java.math] combination of math packages
Daniel, Thank you for the new optimized version. We've analyzed your version and found it's very good. We can accept you version as default for Harmony but we'd like to add some improvements. :) I've updated H-935 and attach diffs for your code. We added optimization for small BigDecimal's objects. Our patch doesn't break your design covers the following issues: - reduce amount of object created during initialization of BigDecimal. In our version we don't use BigInteger during BigDecimal creation for small values. - cached values for powers of tens and for powers of five were added. - additional branches in all calculation methods for supporting small value calculations as well. - toDecimalScaledString method was added to Conversion class. The method is intended only for processing 32-bits numbers. I've attached small micro bench that shows boost for BigDecimal that fits to 64 bits. I should mention that we can't see any degradation in all other performance tests with our patch. Daniel, could you please review our patch? If you agree with suggested changes, I believe we all will vote +1 for our common math :) Thanks, Vladimir. -- Vladimir Strigun, Intel Middleware Product Division On 7/21/06, Daniel Fridlender [EMAIL PROTECTED] wrote: Dear all, On behalf of ITC, I have submitted as H-935 a new implementation of java.math combining previously donated implementations. It includes what we think are the best features of H-380 (donated by Intel) and the best features of H-199 (donated by ITC). We have also fixed some bugs from both implementations and done some further optimizations on methods from both of them. We have also included a few optimizations from H-551, we expect to include the remaining optimizations soon. We have also improved the performance test suite from H-551 and included further tests, among them realistic applications from cryptography. Check the README file included in the package mathPerformanceTestsUpdate.zip (H-935) for some more details about the new features of the test suite. A sample of the output obtained with the performance test suite can be found at http://www.fitc.unc.edu.ar/javadev/math/benchmarking.html A comparative analysis on a method-by-method basis between H-380 and H-199 can be found at http://www.fitc.unc.edu.ar/javadev/math/docs.html We will include further documentation soon. In the meantime, a brief description of the main issues follows: Internal representation of BigInteger: taken from H-380 (Sign-magnitude representation). Design: taken from H-199 (well-defined static libraries grouped by functionality). Serialization: taken from H-380 (it was not implemented in H-199). Most methods and constructors were taken from one of the previous donations and then tuned for consistency with the internal representation, for bug removal and for further optimizations. Very often large parts were reprogrammed (e.g.: shiftRight, bitLength, bitCount, not, setTrueCoded, modInverse, and many more). Nevertheless we can roughly say that the new version started by taking: 1) Methods of BigDecimal: most of them from H-199 because of efficiency. 2) Representation-dependent methods of BigInteger: most of them from H-380. 3) Representation-independent methods of BigInteger: most of them from H-199 for efficiency. 4) From H-551: caches, BigInteger.compareArrays, BigInteger.valueOf, BigDecimal.valueOf, etc. We also took their performance test suite, improve it and added further benchmarks. We plan to introduce remaining optimizations from H-551 and to optimize other methods (modPow, modInverse, nextProbablePrime, etc.) in order to bridge the gap in efficiency with the RI. Best regards, Daniel Fridlender ITC http://issues.apache.org/jira/browse/HARMONY-935 - 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]
[classlib][text] Bidi returns directional runs in visual order rather than in logical
Hi all. Harmony implementation of java.text.Bidi returns directional runs (getRunStart(), getRunLimit(), getRunLevel()) in visual order if paragraph reading order is Right-to-Left. I mean the first run is at the end of character buffer, and the last is at the beginning. I'd expect directional runs are enumerated in the order of the characters in the buffer, i.e. the logical order. I've created a JIRA issue for this: https://issues.apache.org/jira/browse/HARMONY-1028 Another difference from the RI is that in Harmony the text is divided into paragraphs before directional analysis, which is not done in the RI despite the Unicode Bidirectional Algorithm [1] requires it. The output of the test case when run on Harmony: 0: 0 [0, 3] 1: 1 [7, 9] 2: 2 [5, 7] 3: 1 [3, 5] However, I'd expect the following output: 0: 0 [0, 3] 1: 1 [3, 5] 2: 2 [5, 7] 3: 1 [7, 9] The output of the test case when run on the RI: 0: 0 [0, 3] 1: 1 [3, 5] 2: 0 [5, 7] 3: 1 [7, 9] Any thoughts? [1] http://www.unicode.org/reports/tr9/ Regards, -- Alexey A. Ivanov 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: [testing] metadata approach
Hi Richard, Not sure if we really want to involve another migration: TestNG javadoc - TestNG annotation. Any comments? Well, IMHO this depends on time constraints - when do we plan to have the support for anotations? If the answer is about a couple of weeks - no problem, we can wait. But if this is several months... About the migration - I don't think this will be a real painfull migration, all infrastructure will remain the same. We will only need to convert javadocs to annotations (one-one correspondence) and this task can be easily automated. Thanks, 2006/8/1, Richard Liang [EMAIL PROTECTED]: Alexei Zakharov wrote: Hi, I have created this new thread as a single place for discussions started in Re: [testing] Peace and [classlib] Testing conventions – a proposal threads. What did we have in the previous threads? * Test classification proposed by Vladimir * Test classification and group names proposed by George * Solution for Ant and TestNG scripting issues (still being discussed) Since a lot of people are asking about TestNG and wanting TestNG I decide to put some effort and take a closer look at this piece of software. Thus during the last few days I was playing with TestNG - I tried to run different kind of tests with it, to perform various workloads, generate reports in different ways and etc. The purpose of all this activity was to try TestNG in a real work, understand is TestNG really worth our credits and how expensive can be moving to TestNG from our currently implemented testing infrastructure. Now I have some thoughts and facts I'd like to share with the community. I've put it in the form of list for convenience. * TestNG works ok in normal conditions, no visible bugs * It is possible to define and use various (possibly intersecting) test groups with TestNG * TestNG-style metadata is more convenient than JUnit test suites (now I agree with this statement). IMHO this is the main TestNG benefit. * It is possible to run TestNG from command line * There is also the special ant task for running TestNG * Not everything can be configured with the ant task or command-line params, sometimes extra test suite definition file testng.xml is needed * It is possible to run jUnit tests with TestNG (testng.xml is needed in this case) * It is possible to run junit tests we currently have in Harmony with TestNG without any problems and modifications of the source code. However, we probably should write some number of TestNG test suite definition files testng.xml to be able to run all our junit tests (I have tried tests for bean module and some tests for luni) * We can mix jUnit tests and TestNG tests in the single test suite configuration – i.e. single testng.xml file. We can add TestNG metadata to some test classes and leave other test classes untouched * TestNG generates HTML reports in its own style, not a very convenient one IMHO * It is also possible to generate JUnitReports from the output generated by TestNG * Such reports will have a little bit different structure since TestNG doesn't provider any information about enclosing type for test methods. Names for tests (replacement for JUnit test classes) and test suites should be externally configured in testng.xml * TestNG for Java 5 doesn't work on Harmony because some necessary classes from java.util.concurrent package are missing and it seems that jsr14 target (we are currently using) doesn't support annotations * TestNG for Java 1.4 (javadoc version) currently works on Harmony * I have half-way done script that converts TestNG 1.4 metadata (javadoc) tests to TestNG 1.5 (5.0 annotations) tests. Excellent summary! Thanks a lot The question I'd like to raise now is – aren't we ready for TestNG right now? I suppose we will use Java 5.0 annotations of TestNG, so it seems now we are not ready for TestNG. But we can continue our feasibility study, just like what you have done, to know if TestNG really meets our requirements or if there are any potential problems. Maybe we could list a prerequisite list. e.g, 1) Harmony can fully self-host TestNG with Java5 annotations 2) Test groups are well-defined and agreed in community 3) Guidelines to write TestNG testcases 4) Take one module to run a pilot case Please correct me if I'm wrong For example, we could replace our harness from jUnit to TestNG and lazily start converting of some failing and platform dependent tests to javadoc version of TestNG. The rest of the tests will remain jUnit in fact. And when our VM will be ready to handle annotations we can convert all our TestNG 1.4 tests to TestNG 1.5. I understand that this idea may seem to be too early. But anyway we will need to change things some day since many people are unhappy with the current testing infrastructure (me for example). Not sure if we really want to involve another migration: TestNG javadoc - TestNG annotation. Any comments? Thought? Suggestions? Opposite
Re: [build-test-infra] Build Test Infrastructure
Anton, I have no objections here, just thinking about Harmony-hosted Harmony web site - it can become really good self explanatory reliability test. Not today, I agree. But may be some day. With Regards, 2006/8/1, Anton Luht [EMAIL PROTECTED]: Hello Alexei, I believe that there are more installations that can execute CGI than those that can run servlets. I'm sure that for the first time the test infrastructure will be deployed to an existing installation but not to a dedicated server - that's why I decided that CGI suites better. When we have a dedicated host for builds maybe it'll be worth to rewrite test infrastructure in Java. But please do not consider the choice of technology final - I just wanted to pick something that fits for a prototype: fast to develop and easy to deploy. On 8/1/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi Anton, I believe that most common server-side engine is CGI (not PHP or J2EE) so I'd like to implement this using Perl CGI scripts. (just thinking about) there are several good Java-oriented technologies - servlets, JSP, JSF - why not to use them? I don't like to say that servlets are more frequent than perl, but Java itself is not the most widely used language. We should advertise it. :) IMHO having Java web/servlets server (not a complete J2EE) for such type of tasks with theoretically Harmony JRE inside will do a good job for our project. Regards, 2006/7/28, Anton Luht [EMAIL PROTECTED]: Hello, I know why this thread is so lazy - it's because everybody dislikes QA testing :) OK, now let me add my $0.02 about my vision about reporting of test results. I believe it's better to do this using HTTP rather than mail because some people may not have access to SMTP port (for example, be behind proxy with Exchange as mail server - I don't really know if it provides SMTP service). HTTP is open in most configurations and it was already decided that HDK and tests will be delivered via HTTP. I see the reporting of the results in the following way: after executing tests the script packs results and uploads them (as with browser file upload) to the server. After that data is processed on server-side - daemons can send periodical e-mails, draw charts, reports, lists of top test results contributors, etc. Nobody criticized this approach so I assume that it's not too bad. I'm going to implement a sketch for server-side bunch of scripts - one that accepts uploads and puts them to a temp directory and maybe some simple reports. They won't use any database. I believe that most common server-side engine is CGI (not PHP or J2EE) so I'd like to implement this using Perl CGI scripts. Since this is a first draft, I'm not going to use advanced templates language like XSLT. Including HTML output in script is bad idea so I'm going to use something like HTML::Template [1] for pages generation and CGI::Lite [2] for requests handling. Perl is chosen just because it suites well for fast prototyping development. If nobody objects, I'm going to start coding. [1] http://html-template.sourceforge.net/ [2] http://search.cpan.org/~smylers/CGI-Lite-2.02/Lite.pm -- Regards, Anton Luht, 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] -- 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] -- Regards, Anton Luht, 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] -- 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: [rant] Memory options in VM -- why is the default not 'unlimited'
On Tuesday 01 August 2006 01:53 Alex Blewitt wrote: On 31/07/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Alex Blewitt wrote: Don't get me wrong; being able to specify minimum/maximum is a reasonable idea for optimising a VM if you know what to put; but by default, there shouldn't be any arbitrary limitations based on the value of a #define constant ... So, would you be satisfied if the VM defaulted to, say, 3/4 of total physical memory available? (not a #define, but a value detected at startup) I would like to get some concrete practical conclusion from the whole discussion. The question should be: Why have a maximum? and not What should the maximum be? An algorithm that implicitly assumes a maximum is wrong. There is a method Runtime.freeMemory() which returns the memory available in the heap. I wonder what it should return when there is no limit. Some applications may rely on the value which this method returns. Just returning Long.MAX_VALUE may lead to confusion. -- 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]
[performance] performance measurement of HDK
Our project is now in a good shape and we started encouraging people to try real applications on top of Harmony. One of the important parts of the feedback will be general impression of stability, reliability and performance of the HDK. We are doing pretty good in fixing bugs and developing new functionality in HDK, and it might be a good time for us to start thinking of performance as well. It might be a little bit preliminary, but do we consider having any performance targets for us? If yes, we may need to focus at least some of our efforts on benchmarking and tuning overall performance of HDK. One of the main questions here is what should be the targets for us and how should we measure our performance. There are several ways for measuring performance, such us commercial benchmarks, free benchmarks, application startup, small micro suites, etc. Some of free benchmarks have been mentioned in JIRA issues and dev list, nevertheless at the moment we don't have any goals for performance. In spite of application enabling initiative it might be good to consider publicly available benchmarks as the additional list of the software applications which we would enable on Harmony. So I suggest to start discussing performance techniques and methods that can be used for comparing performance between RI and HDK. I think in case we do not consider performance issues, we can get negative feedback from users even if application starts without any errors, exceptions, etc. One of the benchmarks that was mentioned is DaCapo[1]. It's a free open-source benchmark suite and I believe it can be used for regular performance measurement of HDK. I've tried to find other free suites and got the following list: Telco - this one mostly stresses BigInteger/BigDecimal functionality GcOld - the purpose of this one is clear from the name :) SciMark - java benchmark for scientific and numerical computing Linpack java - well-known benchmark solving linear equations The Plasma Benchmark - creates an animated display by continuously summing four sine waves in an applet JavaWorld Benchmark - benchmark for low-level operations: loops, accessing variables, method invocation, arithmetic operators, casting, instantiation, exception handling, thread creation and switching. CaffeineMark 3.0 - low-level benchmark suite, including sieve of Eratosthenes, sorting, logic ops, method invocation, floating point, simple graphics and GUI ops JavaGrande benchmark suite - a set of benchmarks stressing different areas of java. Having in mind that the list of publicly available benchmarks is not too big, sometimes it will be necessary to create micro benches for some of patches (for instance, Harmony-935). IMO micro should be started in case we change some code that the bench covers. Other interesting and possibly more productive way for comparing performance between different implementations are to use non-free benchmarks. For instance, we can use benchmarks from Spec[n], like SpecJVM, SpecJBB, SpecJAppserver. Unfortunately first we should get license for it, but I believe this issue can be solved within the help of companies participating in Harmony :) Thoughts? Comments? [1] http://dacapobench.org [2] http://www.spec.org -- Vladimir Strigun, 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]
[tools] [patch] Modifications to harmony eclipse plugin to make it work with DRLVM
Hi,
I have been reviewing the DRLVM JIRA issues, and came across
HARMONY-699 [DRLVM] modification to eclipse plugin should be applied to plugin
itself
So I took the hyplugin.patch from DRLVM distribution and applied the changes
to plugin source tree, taking into account, that DRLVM executable is no longer
ij.exe,
but plain java.exe.
Then I have tried to run the modified plugin, and found out that it does not
find
kernel jar files by default, because DRLVM does not provide some property file
(default location that is searched from is 'jre/bin/default/clearvm.properties',
which looks pretty similar to the default -vm -vmdir arguments of the launcher).
Anyway, DRLVM does not provide property files for kernel files
(* and I personally do not like them *),
so I figured it would be reasonable to provide a reasonable default coded right
into the plugin code.
The resulting patch is provided below for review.
(HARMONY-699 has the same changes in two patches).
Could you please review the modifications and commit the changes if there are
no objections? This will allow to remove custom plugin build from DRLVM.
The plugin works okay on my Windows/ia32 laptop.
Thanks a lot!
--- /dev/null
+++ eclipse/org.apache.harmony.eclipse.jdt.launching/build.xml
@@ -0,0 +1,74 @@
+?xml version=1.0 encoding=ISO-8859-1?
+!--
+Copyright 2005-2006 The Apache Software Foundation or its licensors, as
applicable.
+
+Licensed under the Apache License, Version 2.0 (the License);
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an AS IS BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+--
+project name=hyplugin default=build
+
+target name=init
+ property name=build.dir value=bin/
+ property name=jar.name
value=${build.dir}/org.apache.harmony.eclipse.jdt.launching_1.0.0.jar /
+/target
+
+target name=find.eclipse
+
+ property environment=env/
+ available property=eclipse.home value=${env.ECLIPSE_HOME}
+ file=${env.ECLIPSE_HOME}/startup.jar/
+ fail unless=eclipse.homeError:
+ Can't find eclipse home.
+ Please set the environment variable ECLIPSE_HOME to Eclipse location
+ or pass it as the property -Declipse.home=...
+ /fail
+
+ path id=java.class.path
+ fileset dir=${java.home} includes=**/*.jar /
+ fileset dir=${eclipse.home} includes=**/*.jar /
+ /path
+
+/target
+
+target name=build depends=init, find.eclipse
+ mkdir dir=${build.dir}/
+ javac destdir=${build.dir}
+ debug=yes
+ classpathref=java.class.path
+ srcdir=src
+ includes=**/*.java/
+
+ jar destfile=${jar.name} manifest=META-INF/MANIFEST.MF
+ fileset dir=${build.dir}
+ include name=**/*.class/
+ /fileset
+ fileset dir=src
+ include name=**/*.properties/
+ /fileset
+ fileset dir=. includes=plugin.xml/
+ /jar
+/target
+
+target name=clean depends=init
+ delete dir=${build.dir}/
+/target
+
+target name=install depends=init, find.eclipse
+ available file=${jar.name} property=jar.built/
+ fail unless=jar.built
+ Can't find built jar file ${jar.name}.
+ Please run 'ant build' first
+ /fail
+ copy file=${jar.name} todir=${eclipse.home}/plugins/
+/target
+
+/project
diff --git
eclipse/org.apache.harmony.eclipse.jdt.launching/src/org/apache/harmony/eclipse/jdt/launching/HyLauncherMessages.java
eclipse/org.apache.harmony.eclipse.jdt.launching/src/org/apache/harmony/eclipse/jdt/launching/HyLauncherMessages.java
old mode 100644
new mode 100755
index 645f92e..c49f850
---
eclipse/org.apache.harmony.eclipse.jdt.launching/src/org/apache/harmony/eclipse/jdt/launching/HyLauncherMessages.java
+++
eclipse/org.apache.harmony.eclipse.jdt.launching/src/org/apache/harmony/eclipse/jdt/launching/HyLauncherMessages.java
@@ -22,8 +22,14 @@ public class HyLauncherMessages {
private static final String RESOURCE_BUNDLE =
org.apache.harmony.eclipse.jdt.launching.HyLauncherMessages; //$NON-NLS-1$
- private static ResourceBundle resourceBundle = ResourceBundle
- .getBundle(RESOURCE_BUNDLE);
+ private static ResourceBundle resourceBundle;
+ static {
+ try {
+ resourceBundle =
ResourceBundle.getBundle(RESOURCE_BUNDLE);
+ } catch (MissingResourceException e) {
+ System.err.println(Can't load resource bundle +
RESOURCE_BUNDLE);
+ }
+ }
private HyLauncherMessages() {
super();
@@ -32,7 +38,7
Re: [classlib] Uncertain behavior of new Socket(0.0.0.0, 1099);
I've attached a fix for this issue.
SY, Alexey
2006/7/21, Victor A Martynov [EMAIL PROTECTED]:
Hello Geir,
I created new JIRA:
HARMONY-946
on this issue.
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
On 7/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
We have a bug. 0.0.0.0 should be all adapters, and is legit.
Can you file a JIRA?
Victor A Martynov wrote:
Hello Mikhail,
Here are the results of running the modified test:
---
import java.net.*;
public class Test {
public static void main(String args[]) throws Throwable {
ServerSocket ss = new ServerSocket(1099, 0,
InetAddress.getByName(0.0.0.0));
System.out.println(ss.getInetAddress());
Socket s = new Socket(0.0.0.0, 1099);
}
}
---
c:\testjava Test
/0.0.0.0
c:\testC:/Harmony/bin/ij -version
Apache Harmony DRLVM HEAD-4807 (2006-05-02), Windows/ia32/msvc 1310,
debug
c:\testC:/Harmony/bin/ij Test
/0.0.0.0
java.net.ConnectException: 0.0.0.0/0.0.0.0:1099 - The address is not
available
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:238)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:200)
at java.net.Socket.startupSocket(Socket.java:715)
at java.net.Socket.init(Socket.java:139)
at Test.main(Test.java:10)
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
On 7/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Add this line to the test to clarify the situation:
System.out.println(ss.getInetAddress());
I think that for PC with multiple network adapters serversocket IP
must be
specified manually.
On 7/20/06, Victor A Martynov [EMAIL PROTECTED] wrote:
Hello,
I'm having trouble with an application. This problem concerns
creating
java.net.Socket on host 0.0.0.0.
The test below illustrates this problem:
import java.net.*;
public class Test {
public static void main(String args[]) throws Throwable {
ServerSocket ss = new ServerSocket(1099);
Socket s = new Socket(0.0.0.0, 1099);
}
}
The output on RI and on Harmony differs:
c:\testjava Test
c:\testC:/Harmony/bin/ij Test
java.net.ConnectException: 0.0.0.0/0.0.0.0:1099 - The address is not
available
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:238)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:200)
at java.net.Socket.startupSocket(Socket.java:715)
at java.net.Socket.init(Socket.java:139)
at Test.main(Test.java:7)
I wonder whether it is a bug in RI or a bug in LUNI of Harmony?
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
--
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]
--
Alexey A. Petrenko
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: [rant] Memory options in VM -- why is the default not 'unlimited'
On 8/1/06, Gregory Shimansky [EMAIL PROTECTED] wrote: There is a method Runtime.freeMemory() which returns the memory available in the heap. I wonder what it should return when there is no limit. Some applications may rely on the value which this method returns. Just returning Long.MAX_VALUE may lead to confusion. It can simply returns the freeMemory available to the Java object allocation, if that's programmer wants. Basically I think this API is only for profiling hints purpose, meaning it has no guarantee about the real memory situation. So it's not recommended to program the application depending on its return value. Thanks, xiaofeng - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[doc]proposal to improve and expand website
Geir, all, I have thought that I could contribute by brushing up and expanding some of the pages on the Harmony website. My first attempt has been to edit the FAQ section, see JIRA issue 1032 [1]. Another thing I could do is to add content to the DRLVM page (a newly added page with no content so far). I thought that placing links to various docs we have for DRLVM now could be useful. If nobody is against this, I could produce a trial patch shortly. One technical question: if I place links to documents that go into SVN and check out the latest version, the link takes you to the HTML doc with no images or styles displayed. As I understand, Geir has overcome this difficulty when linking from the Documentation page to descriptions of classlib bundles by copying the docs into the site/docs/externals directory. Should I do that for Getting Started, Developer's Guide and any other HTML docs I find for DRLVM? Note: the ClassLibrary page [2], section Architecture and Guide has links to external sources [3] that are also HTML displayed with no styles or formatting or images. Perhaps, we should also fix that somehow. [1] JIRA 1032, https://issues.apache.org/jira/browse/HARMONY-1032 [2] ClassLib page http://incubator.apache.org/harmony/subcomponents/classlibrary/index.htm l [3] link to porting docs, http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/d oc/vm_doc/html/index.html?view=co Nadya Morozova, Technical writer
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
On Tue, Aug 01, 2006 at 10:39:03PM +0800, Xiao-Feng Li wrote: On 8/1/06, Gregory Shimansky [EMAIL PROTECTED] wrote: There is a method Runtime.freeMemory() which returns the memory available in the heap. I wonder what it should return when there is no limit. Some applications may rely on the value which this method returns. Just returning Long.MAX_VALUE may lead to confusion. It can simply returns the freeMemory available to the Java object allocation, if that's programmer wants. Basically I think this API is only for profiling hints purpose, meaning it has no guarantee about the real memory situation. So it's not recommended to program the application depending on its return value. That's correct, afaict. Kaffe does not limit per default the amount of memory available, allowing the gc to grow the heap as necessary. That used to confuse some older Eclipse releases, but the bug has been fixed in Eclipse. cheers, dalibor topic Thanks, xiaofeng - 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: [rant] Memory options in VM -- why is the default not 'unlimited'
How did Kaffe deal with SoftReferences? Did they ever go away when you did not have a memory limit? Dalibor Topic wrote: On Tue, Aug 01, 2006 at 10:39:03PM +0800, Xiao-Feng Li wrote: On 8/1/06, Gregory Shimansky [EMAIL PROTECTED] wrote: There is a method Runtime.freeMemory() which returns the memory available in the heap. I wonder what it should return when there is no limit. Some applications may rely on the value which this method returns. Just returning Long.MAX_VALUE may lead to confusion. It can simply returns the freeMemory available to the Java object allocation, if that's programmer wants. Basically I think this API is only for profiling hints purpose, meaning it has no guarantee about the real memory situation. So it's not recommended to program the application depending on its return value. That's correct, afaict. Kaffe does not limit per default the amount of memory available, allowing the gc to grow the heap as necessary. That used to confuse some older Eclipse releases, but the bug has been fixed in Eclipse. cheers, dalibor topic Thanks, xiaofeng - 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [performance] performance measurement of HDK
Vladimir, I've found some more Java benchmarks in bookmarks, maybe some of them will be interesting sor someone. - Richards and deltaBlue [1] - first simulates the task dispatcher in the kernel of an operating system, second is constraint solver benchmark in the Java programming language. - Copier [2] - The source transmits 10,000 numbers through a large number of copiers (1,000 to 20,000) to the sink As far as I understand there are Richards and Copier implementations under Creative Common License. [1] http://research.sun.com/people/mario/java_benchmarking/ [2] http://pws.prserv.net/dlissett/ben/copier1.htm Telco - this one mostly stresses BigInteger/BigDecimal functionality GcOld - the purpose of this one is clear from the name :) SciMark - java benchmark for scientific and numerical computing Linpack java - well-known benchmark solving linear equations The Plasma Benchmark - creates an animated display by continuously summing four sine waves in an applet JavaWorld Benchmark - benchmark for low-level operations: loops, accessing variables, method invocation, arithmetic operators, casting, instantiation, exception handling, thread creation and switching. CaffeineMark 3.0 - low-level benchmark suite, including sieve of Eratosthenes, sorting, logic ops, method invocation, floating point, simple graphics and GUI ops JavaGrande benchmark suite - a set of benchmarks stressing different areas of java. Having in mind that the list of publicly available benchmarks is not too big, sometimes it will be necessary to create micro benches for some of patches (for instance, Harmony-935). IMO micro should be started in case we change some code that the bench covers. Other interesting and possibly more productive way for comparing performance between different implementations are to use non-free benchmarks. For instance, we can use benchmarks from Spec[n], like SpecJVM, SpecJBB, SpecJAppserver. Unfortunately first we should get license for it, but I believe this issue can be solved within the help of companies participating in Harmony :) Thoughts? Comments? [1] http://dacapobench.org [2] http://www.spec.org -- Vladimir Strigun, 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] -- Regards, Anton Luht, 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]
[DRLVM/MMTk] remaining vmmagic bugs in jitrino.jet
All,
I added a bunch of missing regression tests. The only ones missing at
this point are the atomic operations. The regression tests are
currently in the process of being donated. Thus I can't simply post
these tests to Harmony JIRA :(
In any case below are the current tests that fail when running
jitrino.jet. I am not certain about the sign extend tests. I may
have constructed the test cases wrong.
/*
* Test method for '...unboxed.Address.toLong()'
*/
public static boolean toLong() {
Address adr = Address.fromInt(0xffFFffFF);
long lon = adr.toLong();
return lon == 0xffFFffFFL;
}
/*
* Test method for '...unboxed.Address.attempt(int, int, Offset)'
*/
public static boolean attemptInt() {
boolean res = false;
int i = adr.toInt();
adr.store(i, Offset.zero());
// JIT BROKEN res = adr.attempt(i, 0, Offset.zero());
// JIT BROKEN WJW res = !adr.attempt(i, 0, Offset.zero());
return res;
}
/*
* Test method for '...unboxed.Address.attempt(Word, Word)'
*/
public static boolean attemptWord() {
boolean res = false;
Word word = Word.fromIntSignExtend(adr.toInt());
adr.store(word);
// JIT BROKEN WJW res = adr.attempt(word, Word.zero());
// JIT BROKEN res = !adr.attempt(word, Word.zero());
return res;
}
// Extent.fromIntSignExtend() test
public static boolean fromIntSignExtend()
{
boolean res = true; //wjw is this test correct???
//System.out.println(fromIntSignExtend +
Long.toHexString(Extent.fromIntSignExtend(0xBABA).toLong() ) );
res = Extent.fromIntSignExtend(0xBABA).toLong() ==
0xffFFffFFffFFBABAL;
res = Extent.fromIntSignExtend(0x).toLong() ==
0xFFffFFffFFffFFffL;
return res;
}
// Word.fromIntSignExtend() test
public static boolean fromIntSignExtend()
{
boolean res = true; //wjw is this test correct???
//System.out.println(fromIntSignExtend +
Long.toHexString(Extent.fromIntSignExtend(0xBABA).toLong() ) );
res = Word.fromIntSignExtend(0xBABA).toLong() ==
0xffFFffFFffFFBABAL;
res = Word.fromIntSignExtend(0x).toLong() ==
0xFFffFFffFFffFFffL;
return res;
}
// Word.fromIntZeroExtend() test
public static boolean fromIntZeroExtend()
{
boolean res = true;
res = Word.fromIntZeroExtend(0xBABA).toLong() == 0xBABA;
res = Word.fromIntZeroExtend(0x).toLong() == 0xFFffFFffL;
return res;
}
//Word.toLong()
public static boolean toLong()
{
boolean res = false;
Word wor = Word.one();
res = (wor.toLong() == 0x01L);
wor = Word.max();
res = (wor.toLong() == 0xFFffFFffL);
return res;
}
--
Weldon Washburn
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: [rant] Memory options in VM -- why is the default not 'unlimited'
On Tuesday 01 August 2006 18:07, will pugh wrote: How did Kaffe deal with SoftReferences? Did they ever go away when you did not have a memory limit? Why are we discussing Kaffe in the past tense? -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [rant] Memory options in VM -- why is the default not 'unlimited'
-Original Message- From: Chris Gray [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 01, 2006 3:16 PM To: harmony-dev@incubator.apache.org Subject: Re: [rant] Memory options in VM -- why is the default not 'unlimited' On Tuesday 01 August 2006 18:07, will pugh wrote: How did Kaffe deal with SoftReferences? Did they ever go away when you did not have a memory limit? Why are we discussing Kaffe in the past tense? I assume because the resolution of the issue happened in the past? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Yes. I apologize. I stated it in the past because the issue was resolved in the past. More precise english probably would have been either: How did Kaffe decide to deal with SoftReferences? or How does Kaffe deal with SoftReferences? Although, still interested in the answer to either of these questions. Do SoftReferences basically become strong references without a limit? Do they basically become WeakReferences? or do they do something else? Thanks, --Will Magnusson, Geir wrote: -Original Message- From: Chris Gray [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 01, 2006 3:16 PM To: harmony-dev@incubator.apache.org Subject: Re: [rant] Memory options in VM -- why is the default not 'unlimited' On Tuesday 01 August 2006 18:07, will pugh wrote: How did Kaffe deal with SoftReferences? Did they ever go away when you did not have a memory limit? Why are we discussing Kaffe in the past tense? I assume because the resolution of the issue happened in the past? geir - 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: [performance] performance measurement of HDK
Vladimir Strigun wrote: Our project is now in a good shape and we started encouraging people to try real applications on top of Harmony. One of the important parts of the feedback will be general impression of stability, reliability and performance of the HDK. We are doing pretty good in fixing bugs and developing new functionality in HDK, and it might be a good time for us to start thinking of performance as well. It might be a little bit preliminary, but do we consider having any performance targets for us? If yes, we may need to focus at least some of our efforts on benchmarking and tuning overall performance of HDK. One of the main questions here is what should be the targets for us and how should we measure our performance. There are several ways for measuring performance, such us commercial benchmarks, free benchmarks, application startup, small micro suites, etc. Some of free benchmarks have been mentioned in JIRA issues and dev list, nevertheless at the moment we don't have any goals for performance. In spite of application enabling initiative it might be good to consider publicly available benchmarks as the additional list of the software applications which we would enable on Harmony. So I suggest to start discussing performance techniques and methods that can be used for comparing performance between RI and HDK. I think in case we do not consider performance issues, we can get negative feedback from users even if application starts without any errors, exceptions, etc. One of the benchmarks that was mentioned is DaCapo[1]. It's a free open-source benchmark suite and I believe it can be used for regular performance measurement of HDK. I've tried to find other free suites and got the following list: Telco - this one mostly stresses BigInteger/BigDecimal functionality GcOld - the purpose of this one is clear from the name :) SciMark - java benchmark for scientific and numerical computing Linpack java - well-known benchmark solving linear equations The Plasma Benchmark - creates an animated display by continuously summing four sine waves in an applet JavaWorld Benchmark - benchmark for low-level operations: loops, accessing variables, method invocation, arithmetic operators, casting, instantiation, exception handling, thread creation and switching. CaffeineMark 3.0 - low-level benchmark suite, including sieve of Eratosthenes, sorting, logic ops, method invocation, floating point, simple graphics and GUI ops JavaGrande benchmark suite - a set of benchmarks stressing different areas of java. Having in mind that the list of publicly available benchmarks is not too big, sometimes it will be necessary to create micro benches for some of patches (for instance, Harmony-935). IMO micro should be started in case we change some code that the bench covers. Other interesting and possibly more productive way for comparing performance between different implementations are to use non-free benchmarks. For instance, we can use benchmarks from Spec[n], like SpecJVM, SpecJBB, SpecJAppserver. Unfortunately first we should get license for it, but I believe this issue can be solved within the help of companies participating in Harmony :) Thoughts? Comments? one thing that happened in mozilla-land that catalized the community in fixing leaks and performance issues was adding profiling information to the tests and start plotting them overtime. Not only that gives an idea of the evolution of the program performance overtime, but it also keeps people honest because profiling is not something that should be done once and being forgotten but something that should be considered part of the feature of the program. -- 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: [classlib][html] Should we try to be binary compatible with Sun's bdtd?
HARMONY-948 has a serialized dtd file called transitional401.bdtd. When I try to read it by calling DTD.read(DataInputStream) I get a java.io.EOFException. But, on the other hand, when I create a binary DTD by calling DTDUtilities.create(String) I can get it with succeed. How can I read transitional401.bdtd file? I used the JRE Harmony 424571 release in GNU/Linux. Thanks, Diego Mercado On 7/28/06, Miguel Montes [EMAIL PROTECTED] wrote: On 7/28/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 7/28/06, Miguel Montes wrote: So, it seems there is consensus on the following steps: 1) We ask Sun again about the bdtd specs 2) We do NOT reverse engineer the bdtd 3) We choose a format, and document it. It also seems that serialization is not the proper way of doing 3), so we must select a format that doesn't depend on the implementation of, say, Hashtable, and we remain compatible with future versions of the class libraries. What about using ASN.1? We already have a decoder, so it shouldn't be difficult Yep, using ASN.1 for binary format seems logical. If we agree on this I can share my experience of working with ASN.1. In fact, I was thinking in using your decoder, Stepan, so that's great news. Thanks, Stepan. On 7/27/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 26, 2006 9:08 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][html] Should we try to be binary compatible with Sun's bdtd? SNIP The method read(DataInputStream). It's poorly documented, but it reads a DTD in an unspecified binary format. The default DTD is stored in this format in a file named html32.bdtd (or html401.bdtd, in the case of the recent contribution). This method seems to be undocumented at all until people asked for it [1]. As Alexey pointed out, there is no method to write a DTD, so maybe nobody uses the method read() anyway. But I see no point in having a public method that nobody can use. So I think we can: 1) Ask Sun to release the specification (if there is one) We should try this once more (The first attempt was made in [1]). or 2) Figure it out, and document it or 3) Release our own specification Maybe specification is not the right word here. I believe we _can_ document which format we use. So that anyone can prepare their own archive file with DTD, read it using jx.s.t.html.parser.DTD.read, pass it to parser. since the method is public and part of javax.swing, we need to implement it, but this looks like a mistake or an overlook (and there are no swing tests in the TCK anyway so we can do whatever we please). It is not the only place where a public method is present, but it has no use because of lack of documentation. I think it's safe to try #1 and #2 in parallel with different people. Geir can do #1 while you can do #2. /me loves to delegate ;-) (aka lazy ass mode) I would suggest against #3: specifications are something that we are not tasked to do (even to compensate lack of such), as it might deliver the wrong message. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4216248 Regards, -- Alexey A. Ivanov Intel Middleware Product Division -- Thanks, Stepan Mishura 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] -- Miguel Montes - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Intention to work on java.lang.instrument
On 8/1/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Tuesday 01 August 2006 09:47 Leo Li wrote: I agree with this approach. Do you know which API functions and events you will need for such agent? Hi, we will need VM Initialization Event to run premain functions and Class File Load Hook Event for agents to instruct the existing class file. As to the jvmti API, we need RedefineClasses,GetObjectSize and Allocate. Besides, AddCapabilities is also required to turn on the capability of the VM, such as can_generate_all_class_hook_events and can_redefine_classes. Since we have just planned to implement this module, please excuse me if I leave some requirements about it. :) It is not a problem. I just wanted to know which areas are required, not every single API function :) All of the functions and events that you mentioned are implemented already except for RedefineClasses. It is on the TODO list for drlvm. Good! Maybe we can test instruments on drlvm some day.:) -- 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] -- Leo Li China Software Development Lab, IBM
Re: [testing] metadata approach
Alexei Zakharov wrote: Hi Richard, Not sure if we really want to involve another migration: TestNG javadoc - TestNG annotation. Any comments? Well, IMHO this depends on time constraints - when do we plan to have the support for anotations? If the answer is about a couple of weeks - no problem, we can wait. But if this is several months... About the migration - I don't think this will be a real painfull migration, all infrastructure will remain the same. We will only need to convert javadocs to annotations (one-one correspondence) and this task can be easily automated. Sounds reasonable. :-) Maybe drlvm guys or Oliver could tell us when we will have a VM with annotation support? Thanks, 2006/8/1, Richard Liang [EMAIL PROTECTED]: Alexei Zakharov wrote: Hi, I have created this new thread as a single place for discussions started in Re: [testing] Peace and [classlib] Testing conventions – a proposal threads. What did we have in the previous threads? * Test classification proposed by Vladimir * Test classification and group names proposed by George * Solution for Ant and TestNG scripting issues (still being discussed) Since a lot of people are asking about TestNG and wanting TestNG I decide to put some effort and take a closer look at this piece of software. Thus during the last few days I was playing with TestNG - I tried to run different kind of tests with it, to perform various workloads, generate reports in different ways and etc. The purpose of all this activity was to try TestNG in a real work, understand is TestNG really worth our credits and how expensive can be moving to TestNG from our currently implemented testing infrastructure. Now I have some thoughts and facts I'd like to share with the community. I've put it in the form of list for convenience. * TestNG works ok in normal conditions, no visible bugs * It is possible to define and use various (possibly intersecting) test groups with TestNG * TestNG-style metadata is more convenient than JUnit test suites (now I agree with this statement). IMHO this is the main TestNG benefit. * It is possible to run TestNG from command line * There is also the special ant task for running TestNG * Not everything can be configured with the ant task or command-line params, sometimes extra test suite definition file testng.xml is needed * It is possible to run jUnit tests with TestNG (testng.xml is needed in this case) * It is possible to run junit tests we currently have in Harmony with TestNG without any problems and modifications of the source code. However, we probably should write some number of TestNG test suite definition files testng.xml to be able to run all our junit tests (I have tried tests for bean module and some tests for luni) * We can mix jUnit tests and TestNG tests in the single test suite configuration – i.e. single testng.xml file. We can add TestNG metadata to some test classes and leave other test classes untouched * TestNG generates HTML reports in its own style, not a very convenient one IMHO * It is also possible to generate JUnitReports from the output generated by TestNG * Such reports will have a little bit different structure since TestNG doesn't provider any information about enclosing type for test methods. Names for tests (replacement for JUnit test classes) and test suites should be externally configured in testng.xml * TestNG for Java 5 doesn't work on Harmony because some necessary classes from java.util.concurrent package are missing and it seems that jsr14 target (we are currently using) doesn't support annotations * TestNG for Java 1.4 (javadoc version) currently works on Harmony * I have half-way done script that converts TestNG 1.4 metadata (javadoc) tests to TestNG 1.5 (5.0 annotations) tests. Excellent summary! Thanks a lot The question I'd like to raise now is – aren't we ready for TestNG right now? I suppose we will use Java 5.0 annotations of TestNG, so it seems now we are not ready for TestNG. But we can continue our feasibility study, just like what you have done, to know if TestNG really meets our requirements or if there are any potential problems. Maybe we could list a prerequisite list. e.g, 1) Harmony can fully self-host TestNG with Java5 annotations 2) Test groups are well-defined and agreed in community 3) Guidelines to write TestNG testcases 4) Take one module to run a pilot case Please correct me if I'm wrong For example, we could replace our harness from jUnit to TestNG and lazily start converting of some failing and platform dependent tests to javadoc version of TestNG. The rest of the tests will remain jUnit in fact. And when our VM will be ready to handle annotations we can convert all our TestNG 1.4 tests to TestNG 1.5. I understand that this idea may seem to be too early. But anyway we will need to change things some day since many people are unhappy with the current testing infrastructure (me for example). Not
Re: AWT 2D PERFORMANCE ISSUE
Ivanov, Alexey A wrote: -Original Message- From: Igor Stolyarov [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 1:04 PM To: harmony-dev@incubator.apache.org Subject: Re: AWT 2D PERFORMANCE ISSUE I think using WeakReference and ReferenceQueue can't help because according to RI I have to give customer array You give the customer that array, and store a Weak- or PhantomReference in your object. When you need to update some data, you can check if the array you gave is still alive or not. I dealt with this kind of problem in javax.swing.text.GapContent. Its createPosition() method should return an object to client. This object returned must be updated when data (text) stored in GapContent is modified. To reduce the number of Position objects to be updated, I used PhantomReferences to be notified that the object I returned to client was cleared by garbage collector. Has anyone else dealt with reference APIs and similar problems? Just noticed this thread, for your information, there is a o.a.h.luni.platform.IMemorySpy in modules/luni/ module, which is used to free the direct/mapped buffers using ReferenceQueue, and maybe there is some chance to refactor so that it can be more widely used (currently it is limited by the coupling with PlatformAddress, maybe some interface can be extracted, say Freeable or so), because I have seen several similar requirements in different modules(nio, java.net, and awt as well as swing here), so it will be good if we can reuse the codes. And at least, it can be some sample codes of ReferenceQueue:). Regards, Alexey. On 7/28/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: -Original Message- From: Igor Stolyarov [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 9:25 AM To: harmony-dev@incubator.apache.org Subject: Re: AWT 2D PERFORMANCE ISSUE I'm sorry. May be I don't clear explained my question. Main target of my question was discussion of synchronization of two arrays one of these is java array, second is native array. Main issue of this synchronization is the fact that customer can recieve reference to the java array and we don't know when customer will release the array. What about using Weak- or PhantomReferences and ReferenceQueue? They may solve your problem. Regards, -- Alexey A. Ivanov Intel Middleware Product Division SNIP - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Igor V. Stolyarov Intel Middleware Products Division -- Alexey A. Ivanov 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] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Portlib]Proposal to extend portlib with enhanced mmap functions:
Thank you for all your attention on this:), because seems no one objects, I'm going to assign HARMONY-982 to myself, and start to extend the portlib. Paulex Yang wrote: Sorry I forgot to add the prefix just now. Paulex Yang wrote: Hi, all I raise HARMONY-982 (https://issues.apache.org/jira/browse/HARMONY-982) about the portlib extension on mmap. And here goes my proposal about the extension, comments are welcome. Currently portlib has some mmap support, but the support is limited in several ways: 1. it only mmap in private(copy_on_write) mode 2. it always mmap whole file 3. it only accepts filename, but nio needs to map a already opened file descriptor so that the Harmony's mmap is implemented in platform dependent codes so far, I think these are good candidates as the portlib extension. To support the nio's requirement, three current mmap functions need to be enhanced - hymmap_map_file, hymmap_unmap_file and hymmap_capabilities, one new method is added: hymmap_msync. Please see details below: 1. hymmap_map_file /** * Map a part of file into memory. * * @param [in] portLibrary The port library * @param [in] file The file descriptor/handle of the already open file to be mapped * @param [in] offsetThe file offset of the part to be mapped * @param [in] size The number of bytes to be mapped, if zero, the whole file is mapped * @param [in] mappingName The name of the file mapping object to be created/opened. * If a named object is not required, this parameter can be specified as NULL * @param [in] flagsFlags relating to the mapping: * @args HYPORT_MMAP_FLAG_READread only map * @args HYPORT_MMAP_FLAG_WRITE read/write map * @args HYPORT_MMAP_FLAG_COPYONWRITE copy on write map * @args HYPORT_MMAP_FLAG_SHARED share memory mapping with other processes * @args HYPORT_MMAP_FLAG_PRIVATE private memory mapping, do not share with other processes (implied by HYPORT_MMAP_FLAG_COPYONWRITE) * * @returnA pointer to the start of the mapped file or NULL is an error has occurred */ void *hymmap_map_file(HYPortLibrary portLibrary, IDATA file, U_64 offset, UDATA size, const char *mappingName, U_32 flags) This will use CreateFileMapping() and MapViewOfFile() on Windows and mmap() on Unix to map the file into the process' address space. In both cases, it will return the address to which the file has been mapped. The memory mapping API's on all platforms require an open handle/file descriptor to the file to be mapped. The mapAddress parameter has been removed from the original signature. This was an output parameter from the API containing the address at which the file has been mapped. However, this is the return value of the function and was therefore duplication. 2. hymmap_msync /** * Synchronise updates to memory mapped file region with file on disk. The call may wait for the file write * to complete or this may be scheduled for a later time and the function return immediately, depending on * the flags setting * * @param [in] portLibrary The port library * @param [in] start Pointer to the start of the memory mapped area to be synchronised * @param [in] length Length of the memory mapped area to be synchronised * @param [in] flags Flags controlling the behaviour of the function: * @args HYPORT_MMAP_SYNC_WAIT Synchronous update required, function will not * return until file updated. Note that to achieve this on Windows requires the * file to be opened with the FILE_FLAG_WRITE_THROUGH flag * @args HYPORT_MMAP_SYNC_ASYNC Asynchronous update required, function returns * immediately, file will be updated later * @args HYPORT_MMAP_SYNC_INVALIDATE Requests that other mappings of the same * file be invalidated, so that they can be updated with the values just written * * @return 0 on success, -1 on failure. Errors will be reported using the usual port library mechanism */ IDATA hymmap_msync(HYPortLibrary portLibrary, void *start, UDATA length, U_32 flags) This function will use msync on Unix and FlushViewOfFile on Windows. 3.
[classlib] Plan on work on java.lang.instrument
Hi, If no objection, I shall go on with the plan of instrument :) Refer to Harmony status page[1], INSTRUMENT is missing, so this module shall named as instrument. I shall open a wiki-page for its status like other modules on [2]. For Java codes, API classes/interfaces can be added to modules/luni/src/main/java/java/lang/instrument, and implementation can be added to modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument For native codes, instrument need a new directory in modules/luni/src/main/native named instrument, in my plan, there should be two native code, one for instrument native implementation, and another for laugher (for parameter -javaagent). Instrument shall be compiled into a .DLL(.so) file alone. Any suggestions? Thanks! :) [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html [2]http://wiki.apache.org/harmony/INSTRUMENT -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Plan on work on java.lang.instrument
On 8/2/06, Jimmy, Jing Lv wrote: Hi, If no objection, I shall go on with the plan of instrument :) Refer to Harmony status page[1], INSTRUMENT is missing, so this module shall named as instrument. I shall open a wiki-page for its status like other modules on [2]. For Java codes, API classes/interfaces can be added to modules/luni/src/main/java/java/lang/instrument, and implementation can be added to modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument Sorry, I didn't catch why you are going to put code to 'luni' module Did you mean: modules/ instrument/ src/main/java/java/lang/instrument src/main/java/org/apache/harmony/luni/internal/lang/instrument Thanks, Stepan. For native codes, instrument need a new directory in modules/luni/src/main/native named instrument, in my plan, there should be two native code, one for instrument native implementation, and another for laugher (for parameter -javaagent). Instrument shall be compiled into a .DLL(.so) file alone. Any suggestions? Thanks! :) [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html [2]http://wiki.apache.org/harmony/INSTRUMENT -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Stepan Mishura 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: [classlib][nio-charset] RI is inconsistent with spec when loading charset provider
On 8/1/06, Richard Liang wrote: Andrew Zhang wrote: On 7/31/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 7/31/06, Andrew Zhang [EMAIL PROTECTED] wrote: Shall we follow RI or spec? I'd like to suggest follow RI for this specific case, because: 1. If we follow spec, it may cause legacy applications fail. I do not think that fixing this bug will affect legacy applications badly, because we will add new functionality that is turned on by special configuration files. Old functionality will not be affected. Even with our special configuration, Harmony still behaves differently from RI, right? For some case, RI could load user specified configuration file while harmony could not, and vice versa. So I think legacy applications will be affected if they assume system class loader is used. :) 2. Other service provider in nio module are all loaded by system class loader. Any suggestions and comments? This bug is 4 years old. One or two years more and it will become a 'feature' http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4619777 Anyway, I vote to follow spec but not RI :) (AFAIK as classpath did) I tried to run the test against sun 6.0 pre-rc-b65. The result is the same. Seems SUN doesn't take any action on this problem. As you mentioned, it's already 4 years, and is not solved in jdk6. :( So I still think we should follow RI this time. :) Shall we integrate the spec and RI? That is, 1) Try to load the Charset provider via the current thread's context class loader 2) If fail to load the provider in step 1), try to use system class loader to load the Charset provider. I agree. Thanks, Stepan. Please correct me if I'm wrong. Thanks a lot. Best regards, Richard -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Plan on work on java.lang.instrument
It is a lang package, right? Stepan Mishura wrote: On 8/2/06, Jimmy, Jing Lv wrote: Hi, If no objection, I shall go on with the plan of instrument :) Refer to Harmony status page[1], INSTRUMENT is missing, so this module shall named as instrument. I shall open a wiki-page for its status like other modules on [2]. For Java codes, API classes/interfaces can be added to modules/luni/src/main/java/java/lang/instrument, and implementation can be added to modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument Sorry, I didn't catch why you are going to put code to 'luni' module Did you mean: modules/ instrument/ src/main/java/java/lang/instrument src/main/java/org/apache/harmony/luni/internal/lang/instrument Thanks, Stepan. For native codes, instrument need a new directory in modules/luni/src/main/native named instrument, in my plan, there should be two native code, one for instrument native implementation, and another for laugher (for parameter -javaagent). Instrument shall be compiled into a .DLL(.so) file alone. Any suggestions? Thanks! :) [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html [2]http://wiki.apache.org/harmony/INSTRUMENT -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - 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: [Portlib]Proposal to extend portlib with enhanced mmap functions:
Sorry I didn't reply sooner. Have fun :) geir Paulex Yang wrote: Thank you for all your attention on this:), because seems no one objects, I'm going to assign HARMONY-982 to myself, and start to extend the portlib. Paulex Yang wrote: Sorry I forgot to add the prefix just now. Paulex Yang wrote: Hi, all I raise HARMONY-982 (https://issues.apache.org/jira/browse/HARMONY-982) about the portlib extension on mmap. And here goes my proposal about the extension, comments are welcome. Currently portlib has some mmap support, but the support is limited in several ways: 1. it only mmap in private(copy_on_write) mode 2. it always mmap whole file 3. it only accepts filename, but nio needs to map a already opened file descriptor so that the Harmony's mmap is implemented in platform dependent codes so far, I think these are good candidates as the portlib extension. To support the nio's requirement, three current mmap functions need to be enhanced - hymmap_map_file, hymmap_unmap_file and hymmap_capabilities, one new method is added: hymmap_msync. Please see details below: 1. hymmap_map_file /** * Map a part of file into memory. * * @param [in] portLibrary The port library * @param [in] file The file descriptor/handle of the already open file to be mapped * @param [in] offsetThe file offset of the part to be mapped * @param [in] size The number of bytes to be mapped, if zero, the whole file is mapped * @param [in] mappingName The name of the file mapping object to be created/opened. * If a named object is not required, this parameter can be specified as NULL * @param [in] flagsFlags relating to the mapping: * @args HYPORT_MMAP_FLAG_READread only map * @args HYPORT_MMAP_FLAG_WRITE read/write map * @args HYPORT_MMAP_FLAG_COPYONWRITE copy on write map * @args HYPORT_MMAP_FLAG_SHARED share memory mapping with other processes * @args HYPORT_MMAP_FLAG_PRIVATE private memory mapping, do not share with other processes (implied by HYPORT_MMAP_FLAG_COPYONWRITE) * * @returnA pointer to the start of the mapped file or NULL is an error has occurred */ void *hymmap_map_file(HYPortLibrary portLibrary, IDATA file, U_64 offset, UDATA size, const char *mappingName, U_32 flags) This will use CreateFileMapping() and MapViewOfFile() on Windows and mmap() on Unix to map the file into the process' address space. In both cases, it will return the address to which the file has been mapped. The memory mapping API's on all platforms require an open handle/file descriptor to the file to be mapped. The mapAddress parameter has been removed from the original signature. This was an output parameter from the API containing the address at which the file has been mapped. However, this is the return value of the function and was therefore duplication. 2. hymmap_msync /** * Synchronise updates to memory mapped file region with file on disk. The call may wait for the file write * to complete or this may be scheduled for a later time and the function return immediately, depending on * the flags setting * * @param [in] portLibrary The port library * @param [in] start Pointer to the start of the memory mapped area to be synchronised * @param [in] length Length of the memory mapped area to be synchronised * @param [in] flags Flags controlling the behaviour of the function: * @args HYPORT_MMAP_SYNC_WAIT Synchronous update required, function will not * return until file updated. Note that to achieve this on Windows requires the * file to be opened with the FILE_FLAG_WRITE_THROUGH flag * @args HYPORT_MMAP_SYNC_ASYNC Asynchronous update required, function returns * immediately, file will be updated later * @args HYPORT_MMAP_SYNC_INVALIDATE Requests that other mappings of the same * file be invalidated, so that they can be updated with the values just written * * @return 0 on success, -1 on failure. Errors will be reported using the usual port library mechanism */ IDATA hymmap_msync(HYPortLibrary portLibrary, void *start,
Re: AWT 2D PERFORMANCE ISSUE
Thank you Paulex, may be it is that what is needed. -- Igor V. Stolyarov Intel Middleware Products Division
Re: [classlib] Plan on work on java.lang.instrument
Yes, it is. But accoriding to [1] the code should be put into separate 'instrument' module. So the patch should start with 'modules/'instrument'. Thanks, Stepan. [1]http://wiki.apache.org/harmony/componentization On 8/2/06, Geir Magnusson Jr wrote: It is a lang package, right? Stepan Mishura wrote: On 8/2/06, Jimmy, Jing Lv wrote: Hi, If no objection, I shall go on with the plan of instrument :) Refer to Harmony status page[1], INSTRUMENT is missing, so this module shall named as instrument. I shall open a wiki-page for its status like other modules on [2]. For Java codes, API classes/interfaces can be added to modules/luni/src/main/java/java/lang/instrument, and implementation can be added to modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument Sorry, I didn't catch why you are going to put code to 'luni' module Did you mean: modules/ instrument/ src/main/java/java/lang/instrument src/main/java/org/apache/harmony/luni/internal/lang/instrument Thanks, Stepan. For native codes, instrument need a new directory in modules/luni/src/main/native named instrument, in my plan, there should be two native code, one for instrument native implementation, and another for laugher (for parameter -javaagent). Instrument shall be compiled into a .DLL(.so) file alone. Any suggestions? Thanks! :) [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html [2]http://wiki.apache.org/harmony/INSTRUMENT -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - 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] -- Thanks, Stepan Mishura 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: [performance] performance measurement of HDK
Vladimir Strigun wrote: Our project is now in a good shape and we started encouraging people to try real applications on top of Harmony. One of the important parts of the feedback will be general impression of stability, reliability and performance of the HDK. We are doing pretty good in fixing bugs and developing new functionality in HDK, and it might be a good time for us to start thinking of performance as well. It might be a little bit preliminary, but do we consider having any performance targets for us? If yes, we may need to focus at least some of our efforts on benchmarking and tuning overall performance of HDK. Well, I wouldn't say the HDK, as much as Harmony. One of the main questions here is what should be the targets for us and how should we measure our performance. There are several ways for measuring performance, such us commercial benchmarks, free benchmarks, application startup, small micro suites, etc. Some of free benchmarks have been mentioned in JIRA issues and dev list, nevertheless at the moment we don't have any goals for performance. In spite of application enabling initiative it might be good to consider publicly available benchmarks as the additional list of the software applications which we would enable on Harmony. Yep. So I suggest to start discussing performance techniques and methods that can be used for comparing performance between RI and HDK. I think s/HDK/Harmony in case we do not consider performance issues, we can get negative feedback from users even if application starts without any errors, exceptions, etc. One of the benchmarks that was mentioned is DaCapo[1]. It's a free open-source benchmark suite and I believe it can be used for regular performance measurement of HDK. I've tried to find other free suites and got the following list: Telco - this one mostly stresses BigInteger/BigDecimal functionality GcOld - the purpose of this one is clear from the name :) SciMark - java benchmark for scientific and numerical computing Linpack java - well-known benchmark solving linear equations The Plasma Benchmark - creates an animated display by continuously summing four sine waves in an applet JavaWorld Benchmark - benchmark for low-level operations: loops, accessing variables, method invocation, arithmetic operators, casting, instantiation, exception handling, thread creation and switching. CaffeineMark 3.0 - low-level benchmark suite, including sieve of Eratosthenes, sorting, logic ops, method invocation, floating point, simple graphics and GUI ops JavaGrande benchmark suite - a set of benchmarks stressing different areas of java. These are good. I it would be nice to just hook them into the build-test framework as optional parts. Having in mind that the list of publicly available benchmarks is not too big, sometimes it will be necessary to create micro benches for some of patches (for instance, Harmony-935). IMO micro should be started in case we change some code that the bench covers. Sure Other interesting and possibly more productive way for comparing performance between different implementations are to use non-free benchmarks. For instance, we can use benchmarks from Spec[n], like SpecJVM, SpecJBB, SpecJAppserver. Unfortunately first we should get license for it, but I believe this issue can be solved within the help of companies participating in Harmony :) Maybe. What we want to have is those benchmarks available to anyone in the project, although we'll take what we can get for now... geir Thoughts? Comments? [1] http://dacapobench.org [2] http://www.spec.org -- Vladimir Strigun, 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Plan on work on java.lang.instrument
Never appeal to me using a Wiki as an authority :) It's like finding something written in chalk on the sidewalk. However, if you had pointed out http://incubator.apache.org/harmony/auth_cont_quest.html I'd have agreed w/o having the opportunity to make fun of the Wiki. So I agree :) geir Stepan Mishura wrote: Yes, it is. But accoriding to [1] the code should be put into separate 'instrument' module. So the patch should start with 'modules/'instrument'. Thanks, Stepan. [1]http://wiki.apache.org/harmony/componentization On 8/2/06, Geir Magnusson Jr wrote: It is a lang package, right? Stepan Mishura wrote: On 8/2/06, Jimmy, Jing Lv wrote: Hi, If no objection, I shall go on with the plan of instrument :) Refer to Harmony status page[1], INSTRUMENT is missing, so this module shall named as instrument. I shall open a wiki-page for its status like other modules on [2]. For Java codes, API classes/interfaces can be added to modules/luni/src/main/java/java/lang/instrument, and implementation can be added to modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument Sorry, I didn't catch why you are going to put code to 'luni' module Did you mean: modules/ instrument/ src/main/java/java/lang/instrument src/main/java/org/apache/harmony/luni/internal/lang/instrument Thanks, Stepan. For native codes, instrument need a new directory in modules/luni/src/main/native named instrument, in my plan, there should be two native code, one for instrument native implementation, and another for laugher (for parameter -javaagent). Instrument shall be compiled into a .DLL(.so) file alone. Any suggestions? Thanks! :) [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html [2]http://wiki.apache.org/harmony/INSTRUMENT -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Plan on work on java.lang.instrument
Stepan Mishura wrote: Yes, it is. But accoriding to [1] the code should be put into separate 'instrument' module. So the patch should start with 'modules/'instrument'. Ah ... you are right, thanks very much Stepan! :) So I shall put code to modules/ instrument/ src/main/java/java/lang/instrument Thanks, Stepan. [1]http://wiki.apache.org/harmony/componentization On 8/2/06, Geir Magnusson Jr wrote: It is a lang package, right? Stepan Mishura wrote: On 8/2/06, Jimmy, Jing Lv wrote: Hi, If no objection, I shall go on with the plan of instrument :) Refer to Harmony status page[1], INSTRUMENT is missing, so this module shall named as instrument. I shall open a wiki-page for its status like other modules on [2]. For Java codes, API classes/interfaces can be added to modules/luni/src/main/java/java/lang/instrument, and implementation can be added to modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument Sorry, I didn't catch why you are going to put code to 'luni' module Did you mean: modules/ instrument/ src/main/java/java/lang/instrument src/main/java/org/apache/harmony/luni/internal/lang/instrument Thanks, Stepan. For native codes, instrument need a new directory in modules/luni/src/main/native named instrument, in my plan, there should be two native code, one for instrument native implementation, and another for laugher (for parameter -javaagent). Instrument shall be compiled into a .DLL(.so) file alone. Any suggestions? Thanks! :) [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html [2]http://wiki.apache.org/harmony/INSTRUMENT -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - 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] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc]proposal to improve and expand website
Morozova, Nadezhda wrote: Geir, all, I have thought that I could contribute by brushing up and expanding some of the pages on the Harmony website. My first attempt has been to edit the FAQ section, see JIRA issue 1032 [1]. Patch applied and committed Another thing I could do is to add content to the DRLVM page (a newly added page with no content so far). I thought that placing links to various docs we have for DRLVM now could be useful. If nobody is against this, I could produce a trial patch shortly. Yep, that would be wonderful. One technical question: if I place links to documents that go into SVN and check out the latest version, the link takes you to the HTML doc with no images or styles displayed. As I understand, Geir has overcome this difficulty when linking from the Documentation page to descriptions of classlib bundles by copying the docs into the site/docs/externals directory. Should I do that for Getting Started, Developer's Guide and any other HTML docs I find for DRLVM? Yes - until we federate all of this stuff, lets use the externals as a read only copy for this. Note: the ClassLibrary page [2], section Architecture and Guide has links to external sources [3] that are also HTML displayed with no styles or formatting or images. Perhaps, we should also fix that somehow. Somehow. Suggestions welcome. geir [1] JIRA 1032, https://issues.apache.org/jira/browse/HARMONY-1032 [2] ClassLib page http://incubator.apache.org/harmony/subcomponents/classlibrary/index.htm l [3] link to porting docs, http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/d oc/vm_doc/html/index.html?view=co Nadya Morozova, Technical writer - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools] [patch] Modifications to harmony eclipse plugin to make it work with DRLVM
Great. Can you augment this to be applied to a copy of the launcher
code we'll keep in the DRLVM tree? And maybe a simpler buildfile that
isn't a part of the DRLVM build infrastructure? (which we want to get
away from...)
geir
Salikh Zakirov wrote:
Hi,
I have been reviewing the DRLVM JIRA issues, and came across
HARMONY-699 [DRLVM] modification to eclipse plugin should be applied to
plugin itself
So I took the hyplugin.patch from DRLVM distribution and applied the changes
to plugin source tree, taking into account, that DRLVM executable is no
longer ij.exe,
but plain java.exe.
Then I have tried to run the modified plugin, and found out that it does not
find
kernel jar files by default, because DRLVM does not provide some property file
(default location that is searched from is
'jre/bin/default/clearvm.properties',
which looks pretty similar to the default -vm -vmdir arguments of the
launcher).
Anyway, DRLVM does not provide property files for kernel files
(* and I personally do not like them *),
so I figured it would be reasonable to provide a reasonable default coded
right
into the plugin code.
The resulting patch is provided below for review.
(HARMONY-699 has the same changes in two patches).
Could you please review the modifications and commit the changes if there are
no objections? This will allow to remove custom plugin build from DRLVM.
The plugin works okay on my Windows/ia32 laptop.
Thanks a lot!
--- /dev/null
+++ eclipse/org.apache.harmony.eclipse.jdt.launching/build.xml
@@ -0,0 +1,74 @@
+?xml version=1.0 encoding=ISO-8859-1?
+!--
+Copyright 2005-2006 The Apache Software Foundation or its licensors, as
applicable.
+
+Licensed under the Apache License, Version 2.0 (the License);
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an AS IS BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+--
+project name=hyplugin default=build
+
+target name=init
+ property name=build.dir value=bin/
+ property name=jar.name
value=${build.dir}/org.apache.harmony.eclipse.jdt.launching_1.0.0.jar /
+/target
+
+target name=find.eclipse
+
+ property environment=env/
+ available property=eclipse.home value=${env.ECLIPSE_HOME}
+ file=${env.ECLIPSE_HOME}/startup.jar/
+ fail unless=eclipse.homeError:
+ Can't find eclipse home.
+ Please set the environment variable ECLIPSE_HOME to Eclipse location
+ or pass it as the property -Declipse.home=...
+ /fail
+
+ path id=java.class.path
+ fileset dir=${java.home} includes=**/*.jar /
+ fileset dir=${eclipse.home} includes=**/*.jar /
+ /path
+
+/target
+
+target name=build depends=init, find.eclipse
+ mkdir dir=${build.dir}/
+ javac destdir=${build.dir}
+ debug=yes
+ classpathref=java.class.path
+ srcdir=src
+ includes=**/*.java/
+
+ jar destfile=${jar.name} manifest=META-INF/MANIFEST.MF
+ fileset dir=${build.dir}
+ include name=**/*.class/
+ /fileset
+ fileset dir=src
+ include name=**/*.properties/
+ /fileset
+ fileset dir=. includes=plugin.xml/
+ /jar
+/target
+
+target name=clean depends=init
+ delete dir=${build.dir}/
+/target
+
+target name=install depends=init, find.eclipse
+ available file=${jar.name} property=jar.built/
+ fail unless=jar.built
+ Can't find built jar file ${jar.name}.
+ Please run 'ant build' first
+ /fail
+ copy file=${jar.name} todir=${eclipse.home}/plugins/
+/target
+
+/project
diff --git
eclipse/org.apache.harmony.eclipse.jdt.launching/src/org/apache/harmony/eclipse/jdt/launching/HyLauncherMessages.java
eclipse/org.apache.harmony.eclipse.jdt.launching/src/org/apache/harmony/eclipse/jdt/launching/HyLauncherMessages.java
old mode 100644
new mode 100755
index 645f92e..c49f850
---
eclipse/org.apache.harmony.eclipse.jdt.launching/src/org/apache/harmony/eclipse/jdt/launching/HyLauncherMessages.java
+++
eclipse/org.apache.harmony.eclipse.jdt.launching/src/org/apache/harmony/eclipse/jdt/launching/HyLauncherMessages.java
@@ -22,8 +22,14 @@ public class HyLauncherMessages {
private static final String RESOURCE_BUNDLE =
org.apache.harmony.eclipse.jdt.launching.HyLauncherMessages; //$NON-NLS-1$
- private static ResourceBundle resourceBundle = ResourceBundle
- .getBundle(RESOURCE_BUNDLE);
+ private static ResourceBundle resourceBundle;
+ static {
+ try
Re: [general]Snapshot cannot work on Win2K
Why is it needed? Clearly something is wrong w/ the binary snapshot, which is supposed to be a release build... geir Salikh Zakirov wrote: Aleksey Ignatenko wrote: Hi, it looks like your friend needs to install Microsoft Platform SDK on his PC . Another solution is to download and update version of dbghelp library from msdn site. I vaguely remember that Microsoft license allows to include dbghelp.dll to binary distributions. Below is a quote from EULA (end user license agreement). May be we could put dbghelp.dll to binary snapshots? --- 8 --- * Distribution Terms. You may reproduce and distribute an unlimited number of copies of the Sample Code and/or Redistributable Code (collectively Redistributable Components) as described above in object code form, provided that (a) you distribute the Redistributable Components only in conjunction with and as a part of your Application solely for use with a Microsoft Operating System Product; (b) your Application adds significant and primary functionality to the Redistributable Components; (c) you distribute your Application containing the Redistributable Components pursuant to an End-User License Agreement (which may be break-the-seal, click-wrap or signed), with terms no less protective than those contained herein; (d) you do not permit further redistribution of the Redistributable Components by your end-user customers; (e) you do not use Microsoft's name, logo, or trademarks to market your Application; (f) you include a valid copyright notice on your Application; and (g) you agree to indemnify, hold harmless, and defend Microsoft from and against any claims or lawsuits, including attorneys' fees, that arise or result from the use or distribution of your Application. Contact Microsoft for the applicable licensing terms for all other uses and/or distribution of the Redistributable Components. --- 8 --- [1] http://www.microsoft.com/downloads/details.aspx?displaylang=enFamilyID=CD1FC4B2-0885-47F4-AF45-7FD5E14DB6C0 - 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: [classlib] Plan on work on java.lang.instrument
Stepan Mishura wrote: On 8/2/06, Jimmy, Jing Lv wrote: Hi, If no objection, I shall go on with the plan of instrument :) Refer to Harmony status page[1], INSTRUMENT is missing, so this module shall named as instrument. I shall open a wiki-page for its status like other modules on [2]. For Java codes, API classes/interfaces can be added to modules/luni/src/main/java/java/lang/instrument, and implementation can be added to modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument Sorry, I didn't catch why you are going to put code to 'luni' module Did you mean: modules/ instrument/ src/main/java/java/lang/instrument src/main/java/org/apache/harmony/luni/internal/lang/instrument Hi, It is java.lang.instrument, so IMHO it can be put to luni module. And another reason is that it is rather small to be a single module. :) Thanks, Stepan. For native codes, instrument need a new directory in modules/luni/src/main/native named instrument, in my plan, there should be two native code, one for instrument native implementation, and another for laugher (for parameter -javaagent). Instrument shall be compiled into a .DLL(.so) file alone. Any suggestions? Thanks! :) [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html [2]http://wiki.apache.org/harmony/INSTRUMENT -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build-test-infra] Build Test Infrastructure
Anton Luht wrote: Hello, I know why this thread is so lazy - it's because everybody dislikes QA testing :) OK, now let me add my $0.02 about my vision about reporting of test results. I believe it's better to do this using HTTP rather than mail because some people may not have access to SMTP port (for example, be behind proxy with Exchange as mail server - I don't really know if it provides SMTP service). HTTP is open in most configurations and it was already decided that HDK and tests will be delivered via HTTP. I see the reporting of the results in the following way: after executing tests the script packs results and uploads them (as with browser file upload) to the server. After that data is processed on server-side - daemons can send periodical e-mails, draw charts, reports, lists of top test results contributors, etc. Nobody criticized this approach so I assume that it's not too bad. I'm going to implement a sketch for server-side bunch of scripts - one that accepts uploads and puts them to a temp directory and maybe some simple reports. They won't use any database. I believe that most common server-side engine is CGI (not PHP or J2EE) so I'd like to implement this using Perl CGI scripts. Have you thought of maybe... using... Java? I hear it's pretty good :) Since this is a first draft, I'm not going to use advanced templates language like XSLT. Including HTML output in script is bad idea so I'm going to use something like HTML::Template [1] for pages generation and CGI::Lite [2] for requests handling. Perl is chosen just because it suites well for fast prototyping development. If nobody objects, I'm going to start coding. I do think we want to eat our own dogfood here and run it in Harmony. Seriously. Also, before you go off, can we chat about your proposed design a bit? I'm still kinda stuck on email, as it means that everyone gets the messages. One solution to that is pretty much what you suggested : 1) CI infra posts results to some apache-hosted website. For now, I think those results are simply state change (pass- fail, fail-pass) with information about platform, and maybe relevant stack trace. Given that we want to keep some control over this, we could simply have an ID issued by us when someone wants to participate, so they just submit the ID + the info. 2) The website puts the results in a directory. 3) The website sends an email out reporting the transition and the platform it happened on, w/ a link to the posted data from the reporting server. 4) Summary pages are generated on the fly when someone looks... So this is pretty much what you said, but I do agree w/ others that Perl is wrong here. There are great Java webapp frameworks (although I bet I could do this in a day w/ a servlet...) geir [1] http://html-template.sourceforge.net/ [2] http://search.cpan.org/~smylers/CGI-Lite-2.02/Lite.pm - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build-test-infra] Build Test Infrastructure
Anton Luht wrote: Hello Alexei, I believe that there are more installations that can execute CGI than those that can run servlets. I'm sure that for the first time the test infrastructure will be deployed to an existing installation but not to a dedicated server - that's why I decided that CGI suites better. But we aren't going to deploy the central service to everywhere, just to the apache infrastructure. When we have a dedicated host for builds maybe it'll be worth to rewrite test infrastructure in Java. But please do not consider the choice of technology final - I just wanted to pick something that fits for a prototype: fast to develop and easy to deploy. I'm confused. We'll have a host to receive this info from the distributed build machines. One host will be recording the info from the all the other distributed build machines... geir On 8/1/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi Anton, I believe that most common server-side engine is CGI (not PHP or J2EE) so I'd like to implement this using Perl CGI scripts. (just thinking about) there are several good Java-oriented technologies - servlets, JSP, JSF - why not to use them? I don't like to say that servlets are more frequent than perl, but Java itself is not the most widely used language. We should advertise it. :) IMHO having Java web/servlets server (not a complete J2EE) for such type of tasks with theoretically Harmony JRE inside will do a good job for our project. Regards, 2006/7/28, Anton Luht [EMAIL PROTECTED]: Hello, I know why this thread is so lazy - it's because everybody dislikes QA testing :) OK, now let me add my $0.02 about my vision about reporting of test results. I believe it's better to do this using HTTP rather than mail because some people may not have access to SMTP port (for example, be behind proxy with Exchange as mail server - I don't really know if it provides SMTP service). HTTP is open in most configurations and it was already decided that HDK and tests will be delivered via HTTP. I see the reporting of the results in the following way: after executing tests the script packs results and uploads them (as with browser file upload) to the server. After that data is processed on server-side - daemons can send periodical e-mails, draw charts, reports, lists of top test results contributors, etc. Nobody criticized this approach so I assume that it's not too bad. I'm going to implement a sketch for server-side bunch of scripts - one that accepts uploads and puts them to a temp directory and maybe some simple reports. They won't use any database. I believe that most common server-side engine is CGI (not PHP or J2EE) so I'd like to implement this using Perl CGI scripts. Since this is a first draft, I'm not going to use advanced templates language like XSLT. Including HTML output in script is bad idea so I'm going to use something like HTML::Template [1] for pages generation and CGI::Lite [2] for requests handling. Perl is chosen just because it suites well for fast prototyping development. If nobody objects, I'm going to start coding. [1] http://html-template.sourceforge.net/ [2] http://search.cpan.org/~smylers/CGI-Lite-2.02/Lite.pm -- Regards, Anton Luht, 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] -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build-test-infra] Build Test Infrastructure
Alexei Zakharov wrote: Anton, I have no objections here, just thinking about Harmony-hosted Harmony web site - it can become really good self explanatory reliability test. Not today, I agree. But may be some day. Well, I have objections if I understand things correctly. There is no reason for least common denominator CGI+perl for this since it's not made to deploy everywhere. Yes, it can run locally on every build/test installation, but they are all java based anyway! So what am I missing? geir With Regards, 2006/8/1, Anton Luht [EMAIL PROTECTED]: Hello Alexei, I believe that there are more installations that can execute CGI than those that can run servlets. I'm sure that for the first time the test infrastructure will be deployed to an existing installation but not to a dedicated server - that's why I decided that CGI suites better. When we have a dedicated host for builds maybe it'll be worth to rewrite test infrastructure in Java. But please do not consider the choice of technology final - I just wanted to pick something that fits for a prototype: fast to develop and easy to deploy. On 8/1/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi Anton, I believe that most common server-side engine is CGI (not PHP or J2EE) so I'd like to implement this using Perl CGI scripts. (just thinking about) there are several good Java-oriented technologies - servlets, JSP, JSF - why not to use them? I don't like to say that servlets are more frequent than perl, but Java itself is not the most widely used language. We should advertise it. :) IMHO having Java web/servlets server (not a complete J2EE) for such type of tasks with theoretically Harmony JRE inside will do a good job for our project. Regards, 2006/7/28, Anton Luht [EMAIL PROTECTED]: Hello, I know why this thread is so lazy - it's because everybody dislikes QA testing :) OK, now let me add my $0.02 about my vision about reporting of test results. I believe it's better to do this using HTTP rather than mail because some people may not have access to SMTP port (for example, be behind proxy with Exchange as mail server - I don't really know if it provides SMTP service). HTTP is open in most configurations and it was already decided that HDK and tests will be delivered via HTTP. I see the reporting of the results in the following way: after executing tests the script packs results and uploads them (as with browser file upload) to the server. After that data is processed on server-side - daemons can send periodical e-mails, draw charts, reports, lists of top test results contributors, etc. Nobody criticized this approach so I assume that it's not too bad. I'm going to implement a sketch for server-side bunch of scripts - one that accepts uploads and puts them to a temp directory and maybe some simple reports. They won't use any database. I believe that most common server-side engine is CGI (not PHP or J2EE) so I'd like to implement this using Perl CGI scripts. Since this is a first draft, I'm not going to use advanced templates language like XSLT. Including HTML output in script is bad idea so I'm going to use something like HTML::Template [1] for pages generation and CGI::Lite [2] for requests handling. Perl is chosen just because it suites well for fast prototyping development. If nobody objects, I'm going to start coding. [1] http://html-template.sourceforge.net/ [2] http://search.cpan.org/~smylers/CGI-Lite-2.02/Lite.pm -- Regards, Anton Luht, 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] -- 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] -- Regards, Anton Luht, 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Plan on work on java.lang.instrument
Jimmy, Jing Lv wrote: Stepan Mishura wrote: On 8/2/06, Jimmy, Jing Lv wrote: Hi, If no objection, I shall go on with the plan of instrument :) Refer to Harmony status page[1], INSTRUMENT is missing, so this module shall named as instrument. I shall open a wiki-page for its status like other modules on [2]. For Java codes, API classes/interfaces can be added to modules/luni/src/main/java/java/lang/instrument, and implementation can be added to modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument Sorry, I didn't catch why you are going to put code to 'luni' module Did you mean: modules/ instrument/ src/main/java/java/lang/instrument src/main/java/org/apache/harmony/luni/internal/lang/instrument Hi, It is java.lang.instrument, so IMHO it can be put to luni module. And another reason is that it is rather small to be a single module. :) Oops, my mail server meets some problem. Please ignore this letter, sorry for inconvenience. Thanks, Stepan. For native codes, instrument need a new directory in modules/luni/src/main/native named instrument, in my plan, there should be two native code, one for instrument native implementation, and another for laugher (for parameter -javaagent). Instrument shall be compiled into a .DLL(.so) file alone. Any suggestions? Thanks! :) [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html [2]http://wiki.apache.org/harmony/INSTRUMENT -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
