Re: [drlvm][unit] 100% of class library tests pass
Alexei Fedotov wrote: Folks, According to http://harmonytest.org, today 100% of class library unit tests pass on DRLVM. Thank you all! It takes 44 days for the great team we are. Awesome! -- Paulex Yang China Software Development Lab IBM
Re: [classlib][sound] Volunteer to implement missing bad APIs in javax.sound.sampled
Boris Kuznetsov wrote:
ok, let's figure out how many things left.
AudioSystem class and some not yet implemented methods like this:
public final String toString() {
throw new Error(not yet implemented);
}
As someone discussing on the other thread about JAPI, how about use
NotImplementedException instead of Error with not yet implemented
messages? so that JAPI can identify them and can create reports more
precisely.
--
Paulex Yang
China Software Development Lab
IBM
Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1
Richard Liang wrote: On 11/7/06, Nathan Beyer [EMAIL PROTECTED] wrote: On 11/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Paulex Yang wrote: Geir Magnusson Jr. wrote: Paulex Yang wrote: Geir Magnusson Jr. wrote: did we decide not to go to TestNG? Sigh...I guess there must be too many ones have waited too long for TestNG...(including me) I don't understand - what do you mean? Nothing but a joke:). I mean, the TestNG depends on j.u.c, so that it cannot be used for months, so people may think let's just use JUnit instead... What's left for j.u.c? I lost track of that Saga, IIRC. I believe we're down to agreeing to the Objects/Threads classes [1] in luni-kernel and getting them implemented in DRLVM and the donated IBM VM. I believe the Unsafe class needs to be re-implemented with these interfaces, but that may already be done. Yes, I just run testNG successfully by appending suncompat.jar and luni-kernel-stubs.jar to bootclasspath ;-) So you mean we can start the TestNG migration work at any time? -Nathan [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni-kernel/src/main/java/org/apache/harmony/kernel/vm/ Ignore it, I'm all for TestNG...:) geir Paulex - being desperate -- Paulex Yang China Software Development Lab IBM
Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1
Nathan Beyer wrote: On 11/6/06, Paulex Yang [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: Paulex Yang wrote: Geir Magnusson Jr. wrote: did we decide not to go to TestNG? Sigh...I guess there must be too many ones have waited too long for TestNG...(including me) I don't understand - what do you mean? Nothing but a joke:). I mean, the TestNG depends on j.u.c, so that it cannot be used for months, so people may think let's just use JUnit instead... Ignore it, I'm all for TestNG...:) If you're looking for another opinion, I'm not convinced. JUnit 4.x seems just as capable as TestNG. There was a(or several?) long long thread discussing the TestNG/JUnit 4 comparison, and IIRC most people prefer TestNG at that time, I just don't want to trig another thread on this topic...We have waited so long for TestNG, so let's just go for it if nothing is preventing us now...:) -Nathan geir Paulex - being desperate -- Paulex Yang China Software Development Lab IBM -- Paulex Yang China Software Development Lab IBM
Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1
Geir Magnusson Jr. wrote: Paulex Yang wrote: Geir Magnusson Jr. wrote: did we decide not to go to TestNG? Sigh...I guess there must be too many ones have waited too long for TestNG...(including me) I don't understand - what do you mean? Nothing but a joke:). I mean, the TestNG depends on j.u.c, so that it cannot be used for months, so people may think let's just use JUnit instead... Ignore it, I'm all for TestNG...:) geir Paulex - being desperate -- Paulex Yang China Software Development Lab IBM
Re: [general] Interesting discoveries playing around with japitools
Stefano Mazzocchi wrote: Paulex Yang wrote: Gets more interesting with IBM: -- ibm1.5 vs. sun1.5 Total: 99.77% good, 0% bad, 0.22% missing java.lang: Missing method java.lang.StringBuilder.append(java.lang.StringBuilder): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.capacity(): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.charAt(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.codePointAt(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.codePointBefore(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.codePointCount(int, int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.ensureCapacity(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.getChars(int, int, char[], int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.length(): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.offsetByCodePoints(int, int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.setCharAt(int, char): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.setLength(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.subSequence(int, int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.substring(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.substring(int, int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.trimToSize(): missing in /home/stefano/data/japi/sun1.5 It IS more interesting, because there methods are included in Java 5 API Doc (except the first one)!...there may be some problem happened to JAPI or the Sun JDK' rt.jar...;-) Paulex, good catch! It might well be a japitools bug, then. I did look into the javadoc and stopped after I realized that the first method wasn't there... but I should have continued. Anyway, even a single method should be enough to trigger a TCK reaction (since this is clearly against Sun WORA policies). Indeed. -- Paulex Yang China Software Development Lab IBM
Re: [general] Interesting discoveries playing around with japitools
Gets more interesting with IBM: -- ibm1.5 vs. sun1.5 Total: 99.77% good, 0% bad, 0.22% missing java.lang: Missing method java.lang.StringBuilder.append(java.lang.StringBuilder): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.capacity(): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.charAt(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.codePointAt(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.codePointBefore(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.codePointCount(int, int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.ensureCapacity(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.getChars(int, int, char[], int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.length(): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.offsetByCodePoints(int, int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.setCharAt(int, char): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.setLength(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.subSequence(int, int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.substring(int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.substring(int, int): missing in /home/stefano/data/japi/sun1.5 method java.lang.StringBuilder.trimToSize(): missing in /home/stefano/data/japi/sun1.5 It IS more interesting, because there methods are included in Java 5 API Doc (except the first one)!...there may be some problem happened to JAPI or the Sun JDK' rt.jar...;-) javax.management.remote.rmi: Missing class javax.management.remote.rmi._RMIConnectionImpl_Tie: missing in /home/stefano/data/japi/sun1.5 class javax.management.remote.rmi._RMIServerImpl_Tie: missing in /home/stefano/data/japi/sun1.5 javax.xml.datatype: Bad field javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS: constant [org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in /home/stefano/data/japi/ibm1.5, but constant [com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl] in /home/stefano/data/japi/sun1.5 org.omg.stub.java.lang: Missing package org.omg.stub.java.lang: missing in /home/stefano/data/japi/sun1.5 org.omg.stub.java.security: Missing package org.omg.stub.java.security: missing in /home/stefano/data/japi/sun1.5 org.omg.stub.java.util: Missing package org.omg.stub.java.util: missing in /home/stefano/data/japi/sun1.5 org.w3c.dom.html: Missing method org.w3c.dom.html.HTMLOptionElement.setIndex(int): missing in /home/stefano/data/japi/sun1.5 method org.w3c.dom.html.HTMLTableCellElement.setCellIndex(int): missing in /home/stefano/data/japi/sun1.5 method org.w3c.dom.html.HTMLTableRowElement.setCells(org.w3c.dom.html.HTMLCollection): missing in /home/stefano/data/japi/sun1.5 method org.w3c.dom.html.HTMLTableRowElement.setRowIndex(int): missing in /home/stefano/data/japi/sun1.5 method org.w3c.dom.html.HTMLTableRowElement.setSectionRowIndex(int): missing in /home/stefano/data/japi/sun1.5 org.w3c.dom.xpath: Missing package org.w3c.dom.xpath: missing in /home/stefano/data/japi/sun1.5 - o - First the not-so-shocking things: 1) IBM ships with xpath support with DOM, while Sun does not. Is this true of it's a bug? 2) IBM has a 'stub' subpackage of org.omg that Sun does not have but the real shocker is that japitools reports that IBM has *modified* the java.lang.StringBuilder class and added *15* new methods to it! If this is true, how is it possible for this JVM to pass the TCK if you add methods to a java.lang class? Isn't this the kind of stuff that TCKs are supposed to prevent? Can anybody explain to me if this is true or if this is a japi bug? Also, I found out that Japitools triggers some NullPointerExceptions here and there, so it needs some tuning. I'll investigate more. Stay tuned. -- Paulex Yang China Software Development Lab IBM
Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1
Geir Magnusson Jr. wrote: did we decide not to go to TestNG? Sigh...I guess there must be too many ones have waited too long for TestNG...(including me) Paulex - being desperate Leo Li wrote: Ya, I think we can. I would like the new features in JUnit4, but it is written in a quite different style from current harmony test codes. Migrate them? Besides, it is related with the thread of JUnit best practice discussing now. We need to make a decision since we can merge the task of migration with the action to enforce JUnit best practice.:) On 11/4/06, Nathan Beyer [EMAIL PROTECTED] wrote: Assuming we get this functioning, does this mean we can use JUnit 4 testing? -Nathan On 11/3/06, Leo Li [EMAIL PROTECTED] wrote: Hi, all I have just tested JUnit4.1 on Harmony. With J9 VM, harmony passes both on windows xp2 and redhat enterprise 4.0. While drlvm fails on linux, which fails to create new thread becauseof out-of-memory-error. Since it can always be reproduced, I think actually system doesnot lack memory at the time. So I reported it as an application-oriented bugs as JIRA [1]. Besides I have got the time used in these tests which shows there is space for us to improve our performance. VM Windows xp2 Redhat Enterprise4 RI 0.985+0.921 0.75+0.717 J9 4.25+2.61 2.888+2.897 drlvm 8.437+5.359 / *The former data represents the time to run junit.tests.AllTests The latter, junit.samples.AllTests. For detailed information, including how to run tests, I have posted it on Harmony wiki[2]. [1]http://issues.apache.org/jira/browse/HARMONY-2060 [2]http://wiki.apache.org/harmony/JUnit -- Leo Li China Software Development Lab, IBM -- Paulex Yang China Software Development Lab IBM
Re: [classlib] Jigsaw status is added to the apps page
Anton Rusanov wrote: Hi, I discovered that some entries in application status haven't been updated since May. I am finishing working on JarSigner tool and I can update status info which became out of date. If there are no objections I will do this. Sure, why not. Further, I think we need more application test on the popular FOSS Java applications from all over the community, even the commercial product test is also welcome:). btw, IIRC, we have got JBoss run on Harmony, but didn't find it on the status page (Igor? ;-)). 2006/11/2, Mikhail Loenko [EMAIL PROTECTED]: I've added Jigsaw to the list of being enabled apps [1] Thanks, Mikhail [1] http://wiki.apache.org/harmony/Application_Status -- Paulex Yang China Software Development Lab IBM
Re: [classlib][luni]clean up excluded testcases in java.net
Tony Wu wrote: Hi all, I noticed that some tests of java.net were excluded due to external server dependency. Now we have a jetty in /depends/jars, is it time to clean up these testcases to use jetty and make them run-able? I volunteer to do it if so. Go ahead! :) -- Paulex Yang China Software Development Lab IBM
Re: [classlib][portlib] Docs?
Geir Magnusson Jr. wrote: Paulex Yang wrote: Geir Magnusson Jr. wrote: yeah - someone generate, and we can hang them on the website. I'm not sure we'd want to check them in though... Is it possible to add documents into website but not to commit them in SVN? Yep. I was thinking the same for the Doxygen docs. Basically, you just create locally, review, and then tar and put up on site manually. +1 to go for that It does remove the ability for group oversight (IOW, no commit msgs), but if the generation process isn't very stale (small changes to one page have repercussions all over...) then it keeps the SVN churn to a minimum. Actually I have no idea what kind of commit msgs needed for API document...they are just generated by tools from codes. I think the most important information is the svn revision number against which the document is generated, any doxygen guru can help to find a way? Any chance to pass a revision number to doxygen and to get it added into footer of every page? geir We removed them from classlib/trunk/doc because the SVN metadata get in the way when updating the document. I've done this before for API docs... geir Alexey Petrenko wrote: Having these docs on website will be really good! SY, Alexey 2006/11/1, Paulex Yang [EMAIL PROTECTED]: If you get Doxygen installed, you can create it by running ant doxygen-natives in classlib/trunk/doc. There were discussions to move the document to somewhere on website, but seems it is still to be done. Morozova, Nadezhda wrote: Not that I know of :( bits of things are in the devguide, maybe. But you probably won't find that of much notice. Anyone, please tell me it's not true! Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 4:15 PM To: harmony-dev@incubator.apache.org Subject: [classlib][portlib] Docs? Guys, do we have any docs on portlib? SY, Alexey -- Paulex Yang China Software Development Lab IBM -- Paulex Yang China Software Development Lab IBM
Re: Programmer Volunteering (sorry if I should read a FAQ before)
Tim Ellison wrote: I'll add my welcome (I don't see your original post?) I didn't see, either...the original mail's date is May 13, 2005, even before Harmony is created Please don't get me wrong, just add my welcome ;-) -- what area are you interested in? We have cool work in progress in VMs, Memory Management, JIT compilation, class library development, testing, documentation, build systems, tooling, and more that I've probably forgotten! Regards, Tim Fedotov, Alexei A wrote: So, you are very welcome. :-) I enjoyed the quotes at the end of your post. Recently Sveta and Geir updated http://incubator.apache.org/harmony/quickhelp_contributors.html - I Agree, that's the right place to start. And if you have planned to contribute, here is another link as instruction: http://incubator.apache.org/harmony/get-involved.html And please be kindly noted, in the near future(but I'm sure not tomorrow) the links will be out-dated, because we are going to http://harmony.apache.org! ;-) believe it worth to take a look at. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Nilseu Padilha JMiB [mailto:[EMAIL PROTECTED] Sent: Friday, May 13, 2005 8:15 PM To: harmony-dev@incubator.apache.org Subject: Programmer Volunteering (sorry if I should read a FAQ before) Greetings. I am a cmomercial Systems Architect and would like to volunteer myself as a developer to the Harmony Project. Sorry if I should read any FAQ before, but I like to know how I could contribute to the project. Thank you. Regards, Padilha id=Nilseu name=Nilseu Perside Ortiz Padilha Junior jCert=SCEA P1 - Sun Certified Enterprise Architect for J2EE Part 1 aka=JMiB jobTitle=J2EE Hardcore Architect jobMainAssignment=Omnipres Co-Architect - Solution for Distributed Enterprise Data jobOffice=Immediate Consultoria e Sistemas jobPhone=+55-051-3233-8495 jobPage=http://www.immediate.com.br; association=Association for Computing Machinery - ACM education=Bachelor\'s in Computer Science - ULBRA Quote author=Colonel Samuel Trautman And one more thing, what you choose to call hell, he calls home. /Quote Quote author=Cha-ka Oganza bi sasa! /Quote Quote author=E. W. Dijkstra Computer science is no more about computers than astronomy is about telescopes. /Quote Quote author=General Zod Son of Jor-el, kneel before Zod /Quote Quote author=Dave Clark We reject kings, presidents and voting. We believe in rough consensus and running code. /Quote Quote author=Vilfredo Pareto A minority of input produces the majority of results. /Quote Quote author=Daffy Duck You\'re...You\'re despicable! /Quote Quote author=Sophocles It is a painful thing To look at your own trouble and know That you yourself and no one else has made it. /Quote Quote author=T-101 John Connor, It is time. /Quote Quote author=Master Yoda One exam does not a (J2EE) architect make. /Quote Scorea href=http://www.nerdtests.com/ft_nq.php?im; img src=http://www.nerdtests.com/images/ft/nq.php?val=8792; alt=I am nerdier than 97% of all people. Are you nerdier? Click here to find out! /a/Score/Padilha -- Paulex Yang China Software Development Lab IBM
Re: [classlib]Harmony passes 100% testcases of Tomcat5.5
Sigh...you must didn't read into it...;-) Leo The detailed information about how to build and run tests have been put on http://wiki.apache.org/harmony/Apache_Tomcat /Leo Geir Magnusson Jr. wrote: Nice! Post it on the wiki? Leo Li wrote: Hi, all: Harmony now has been able to pass 100% testcases on Tomcat5.5. I ran them both on WindowsXP and Unbuntu, with J9 VM and drlvm. The detailed information about how to build and run tests have been put on http://wiki.apache.org/harmony/Apache_Tomcat. Note: 1. Harmony launches slower than RI, so I add the interval between the launch of Tomcat Server and tests from 8 seconds to 30 seconds to ensure the server has been running. 2. Runtime.exec fails on linux with J9 vm, as discussed on[1], so I have altered the usage of fork to vfork as a workround despite of the possible side-effect of the latter. mailing thread [1] http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg16002.html -- Paulex Yang China Software Development Lab IBM
Re: [classlib]Harmony passes 100% testcases of Tomcat5.5
Tim Ellison wrote: Geir Magnusson Jr. wrote: Great! Does anything link to that page? IOW, if I started at the top, could I find the page using some reasonable path to get there? Front Page Application Status (in the 'Status' section) There are a number of apps listed there as people test them. Yes, and I suggest we always add links to this page when somebody creates a wiki page for application test, a few days ago, I just added several links to it(IIRC, Eclipse, Tomcat, Log4j...), because I thought they should be there but couldn't find... Regards, Tim -- Paulex Yang China Software Development Lab IBM
Re: [classlib][portlib] Docs?
If you get Doxygen installed, you can create it by running ant doxygen-natives in classlib/trunk/doc. There were discussions to move the document to somewhere on website, but seems it is still to be done. Morozova, Nadezhda wrote: Not that I know of :( bits of things are in the devguide, maybe. But you probably won't find that of much notice. Anyone, please tell me it's not true! Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 4:15 PM To: harmony-dev@incubator.apache.org Subject: [classlib][portlib] Docs? Guys, do we have any docs on portlib? SY, Alexey -- Paulex Yang China Software Development Lab IBM
Re: [doc] No Doxygen reference for code :(
Morozova, Nadezhda wrote: Hi everyone, I've noticed that there's no API reference documentation for Harmony code - generated by Doxygen/Javadoc. I guess many will agree that having API reference is very useful and convenient. This issue was discussed a while ago [1] for kernel classes and vmi interface in classlib. We agreed to store the Doxygen docs on the website by generating them manually from code and placing there. It seems that the old version of the docs was removed from SVN but never made its way to the website, so it's just NOWHERE now :-(. Let's fix it! AFAIU, we want to have the following: 1. Ability to generate docs locally from source code as part of build - need to change existing build files or write new ones. 2. Ability to see docs on the website - manually copy a local bundle of docs to the website and add a link. Geir has been planning to include the website into the next snapshot; supplying ready reference with it seem nice. Volunteers? I can work on item 2 for sure to get a nice config file and patch the website to link to our new Doxygen API. Item 1 -fixing the build - might be more extravagant, so your aid's welcome ;) It is me that removed the original document in classlib/trunk/doc as we discussed before, so seems it should be my responsibility to make the work complete:). Sorry for delaying so long. But I still have no strong feelings where to put them in standard/site, any suggestions? You can create all the API document by run ant in classlib/trunk/doc, you can get all document created, assuming Doxygen is installed. If you kindly provide the patch, I will look at it and merge it into SVN. [1] mail thread http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mb ox/[EMAIL PROTECTED] Thanks, Nadya Morozova -- Paulex Yang China Software Development Lab IBM
Re: [doc] No Doxygen reference for code :(
Alexey Petrenko wrote: I think that we can place the docs here: http://incubator.apache.org/harmony/subcomponents/classlibrary/index.html Yes, that's one of my candidate, another one is here: standard/site/docs/documentation/documentation.html, because I think it is also a reasonable idea for the user to go for documentation if you wanna some API explanation. How about we put the API document in each subcomponents(classlib/drlvm/jchevm), but also add their link in documentation/documentation.html? 2006/11/1, Paulex Yang [EMAIL PROTECTED]: Morozova, Nadezhda wrote: Hi everyone, I've noticed that there's no API reference documentation for Harmony code - generated by Doxygen/Javadoc. I guess many will agree that having API reference is very useful and convenient. This issue was discussed a while ago [1] for kernel classes and vmi interface in classlib. We agreed to store the Doxygen docs on the website by generating them manually from code and placing there. It seems that the old version of the docs was removed from SVN but never made its way to the website, so it's just NOWHERE now :-(. Let's fix it! AFAIU, we want to have the following: 1.Ability to generate docs locally from source code as part of build - need to change existing build files or write new ones. 2.Ability to see docs on the website - manually copy a local bundle of docs to the website and add a link. Geir has been planning to include the website into the next snapshot; supplying ready reference with it seem nice. Volunteers? I can work on item 2 for sure to get a nice config file and patch the website to link to our new Doxygen API. Item 1 -fixing the build - might be more extravagant, so your aid's welcome ;) It is me that removed the original document in classlib/trunk/doc as we discussed before, so seems it should be my responsibility to make the work complete:). Sorry for delaying so long. But I still have no strong feelings where to put them in standard/site, any suggestions? You can create all the API document by run ant in classlib/trunk/doc, you can get all document created, assuming Doxygen is installed. If you kindly provide the patch, I will look at it and merge it into SVN. [1] mail thread http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mb ox/[EMAIL PROTECTED] Thanks, Nadya Morozova -- Paulex Yang China Software Development Lab IBM -- Paulex Yang China Software Development Lab IBM
Re: [classlib][portlib] Docs?
Geir Magnusson Jr. wrote: yeah - someone generate, and we can hang them on the website. I'm not sure we'd want to check them in though... Is it possible to add documents into website but not to commit them in SVN? We removed them from classlib/trunk/doc because the SVN metadata get in the way when updating the document. I've done this before for API docs... geir Alexey Petrenko wrote: Having these docs on website will be really good! SY, Alexey 2006/11/1, Paulex Yang [EMAIL PROTECTED]: If you get Doxygen installed, you can create it by running ant doxygen-natives in classlib/trunk/doc. There were discussions to move the document to somewhere on website, but seems it is still to be done. Morozova, Nadezhda wrote: Not that I know of :( bits of things are in the devguide, maybe. But you probably won't find that of much notice. Anyone, please tell me it's not true! Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 4:15 PM To: harmony-dev@incubator.apache.org Subject: [classlib][portlib] Docs? Guys, do we have any docs on portlib? SY, Alexey -- Paulex Yang China Software Development Lab IBM -- Paulex Yang China Software Development Lab IBM
Re: Harmony passes 94% on derby tests.
Leo Li wrote: So I recommend to delay putting formal derby tests in Harmony project util they are ported to junit. Since there will be quite some trouble to build them and to test them. Furthermore, current tests which are large and compared by console output are not so easy for debugging.:) Besides, I will put my patch on Harmony wiki page and give some instructions about how to build and test for those who are interested in this topic right now. Excellent work and very nice page! On 10/26/06, Daniel John Debrunner [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: Nice work! More inline.. Leo Li wrote: 467 Tests Run 94% Pass (443 tests passed) 6% Fail (24 tests failed) 5 Suites skipped The main progress focuses here: 1. Harmony classlib fails to load class when user-defined security policy exists. It is due to the sequence of library loading of VM, which has been resolved now. 2. A new workround for derby tests which allow useprocess to run test or else several testcases might fail due to derby lack these tests when useprocess = false. 3. Derby source code uses the version and the name of java vm to decide what to do, while current IBM VM has the version of 1.4.2 and the name of j9, which has different output on the screen from that of standard RI 1.5. At the same time Derby test compares the output of the iteractive test scripts to that of expected. I have made some slight modification in its source code, but I have not throughly change this odd behavior, ...,too much:( Have you approached the derby community with the changes? Derby is moving to a pure JUnit based world, so it is probably not worth a lot of effort patching up the old harness to run with Harmony. One of the reasons to kill the old harness is that how to run with a new vm is not obvious. http://wiki.apache.org/db-derby/KillDerbyTestHarness Dan. -- Paulex Yang China Software Development Lab IBM
Re: [general]97.63% unit tests of Axis passed on Harmony+IBMVM
Tony Wu wrote: Hi all, I tried to run the unit tests of apache axis on harmony+IBMVM and got this result[1]. It looks not bad. I will update the detail on wiki. Furthermore, I will dive into the failure and try the functional test next week. [1] Tests Failures Errors Success rate Time 7183 14 97.63%74.739 BTW RI got 100.00% passed Excellent! Would you also add some instruction on how to configure/run Axis on Harmony? -- Paulex Yang China Software Development Lab IBM
Re: svn commit: r467634 - in /incubator/harmony/enhanced/classlib/trunk/doc: build.xml vminterface/natives.cfg
Mark Hindess wrote:
Thanks Paulex. I really should have remembered that when I committed
that the JIRA to move that code.
You are welcome:). Just seems no one else ever need to create and look
at that document like me:).
-Mark.
On 25 October 2006 at 13:21, [EMAIL PROTECTED] wrote:
Author: pyang
Date: Wed Oct 25 06:21:53 2006
New Revision: 467634
URL: http://svn.apache.org/viewvc?view=revrev=467634
Log:
Update the portlib document creation script to adapt the relayout that move p
ortlib out of luni
Modified:
incubator/harmony/enhanced/classlib/trunk/doc/build.xml
incubator/harmony/enhanced/classlib/trunk/doc/vminterface/natives.cfg
Modified: incubator/harmony/enhanced/classlib/trunk/doc/build.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/d
oc/build.xml?view=diffrev=467634r1=467633r2=467634
=
=
--- incubator/harmony/enhanced/classlib/trunk/doc/build.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/doc/build.xml Wed Oct 25 06:21:
53 2006
@@ -88,6 +88,7 @@
env key=HARMONY_DOC_DIR value=${basedir} /
env key=HARMONY_LUNI_NATIVES_DIR value=${basedir}/../modules
/luni/src/main/native /
env key=HARMONY_ARCHIVE_NATIVES_DIR value=${basedir}/../modu
les/archive/src/main/native /
+env key=HARMONY_PORTLIB_NATIVES_DIR value=${basedir}/../modu
les/portlib/src/main/native /
env key=HARMONY_TARGET_PLATFORM value=${target.platform} /
/exec
/target
Modified: incubator/harmony/enhanced/classlib/trunk/doc/vminterface/natives.c
fg
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/d
oc/vminterface/natives.cfg?view=diffrev=467634r1=467633r2=467634
=
=
--- incubator/harmony/enhanced/classlib/trunk/doc/vminterface/natives.cfg (or
iginal)
+++ incubator/harmony/enhanced/classlib/trunk/doc/vminterface/natives.cfg Wed
Oct 25 06:21:53 2006
@@ -438,16 +438,18 @@
$(HARMONY_DOC_DIR)/vminterface \
$(HARMONY_LUNI_NATIVES_DIR)/vmi/$(HARMONY_TARGET_PLATFORM) \
$(HARMONY_LUNI_NATIVES_DIR)/luni/$(HARMONY_TARGET_PLATFORM) \
- $(HARMONY_LUNI_NATIVES_DIR)/pool/$(HARMONY_TARGET_PLATFORM) \
- $(HARMONY_LUNI_NATIVES_DIR)/port/$(HARMONY_TARGET_PLATFORM) \
- $(HARMONY_LUNI_NATIVES_DIR)/thread/$(HARMONY_TARGET_PLATFORM)
\
$(HARMONY_LUNI_NATIVES_DIR)/include/$(HARMONY_TARGET_PLATFORM)
\
+ $(HARMONY_PORTLIB_NATIVES_DIR)/pool/$(HARMONY_TARGET_PLATFORM)
\
+ $(HARMONY_PORTLIB_NATIVES_DIR)/port/$(HARMONY_TARGET_PLATFORM)
\
+ $(HARMONY_PORTLIB_NATIVES_DIR)/thread/$(HARMONY_TARGET_PLATFOR
M) \
+ $(HARMONY_PORTLIB_NATIVES_DIR)/include/$(HARMONY_TARGET_PLATFO
RM) \
$(HARMONY_LUNI_NATIVES_DIR)/vmi/shared \
$(HARMONY_LUNI_NATIVES_DIR)/luni/shared \
- $(HARMONY_LUNI_NATIVES_DIR)/pool/shared \
- $(HARMONY_LUNI_NATIVES_DIR)/port/shared \
- $(HARMONY_LUNI_NATIVES_DIR)/thread/shared \
$(HARMONY_LUNI_NATIVES_DIR)/include/shared \
+ $(HARMONY_PORTLIB_NATIVES_DIR)/pool/shared \
+ $(HARMONY_PORTLIB_NATIVES_DIR)/port/shared \
+ $(HARMONY_PORTLIB_NATIVES_DIR)/thread/shared \
+ $(HARMONY_PORTLIB_NATIVES_DIR)/include/shared \
$(HARMONY_ARCHIVE_NATIVES_DIR)/zip/$(HARMONY_TARGET_PLATFORM)
\
$(HARMONY_ARCHIVE_NATIVES_DIR)/archive/$(HARMONY_TARGET_PLATFO
RM) \
$(HARMONY_ARCHIVE_NATIVES_DIR)/zip/shared \
@@ -975,7 +977,9 @@
# contain include files that are not input files but should be processed by
# the preprocessor.
-INCLUDE_PATH = $(HARMONY_LUNI_NATIVES_DIR)/include/shared \
+INCLUDE_PATH = $(HARMONY_PORTLIB_NATIVES_DIR)/include/shared \
+ $(HARMONY_PORTLIB_NATIVES_DIR)/include/$(HARMONY_TARGET_PLATFO
RM) \
+ $(HARMONY_LUNI_NATIVES_DIR)/include/shared \
$(HARMONY_LUNI_NATIVES_DIR)/include/$(HARMONY_TARGET_PLATFORM)
# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
--
Paulex Yang
China Software Development Lab
IBM
[classlib][security]Re: [jira] Created: (HARMONY-1963) [classlib][security] Harmony cannot read security policy file correctly
Any security guys can help to look at this issue? thanks in advance. I
haven't found time to looked closer to find the cause yet, but it seems
a little serious.
Paulex Yang (JIRA) wrote:
[classlib][security] Harmony cannot read security policy file correctly
---
Key: HARMONY-1963
URL: http://issues.apache.org/jira/browse/HARMONY-1963
Project: Harmony
Issue Type: Bug
Components: Classlib
Environment: Harmony classlib + IBM VME, windows XP+sp2
Reporter: Paulex Yang
I created simple a java.policy file[1], and try to run SecurityManagerTest with
argument:
-Djava.security.manager -Dtest.bin.dir=path to test bin directory
-Djava.security.policy=path to policy file
public class SecurityManagerTest {
public static void main(String[] args) throws Exception{
System.out.println(System.getProperty(os.name)); //read access for
this property has been granted by default policy
System.out.println(System.getProperty(notexist)); // no access for
this property has been granted by default policy
}
}
RI prints:
Windows XP
null
Harmony prints:
Windows XP
K0319java.security.AccessControlException: Access denied
(java.util.PropertyPermission notexist read)
at
java.security.AccessController.checkPermission(AccessController.java:94)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:739)
at
java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:374)
at java.lang.System.getProperty(System.java:675)
at java.lang.System.getProperty(System.java:660)
at SecurityManagerTest.main(Unknown Source)
I got same results if add the content customized java.policy to default policy
file without specifying policy file in cmd line.
[1]
grant codeBase file:${test.bin.dir}/- {
permission java.security.AllPermission;
};
--
Paulex Yang
China Software Development Lab
IBM
Re: [classlib][luni] java.io.File bug?
Spark Shen wrote:
Hi All:
When login as 'root' under Linux, the following test case fails on
Harmony while passes on RI.
public void test_canWrite() throws IOException{
File f = File.createTempFile(test, null);
f.setReadOnly();
assertTrue(f.canWrite());
f.deleteOnExit();
}
I think RI's behavior is more reasonable since the 'root' account does
have read/write privilege for temp files. However, Harmony only treats
'root' as ordinary other users.
It seems that similar problem happens on java.io.File.canRead().
I agree that RI's behavior is reasonable, although a little different
with spec[1], Harmony should fix the implementation.
[1]public boolean *setReadOnly* ()
Marks the file or directory named by this abstract pathname so that only
read operations are allowed. After invoking this method the file or
directory is guaranteed not to change until it is either deleted or
marked to allow write access. Whether or not a read-only file or
directory may be deleted depends upon the underlying system.
As we all know, File class deals with many different file object on
many different file system, would any one test File behavior on other
file systems.
I didn't follow, what you mean here?
Best regards
--
Paulex Yang
China Software Development Lab
IBM
Re: [vote] Graduate Apache Harmony podling from the Incubator
+1 - Paulex Geir Magnusson Jr. wrote: We're trying something a little different. I think Roy Fielding one said something along the lines of when a community gets organized enough to vote itself out of the Incubator, it's appropriate. So to bring the Harmony community and the Incubator community together for this important event in Harmony's life, I'm calling for a vote on graduating Harmony here on our own -dev list. The objective is for all in both the Harmony community and the Incubator community that have an opinion to vote together, in the same place, and have it hosted by the Harmony podling. This is an unconventional way to do this, but I think that it's valid and could provide one example to the Incubator on how it can work going forward. So, without any further ado : [ ] +1 Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status [ ] 0 No opinion [ ] -1 No, don't graduate Harmony. Here's why : This vote will end 72 hours from now + time of Apache mail outage. It will therefore end on Monday, October 23, at 3:30 PM eastern, + delta for mail outage. Thanks geir - 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
Re: [general] Incubator graduation update
Alex Blewitt wrote: However, if not, and some IPMC memebers still really want to see a demonstration of a release process, we can certainly do that. I've thought about what we might release. One thing that came to mind is a Pack200 jar :) :-) So, you're saying I've got less than a month to finish it ... I'll probably be able to get *something* ready for a release, but I doubt it will be fully compliant by then. The problem is that decompressed Jars are supposed to be exactly the same for any decompressor, so that MD5 signatures remain valid afterwards. What I can probably get is an unpacked Jar that will execute, but might be in a different ordering or have different MD5 signatures for components. The problem is that there's a lot of possible combinations of input files ... I've also tended to do fairly large code drops in patches, because it normally means a few days between submission and when it can be applied (thanks for the last one Paulex :-) I'd prefer to submit smaller patches as and when new functionality is added, but it would take longer that way. You are welcome:). About the size of patches, IMO it's a dilemma, if the patch is large and contains too many information for committers to understand in a glance, it generally needs more time to get it applied; while a relative smaller patch with clear objective and reasonable tests probably has more chance to go in the SVN very soon. PS When's the code going to be moved to a jdktools subproject? I can do that if no one objects(I personally +1 for that, but I'm waiting for more committers' opinion on this issue), and if you can provide a script to do that(svn move or so), it would be nice. Alex. - 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] Build failure messages
Nathan Beyer wrote: I added a compiler arg to the main 'build-java.xml' compile to disable all of the warnings. Thanks a lot, Nathan, but how about also add that arg to build-test.xml? I think the ECJ probably feels more unhappy with the test cases:). This should take care of the warnings. -Nathan On 10/18/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Can we just shut them off for now? it's a good project for someone to go and clean those up, but there's no need for all of us to see them. geir Mark Hindess wrote: These messages aren't getting through on the commits list on due to the large number of warnings since switching to ecj. I've modified the summary process so that it ignores these for the moment. Hopefully this means that the failure messages that haven't been making the commits list will start getting through. Regards, Mark. - 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] -- 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][test] Configuration dependent test of InetAddress.getHostName
Denis Kishenko wrote:
I have researched issue H-1664 and found one more difference with RI.
I run simple test on Windows Server 2003 SP1
=== Test =
import java.net.InetAddress;
import java.net.UnknownHostException;
public class Test {
public static void main(String[] args) throws UnknownHostException {
System.out.println(by name (127.0.0.1) - +
InetAddress.getByName(127.0.0.1).getHostName());
System.out.println(by name (localhost) - +
InetAddress.getByName(localhost).getHostName());
System.out.println(by address - +
InetAddress.getByAddress(new byte[]{127, 0, 0, 1}).getHostName());
System.out.println(localhost - + InetAddress.getLocalHost());
}
}
Windows Server 2003 SP1
=== RI ==
by name (127.0.0.1) - 127.0.0.1
by name (localhost) - localhost
by address - 127.0.0.1
localhost - nstdrlew21/10.125.122.60
= Harmony ==
by name (127.0.0.1) - nstdrlew21.ins.intel.com
by name (localhost) - localhost
by address - nstdrlew21.ins.intel.com
localhost - nstdrlew21/10.125.122.60
WinXP
= Both ===
by name (127.0.0.1) - localhost
by name (localhost) - localhost
by address - localhost
localhost - pbwdmkishen/10.125.132.226
Actually Harmony use native call of getnameinfo() to get host name
(which is reasonable IMHO). MSDN says The getnameinfo function
provides name resolution from an address to the host name.
InetAddressTest.test_getHostName (see H-1664) failed on WinServer
because InetAddress.getByName(127.0.0.1).getHostName() returned
nstdrlew21.ins.intel.com while localhost expected. So this test
looks like configuration dependent.
I see three possible options
1. Stay test as is. Just keep in mind that on specific configurations
this one fails.
2. Rewrite test to be configuration dependent. Test has to do the same
native call.
3. Exclude localhost checking from test_getHostName.
I think Harmony does the right thing as spec requires, the difference is
caused by underlying system call, so it should be acceptable, i.e., the
test needs to be rewritten or excluded. But this issue worth a non-bug
difference together with getHostName()'s different behavior when
SecurityManager presents[1](thanks Alexei Fedotov helped to find this
link and commented to HARMONY-1664:))
Harmony-73 is another issue, which is actually caused by HARMONY-84 and
irrelevant with getHostName() method.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED]
What do you think about this situation?
--
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: [general][svn] which svn revision we take into consideration?
Volynets, Vera wrote: Hi, svn has two commands where you can get svn revision. It's nice bug the problem is that results are different. example: 1) svn log --limit 1 r466095 | smishura | 2006-10-20 16:47:14 +0400 (Fri, 20 Oct 2006) | 1 line Apply patch for HARMONY-1927 ([classlib][tools] KeyStoreLoaderSaver.saveStore(..) throws unhandled IllegalArgumentException) 2) svn info Path: . URL: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 466101 Node Kind: directory Schedule: normal Last Changed Author: smishura Last Changed Rev: 466095 Last Changed Date: 2006-10-20 16:47:14 +0400 (Fri, 20 Oct 2006) Properties Last Updated: 2006-10-19 15:19:37 +0400 (Thu, 19 Oct 2006) Could someone explain what the difference between Revision and Last Changed Rev is? Maybe Revision shows current revision which would be Last Updated after next commit? Which of these two revisions we call revision? The svn repository revision is global, which means, in Apache, all projects share the current revision number, that's what the Revision means. While specific to the node(file or directory) under consideration, the Last Changed Rev means the last update revision for it. With best regards, Vera! Vera Volynets 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] -- 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][archive]Security policy leads to vm crashes in loading class of JarFile
Leo Li wrote:
Hi, all:
During the self-hosting of Derby, I found a security policy if is
applied will lead to errors in loading the class of JarFile. IBM vm
will throw java/lang/UnsatisfiedLinkError: java/util/zip/ZipFile.ntvi
while
drlvm will crash with SEH handler: shutdown errorSEH handler: too many
shutdown errors...
Sadly I found the problem is more general...Seems Harmony+IBM VME cannot
accept any customized policy file, just try the test case below with
option: -Djava.security.manager -Djava.security.policy=test.policy
public static void main(String[] args) throws Exception{
System.out.println(hello);
}
you'll get same error.
Here is the testcase:
import java.util.jar.*;
public class TestJarFile {
public static void main(String[] args) throws Exception{
System.out.println(JarFile.CENATT);
}
}
And the attachment is the derby_tests.policy.
Then run:
java -Djava.security.manager
-Djava.security.policy=derby_tests.policyTestJarFile
Run passes,
Harmony on IBM VM fails with java/lang/UnsatisfiedLinkError:
java/util/zip/ZipFile.ntvi
Harmony on Drlvm fails with SEH handler: shutdown errorSEH handler:
too many
shutdown errors
If the security manager is not specified, Harmony passes.
--
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][archive]Security policy leads to vm crashes in loading class of JarFile
A little further hack shows that, the cause is o.a.h.luni.util.Msg
cannot be initialized so early, which is the exception message i18n
helper class. Its static init codes try to load ResourceBundle but
failed. The new i18n helper o.a.h.l.internal.nls.Messages has same
issue. I modified the java.net.URL ln.296 as below, and the test passed.
-throw new MalformedURLException(
-org.apache.harmony.luni.util.Msg.getString(
-K00d8, spec)); //$NON-NLS-1$
+ throw new MalformedURLException(exception message here);
Leo Li wrote:
Hi, all:
During the self-hosting of Derby, I found a security policy if is
applied will lead to errors in loading the class of JarFile. IBM vm
will throw java/lang/UnsatisfiedLinkError: java/util/zip/ZipFile.ntvi
while
drlvm will crash with SEH handler: shutdown errorSEH handler: too many
shutdown errors...
Here is the testcase:
import java.util.jar.*;
public class TestJarFile {
public static void main(String[] args) throws Exception{
System.out.println(JarFile.CENATT);
}
}
And the attachment is the derby_tests.policy.
Then run:
java -Djava.security.manager
-Djava.security.policy=derby_tests.policyTestJarFile
Run passes,
Harmony on IBM VM fails with java/lang/UnsatisfiedLinkError:
java/util/zip/ZipFile.ntvi
Harmony on Drlvm fails with SEH handler: shutdown errorSEH handler:
too many
shutdown errors
If the security manager is not specified, Harmony passes.
--
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: [JBoss] JBoss works on Harmony DRLVM + Classlib
Igor Stolyarov wrote: 2006/10/18, Paulex Yang [EMAIL PROTECTED]: All of JBoss feature works? I cannot believe it, brilliant! I couldn't guarantee what all features work. I've tryed Duke's Bank example from the J2EE tutorial. Oh yeah, that's more than brilliant already! :D What I meant about all is that the JBoss's test case can pass at same rate with RI, though that also doesn't mean all really.;-) Igor Stolyarov wrote: Hello all! I pleased to inform you - JBoss AS successfully works on Harnony DRLVM + Harmony classlib! JBoss was tested with MySQL(JDBC driver - mysql-connector-java-3.1.8-bin.jar) and HypersonicSQL DBs on Win and Linux platforms. Known issues: 1) Harmony JDK structure doesn't compatible with RI JDK structure (H-1888, H-1889); 2) Harmony classlib has mx4j v.3.0.1 implementation of Java Management Extensions. This implementation has bug which doesn't allow to launch JBoss (H-1901). 3) Using JDBC driver mysql-connector-java-3.1.13-bin.jar leads to jitrino's issue H-1877, but using -Xem:jet helps to solve this problem. 4) On Linux platform there is a problem with interruption of socket. (H-1904). -- 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][luni][charset]Strange behavior of UnicodeBig
Tony Wu wrote:
Thank you Andrew,
I think I got the point. The j.l.String of RI uses the encoding of IO
whereas Charset.forName use another of NIO.
And the new problem is shall we follow the spec[1] to support the two
suites of charset implemetation? I just have a look and find we does
not support some Canonical Name for java.io and java.lang API such as
UnicodeBigUnmarked,UnicodeLittleUnmarked,UnicodeBig,Unicodelittle,etc.
There is such a charset name mapping in InputStreamReader, I think we
have no choice but to support these legacy charset names, you may need
some refactory work to make these classes use the same mapping data.
[1] http://java.sun.com/j2se/1.5.0/docs/guide/intl/encoding.doc.html
On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 10/17/06, Leo Li [EMAIL PROTECTED] wrote:
I think Harmony is more reasonable.
As spec says, if Charset.forName(UnicodeBig) throws
.UnsupportedCharsetException then no support for the named
charset is
available in this instance of the Java virtual machine. Then how
can we
get
new String(b, UnicodeBig) without throwing
UnsupportedCharsetException
on
the same jvm? The spec for String(byte[] bytes,String
charsetName) also
says
if the named charset is not supported, UnsupportedCharsetException
should be
thrown out.
UNICODEBIG is a java alias for UTF-16BE. I think we'd better
support such
mapping in String and follow RI.
You can find the encoding set from spec. [1]
[1] http://java.sun.com/j2se/1.5.0/docs/guide/intl/encoding.doc.html
On 10/17/06, Tony Wu [EMAIL PROTECTED] wrote:
Hi all,
I found this when I tried to debug the failure tests of ant on
harmony. Note the output of testcases below.
import java.io.UnsupportedEncodingException;
import java.nio.charset.Charset ;
import junit.framework.TestCase;
public class TestCharset extends TestCase {
public void test1() throws UnsupportedEncodingException {
byte[] b = new byte[] { 'a', 'b', 'c' };
String s = new String(b, UnicodeBig);
assertEquals(abc, s);
}
public void test2() {
Charset.forName(UnicodeBig);
}
}
RI:
test1: junit.framework.ComparisonFailure: expected:abc but
was:
test2: java.nio.charset.UnsupportedCharsetException: UnicodeBig
Harmony:
test1:java.nio.charset.UnsupportedCharsetException: UnicodeBig
test2:
java.nio.charset.UnsupportedCharsetException: The unsupported
charset
name is UnicodeBig
seems RI can recognize the *UnicodeBig* in Constructor of
j.l.String,
whereas Harmony does not support this alias at all.
Do you have any concern about that?
--
Tony Wu
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]
--
Leo Li
China Software Development Lab, IBM
--
Best regards,
Andrew Zhang
--
Best regards,
Andrew Zhang
--
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][luni] Please review HARMONY-1858 (Eclipse Help failure)
Nina Rinskaya wrote:
Hi all,
Could anyone please review the problem description and the fix
suggested for
https://issues.apache.org/jira/browse/HARMONY-1858#action_12442838?
Although the problem reported is not reproducible with the fix, I
suspect that the issue might need more thorough investigation and a
better fix. Thank you in advance!
Oh, yes, I noticed same problem yesterday, and committed a fix(maybe a
work around) at r464582 in another way, I updated the Ln.249 of
JarURLConnection in following way:
-}else{
+}else if(fileString != null){
My understanding of JarURLConnection.findJarFile() is as follows:
1. If the url's protocol is file, tries to create JarFile directly and
return
2. Else if useCaches is true, tries to get it from cache and return
3. Else try to get InputStream from that URLConnection, and write the
contents to a temp file, then construct a JarFile based on that temp
file and return
4. Else, throw IOException
The original implementation pass null as file name to openJarFile() in
step 2, so that if the useCaches is false, NPE will be thrown, this is
definitely a bug, as HARMONY-1858 shows. The patch for HARMONY-1858
tried to pass a externalForm as file name to openJarFile() instead, but
if the url's protocol is not file, there is no way to create a JarFile
on that URL, so that the attempt will always throw IOException,
findJarFile() will catch this exception and go into step 3. I thought
the IOException thrown/catch is not necessary, instead I add a condition
checking to openJarFile(), so that if the fileString is null, just
return from openJarFile() and go into step 3. Comments?
I also think these two methods, findJarFile()/openJarFile(), need some
refactory to make them easier to understand, I will look at it when I
get a little more time.
Best regards,
Nina Rinskaya
-
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][luni]Runtime.exec fails on Linux
Geir Magnusson Jr. wrote:
I'm confused. Didn't you just report this on Ubuntu?
Let Leo speak for himself, but I thought Leo meant IBM VME + Harmony
classlib failed on Ubuntu and Redhat, but Alexey just reported that both
(VME and DRLVM) works on SUSE, that's why it seems interesting.
I have had similar forking problems on Ubuntu 6 (I once found a bug in
classlib related to forking...).
I never figured out why Unbuntu does this, but it seemed that under
memory stress, Ubuntu's fork() fails. Try this - close Eclipse and
run the test again...
geir
Leo Li wrote:
Thank you.
I have just run it on drlvm of unbuntu, it works.
What a qurious problem!
On 10/16/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Both DRLVM and J9 works for me (SUSE9).
--
Alexey
2006/10/16, Leo Li [EMAIL PROTECTED]:
Hi, all:
The harmony Runtime.exec fails on Linux with ENOMEM.
Here is the testcase:
public class Exec {
public static void main(String[] args) throws Exception {
Runtime.getRuntime().exec(ls);}
}
I have tried it on RedHat Enterprise 4 and Unbuntu, both get
ENOMEM
in
native code.
After digging into it, I found it fails in procimpl.c, line 135:
grdpid = fork ();
If the call to fork is changed to vfork, the testcase will pass
but
still get exitcode = 1 which indicates that some error has
happened. The
difference between fork and vfork is just whether page tables is
copied
to
child process or not. But I do not think it is the main cause.
Besides,
vfork has become outdated since it main usage is supplied by fork
with
copy-on-write function implemented in modern linux kernel.
Furthermore,
vfork is also not so safe as fork. So I do not think it is the
accepted
way
to solve the problem.
I will try whether it can be reproduced on drlvm of linux since
I am
not
sure whether it is relevent to VM or classlib. If any drlvm man
can tell
me
the result, it can avoid my trouble to build it on linux. :)
--
Leo Li
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]
--
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: Ant get error
Can you access http://www.reverse.net/pub/apache/apr/apr-1.2.6.zip in browser? Justin Zheng wrote: Hi all, I receive this error when I begin to fetch working_vm's dependencies: BUILD FAILED C:\Harmony\trunk\working_vm\build\make\build.xml:240: The following error occurr ed while executing this line: C:\Harmony\trunk\working_vm\build\make\setup.xml:268: The following error occurr ed while executing this line: C:\Harmony\trunk\working_vm\build\make\setup.xml:270: The following error occurr ed while executing this line: C:\Harmony\trunk\working_vm\build\make\setup.xml:444: Can't get http://www.rever se.net/pub/apache/apr/apr-1.2.6.zip to C:\Harmony\trunk\working_vm\build\pre-cop ied\archives\win\APR\apr-1.2.6.zip It is Ant get error and I can not resolve it. Can anyone help? Thanks. My platform is Windows. Justinz -- 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]97.16% tests of Apache Ant passed on Harmony
Nice work, Tony! Any more description on what happened to these failures/errors? Spark, you must not clicked that link, it shows one error on RI:) Spark Shen wrote: Tony Wu 写道: I have tried the Apache ant 1.6.5 on lateset harmony classlib on Win32 system. It got 97.16% passed, seems not bad ;-) I'll go ahead to run on other vm and other platform and analyse the failure and fix them if possible. What I have done was updated on the wiki page http://wiki.apache.org/harmony/Apache_Ant Anyone have interest are welcome to join me:) Hi Tony: What is pass rate of RI? Best regards -- 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][regex|luni] build break
in SupplRangeSet.java
So I corrected method matches() of the SupplRangeSet class as follows:
...
int offset = -1;
if (stringIndex strLength) {
char high = testString.charAt(stringIndex++);
if (contains(high)
(offset = next.matches(stringIndex, testString,
matchResult)) 0) {
return offset;
}
...
I corrected the patch and attached it to the issue.
I verified that regex and luni tests pass normally with the patch
applied.
Thanks,
Anton
Hi Anton:
It must be very excited to handle such a complex problem. :-)
But after applying the new patch (and test patch applied), I still got
problems:
Of test class: org.apache.harmony.tests.java.util.regex.PatternTest, 4
test methods fail on RI:
testCanonEqFlag:
java.util.regex.PatternSyntaxException: Unclosed group near index 59
(?:ǠI|ǠI|ǠI|ȦĪ|ȦĪ|ȦĪ|ǠI|ǠI|Aİ̄(?:Ìc|Ìc|Ic̀)db(ac)
^
at java.util.regex.Pattern.error(Pattern.java:1650)
at java.util.regex.Pattern.accept(Pattern.java:1508)
at java.util.regex.Pattern.group0(Pattern.java:2460)
at java.util.regex.Pattern.sequence(Pattern.java:1715)
at java.util.regex.Pattern.expr(Pattern.java:1687)
at java.util.regex.Pattern.compile(Pattern.java:1397)
at java.util.regex.Pattern.init(Pattern.java:1124)
at java.util.regex.Pattern.compile(Pattern.java:840)
at
org.apache.harmony.tests.java.util.regex.PatternTest.testCanonEqFlag(
PatternTest.java:1060)
testIndexesCanonicalEq:
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at
org.apache.harmony.tests.java.util.regex.PatternTest.testIndexesCanonicalEq
(PatternTest.java:1247)
testCanonEqFlagWithSupplementaryCharacters:
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at
org.apache.harmony.tests.java.util.regex.PatternTest.testCanonEqFlagWithSupplementaryCharacters
(PatternTest.java:1275)
testPredefinedClassesWithSurrogatesSupplementary
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertFalse(Assert.java:34)
at junit.framework.Assert.assertFalse(Assert.java:41)
at
org.apache.harmony.tests.java.util.regex.PatternTest.testPredefinedClassesWithSurrogatesSupplementary
(PatternTest.java:1477)
If they are the bugs of RI, shall we add comments for them in the test
case?
and Error message printed out on console on Harmony. Since there are
test cases use System.out instead of assert, I could not locate where
these error message comes from:
java.util.regex.PatternSyntaxException: unmatched ) near index: 1
b)a
^
java.util.regex.PatternSyntaxException: unmatched ) near index: 4
bcde)a
^
java.util.regex.PatternSyntaxException: unmatched ) near index: 5
bbg())a
^
java.util.regex.PatternSyntaxException: unmatched ) near index: 7
cdb(?i))a
^
And last, the good news is luni tests do pass. :-)
Best regards
--
Spark Shen
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: ICU4C gurus? (was: [jira] Commented: (HARMONY-100) text/BidiWrapper issue?)
Alexey Petrenko wrote:
In fact the most interesting question: can ubidi_getLevels return
another pointer or not? If there is such possibility then we need to
store original pointer somewhere.
Yes, there is such possibility. If I understand correctly, in case Oleg
just mentioned, a new level array will be created and returned by
ubidi_getLevels, although I'm not ICU4C guru:).
IMO, the original pointer should be kept by the application using ICU4C,
because the ubidi API document doesn't gurantee that the ubidi_getLevels
will return the embeddinglevel from setPara(), but it does requires the
application to take care of that embeddinglevel's life
cycle(allocate/deallocate), so it is safer to keep this pointer somewhere.
2006/10/12, Oleg Khaschansky [EMAIL PROTECTED]:
What exactly your code is? It, probably, may rearrange the levels if
you didn't explicitely set them for all the characters including
trailing whitespace. If this is the case it may add some additional
levels and relocate the array. Could you check if the size of the
array changed?
On 10/12/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
Is any ICU4C gurus here?
I'm setting an embedding levels pointer with ubidi_setPara method. And
it seems that ubidi_getLevels returns not the same pointer.
Is this correct feeling or am I doing something wrong?
SY, Alexey
2006/10/11, Alexey Petrenko (JIRA) [EMAIL PROTECTED]:
[
http://issues.apache.org/jira/browse/HARMONY-100?page=comments#action_12441378
]
Alexey Petrenko commented on HARMONY-100:
-
I agree with Tim's suggestion and will create a patch.
text/BidiWrapper issue?
---
Key: HARMONY-100
URL:
http://issues.apache.org/jira/browse/HARMONY-100
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Vladimir Gorr
Let's consider the following test:
import java.text.Bidi;
public class Test {
public static void main(String[] args) throws Exception {
Bidi bd = new Bidi(new char[] { 's', 's', 's' }, 0,
new byte[] { (byte) -7, (byte)
-2, (byte) -3 },
0, 3,
Bidi.DIRECTION_DEFAULT_LEFT_TO_RIGHT);
System.out.println(Expected 7, real +
+ bd.getLevelAt(0));
}
}
In my opinion the JNI implementation of Bidi
(text/BidiWrapper.c file, ubidi_1setPara() function) contains a
potential bug, namely:
1. If the embeddingLevels argument is not NULL then
_embeddingLevels variable is initialized with the JNI
GetByteArrayElements() function;
2. ICU function (ubidi_setPara) initializes ICU inner structure
and puts the _embeddingLevels into it;
3. If _embeddingLevels pointer is not NULL then the JNI
ReleaseByteArrayElements() function (with 0 as fourth parameter) is
called.
This function releases the memory (according to JNI
specification) the _embeddingLevels pointer refers to;
4. After that ICU inner structure isn't initialized properly.
Call of ICU ubidi_getLevels() function can return incorrect values
(see java test above).
It seems the JNI_COMMIT parameter instead of 0 should be
passed to the ReleaseByteArrayElements() to avoid this problem.
I'd like to underline the test mentioned above works w/o any
issues for Harmony-14 contribution (although it shouldn't sometimes
IMHO).
Therefore if there are any doubts in my argumentation this
issue can be closed as invalid.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
--
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]
-
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: ICU4C gurus? (was: [jira] Commented: (HARMONY-100) text/BidiWrapper issue?)
Alexey Petrenko wrote:
So I'll implement a new native structure for BiDiWrapper to keep UBiDi
and embedding levels pointers at the same place. And not disturb Java
code at all.
+1, I think it should work for this issue, as long as the memory for
embedding level won't been automatically collected by GC.
SY, Alexey
2006/10/12, Paulex Yang [EMAIL PROTECTED]:
Alexey Petrenko wrote:
In fact the most interesting question: can ubidi_getLevels return
another pointer or not? If there is such possibility then we need to
store original pointer somewhere.
Yes, there is such possibility. If I understand correctly, in case Oleg
just mentioned, a new level array will be created and returned by
ubidi_getLevels, although I'm not ICU4C guru:).
IMO, the original pointer should be kept by the application using ICU4C,
because the ubidi API document doesn't gurantee that the ubidi_getLevels
will return the embeddinglevel from setPara(), but it does requires the
application to take care of that embeddinglevel's life
cycle(allocate/deallocate), so it is safer to keep this pointer
somewhere.
2006/10/12, Oleg Khaschansky [EMAIL PROTECTED]:
What exactly your code is? It, probably, may rearrange the levels if
you didn't explicitely set them for all the characters including
trailing whitespace. If this is the case it may add some additional
levels and relocate the array. Could you check if the size of the
array changed?
On 10/12/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
Is any ICU4C gurus here?
I'm setting an embedding levels pointer with ubidi_setPara
method. And
it seems that ubidi_getLevels returns not the same pointer.
Is this correct feeling or am I doing something wrong?
SY, Alexey
2006/10/11, Alexey Petrenko (JIRA) [EMAIL PROTECTED]:
[
http://issues.apache.org/jira/browse/HARMONY-100?page=comments#action_12441378
]
Alexey Petrenko commented on HARMONY-100:
-
I agree with Tim's suggestion and will create a patch.
text/BidiWrapper issue?
---
Key: HARMONY-100
URL:
http://issues.apache.org/jira/browse/HARMONY-100
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Vladimir Gorr
Let's consider the following test:
import java.text.Bidi;
public class Test {
public static void main(String[] args) throws Exception {
Bidi bd = new Bidi(new char[] { 's', 's', 's'
}, 0,
new byte[] { (byte) -7, (byte)
-2, (byte) -3 },
0, 3,
Bidi.DIRECTION_DEFAULT_LEFT_TO_RIGHT);
System.out.println(Expected 7, real +
+ bd.getLevelAt(0));
}
}
In my opinion the JNI implementation of Bidi
(text/BidiWrapper.c file, ubidi_1setPara() function) contains a
potential bug, namely:
1. If the embeddingLevels argument is not NULL then
_embeddingLevels variable is initialized with the JNI
GetByteArrayElements() function;
2. ICU function (ubidi_setPara) initializes ICU inner structure
and puts the _embeddingLevels into it;
3. If _embeddingLevels pointer is not NULL then the JNI
ReleaseByteArrayElements() function (with 0 as fourth parameter) is
called.
This function releases the memory (according to JNI
specification) the _embeddingLevels pointer refers to;
4. After that ICU inner structure isn't initialized properly.
Call of ICU ubidi_getLevels() function can return incorrect values
(see java test above).
It seems the JNI_COMMIT parameter instead of 0 should be
passed to the ReleaseByteArrayElements() to avoid this problem.
I'd like to underline the test mentioned above works w/o any
issues for Harmony-14 contribution (although it shouldn't sometimes
IMHO).
Therefore if there are any doubts in my argumentation this
issue can be closed as invalid.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
--
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]
-
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
Re: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test
Sorry, it should be me, RandomAccessFileTest failed after HARMONY-1790's patch, I didn't test it on Linux, I will roll back at once. [EMAIL PROTECTED] wrote: Online report : http://people.apache.org/~hindessm/continuum/classlib/linux.ia32/2006/10/12/20061012-151835.failure.log.gz Build statistics: State: Failed Previous State: Ok Started at: Thu, 12 Oct 2006 15:01:58 +0100 Finished at: Thu, 12 Oct 2006 16:18:33 +0100 Total time: 1h 16m 35s Build Trigger: Schedule Exit code: 1 Building machine hostname: hy2 Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes classlib/modules/math/src/test/java/tests/api/java/math/BigIntegerTest.java classlib/modules/math/src/main/java/java/math/BigInteger.java classlib/modules/math/src/main/java/java/math/Division.java classlib/modules/math/src/main/java/java/math/Primality.java classlib/modules/luni/src/test/java/org/apache/harmony/luni/tests/java/lang/ClassTest.java classlib/modules/luni/src/test/java/org/apache/harmony/luni/tests/java/lang/FloatTest.java classlib/modules/luni/src/main/java/java/io/RandomAccessFile.java classlib/modules/luni/src/main/java/org/apache/harmony/luni/platform/OSFileSystem.java classlib/modules/luni/src/main/java/org/apache/harmony/luni/util/FloatingPointParser.java -- 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: Reconstituting the 'sandbox' directory
[EMAIL PROTECTED] wrote: Due to changes in the way that 'incubator/harmony/enhanced/trunk' was rearranged in the summer to reflect its new usage, its 'sandbox' tree was accidentally hidden by SVN activity. However, there are still some directories there that still need to be made available. Is there any reason not to create a 'sandbox' directory in 'incubator/harmony/enhanced' where these items may be made visible again? (New sandbox items could, of course, be placed there also. Of immediate need is the 'bootjvm' directory tree. I spoke with Geir and it is fine with him.) Is this okay with everyone? I see no reason why it cannot be there. Thanks, Dan Lydick Dan Lydick - 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: [vote] HARMONY-1609 - bulk contribution of Applet, ImageIO and Print modules
+1 from me, though I knew it may be a little late(just back from vacation)... Geir Magnusson Jr. wrote: BCC and ACQs in place. [ ] +1 Yes, accept the contribution [ ] -1 No, don't. reason : As usual, 3 days or until all committers vote, or there is an objection/request for continuance - 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][doc]Recommend to remove trunk\doc\kernel_doc and trunk\doc\vm_doc from svn repository.
Geir Magnusson Jr. wrote: On Sep 29, 2006, at 1:03 PM, Paulex Yang wrote: Geir Magnusson Jr. wrote: I'm still pro stuffing the generated content into the svn fo the website, and then pushing that out, because in the next snapshot, I want to start getting into the habit of including the entire website generated docs (except tim's eclipse movie) in the tar file, so that users have information at the ready when they download. So +1 for : - getting the generated stuff out of classlib and drlvm trees - autogenerating as part of our CI - putting into SVN of website - publishing AFAIK, publishing to website still needs some manual work? (ssh, update or so) For now, yes, although with these new-fangled television-typewriters, I hear you can make them do things automatically. :) Really? Is it expensive? ;-) Back to document, do you mean to generate document into the standard/site instead of current enhanced/classlib/doc? I this this is good idea so that everyone can access the API document online. But I didn't catch up if you meant the publish should be automatically updated by CI? I thought the API document only needs manual update when necessary... geir - 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][auth]LoginContext should always invoke the LoginModules?
Paulex Yang wrote:
Hi, all
I'm not a security expert, so please correct me if I miss something. I
found some different behavior of Harmony and RI on
javax.security.auth.login.LoginContext, the testcase[1] shows the
difference.
Actually I tried to create the event sequence like below:
1. create LoginContext with some Subject
2. LoginContext.login() and return successfully
3. Modify Subject's content to make it invalid(one Principal's name
here, maybe passwd/username/servername in more general case)
4. LoginContext.login() again
In RI, the second login() invocation really tried to invoke the
relative LoginModule.login() and then failed to login with the
modified Subject, but in Harmony, both invocations succeed. I consider
RI's behavior is more reasonable.
After a rough look of LoginContext implementation, I found the cause
may be the Ln. 275
private void loginImpl() throws LoginException {
if (loggedIn) {
return;
}
}
Seems Harmony won't invoke the LoginModule.login() again only if the
login ever succeeds. If I comment out these lines, the test below
passes happily. Any ideas on this issue?
I've removed these lines at revision r451557 with regression test,
please shout if anyone thinks the update harmful for some reason.
[1]
public class LoginContextTest extends TestCase {
private static final String VALID_NAME = name1;
private static final String INVALID_NAME = name2;
public void testLogin() throws Exception{
MyPrincipal pri = new MyPrincipal();
HashSet set = new HashSet();
set.add(pri);
Subject sub = new Subject(false, set, new HashSet(), new
HashSet());
Configuration.setConfiguration(new MyConfig());
LoginContext context = new LoginContext(moduleName, sub);
context.login();
pri.name = INVALID_NAME;
try{
context.login();
fail(Should throw LoginException);
}catch(LoginException e){
}
} static class MyConfig extends Configuration{
AppConfigurationEntry[] entries = new
AppConfigurationEntry[]{new
AppConfigurationEntry(MyModule.class.getName(),
LoginModuleControlFlag.REQUIRED, new HashMap())};
public AppConfigurationEntry[] getAppConfigurationEntry(String
name) {
return entries;
}
public void refresh() {
}
}
public static class MyModule implements LoginModule{
Subject sub;
public void MyModule(){
}
public boolean abort() throws LoginException {
return false;
}
public boolean commit() throws LoginException {
return true;
}
public void initialize(Subject arg0, CallbackHandler arg1,
MapString, ? arg2, MapString, ? arg3) {
sub = arg0;
}
public boolean login() throws LoginException {
Principal[] pris = sub.getPrincipals().toArray(new
Principal[0]);
return VALID_NAME.equals(pris[0].getName());
}
public boolean logout() throws LoginException {
return false;
}
}
public static class MyPrincipal implements Principal{
public String name = VALID_NAME;
public String getName() {
return name;
}
public String toString(){
return name;
}
};
}
--
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]
[classlib][auth]LoginContext should always invoke the LoginModules?
Hi, all
I'm not a security expert, so please correct me if I miss something. I
found some different behavior of Harmony and RI on
javax.security.auth.login.LoginContext, the testcase[1] shows the
difference.
Actually I tried to create the event sequence like below:
1. create LoginContext with some Subject
2. LoginContext.login() and return successfully
3. Modify Subject's content to make it invalid(one Principal's name
here, maybe passwd/username/servername in more general case)
4. LoginContext.login() again
In RI, the second login() invocation really tried to invoke the relative
LoginModule.login() and then failed to login with the modified Subject,
but in Harmony, both invocations succeed. I consider RI's behavior is
more reasonable.
After a rough look of LoginContext implementation, I found the cause may
be the Ln. 275
private void loginImpl() throws LoginException {
if (loggedIn) {
return;
}
}
Seems Harmony won't invoke the LoginModule.login() again only if the
login ever succeeds. If I comment out these lines, the test below passes
happily. Any ideas on this issue?
[1]
public class LoginContextTest extends TestCase {
private static final String VALID_NAME = name1;
private static final String INVALID_NAME = name2;
public void testLogin() throws Exception{
MyPrincipal pri = new MyPrincipal();
HashSet set = new HashSet();
set.add(pri);
Subject sub = new Subject(false, set, new HashSet(), new HashSet());
Configuration.setConfiguration(new MyConfig());
LoginContext context = new LoginContext(moduleName, sub);
context.login();
pri.name = INVALID_NAME;
try{
context.login();
fail(Should throw LoginException);
}catch(LoginException e){
}
}
static class MyConfig extends Configuration{
AppConfigurationEntry[] entries = new
AppConfigurationEntry[]{new
AppConfigurationEntry(MyModule.class.getName(),
LoginModuleControlFlag.REQUIRED, new HashMap())};
public AppConfigurationEntry[] getAppConfigurationEntry(String
name) {
return entries;
}
public void refresh() {
}
}
public static class MyModule implements LoginModule{
Subject sub;
public void MyModule(){
}
public boolean abort() throws LoginException {
return false;
}
public boolean commit() throws LoginException {
return true;
}
public void initialize(Subject arg0, CallbackHandler arg1,
MapString, ? arg2, MapString, ? arg3) {
sub = arg0;
}
public boolean login() throws LoginException {
Principal[] pris = sub.getPrincipals().toArray(new
Principal[0]);
return VALID_NAME.equals(pris[0].getName());
}
public boolean logout() throws LoginException {
return false;
}
}
public static class MyPrincipal implements Principal{
public String name = VALID_NAME;
public String getName() {
return name;
}
public String toString(){
return name;
}
};
}
--
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][test] Test input/output files location
Denis Kishenko wrote: I am going to fix some commented tests from java.awt.geom package. I have several organizational questions before start to do. 1. Where is the best place to put test resource files (golden files)? Testing conventions [1] keep silence about this. There are many such files located near the tests, for example modules\awt\src\test\api\java\common\java\awt\geom\shapes\* modules\awt\src\test\api\java\common\java\awt\shapes\* I cannot find it in the archive, but IIRC, this topic was discussed before, and the conclusion was they should be in the modules\awt\src\test\resources\package structure 2. Where is the best place to put test output files? Now it is modules\awt\bin\test\java\awt\shapes\output modules\awt\bin\test\java\awt\geom\shapes\output If they are used temporarily, they should be removed after the test execution, so IMHO the position is not so significant, but maybe the user temp directory is good place to go. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html -- 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][doc]Recommend to remove trunk\doc\kernel_doc and trunk\doc\vm_doc from svn repository.
Geir Magnusson Jr. wrote: On Sep 28, 2006, at 5:15 AM, Morozova, Nadezhda wrote: Do you think we can have the docs built on a regular basis (like, a script that triggers Doxygen build say 2 times a week + on demand to push updates if needed) and resulting docs stored on the website? This way, you don't have SVN versioning for auto-generated content and keep info available for all. I'm still pro stuffing the generated content into the svn fo the website, and then pushing that out, because in the next snapshot, I want to start getting into the habit of including the entire website generated docs (except tim's eclipse movie) in the tar file, so that users have information at the ready when they download. So +1 for : - getting the generated stuff out of classlib and drlvm trees - autogenerating as part of our CI - putting into SVN of website - publishing AFAIK, publishing to website still needs some manual work? (ssh, update or so) geir -- 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: [vote] HARMONY-1410 : JDWP agent for DRLVM
+1 Geir Magnusson Jr. wrote: BCC and ACQs are in. What say ye? Would it be nice to debug using eclipse debugger in DRLVM? [ ] + 1 accept this contribution into the project [ ] -1 don't accept (please give reason) Vote runs usual 3 days unless protest or early completion. geir - 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][doc]Recommend to remove trunk\doc\kernel_doc and trunk\doc\vm_doc from svn repository.
Leo Li wrote: Hi, all: I have fixed the script to generate vm_doc but there is a problem: the newly generated vm_doc will override the original one which is under control of svn. Thus it will lead to build failure since vm_doc lacks from the perspective of svn. LOL, is it a problem of build script? Since the content under the directories of trunk\doc\kernel_doc and trunk\doc\vm_doc can be generated accordingly, I recommend to remove them from svn control as the doc of classlib does. Hmm...just had a look at the classlib/trunk/doc directory, I agree that current structure is interesting, there are three config files for Doxygen: kernel/kernel.cfg, classlib/classlib.cfg and vminterface/natives.cfg(I guess, for kernel class, classlib and native vmi respectively), while only two directories with Doxygen genereated documents: kernel_doc and vm_doc. IMHO, there is no reason to put the Doxygen generated files into SVN, which just like .class compiled by javac. I vote to remove the two directories, and keep the config files only. And, maybe we can add a build-doc target in the classlib/trunk/build.xml to make document creation more handy. -- 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][launcher] I am looking at the interaction between {classlib, launcher, drlvm} and {hysock, hysig, hythread}
Weldon Washburn wrote:
On 9/26/06, Leo Li [EMAIL PROTECTED] wrote:
Hi, Weldon:
The usage of the argument of portLibrary is for the function to call
other functions of the port library if needed. The argument is just a
virtual function table, as you said, can be any implemenatation of the
HyPortLibrary struct, not only the HyPortLibrary struct the function
belongs
to. Of course, different HyPortLibrary might lead to different
behavior of
the function if the HyPortLibrary is used by it.
I think the main purpose of the design is to alter some function
of a
specified HyPortLibrary struct flexibly, especially at runtime: What is
necessary to do is just to change an entry in HyPortLibrary while the
altered function can make use of other functions as well as other
functions
can use it.
Am I all right?:)
Hmmm... Interesting idea you have. Basically the idea is to rewrite the
virtual function table _before_ any of the functions are used. This
makes
much more sense than the way drlvm currently boots up. By the way, is
there
any documentation that says what you are suggesting? In other words, was
portlib specifically designed to do what you suggest?
I think so, here below the part of portlib document at {harmony svn
root}/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html
The port library is implemented as a table of function pointers. One
advantage of a function pointer based table is the ability to replace
any functionality without recompiling the entire Java virtual machine.
For example if an application is experiencing a memory leak, the memory
management functions of the port library can be replaced to help
determine the root cause of this leak. Alternatively applications
wishing to control all memory allocation can provide their own routines
to override the platform specific allocation and deallocation of memory.
Various implementations of the port library may choose not to implement
all functionality contained in the port library table. If a platform
does not support sockets, and thus the Java virtual machine does not
utilize sockets, the port library does not need to provide a valid
socket behavior. The port library contains version control information
cid:part1.01000201.01070009@gmail.com that enables applications to
determine if required functionality is supported. In addition the
version control information allows applications to determine if the port
library provided is compatible with the one which they were compiled
against.
On 9/25/06, Weldon Washburn [EMAIL PROTECTED] wrote:
It looks like hysignal.c is using the right monitor enter/exit().
That
is,
the one
from drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre/bin/hythr.dll
However, a bunch of functions in classlib's hysignal.c have an
incoming
argument of HyPortLibrary *portlib. The portlib variable can either
point
to the original classlib portlib C struct. Or it can point to PORTLIB
which
is a C struct with all the entries nulled out (more on this later.)
I think the next question to ask is what hysignal.c does with
the HyPortLibrary *portlib argument. If anyone knows, please
tell us.
Otherwise I will keep digging.
From stepping through DRLVM bootup, it looks like classlib's
portlib is
_dropped_ in signalProtectMain(). Then launcher gpProtectedMain
calls
invocation(PORTLIB,...) where PORTLIB is a nulled out HyPortLibrary C
struct. We need to put comments in the code describing the switch
from
classlib's portlib to drlvm's nulled out version.
On 9/22/06, Weldon Washburn [EMAIL PROTECTED] wrote:
All,
Its not clear at this moment what threading implementation is being
executed when hysignal.c calls hythread_monitor_enter(). If someone
already knows, please tell us. Otherwise, I will step through it
with
the
debugger to find out what is going on.
- Weldon
--
Weldon Washburn
Intel Middleware Products Division
--
Weldon Washburn
Intel Middleware Products Division
--
Leo Li
China Software Development Lab, IBM
--
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][logging] A non bug difference from RI?
Now I think I understand why RI locks .lck file instead of the log
file itself - if the log file is locked, user cannot use another
process(say, tail -f ***.log) to display the log file:(. So I'm going to
update the FileHandler to follow RI if no one objects.
Andrew Zhang wrote:
Hi folks,
When SecurityManager is enabled and all file permissions are disabled, RI
fails to new a FileHandler while Harmony allows.
Following test code shows the differences:
public void test_FileHandler() throws Exception {
FileHandler handler = new FileHandler();
SecurityManager originalSecurityManager =
System.getSecurityManager
();
try {
System.setSecurityManager(new MockFileSecurityManager());
handler.publish(new LogRecord(Level.SEVERE, msg));
// SecurityException is thrown here
handler.close();
} finally {
System.setSecurityManager(originalSecurityManager);
}
}
public static class MockFileSecurityManager extends SecurityManager {
public void checkPermission(Permission perm) {
if (perm instanceof FilePermission) {
System.out.println(check + perm.getName());
throw new SecurityException();
}
}
}
FileHandler.close() spec says Throws: SecurityException - if a security
manager exists and if the caller does not have
LoggingPermission(control)., In the code above, control permission is
allowed. The failure stack trace against RI looks like:
java.lang.SecurityException
at com.andrew.LoggingTest$MockFileSecurityManager.checkPermission(
LoggingTest.java:131)
at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
at java.io.File.exists(File.java:700)
at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:401)
at java.io.File.getCanonicalPath(File.java:531)
at java.io.FilePermission$1.run(FilePermission.java:218)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.FilePermission.init(FilePermission.java:212)
at java.io.FilePermission.init(FilePermission.java:264)
at java.lang.SecurityManager.checkDelete(SecurityManager.java:990)
at java.io.File.delete(File.java:869)
at java.util.logging.FileHandler.close(FileHandler.java:594)
at com.andrew.LoggingTest.test_FileHandler(LoggingTest.java:121)
...
The output is check C:\Documents and Settings\myaccount\java0.log.lck
It seems RI tries to delete log file.lck file, but has no permission.
.lck file is never mentioned in spec, and should be implementation
detail.
Current Harmony code never tries to lock a temp empty .lck file, so
the test
passes against Harmony.
If we revise the MockSecurityManager a little, to allow .lck file
permission,
public void checkPermission(Permission perm) {
if (perm instanceof FilePermission) {
if (perm.getName().indexOf(.lck) == -1) {
System.out.println(check + perm.getName());
throw new SecurityException();
}
}
}
The test will pass both against RI and Harmony.
So I'd suggest to leave it as non-bug difference from RI.
Any comments? Thank you!
--
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: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test
/jars/xerces_2.8.0/xercesImpl.jar [exec] [echo] Checking for depends/jars/xerces_2.8.0/xml-apis.jar [exec] [echo] Checking for depends/jars/junit_3.8.2/junit.jar [exec] [echo] Checking for depends/jars/bcprov-jdk14-133/signed.bcprov.jar [exec] [echo] Checking for depends/jars/icu4j_3.4.4/icu4j_3_4_4.jar [exec] [echo] Checking for depends/jars/mx4j_3.0.1/mx4j.jar [exec] [echo] Checking for depends/jars/mx4j_3.0.1/mx4j-remote.jar [exec] [echo] Checking for depends/jars/ecj_3.2/ecj_3.2.jar [exec] [echo] Checking for depends/jars/jetty/jetty-6.0.0.jar [exec] BUILD FAILED [exec] /home/hybld/continuum-working-directory/6/classlib/build.xml:106: The following error occurred while executing this line: [exec] /home/hybld/continuum-working-directory/6/classlib/make/build-java.xml:216: The following error occurred while executing this line: [exec] /home/hybld/continuum-working-directory/6/classlib/make/depends.xml:55: The following error occurred while executing this line: [exec] /home/hybld/continuum-working-directory/6/classlib/make/depends.xml:180: ... [exec] Missing dependency. The jar from: [exec] http://www.ibiblio.org/maven2/jetty/jetty/6.0.0/jetty-6.0.0.jar [exec] should be downloaded to: [exec] depends/jars/jetty/jetty-6.0.0.jar [exec] Run ant fetch-depends to automatically fetch dependencies. [exec] Note: Some of Harmony's dependencies are licensed under terms other [exec] than the Apache License v2. [exec] Total time: 27 seconds BUILD FAILED /home/hybld/continuum-working-directory/6/build.xml:118: exec returned: 1 Total time: 32 seconds -- 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][html] Differences with RI
Miguel Montes wrote: Hi, I fllled several JIRA issues more than three weeks ago, but they are still unassigned. (HARMONY-1272, 1349, 1350, 1395). We are working in the parser, and there are some issues that should be solved, such as the structure of ContentModel. I'd like to look at patches for 1349 and 1350 today, but 1395 is a contribution, so probably it needs Geir to raise a voting on it. And anyone interests to provide a patch for 1272? I would like to hear other people thoughts about this, particularly those from the developers of the existing javax.swing.text.html.parser code Regards Miguel Montes On 8/23/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I think that filing JIRA issue is right way :) 2006/8/23, Miguel Montes [EMAIL PROTECTED]: Hi: We have found several differences between Harmony's implementation of j.s.t.h.parser and the RI. I'm not sure if these should be reported individually as JIRA issues, or should be discussed here. For instance, in j.s.t.h.p.Entity, the RI. encodes isParameter and isGeneral in the type, which is a public field, while the current implementation in Harmony uses two boolean fields. So, the value of a public field is different in both implementations. Another case: ContentModel: The method first() should return the element that must be the first element to appear in a ContentModel. If it's not unique, the RI returns null. For instance, for the following ContentModel: TITLE ISINDEX? BASE? Any of those elements could appear at the beggining of a valid matching expression. So, the method first should return null, because there is not a single element that could be considered as the unique one that can appear at the head of a matching expression. Nevertheless, for this example (as for some others), HARMONY-948 returned a value. For this example, a BASE value was obtained. There are several more. Should we post them as separate JIRA issues, o as one big issue, with the suggeste patches? -- Miguel Montes -- 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] -- 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][logging] In applying the LogManager patch...
Geir Magnusson Jr. wrote: ... as suggested by Nikolay, I did run the tests $ cd modules/logging $ ant test and it was endless stacktraces, both before and after I made the modification. How do I know if I broke anything? I'm going to go forward with the patch as I don't see any harm, since Logger.global is supposed to be set via getLogger(global) anyway, so subsequent settings shouldn't harm. ant test in specific module directory returns build successfully even there is some tests fail, so I prefer to ant -Dbuild.module=logging test in classlib/trunk directory, which will check the test result and generate test report in html format. About the logging tests, probably because of the default java.util.logging.ErrorManager, wihch is used to handle the exception of associated handlers, and its default behavior is to print the error message to System.err, the solution I can imagine includes: redefine the System.err to sth. like /dev/null, or specify a customized ErrorManager. geir - 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: [VOTE] HARMONY-1217 : JNI-style C header file generator (aka 'javah')
+1 Geir Magnusson Jr. wrote: All is in order and in SVN for Harmony-1217 wrt BCC and ACQ. Please vote to accept or reject this contribution into the Apache Harmony project : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. geir - 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: [general] tasks for new snapshot?
Geir Magnusson Jr. wrote: we should probably just fix that Character problem and then create a new HDK snapshot. We're not there for JRE yet, but no reason to hold back HDK. I've rolled back the update from HARMONY-1500, the original codes should work. I don't expect that problem can be fixed very soon (which may needs ICU4J's modification, if so we need to get agreement with ICU community even we find the cause and get a solution). geir On Sep 21, 2006, at 3:08 PM, Tim Ellison wrote: Sounds like the launcher issues have been resolved, and we are at least no worse off with handling JAVA_HOME than before. Is it just the HARMONY-1500 Character problem now that would prevent us from cutting a snapshot of code? Anything else I missed? Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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][swing/awt] caffinemark shows that our graphics are sloooowwwww....
Geir Magnusson Jr. wrote: I've been playing a bit with caffinemark, and our numbers for everything except graphics are amazing. Convenient to post some results vs RI? I believe many ones(includes myself of course) would be very interest to see the numbers:) However, our graphics numbers are *terrible*. I was testing on Ubuntu. We need to fix this. Does anyone with familiarity with our swing/awt impl that could point us in the right direction? geir - 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: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
Vladimir Gorr wrote: On 9/22/06, Paulex Yang [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: When I roll away the latest changes for Character.java (H-1500 *Refactor some methods in java.lang.Character*) this issue disappears. It means a clue is here. I've revert the update for HARMONY-1500 at revision r448784, please check if the problem disappears. Yep, it helps and helped as I mentioned yet yesterday. One thing I don't understand is why this problem exists only on Windows. I mean all works fine w/o any changes for Linux. Can anybody explain me this? Hmm...I have no idea yet, still struggling on the DRLVM+ICU4J environment so far, will back to this thread when I find something. Thanks, Vladimir. Gang, it'd be not bad to run DRLVM testing for any commits to SVN repository. Otherwise we will be very hard to catch any errors like this. Any thoughts? Thanks, Vladimir. On 9/21/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/21/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: NPE is thrown for all kernel tests when testing is run on Windows at revision 448448: build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test ... [echo] RUNNING : java.lang.Class1_5Test [junit] java.lang.NullPointerException [junit] at com.ibm.icu.lang.UCharacter.getProperty (UCharacter.java :6073) [junit] at com.ibm.icu.lang.UCharacter.getType(UCharacter.java :2974) [junit] at com.ibm.icu.lang.UCharacter.isWhitespace(UCharacter.java :3162) [junit] at java.lang.Character.isWhitespace(Character.java:3091) [junit] at java.lang.Character.isWhitespace(Character.java:3078) [junit] at java.util.Properties.load(Properties.java:378) [junit] at java.util.PropertyResourceBundle .init( PropertyResourceBundle.java:44) snipped Does anybody observe this issue? As for Linux all works fine. I am looking into this issue. Is there any progress here? Did you managed to reproduce it? Same issue is also mentioned for other thread (*Trouble Building DRLVM*). Thanks in advance, Vladimir. Best regards Thanks, Vladimir. -- Spark Shen 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] -- 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]build failed on windows
Leo Li wrote: Dear Geir: I advise to use -Werror in Linux compiling but I am not sure of the side-effect. I am now trying to know whether all the warning can be fixed in Linux.:) Volunteer is welcome:). If the errors number is too large to be fixed in one run, I suggest to fix them one module by another. On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Sorry. My fault. Fixing now. I need to find settings to make gcc on linux enforce the same... geir On Sep 20, 2006, at 9:36 PM, Leo Li wrote: Hi, all I found that the classlib build fails on windows today. I have tried to fixed it in File main.c 1. move some declarations of variables to the top part of a function. at line 311: char *dirs[2]; at line 1045: int found = 0; int i=0; at line 1067:int strLen 2. comments out unused variable at line 1019: //UDATA newPathLength; -- Leo Li 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]build failed on windows
Leo Li wrote: Hi, Paulex: I plan to fix the warning in module luni first if no one objects.:) Go ahead for it. On 9/21/06, Paulex Yang [EMAIL PROTECTED] wrote: Leo Li wrote: Dear Geir: I advise to use -Werror in Linux compiling but I am not sure of the side-effect. I am now trying to know whether all the warning can be fixed in Linux.:) Volunteer is welcome:). If the errors number is too large to be fixed in one run, I suggest to fix them one module by another. On 9/21/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Sorry. My fault. Fixing now. I need to find settings to make gcc on linux enforce the same... geir On Sep 20, 2006, at 9:36 PM, Leo Li wrote: Hi, all I found that the classlib build fails on windows today. I have tried to fixed it in File main.c 1. move some declarations of variables to the top part of a function. at line 311: char *dirs[2]; at line 1045: int found = 0; int i=0; at line 1067:int strLen 2. comments out unused variable at line 1019: //UDATA newPathLength; -- Leo Li 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] -- 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: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
Geir Magnusson Jr. wrote: Do you think this is a drlvm issue or a classlib issue? I guess it is an integration issue, i.e., ICU4J's UCharacter needs to load some resources for initialization, while at that time on DRLVM, some necessary kernel classes haven't been inited, so that the UCharacter cannot load these properties sucessfully and leave them to null. I'll roll back the patch for Character temporarily if no one objects, and will look inside later(I need to checkout ICU4J's source at first ...). geir On Sep 21, 2006, at 1:07 AM, Vladimir Gorr wrote: NPE is thrown for all kernel tests when testing is run on Windows at revision 448448: build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test ... [echo] RUNNING : java.lang.Class1_5Test [junit] java.lang.NullPointerException [junit] at com.ibm.icu.lang.UCharacter.getProperty(UCharacter.java :6073) [junit] at com.ibm.icu.lang.UCharacter.getType(UCharacter.java:2974) [junit] at com.ibm.icu.lang.UCharacter.isWhitespace(UCharacter.java :3162) [junit] at java.lang.Character.isWhitespace(Character.java:3091) [junit] at java.lang.Character.isWhitespace(Character.java:3078) [junit] at java.util.Properties.load(Properties.java:378) [junit] at java.util.PropertyResourceBundle.init( PropertyResourceBundle.java:44) snipped Does anybody observe this issue? As for Linux all works fine. Thanks, Vladimir. - 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: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
Vladimir Gorr wrote: When I roll away the latest changes for Character.java (H-1500 *Refactor some methods in java.lang.Character*) this issue disappears. It means a clue is here. I've revert the update for HARMONY-1500 at revision r448784, please check if the problem disappears. Gang, it'd be not bad to run DRLVM testing for any commits to SVN repository. Otherwise we will be very hard to catch any errors like this. Any thoughts? Thanks, Vladimir. On 9/21/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/21/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: NPE is thrown for all kernel tests when testing is run on Windows at revision 448448: build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test ... [echo] RUNNING : java.lang.Class1_5Test [junit] java.lang.NullPointerException [junit] at com.ibm.icu.lang.UCharacter.getProperty (UCharacter.java :6073) [junit] at com.ibm.icu.lang.UCharacter.getType(UCharacter.java:2974) [junit] at com.ibm.icu.lang.UCharacter.isWhitespace(UCharacter.java :3162) [junit] at java.lang.Character.isWhitespace(Character.java:3091) [junit] at java.lang.Character.isWhitespace(Character.java:3078) [junit] at java.util.Properties.load(Properties.java:378) [junit] at java.util.PropertyResourceBundle .init( PropertyResourceBundle.java:44) snipped Does anybody observe this issue? As for Linux all works fine. I am looking into this issue. Is there any progress here? Did you managed to reproduce it? Same issue is also mentioned for other thread (*Trouble Building DRLVM*). Thanks in advance, Vladimir. Best regards Thanks, Vladimir. -- Spark Shen 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][luni] JIRA 1492 Constructor of HashMap throw unexpected exception
, V extends HashMapK, V {
public SubMap(Map? extends K, ? extends V m) {
super(m);
}
public V put(K key, V value) {
throw new RuntimeException();
}
}
Best regards
--
Spark Shen
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]
--
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][luni] JIRA 1492 Constructor of HashMap throw unexpected exception
Alexey Petrenko wrote:
Are you trying to say that the methods in Harmony can use only methods
used in corresponding RI implementations?
Let Spark speak for himself, but IMHO let's discuss the specific case
before considering it as a rule, this is not yet another reverse
engineering, the testcase is clear, without injection or reflection,
and the method under test is a constructor which invokes a public
method, so that user may have risk cannot to init their subclass of
HashMap.
2006/9/20, Spark Shen [EMAIL PROTECTED]:
Spark Shen 写道:
Hi :
Following is the discussion about JIRA 1492, shall we discuss it here?
public class SubMapTest extends TestCase {
public void testSubclass() {
HashMap map = new HashMap();
map.put(a, a);
SubMap map2 = new SubMap(map); // Harmony will throw an unexpected
exception here.
}
}
class SubMapK, V extends HashMapK, V {
public V put(K key, V value) {
throw new RuntimeException();
}
}
Nathan Beyer
Harmony's behavior may be different in this case, but I'm not sure I
would consider this a valid issue. What's a real use case for this
type of sub-classing?
[ Show » http://issues.apache.org/jira/browse/HARMONY-1492 ]
Nathan Beyer
http://issues.apache.org/jira/secure/ViewProfile.jspa?name=nbeyer
[18/Sep/06 08:41 PM] Harmony's behavior may be different in this case,
but I'm not sure I would consider this a valid issue. What's a real
use case for this type of sub-classing?
http://issues.apache.org/jira/secure/ViewProfile.jspa?name=spark+shenSpark
Shen
What if change the RuntimeException to UnsupportedOperationException?
[ Show » http://issues.apache.org/jira/browse/HARMONY-1492 ]
spark shen
http://issues.apache.org/jira/secure/ViewProfile.jspa?name=spark+shen
[18/Sep/06 08:48 PM] What if change the RuntimeException to
UnsupportedOperationException?
Alexey Petrenko
I'm not sure that this is a valid issue to.
As far as I understood the issue is that Harmony calls put method in
constructor while RI does not. Right?
If so I do not see any issue here.
I can not figure out what RI does. And please refer to JIRA 839, it
reports similar use case.
My point here is
1. we may not be able to predict how users will use our library.
2. Users could guess our implementation w/o difficulty, which
contradicts the encapulation priciple.
So I prefer to follow RI on this behavior.
When changing to UnsupportedOperationException, the use case is more
practical, since it is highly like that put operation is not supported.
But it seems not so practical that this sub-hashMap can not be
instantiated. May be one more assertion can convince you that this is
bug.
public class SubMapTest extends TestCase {
public void testSubclass() {
HashMap map = new HashMap();
map.put(a, a);
SubMap map2 = new SubMap(map);
assertEquals(1, map2.size());
}
}
class SubMapK, V extends HashMapK, V {
public SubMap(Map? extends K, ? extends V m) {
super(m);
}
public V put(K key, V value) {
throw new RuntimeException();
}
}
Best regards
--
Spark Shen
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][luni] JIRA 1492 Constructor of HashMap throw unexpected exception
Alexey Petrenko wrote:
But we can create such test case for every difference in used methods
between RI and Harmony. Right?
Sure we can:), I guess the issue is just if it is necessary. I've
described why I think it is necessary for HashMap's constructor in
another post of this thread - HashMap is fundamental and widely used,
so it should be tolerant; constructor is special, so it should be taken
care of.
2006/9/20, Paulex Yang [EMAIL PROTECTED]:
Alexey Petrenko wrote:
Are you trying to say that the methods in Harmony can use only methods
used in corresponding RI implementations?
Let Spark speak for himself, but IMHO let's discuss the specific case
before considering it as a rule, this is not yet another reverse
engineering, the testcase is clear, without injection or reflection,
and the method under test is a constructor which invokes a public
method, so that user may have risk cannot to init their subclass of
HashMap.
2006/9/20, Spark Shen [EMAIL PROTECTED]:
Spark Shen 写道:
Hi :
Following is the discussion about JIRA 1492, shall we discuss it
here?
public class SubMapTest extends TestCase {
public void testSubclass() {
HashMap map = new HashMap();
map.put(a, a);
SubMap map2 = new SubMap(map); // Harmony will throw an unexpected
exception here.
}
}
class SubMapK, V extends HashMapK, V {
public V put(K key, V value) {
throw new RuntimeException();
}
}
Nathan Beyer
Harmony's behavior may be different in this case, but I'm not
sure I
would consider this a valid issue. What's a real use case for this
type of sub-classing?
[ Show » http://issues.apache.org/jira/browse/HARMONY-1492 ]
Nathan Beyer
http://issues.apache.org/jira/secure/ViewProfile.jspa?name=nbeyer
[18/Sep/06 08:41 PM] Harmony's behavior may be different in this
case,
but I'm not sure I would consider this a valid issue. What's a real
use case for this type of sub-classing?
http://issues.apache.org/jira/secure/ViewProfile.jspa?name=spark+shenSpark
Shen
What if change the RuntimeException to
UnsupportedOperationException?
[ Show » http://issues.apache.org/jira/browse/HARMONY-1492 ]
spark shen
http://issues.apache.org/jira/secure/ViewProfile.jspa?name=spark+shen
[18/Sep/06 08:48 PM] What if change the RuntimeException to
UnsupportedOperationException?
Alexey Petrenko
I'm not sure that this is a valid issue to.
As far as I understood the issue is that Harmony calls put
method in
constructor while RI does not. Right?
If so I do not see any issue here.
I can not figure out what RI does. And please refer to JIRA 839, it
reports similar use case.
My point here is
1. we may not be able to predict how users will use our library.
2. Users could guess our implementation w/o difficulty, which
contradicts the encapulation priciple.
So I prefer to follow RI on this behavior.
When changing to UnsupportedOperationException, the use case is more
practical, since it is highly like that put operation is not
supported.
But it seems not so practical that this sub-hashMap can not be
instantiated. May be one more assertion can convince you that this is
bug.
public class SubMapTest extends TestCase {
public void testSubclass() {
HashMap map = new HashMap();
map.put(a, a);
SubMap map2 = new SubMap(map);
assertEquals(1, map2.size());
}
}
class SubMapK, V extends HashMapK, V {
public SubMap(Map? extends K, ? extends V m) {
super(m);
}
public V put(K key, V value) {
throw new RuntimeException();
}
}
Best regards
--
Spark Shen
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]
--
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: [build]Anyone else got these test errors of Pack200 like this?
Alex Blewitt wrote: Phew :-) You had me worried there for a moment ... :-) Alex. On 18/09/06, Paulex Yang [EMAIL PROTECTED] wrote: Pls. ignore it, cannot reproduce at r447234, probably I forgot ant build before running ant -Dbuild.module=archive test. Sorry for the confusion caused. Paulex Yang wrote: My build machine is WinXP SP2, Harmony classlib+IBM VME, at revision r 447234, and I got 5 similar errors of org.apache.harmony.archive.tests.internal.pack200.CodecTest like this: java.lang.NoSuchFieldError: org/apache/harmony/archive/internal/pack200/Codec.BYTE1 at org.apache.harmony.archive.tests.internal.pack200.CodecTest.testCodecToString(CodecTest.java:59) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) Any ideas or comments? -- 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] - 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]
[build]Anyone else got these test errors of Pack200 like this?
My build machine is WinXP SP2, Harmony classlib+IBM VME, at revision r 447234, and I got 5 similar errors of org.apache.harmony.archive.tests.internal.pack200.CodecTest like this: java.lang.NoSuchFieldError: org/apache/harmony/archive/internal/pack200/Codec.BYTE1 at org.apache.harmony.archive.tests.internal.pack200.CodecTest.testCodecToString(CodecTest.java:59) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) Any ideas or comments? -- 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: [build]Anyone else got these test errors of Pack200 like this?
Pls. ignore it, cannot reproduce at r447234, probably I forgot ant build before running ant -Dbuild.module=archive test. Sorry for the confusion caused. Paulex Yang wrote: My build machine is WinXP SP2, Harmony classlib+IBM VME, at revision r 447234, and I got 5 similar errors of org.apache.harmony.archive.tests.internal.pack200.CodecTest like this: java.lang.NoSuchFieldError: org/apache/harmony/archive/internal/pack200/Codec.BYTE1 at org.apache.harmony.archive.tests.internal.pack200.CodecTest.testCodecToString(CodecTest.java:59) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) Any ideas or comments? -- 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: [drlvm] putting kernel.jar in jre/bin/default
Alexey Varlamov wrote: 2006/9/13, Paulex Yang [EMAIL PROTECTED]: Alexey Varlamov wrote: Looks like sending my reply failed, here is a second try: I'm not sure I catch up what you mean, about Emma, Harmony's current test coverage exclude list[1] shows that not all classes can be instrumented, I don't think it is due to the position of kernel classes. Paulex, I'm sorry for causing confusion - I was a bit wrong. I experienced troubles with complete overriiding via -Xbootclasspath: argument, and just prepending -Xbootclasspath/p: works OK. Not all kernel classes are instrumented due to dependencies in instrumentation code itself, this is of course different thing. Agreed. Further, for the special requirement(instrument, AOP, or so), anything prevent the user to add -Xbootclasspath/p to replace the kernel class implementation? Or, what's the difference on this between RI and current Harmony? So the difference is that for -Xbootclasspath:, launcher+j9 always stealthily prepend luni-kernel.jar to user-specified bootclasspath, while RI allows fully custom bootclasspath. This is interesting. Yes, I think we should handle it, although it probably won't work to replace the kernel class implementation due to the VM dependency, we have no reason forbidding user to do this. Just had a look at how the normal bootclasspath(luni.jar, text.jar...) is processed, the interesting thing is they are loaded by JNI_OnLoad of hyluni.dll(libhyluni.so), with the source codes located in modules/luni/src/native/luni/shared/luniglob.c (It is interesting because I thought it was in launcher, but maybe the original author had similar issues to get the absolute path of jre/lib/boot). And it takes a straightforward way to handle the -Xbootclasspath: if this argument is passed in command line, just give up parsing the default bootclasspath. I have two thoughts on this: 1. If this is acceptable, we can deal with kernel class in similar way. 2. Supposing we can have better solution to locate the jre path, is there any chance to merge the both bootclasspath handling(kernel and normal) to launcher, so that it doesn't need to deal with bootclasspath twice? Or any other proposals? We had a discussion about this month ago [1], and the main argument against the launcher was there may be several launchers, moreover bootclasspath has to be set for any application that calls JNI_CreateJavaVM. So no better place than luni natives was suggested for the shared part of the bootlclasspath. BTW, there is reliability fix HARMONY-1243 related to this and still unresolved... OK, I'll look at it. But as kernel classes packaging is VM-specific, the VM should take care of them. Evidently the same argument about launcher applies to kernels as well, so current way with harmonyvm.properties is a sort of workaround anyway. And to handle the -Xbooclasspath: issue, there should be double filtering: check user-supplied arguments then filter autoloaded ones from harmonyvm.properties. Smells not really good ;). That's what I meant... More logical would be to get rid of handling harmonyvm.properties in launcher entirely, leaving this to VM if it needs it. I thought about this, but launcher actually uses standard invocation API to create VM, so if VM's invocation API implementation takes care of the kernel class(which are part of Harmony VMI), it's a little difficult for VM vendor to provide an adaptive VM, adaptive here means it can adapt Harmony classlib as well as others without too much effort, say, GNU Classpath(or maybe Sun's Open Sourced Classlib). I still prefer to handle the Harmony VMI related things in *Harmony* Launcher. And anyway, if the normal bootclasspath should be taken care of in luni, while kernel bootclasspath must be dealed with elsewhere, the double filtering is hard to avoid, [1] http://thread.gmane.org/gmane.comp.java.harmony.devel/11776/focus=11818 -- Alexey - 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] - 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: [general] Marking JIRA issues before creation of patches.
Denis Kishenko wrote: If I am going to work with whole module then Harmony class library development status[1] page is useful but if I want to work with several classes, for example fix some JAPI issues or make serious changes, then existing wiki page can't be used. Anyone can create detail page for some component, there already has been some, for example, luni page[2]. I agree with creating JIRA issue and sending notification to dev-list, but I think more detailed status list is necessary, not only modules but packages and classes too. Discussion on dev-list is generally first choice, I totally agree with that. Wiki is just supplement to record somewhat significant work needs longer time or relative big effort, for example, the luni page[2], as well as others, has shown to be very useful when several volunteers from different party worked together to bring the original luni contribution up to 5.0 compatible, especially when someone has interested in some component, the relevant page can be subscribed so that he/she can get update notification. Wiki is useful also because of mailing list's traffic, it's hard for new comer (and often for regular Harmony watcher) to see what's going on, what is most expected to contribute, etc, only in mailing list. Further, I guess many potential user may not visit dev-list at all... However, as others said for several times, it is not necessary to record everything on Wiki(even in list), and it is still good suggestion to discuss at the mailing list before/when trying to update Wiki. [1] http://wiki.apache.org/harmony/component_development_status [2] http://wiki.apache.org/harmony/LUNI 2006/9/7, Paulex Yang [EMAIL PROTECTED]: Geir Magnusson Jr. wrote: Good. Also, don't just do things in JIRA. Add the comment in JIRA, but also send something to the dev list. That way, people who are interested will more easily notice and maybe offer to help, or such... +1, and for classlib, we have had some wiki pages[1]-[3] to list the ToDos and to record who is doing or has interest on what. [1] http://wiki.apache.org/harmony/component_development_status [2] http://wiki.apache.org/harmony/Excluded_tests [3] http://wiki.apache.org/harmony/ClassLibrary geir Oleg Khaschansky wrote: Hi all, There were situations when several people started work on the same issue simultaneously. This happens because it is impossible to assign an issue to a non-committer. I suggest the following process to prevent these collisions: 1. If non-committer starts investigation and is pretty sure that he will proceed with the patch then he adds a comment like starting investigation to the JIRA issue. Maybe we should have a special keyword for this to make a search easier. 2. If for some reason he is unable to provide the patch, he adds a comment about this also. What do you think about this? -- Oleg - 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] -- 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: [vm] ArgoUML application crashes IBM VME
Oliver Deakin wrote: Thanks for the link Paulex - sorry it's taken a while to reply. I have added ArgoUML to the list of apps on the page you linked, and have put in the details at [1]. If there's anything that needs adding, please let me know. Nice page! Thank you:). Hopefully the problem can be fixed soon:). Regards, Oliver [1] http://wiki.apache.org/harmony/ArgoUML Paulex Yang wrote: Vladimir Gorr wrote: Yes, it makes sense, I think. Although I don't know what the right place is? there is a section named what can it do[1], and it would be very useful to add a new page for Argo on the test procedure/result/missing class etc, and add the link to that section. [1] http://wiki.apache.org/harmony/ClassLibrary Thanks, Vladimir. Regards, -- 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: [general] Marking JIRA issues before creation of patches.
Denis Kishenko wrote: Most of wiki module pages were updated last time several months ago. Do they have actual information? It is easier for Wiki to be out-dated, that's why it needs to be taken care of more:). Specific for the module page, AFAIK, the 5.0 bring up work on many modules are almost complete, so I'm not surprised they are not updated actively now, while some others are under actively working, say, the excluded tests[1]. Actually I just meant that Wiki is a tool to record the interest and ToDos. [1] http://wiki.apache.org/harmony/Excluded_tests 2006/9/13, Paulex Yang [EMAIL PROTECTED]: Discussion on dev-list is generally first choice, I totally agree with that. Wiki is just supplement to record somewhat significant work needs longer time or relative big effort, for example, the luni page[2], as well as others, has shown to be very useful when several volunteers from different party worked together to bring the original luni contribution up to 5.0 compatible, especially when someone has interested in some component, the relevant page can be subscribed so that he/she can get update notification. Wiki is useful also because of mailing list's traffic, it's hard for new comer (and often for regular Harmony watcher) to see what's going on, what is most expected to contribute, etc, only in mailing list. Further, I guess many potential user may not visit dev-list at all... However, as others said for several times, it is not necessary to record everything on Wiki(even in list), and it is still good suggestion to discuss at the mailing list before/when trying to update Wiki. -- 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: [OLD JIRA]Deal with 780 866 1367 according to discussion
Well done, Spark! Spark Shen wrote: Hi All: Component attribute of JIRA 780 has been left as none, can any committer change it to [classlib]. Done. The patch has already outdated and seems incorrect, I will provide a new patch. Any specific comments for the reasons? According to the 'Fighting Old JIRA Issues' guideline, I suggest to change component of JIRA 866 from 'Non-bug differences from RI' into 'classlib'. Since RI's behavior make sense here. An arbitrary object will not be found in a 0-length array, no matter it is comparable or not. The attached patch is already outdated, I will attach a new patch if no one objects. And of course, I will comment it on the JIRA. Seems Nathan is faster than me;-) The patch acompany JIRA 1367 has not any test cases and already outdated, the patch should also be renewed. Go ahead, please, thank you. Best regards -- 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: [drlvm] putting kernel.jar in jre/bin/default
Alexey Varlamov wrote: 2006/9/11, Paulex Yang [EMAIL PROTECTED]: Alexey Varlamov wrote: 2006/9/11, Geir Magnusson Jr. [EMAIL PROTECTED]: Evgueni Brevnov wrote: On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: There seems to be no easy solution, other than parse LD_LIBRARY_PATH or PATH... Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside in one directory? I was thinking about this for packaging - that way you can have : jre/ bin/ j9/ drlvm/ and setup a symlink if you wish. if we have kernel.jar in jre/lib/boot as we do now, it's must less convenient and probably error prone to switch back and forth. If yes then we can take vmcore.dll base path as a location of kerenel.jar. Sure - where will you get that? and what do you w/ .so's in unix? I've come to the conclusion that the only way will be to manually run the PATH (win) and LD_LIBRARY_PATH (linux) IIUC, j9 does this in astonishingly simple way - it just specifies -Xbootclasspath/p:%LAUNCHER_HOME%/default/luni-kernel.jar in the vmdir/harmonyvm.properties file, and the launcher does the rest. Namely, it automatically reads that file, replaces %LAUNCHER_HOME% with actual location and feeds extra arguments to VM among user's ones. This solution looks sufficient for now, but it seems to be only partial: it does not work for pure Invocation API usecase.Besides,those hardcoded arguments to VM appear confusing in some cases - e.g. it is impossible to override kernel.jar via command-line. Is it necessary to override the kernel.jar via command-line? The kernel class is provided by VM, so it is natural to locate it by VM specific property file. The first example which came to mind, how could you instrument the kernel classes, say for coverage analysis by emma or custom profiling? I'm sure there are more usecases, but anyway this is generally adopted behaviour and not following it may be far more disappointing than exception message incompatibility which we care so much ;) I'm not sure I catch up what you mean, about Emma, Harmony's current test coverage exclude list[1] shows that not all classes can be instrumented, I don't think it is due to the position of kernel classes. Further, for the special requirement(instrument, AOP, or so), anything prevent the user to add -Xbootclasspath/p to replace the kernel class implementation? Or, what's the difference on this between RI and current Harmony? [1] http://viv.byethost15.com/exclude.list Also note hardcoded default vmdir. Agree, default should be replaced by some variables(%vmdir% or so), so it is easier to move VME to another directory. OK, I will file a JIRA for this. -- Regards, Alexey - 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: [build] anybody seeing MathTest failure?
Seems caused by r442438, I have recovered part of the update to make the test pass at revision r442527, please verify. Mikhail Loenko wrote: I see this on both linux and windows. anybody else seeing it? Class org.apache.harmony.luni.tests.java.lang.MathTest test_hypot_DD Failure Should return NaN expected:NaN but was:NaN junit.framework.AssertionFailedError: Should return NaN expected:NaN but was:NaN at org.apache.harmony.luni.tests.java.lang.MathTest.test_hypot_DD(MathTest.java:277) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) 0.000 test_log1p_D Failure Should return NaN expected:NaN but was:NaN junit.framework.AssertionFailedError: Should return NaN expected:NaN but was:NaN at org.apache.harmony.luni.tests.java.lang.MathTest.test_log1p_D(MathTest.java:323) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) Thanks, Mikhail - 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: [build] anybody seeing MathTest failure?
Mikhail Loenko wrote:
it works! thanks, Paulex
Welcome, thanks a lot for Spark's tips:).
However, I consider it as a JUnit's bug, because it's
assertEquals(String, double, double, double) method has special handling
code for INFINITE but not for NaN[1], but seems it is intended behavior
as the comment shows, hmm...
[1] snippet from junit.framework.Assert
static public void assertEquals(String message, double expected,
double actual, double delta) {
// handle infinity specially since subtracting to infinite
values gives NaN and the
// the following test fails
if (Double.isInfinite(expected)) {
if (!(expected == actual))
failNotEquals(message, new Double(expected), new
Double(actual));
} else if (!(Math.abs(expected-actual) = delta)) // Because
comparison with NaN always returns false(== Paulex: before this
line, seems should check the NaN at first)
failNotEquals(message, new Double(expected), new
Double(actual));
}
2006/9/12, Paulex Yang [EMAIL PROTECTED]:
Seems caused by r442438, I have recovered part of the update to make the
test pass at revision r442527, please verify.
--
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: [build] anybody seeing MathTest failure?
Nathan Beyer wrote:
For asserting NaN we should do something like this:
assertTrue(Double.isNaN((code to return NaN));
I agree, it's much clear and concise. But I think the assertEquals()
should be more defensive, for example, we may need to write test like this:
assertEquals(some code may return NaN, some_other_code may return NaN,
delta);
-Nathan
-Original Message-
From: Paulex Yang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 12, 2006 4:50 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [build] anybody seeing MathTest failure?
Mikhail Loenko wrote:
it works! thanks, Paulex
Welcome, thanks a lot for Spark's tips:).
However, I consider it as a JUnit's bug, because it's
assertEquals(String, double, double, double) method has special handling
code for INFINITE but not for NaN[1], but seems it is intended behavior
as the comment shows, hmm...
[1] snippet from junit.framework.Assert
static public void assertEquals(String message, double expected,
double actual, double delta) {
// handle infinity specially since subtracting to infinite
values gives NaN and the
// the following test fails
if (Double.isInfinite(expected)) {
if (!(expected == actual))
failNotEquals(message, new Double(expected), new
Double(actual));
} else if (!(Math.abs(expected-actual) = delta)) // Because
comparison with NaN always returns false(== Paulex: before this
line, seems should check the NaN at first)
failNotEquals(message, new Double(expected), new
Double(actual));
}
2006/9/12, Paulex Yang [EMAIL PROTECTED]:
Seems caused by r442438, I have recovered part of the update to make
the
test pass at revision r442527, please verify.
--
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]
-
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]volunteer to supply patches for old JIRAs
Nathan Beyer wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan +1 from me, this is an excellent guide. Only one more thing: * If the JIRA/patch is debatable for any reasons (non-bug difference, break others, any other concerns...), don't hesitate to forward it to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, for example, there may be several issues/patches related to ObjectOutputStream, if you fixed/updated one, another patch may be outdated, a better way is to link them and consider them together. -- 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]volunteer to supply patches for old JIRAs
Tony Wu wrote: so helpful suggestion, thank you Nathan. According to Nathan's suggestion, I suggest we go ahead as below, 1. verify all the issues without patch, supply a patch if possible. 2. for the issues already has a patch, verify the reason why it was ignored, and then a.write testcase if caused by lack of test. b.supply another patch if the patch is out of date. c.add comments to support it if the patch is ok. IIRC, there is a discussion related to patch available status, if it is opened, it would be easier to express support:). On 9/13/06, Nathan Beyer [EMAIL PROTECTED] wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan -Original Message- From: Tony Wu [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 10:26 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib]volunteer to supply patches for old JIRAs On 9/13/06, Spark Shen [EMAIL PROTECTED] wrote: Tony Wu 写道: Hi all, I noticed there're many unresolved JIRAs posted so long time. I purpose to dive into and find whether it is in my range and try to supply a patch if no one objects :) Is there anyone alse has interest and would like to work with me? Hi, It is interesting of your proposal. May I join in? Great! Welcome! I noticed that there are many categories of components. I suggest we only deal with those components we are familier with. Since there are so many unresolved JIRAs, will you start from the beginning and I will start from the end. If someone else is interested, he/she may start from the middle. :-) good idea, I'll start to look in descendent order of jira sn. Best regards -- Spark Shen 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] -- Tony Wu 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: [build] anybody seeing MathTest failure?
Nathan Beyer wrote:
-Original Message-
From: Paulex Yang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 12, 2006 10:11 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [build] anybody seeing MathTest failure?
Nathan Beyer wrote:
For asserting NaN we should do something like this:
assertTrue(Double.isNaN((code to return NaN));
I agree, it's much clear and concise. But I think the assertEquals()
should be more defensive, for example, we may need to write test like
this:
assertEquals(some code may return NaN, some_other_code may return NaN,
delta);
I'm not sure that I would agree with that; NaN is a special value that's
defined by its inequality with itself (d != d).
In any case, the JUnit methods have worked like this for years, so their
behavior couldn't change now.
Of course not:).
-Nathan
-Original Message-
From: Paulex Yang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 12, 2006 4:50 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [build] anybody seeing MathTest failure?
Mikhail Loenko wrote:
it works! thanks, Paulex
Welcome, thanks a lot for Spark's tips:).
However, I consider it as a JUnit's bug, because it's
assertEquals(String, double, double, double) method has special
handling
code for INFINITE but not for NaN[1], but seems it is intended behavior
as the comment shows, hmm...
[1] snippet from junit.framework.Assert
static public void assertEquals(String message, double expected,
double actual, double delta) {
// handle infinity specially since subtracting to infinite
values gives NaN and the
// the following test fails
if (Double.isInfinite(expected)) {
if (!(expected == actual))
failNotEquals(message, new Double(expected), new
Double(actual));
} else if (!(Math.abs(expected-actual) = delta)) // Because
comparison with NaN always returns false(== Paulex: before this
line, seems should check the NaN at first)
failNotEquals(message, new Double(expected), new
Double(actual));
}
2006/9/12, Paulex Yang [EMAIL PROTECTED]:
Seems caused by r442438, I have recovered part of the update to make
the
test pass at revision r442527, please verify.
--
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]
-
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]
-
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: [drlvm] putting kernel.jar in jre/bin/default
Alexey Varlamov wrote: Looks like sending my reply failed, here is a second try: I'm not sure I catch up what you mean, about Emma, Harmony's current test coverage exclude list[1] shows that not all classes can be instrumented, I don't think it is due to the position of kernel classes. Paulex, I'm sorry for causing confusion - I was a bit wrong. I experienced troubles with complete overriiding via -Xbootclasspath: argument, and just prepending -Xbootclasspath/p: works OK. Not all kernel classes are instrumented due to dependencies in instrumentation code itself, this is of course different thing. Agreed. Further, for the special requirement(instrument, AOP, or so), anything prevent the user to add -Xbootclasspath/p to replace the kernel class implementation? Or, what's the difference on this between RI and current Harmony? So the difference is that for -Xbootclasspath:, launcher+j9 always stealthily prepend luni-kernel.jar to user-specified bootclasspath, while RI allows fully custom bootclasspath. This is interesting. Yes, I think we should handle it, although it probably won't work to replace the kernel class implementation due to the VM dependency, we have no reason forbidding user to do this. Just had a look at how the normal bootclasspath(luni.jar, text.jar...) is processed, the interesting thing is they are loaded by JNI_OnLoad of hyluni.dll(libhyluni.so), with the source codes located in modules/luni/src/native/luni/shared/luniglob.c (It is interesting because I thought it was in launcher, but maybe the original author had similar issues to get the absolute path of jre/lib/boot). And it takes a straightforward way to handle the -Xbootclasspath: if this argument is passed in command line, just give up parsing the default bootclasspath. I have two thoughts on this: 1. If this is acceptable, we can deal with kernel class in similar way. 2. Supposing we can have better solution to locate the jre path, is there any chance to merge the both bootclasspath handling(kernel and normal) to launcher, so that it doesn't need to deal with bootclasspath twice? Or any other proposals? -- Alexey - 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: [drlvm] putting kernel.jar in jre/bin/default
Alexey Varlamov wrote: 2006/9/11, Geir Magnusson Jr. [EMAIL PROTECTED]: Evgueni Brevnov wrote: On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: There seems to be no easy solution, other than parse LD_LIBRARY_PATH or PATH... Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside in one directory? I was thinking about this for packaging - that way you can have : jre/ bin/ j9/ drlvm/ and setup a symlink if you wish. if we have kernel.jar in jre/lib/boot as we do now, it's must less convenient and probably error prone to switch back and forth. If yes then we can take vmcore.dll base path as a location of kerenel.jar. Sure - where will you get that? and what do you w/ .so's in unix? I've come to the conclusion that the only way will be to manually run the PATH (win) and LD_LIBRARY_PATH (linux) IIUC, j9 does this in astonishingly simple way - it just specifies -Xbootclasspath/p:%LAUNCHER_HOME%/default/luni-kernel.jar in the vmdir/harmonyvm.properties file, and the launcher does the rest. Namely, it automatically reads that file, replaces %LAUNCHER_HOME% with actual location and feeds extra arguments to VM among user's ones. This solution looks sufficient for now, but it seems to be only partial: it does not work for pure Invocation API usecase.Besides,those hardcoded arguments to VM appear confusing in some cases - e.g. it is impossible to override kernel.jar via command-line. Is it necessary to override the kernel.jar via command-line? The kernel class is provided by VM, so it is natural to locate it by VM specific property file. Also note hardcoded default vmdir. Agree, default should be replaced by some variables(%vmdir% or so), so it is easier to move VME to another directory. As for the .so locations, I'm not sure if there is portable solution (parsing LD_LIBRARY_PATH looks error-prone). Maybe better solution would be leave this to user - for setting JAVA_HOME or such... -- Alexey -- 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: [general] Marking JIRA issues before creation of patches.
Geir Magnusson Jr. wrote: Good. Also, don't just do things in JIRA. Add the comment in JIRA, but also send something to the dev list. That way, people who are interested will more easily notice and maybe offer to help, or such... +1, and for classlib, we have had some wiki pages[1]-[3] to list the ToDos and to record who is doing or has interest on what. [1] http://wiki.apache.org/harmony/component_development_status [2] http://wiki.apache.org/harmony/Excluded_tests [3] http://wiki.apache.org/harmony/ClassLibrary geir Oleg Khaschansky wrote: Hi all, There were situations when several people started work on the same issue simultaneously. This happens because it is impossible to assign an issue to a non-committer. I suggest the following process to prevent these collisions: 1. If non-committer starts investigation and is pretty sure that he will proceed with the patch then he adds a comment like starting investigation to the JIRA issue. Maybe we should have a special keyword for this to make a search easier. 2. If for some reason he is unable to provide the patch, he adds a comment about this also. What do you think about this? -- Oleg - 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] -- 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][luni] Put setInterruptAction() in our j.l.Thread stub?
Geir Magnusson Jr. wrote: This came up in another thread. Currently, java.nio.channels.spi.AbstractInterruptibleChannel depends on there being a setInterruptAction() method on java.lang.Thread. I certainly think that this kind of thing should be documented, so the question - should we add this to our Thread stub class? I think so, actually it has been added as part of patch for HARMONY-635 with documentations, but it was removed later for unknown reasons...I can recover it if no one objects. geir - 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] internationalization and new patches
Ilya Okomin wrote: When I dealt with nio_char module I found that some messages were already marked with non-nls tag. (e.g. java.nio.charset.CharsetDecoder) These messages aren't described in the spec. Is there any reason to left them as is without internationalization? Specific to CharsetDecoder.replaceWith(), I don't believe there is any reason not to i18n the exception messages, I guess it was marked non-nls by mistake, or just because the developer didn't like to see the warning message;-). Please go ahead and provide patch for it. Thanks, Ilya. [SNIP] -- 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][TestNG] groups of Harmony test
Vladimir Ivanov wrote: Do we really need in it? At present time tests were designed for win/unix only. I thought at least we have interest to port Harmony to these platforms[1]. [1] http://incubator.apache.org/harmony/roadmap.html#Porting%20Matrix -- 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][logging] a test suite shouldn't touch any of JRE config files!!!
Stepan Mishura wrote: On 9/4/06, *Paulex Yang* wrote: Stepan Mishura wrote: On 9/1/06, Paulex Yang wrote: Stepan Mishura wrote: Hi Andrew, I've just looked into static initialization block and then to the spec. for LogManager class. My impression is that Harmony implementation doesn't follow the spec. The spec. says: At startup the LogManager class is located using the ' java.util.logging.manager' system property.By default, the LogManager reads its initial configuration from a properties file lib/logging.properties in the JRE directory Stepan, I think the meaning of By default is debatable. Actually the spec looks like this: At startup the LogManager class is located using the java.util.logging.manager system property. By default, the LogManager reads its initial configuration from a properties file lib/logging.properties in the JRE directory. If you edit that property file you can change the default logging configuration for all uses of that JRE. In addition, the LogManager uses two optional system properties that allow more control over reading the initial configuration: * java.util.logging.config.class * java.util.logging.config.file... So I consider the By default doesn't necessarily means default case without java.util.logging.manager property, but means the default case without java.util.logging.config.class/file properties. A simple test on RI of specifying a customized MockLogManager by j.u.l.manager property shows the default lib/logging.properties does affect the behavior of the customized LogManager, say the root logger's level, etc. Do you mean that RI resets the root logger's level of customized LogManager to default value from lib/logging.properties? Yes, so I think customized LogManager also needs to initialize itself in same procedure as j.u.l.LogManager. Hi Paulex, I've implemented custom LogManager (see attachment): it sets value for root logger's level different from default value(INFO). According to my test (see attachment) RI doesn't change level of root logger. The test prints the following: $java -classpath . MyTest INFO $java -classpath . -Djava.util.logging.manager=CustomLogManager MyTest SEVERE Did I missed something? Stepan, I run the test under Sun JDK 1.5.0_06 for WinXP, but I got INFO printed for both cases... Thanks, Stepan. -- 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][logging] A non bug difference from RI?
Stepan Mishura wrote:
On 9/1/06, Paulex Yang wrote:
Stepan Mishura wrote:
Andrew, thanks for the test. But working test doesn't mean that there
is no
bug :-)
AFAIK in our case an operation on file (if file is not exist - create
file)
should be atomic. And it looks like Harmony implementation doesn't
do in
atomic way.(see FileHandler.initOutputFiles() method)
Seems there is a bug in the FileHandler.initOutputFiles(), in Ln. 232,
if the FileLock isn't held, the FileOutputStream should be closed before
continue.
code
lock = channel.tryLock();
if (null == lock) {
//the FileChannel(or FileOutputStream) should be
closed here
continue;
}
/code
BTW, why FileNotFoundException is re-thrown in Ln. 223 ? IMO, try-catch
block should be deleted.
try {
fileStream = new FileOutputStream(fileName, append);
channel = fileStream.getChannel();
} catch(FileNotFoundException e){
//invalid path name, throw exception
throw e;
}
Agree, fixed at revision r440292.
But I didn't catch up what's the atomic means here, do you mean the
tryLock() is not atomic or sth.? If so, any other solutions for Java
codes? Otherwise, I think current implementation is fine, if two process
try to open same log file at same time, only one process can get the
lock by tryLock(), and the other will close the FileOutputStream then
continue to try another log file name, anything I missed?
I was confused by gaps in code between File.exists(), new
FileOutputStream()
and FileChannel.tryLock().
For example, I've tried to emulate the following situation:
A process VM_1 is up to lock a created file (Ln.230) and in this time a
process VM_2 found out that the file exists and deleted it (Ln.213). My
current result is that the file is locked successfully but may be I
incorrectly emulated situation. I'm going to continue experimenting
and let
you know if it is possible to create reproducible files conflict.
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]
--
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][logging] a test suite shouldn't touch any of JRE config files!!!
Stepan Mishura wrote: Paulex, thanks for your patience and answers. Yes, Sun's JRE sets root logger's level according to 'lib/logging.properties'. Also specifying the level for root logger in j.u.l.config.file doesn't help. (I assumed before that a JRE respects my lovely custom LogManager settings :-(! ) OK. Let's return to the initial issue: how to run logging tests without changing JRE config files? I still believe that there should be some elegant way for testing logging implementation without touching JRE files. I agreed this is not acceptable. AFAIK current LogManagerTest has used a MockLogManager in most test cases, so the migration should be relatively easy. For example, what about developing custom LogManager for testing? The testing manager will work in 2 modes: default configuration and custom configuration. A test will have a hook to switch testing manager's mode. The first configuration is read from JRE config files (by j.u.l.LogManager implementation) and the second one will be fully controlled by a test and is set by the test via some manager's method (say readConfiguration(InputStream)). Does this sound crazy? Maybe we just need one Support_Exec() invocation to verify if the LogManager reads the default logging properties(jre/lib/logging.properties) correctly(which should be straightforward by also loading and parsing that properties in test codes), for other tests, we always use customized LogManager or configuration files. If you are fine with this, I'm volunteer to refactor the tests. Thoughts? Other suggestions? 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] -- 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][logging] a test suite shouldn't touch any of JRE config files!!!
Stepan Mishura wrote: On 9/1/06, Paulex Yang wrote: Stepan Mishura wrote: Hi Andrew, I've just looked into static initialization block and then to the spec. for LogManager class. My impression is that Harmony implementation doesn't follow the spec. The spec. says: At startup the LogManager class is located using the ' java.util.logging.manager' system property.By default, the LogManager reads its initial configuration from a properties file lib/logging.properties in the JRE directory Stepan, I think the meaning of By default is debatable. Actually the spec looks like this: At startup the LogManager class is located using the java.util.logging.manager system property. By default, the LogManager reads its initial configuration from a properties file lib/logging.properties in the JRE directory. If you edit that property file you can change the default logging configuration for all uses of that JRE. In addition, the LogManager uses two optional system properties that allow more control over reading the initial configuration: * java.util.logging.config.class * java.util.logging.config.file... So I consider the By default doesn't necessarily means default case without java.util.logging.manager property, but means the default case without java.util.logging.config.class/file properties. A simple test on RI of specifying a customized MockLogManager by j.u.l.manager property shows the default lib/logging.properties does affect the behavior of the customized LogManager, say the root logger's level, etc. Do you mean that RI resets the root logger's level of customized LogManager to default value from lib/logging.properties? Yes, so I think customized LogManager also needs to initialize itself in same procedure as j.u.l.LogManager. Thanks, Stepan. -- 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][logging] A non bug difference from RI?
Stepan Mishura wrote:
Andrew, thanks for the test. But working test doesn't mean that there
is no
bug :-)
AFAIK in our case an operation on file (if file is not exist - create
file)
should be atomic. And it looks like Harmony implementation doesn't do in
atomic way.(see FileHandler.initOutputFiles() method)
Seems there is a bug in the FileHandler.initOutputFiles(), in Ln. 232,
if the FileLock isn't held, the FileOutputStream should be closed before
continue.
code
lock = channel.tryLock();
if (null == lock) {
//the FileChannel(or FileOutputStream) should be
closed here
continue;
}
/code
But I didn't catch up what's the atomic means here, do you mean the
tryLock() is not atomic or sth.? If so, any other solutions for Java
codes? Otherwise, I think current implementation is fine, if two process
try to open same log file at same time, only one process can get the
lock by tryLock(), and the other will close the FileOutputStream then
continue to try another log file name, anything I missed?
Thanks,
Stepan.
--
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][luni] signalis interruptus in hysock
This is a VMI extension introduced by HARMONY-635, and this modification
was discussed before in a very long thread[1]
But it's weird that, at revision r431077, it is removed, anyone knows
why:-(.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL PROTECTED]
Alexey Varlamov wrote:
Guys,
Probably I missed that thread on InterruptibleChannel implementation,
but I've just hit on the following code in
java.nio.channels.spi.AbstractInterruptibleChannel:
static {
try {
setInterruptAction = AccessController
.doPrivileged(new PrivilegedExceptionActionMethod() {
public Method run() throws Exception {return
Thread.class.getDeclaredMethod(setInterruptAction,new
Class[] {
Runnable.class });
}
});
setInterruptAction.setAccessible(true);
} catch (Exception e) {
// FIXME: be accomodate before VM actually provides
// setInterruptAction method
// throw new Error(e);
}
}
There are no docs on j.l.Thread.setInterruptAction()... Does this code
snippet relate to the subject of this discussion?
--
Alexey
2006/8/31, Paulex Yang [EMAIL PROTECTED]:
Geir Magnusson Jr. wrote:
Time to take another run at this since I didn't get any responses on
the drlvm thread.
We have the problem that DRLVM uses SIGUSR2 in the thread manager (not
an unreasonable thing to do, I believe) but this results in knocking
threads out of select() in hysock.c (and I'm sure we'll see it in
other places.)
Now, I'm not sure what the right course of action is. We have a
suggested patch from Artem that suggests we just ignore when the tread
is interrupted :
--- modules/luni/src/main/native/port/linux/hysock.c
+++ modules/luni/src/main/native/port/linux/hysock.c
@@ -2570,11 +2570,16 @@ hysock_select (struct HyPortLibrary * po
I_32 rc = 0;
I_32 result = 0;
- result =
+ do
+ {
+result =
select (nfds, readfds == NULL ? NULL : readfds-handle,
writefds == NULL ? NULL : writefds-handle,
exceptfds == NULL ? NULL : exceptfds-handle,
timeout == NULL ? NULL : timeout-time);
+ }
+ while (result == -1 errno == EINTR);
+
if (result == -1)
{
rc = errno;
IIRC, months ago similar approach was discussed in another thread for
j.nio.channels.InterruptibleChannel implementation, but IMHO it can be a
workaround but is not acceptable as a solution, because
InterruptibleChannel is extensible by user application, i.e., user can
implement their own interruptible blocking I/O easily without
considering too much on thread sync issues, it's not reasonable to ask
user writing codes within a loop like this.
this works, but I'm bothered by the fact that we're just blindly
ignoring signals like this. I also think that I need to go and do
this everywhere we have a non-restarted interruptable blocking system
call.
Now, I'd like to get this fixed today, as it's high time for another
snapshot of the JRE and HDK, but w/o it, Tomcat runs for 2 seconds at
best :)
So - does anyone have any other bright ideas? Why don't we see this
with J9?Would it be better to do a per-thread signal mask after
asking the thread manager what signal it's using du jour? (Andrey
noted that Sun allows one to change the signals used, apparently to
prevent collision w/ user code vi JNI, I guess...)
geir
-
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]
-
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][logging] A non bug difference from RI?
Stepan Mishura wrote:
On 8/30/06, Andrew Zhang wrote:
On 8/30/06, Stepan Mishura wrote:
On 8/30/06, Andrew Zhang wrote:
Hi folks,
When SecurityManager is enabled and all file permissions are
disabled,
RI
fails to new a FileHandler while Harmony allows.
Following test code shows the differences:
public void test_FileHandler() throws Exception {
FileHandler handler = new FileHandler();
SecurityManager originalSecurityManager =
System.getSecurityManager
();
try {
System.setSecurityManager(new MockFileSecurityManager());
handler.publish(new LogRecord(Level.SEVERE, msg));
// SecurityException is thrown here
handler.close();
} finally {
System.setSecurityManager(originalSecurityManager);
}
}
public static class MockFileSecurityManager extends
SecurityManager
{
public void checkPermission(Permission perm) {
if (perm instanceof FilePermission) {
System.out.println(check + perm.getName());
throw new SecurityException();
}
}
}
FileHandler.close() spec says Throws: SecurityException - if a
security
manager exists and if the caller does not have
LoggingPermission(control)., In the code above, control
permission
is
allowed. The failure stack trace against RI looks like:
java.lang.SecurityException
at com.andrew.LoggingTest$MockFileSecurityManager.checkPermission(
LoggingTest.java:131)
at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
at java.io.File.exists(File.java:700)
at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:401)
at java.io.File.getCanonicalPath(File.java:531)
at java.io.FilePermission$1.run(FilePermission.java:218)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.FilePermission.init(FilePermission.java:212)
at java.io.FilePermission.init(FilePermission.java:264)
at java.lang.SecurityManager.checkDelete(SecurityManager.java:990)
at java.io.File.delete(File.java:869)
at java.util.logging.FileHandler.close(FileHandler.java:594)
at com.andrew.LoggingTest.test_FileHandler(LoggingTest.java:121)
...
The output is check C:\Documents and
Settings\myaccount\java0.log.lck
It seems RI tries to delete log file.lck file, but has no
permission.
.lck file is never mentioned in spec, and should be implementation
detail.
Current Harmony code never tries to lock a temp empty .lck file, so
the
test
passes against Harmony.
If I understoond correctly, new FileHandler() creates temporary
file for
logging (its name is defined by default configuration properties).
That
is
true for Harmony and RI. Right?
Stepan, you missed something here. :)
Both Harmony and RI creates a file (not temporary) for logging, and RI
created one more file(temporary) for locking.
RI tries to delete the temporary .lck file when fileHandler.close() is
invoked. Harmony has nothing to be deleted. :)
IOW, Harmony uses different locking approach for log-files and the test
above demonstrate side-effect of different approaches. Right?
IMO, this test show RI's locking mechanism has side-effect(needs more
file permissions), while Harmony's is more clean.
IMO, we should add a note to the documentation: why we chose different
locking approach.
Agree, documentation is useful here. Actually I'm a little confused why
RI chose its current locking approach, IIRC, why the file needs to be
locked is due to the spec[1], and IMO the spec hints the lock of logging
file needs to be detected and held.
[1] However, if the FileHandler tries to open the filename and finds
the file is currently in use by another process it will increment the
unique number field and try again.
Thanks,
Stepan.
RI tries to delete the created file if FileHandler.close() is
invoked. And
Harmony doesn't. Why?
Thanks,
Stepan.
If we revise the MockSecurityManager a little, to allow .lck file
permission,
public void checkPermission(Permission perm) {
if (perm instanceof FilePermission) {
if (perm.getName().indexOf(.lck) == -1) {
System.out.println(check + perm.getName());
throw new SecurityException();
}
}
}
The test will pass both against RI and Harmony.
So I'd suggest to leave it as non-bug difference from RI.
Any comments? Thank you!
--
Andrew Zhang
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
Re: [jira] Created: (HARMONY-1295) [classlib][net] flaw in setReuseAddrAndReusePort()
Jimmy, Jing Lv wrote: Andrew Zhang wrote: On 8/29/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/8/29, Andrew Zhang [EMAIL PROTECTED]: On 8/28/06, Alexey Varlamov (JIRA) [EMAIL PROTECTED] wrote: [classlib][net] flaw in setReuseAddrAndReusePort() -- Key: HARMONY-1295 URL: http://issues.apache.org/jira/browse/HARMONY-1295 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey Varlamov Priority: Critical The tests.api.java.net.DatagramSocketTest test crashes on assert in DRLVM : Assertion `IsInstanceOf(env, obj, struct_Class_to_jclass(f-get_class()))' failed. The reason is that java.net.DatagramSocket.setReuseAddress(boolean) calls to PlainDatagramSocketImpl.setOption(int optID, Object val) with Boolean value, but underlying native code treats this value as Integer. Quickfix must be straightforward enough, but I inclined to blame the design of INetworkSystem.[set|get]SocketOption() as the actual root of the evil. The problem is that this API conceals the details of contract for particular options, and a client have to guess which type of value to pass. I think it's determine, not guess. :) And the implementation is basically an ugly switch sorting requests out to setBoolSocketOption() or setIntegerSocketOption(), etc. Shouldn'te refactor this? Any proposals? Thanks! Of course, lots of them ;). Just to start: 1) Why at all we clone underlying OS interface to Java with extra mapping JAVASOCKOPT_* to HY_SO_*? Totally agree with you. :) Current two option lists are duplicated. I think we'd better use one type defination. Let's have a clean API with specialized methods as XXXSocket classes have: setTTL(int) , isReuseAddress() etc. It's a design problem. The legacy design provides simple unified interface to classlib, while your proposal seems more specific and direct for classlib API usage. 2) At least we could provide more typified [s|g]etOption() methods, which take/return primitive values instead of wrappers. At first glance int and boolean would fit all needs, am I wrong? This way, type mismatch will be found immediately during compilation. Though this would not detect optid and value type disparity... Agree. For this case, at least, we could use booleanValue for Boolean and intValue for Integer. :) Interesting, deep look into code, I find JNI use pointer as the field ID, so field-ID of value in Boolean is the same as the one of Integer. In this way the code can get a value field of Integer out of a Boolean (C pointer is great! :) ). IMO, this is a mis-use but cause no error until a strict check is taken. :) This is a bug of native code, I agree we should use booleanValue instead of intValue, may we raise a JIRA and fix? Just go ahead and provide a patch for HARMONY-1295 to get this error fixed, and go on discussing the design issue, I agree that there are some things better to be improved. -- Regards, Alexey - 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][luni] A problem about behavior of EnumMap
Spark Shen wrote:
Hi All:
When I develop EnumMap,I find EnumMap strange on RI. As the following
code describes, the method entrySet() of EnumMap returns a set view of
mappings contained in this map. Then we get the set's iterator and use
the iterator's next() method to get an Entry which contains one
mapping. But if we use next() method again to get another Entry, the
previous Entry will also point to the next Entry.
import java.util.EnumMap;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;
import junit.framework.TestCase;
public class EnumMapTest extends TestCase{
enum Size {
Small, Middle, Big {
};
}
public void test_entrySet() {
EnumMap enumSizeMap = new EnumMap(Size.class);
enumSizeMap.put(Size.Middle, 1);
enumSizeMap.put(Size.Big, null);
Set set = enumSizeMap.entrySet();
Iterator iter = set.iterator();
Map.Entry entry = (Map.Entry) iter.next();
assertEquals(Size.Middle, entry.getKey());
Map.Entry entry1 = (Map.Entry) iter.next();
assertEquals(Size.Big, entry.getKey());
assertSame(entry,entry1);
}
}
I guess on RI, the returned iterator maintains a reference to current
entry and returns this reference in iter.next() method.
I do not think RI's behavior makes sense here. So I suggest not to
follow RI on the behavior.
+1 from me.
Best regards
--
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][luni] A problem about behavior of EnumMap
Spark Shen wrote:
Spark Shen 写道:
I guess on RI, the returned iterator maintains a reference to current
entry and returns this reference in iter.next() method.
I do not think RI's behavior makes sense here. So I suggest not to
follow RI on the behavior.
I want to adopt the behavior described below because it seems more
reasonable.
The previous Entry should not point to the next Entry when the
iterator's next() is invoked. And then the methods of the Class Entry,
such as getKey(), getValue() ,setValue() etc,
will act on the different objects.
Based on my implement,I expect the following test cases pass on
Harmony.(Some of them will fail on RI.)
enum Size {
Small, Middle, Big {
};
}
public void test_entrySet() {
EnumMap enumSizeMap = new EnumMap(Size.class);
enumSizeMap.put(Size.Middle, 1);
enumSizeMap.put(Size.Big, null);
Set set = enumSizeMap.entrySet();
Iterator iter = set.iterator();
Map.Entry entry1 = (Map.Entry) iter.next();
Map.Entry entry2 = (Map.Entry) iter.next();
assertEquals(Size.Middle, entry1.getKey());
assertEquals(1, entry1.getValue());
enumSizeMap.remove(Size.Middle);
try {
entry1.setValue(0);
fail(Should throw IllegalStateException); //$NON-NLS-1$
} catch (IllegalStateException e) {
// Expected
}
assertEquals(1, set.size());
entry2.setValue(2);
assertEquals(Size.Big, entry2.getKey());
assertEquals(2, entry2.getValue());
}
Sounds reasonable, what's RI's behavior on the entries
getKey()/getValue()/setValue() then (i.e., which asserts fails on RI)?
Best regards
--
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]
[classlib][logging]yet another non-bug difference with RI(Re: [jira] Created: (HARMONY-1300) [classlib][logging] XMLFormatter.format returns a String contains message/ while RI doesn't when log m
From the DTD for j.u.logging.XMLFormatter[1], message is required by
record, so I consider this is RI's bug, and I suggest to follow spec in
this case, because it is hard to believe this difference with RI will
make application fail, while there is possibilities for some
applications to validate logging record using the DTD, it may fail on
RI. If no one objects, I will mark this issue as non-bug difference
with RI.
[1]
...
!-- Each logging call is described by a record element. --
!ELEMENT record (date, millis, sequence, logger?, level,class?,
method?, thread?, message, key?, catalog?, param*, exception?)
...
Andrew Zhang (JIRA) wrote:
[classlib][logging] XMLFormatter.format returns a String contains message/ while RI doesn't when log message and pattern is null.
---
Key: HARMONY-1300
URL: http://issues.apache.org/jira/browse/HARMONY-1300
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Andrew Zhang
Following test reproduces the bug:
public void test_format() {
formatter = new XMLFormatter();
LogRecord lr = new LogRecord(Level.SEVERE, null);
String output = formatter.format(lr);
assertFalse(output.indexOf(message) 0);
}
The test passes against RI while fails against Harmony.
I'll upload a patch to fix this problem soon.
Best regards,
Andrew
--
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] support for multiple VMs?
Oliver Deakin wrote: Hi Alexey, I have taken a look at the patch - generally it looks good to me, and if it all works ok when you test it, it's fine by me. I think if there are cases where some functionality is repeated many times, it would be good to see it split out somewhere central. However, Im not sure the port library is the right place for these functions - the port library is really a generic front hiding platform specific operations. These functions do not really fit into that category - perhaps they would be better placed in the common library (luni/src/main/native/common)? This component provides a set of helper functions required by many native modules, and seems like the right place to put them. Agree, portlib is designed to encapsulate OS/architecture difference, and it should be taken care to be concise, so that it can be ported easily to as many platforms as possible(at least to those Harmony planned to support), it is not a common library. Regards, Oliver Alexey Varlamov wrote: Oliver, Please take a look at a HARMONY-1243 patch. I fixed all bugs noticed and made parsing a bit more robust. Also, added a define for org.apache.harmony.boot.class.path name to vmi.h - to enforce that there is 2-sided contract for this property. I still think that some of those functions may worth to be added to the portlib, namely: char * str_concat (HyPortLibrary * portLibrary, ...); int props_read_from_file(HyPortLibrary * portLibrary, const char *filename, key_value_pair** properties, U_32 *number); void props_free(HyPortLibrary * portLibrary, key_value_pair * properties); Justification: the same functionality is duplicated at least in launcher/shared/main.c, and there are other property files to be read by VM. If nobody object, I will try to add these 3 functions to portlib. -- 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: [vm] ArgoUML application crashes IBM VME
Vladimir Gorr wrote: Yes, it makes sense, I think. Although I don't know what the right place is? there is a section named what can it do[1], and it would be very useful to add a new page for Argo on the test procedure/result/missing class etc, and add the link to that section. [1] http://wiki.apache.org/harmony/ClassLibrary Thanks, Vladimir. Regards, -- 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: [build-test] Re: Build-Test regular expression matcher pb
Jean, Sorry for response so late, do you still get this error? I use Sun JVM 1.5.0_06 and ant 1.6.5 on WinXP SP2, I think this env should be similar with you, but I cannot reproduce it. If you still cannot get it work, would you please raise a JIRA? Jean-frederic Clere wrote: Geir Magnusson Jr. wrote: Jean-frederic Clere wrote: Geir Magnusson Jr. wrote: (can you please prefix the subject line with something like [build-test] in the future :)) What JRE are you using? Sun JVM 1.5.0_06. Cheers Jean-Frederic And you simply checked it out, followed the directions, and it didn't work? Yes ;-( What version of ant? 1.6.5 Cheers Jean-Frederic 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] -- 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]
