Re: [drlvm] fyi -- what to try if "build.bat update...." is not working
On 5/15/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: FYI -- If you get "connection timed out" errors when trying to run "build.bat update...", it could be because http.proxyhost and http.proxyPort are not set correctly. Proxy settings can be set as follows: build.bat -Dhttp.proxyHost=your_proxy_host -Dhttp.proxyPort=your_proxy_port# update Proxy port & host most likely will be available in a current web browser settings. Or, one can ask a system administrator to learn them. The alternative way to set proxy is to put the lines: http.proxyHost=your_proxy_host http.proxyPort=your_proxy_port# at build\make\*.properties files. Andrey Chernyshev Intel Middleware Products Division -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Supporting working on a single module?
That layout works for me too. Patches welcome ;-) Regards, Tim Oliver Deakin wrote: > Andrey Chernyshev wrote: >>> I was thinking that platform specific directories would be laid out >>> underneath each native >>> component directory. So, for example, underneath the >>> modules/luni/src/main/native/port >>> directory there would be the following structure (avoiding ascii tree >>> diagrams): >>> >>> modules/luni/src/main/native/port/shared >>> modules/luni/src/main/native/port/linux >>> modules/luni/src/main/native/port/windows >>> >>> with further platform specific directories being added as we expand. >> >> Yes, I was thinking about that too, but didn't mention :). >> I remember there was a discussion about this sometime in the past [1], >> it looked like most people agreed at that time that keeping OSes & >> platforms as the directory names is the preferred choice. >> > > Yes, I think you're right. At the moment the layout is quite simple > since we only have > two platforms. > > When we start to expand our platform list, I believe the layout that you > linked in [1] is > suitably descriptive and simple to use, with directory names > incorporating OS as the > first level of code specialization and architecture the second, > separated by an underscore. > I envisage that eventually we might have a layout similar to (hope this > diagram > works - all subdirs under are at the same level): > > modules//src/main/native// > > |--shared/ > > |--aix/ > > |--linux/ > > |--linux_amd/ > > |--linux_ppc/ > > |--linux_s390/ > > |--linux_x86/ > > |--solaris/ > > |--solaris_x86/ > > |--windows/ > > |--windows_amd/ > > |--windows_x86/ > > |--unix/ > > |--zos/ > > |--shared_include/ > > |--windows_include/ > > \--unix_include/ > > > Regards, > Oliver > > >> Thanks, >> Andrey. >> >> [1] >> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/[EMAIL >> PROTECTED] >> >> > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-211 : Contribution of java.rmi
Sure, I'll volunteer to check this one in. (If somebody else wants to do it just holler and I'll willingly give it up). Regards, Tim Geir Magnusson Jr wrote: > > 12 +1 votes, no others. > > Someone want to re-assign to themselves and bring this in? : > > Please make sure that the initial commit is *identical* to what was > contributed, and then do any tweaks, fixes, moves etc from there. > > geir > > Geir Magnusson Jr wrote: >> I have received the ACQs and the BCC for Harmony-211 in paper form and >> have reviewed them, so I can assert that the critical provenance >> paperwork is in order. It is not in SVN yet, but I wanted to get this >> vote going at the same time as the Intel contribution in the same >> area. I will get scanned and in SVN ASAP. >> >> This is the contribution from ITC. >> >> Please vote to accept or reject this codebase into the Apache Harmony >> class library : >> >> [ ] + 1 Accept >> [ ] -1 Reject (provide reason below >> >> Lets let this run 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] >> >> > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-256 : Contribution of DNS service provider for JNDI classlibrary code
I'll grab this and bring it in. Regards, Tim Geir Magnusson Jr wrote: > 9 +1 votes, no others. > > Someone want to re-assign to themselves and bring this in? :) > > Please make sure that the initial commit is *identical* to what was > contributed, and then do any tweaks, fixes, moves etc from there. > > geir > > Geir Magnusson Jr wrote: >> I have received the ACQs and the BCC for Harmony-256, so I can assert >> that the critical provenance paperwork is in order and in SVN. >> >> Please vote to accept or reject this codebase into the Apache Harmony >> class library : >> >> [ ] + 1 Accept >> [ ] -1 Reject (provide reason below >> >> Lets let this run 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] >> >> > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] 2nd Annual HarmonyOne Event
eventhough I cant come~ ( US visa making us back )... chears to Harmony!!! The 1st and the only open source Java way to go guys Thanks alot!!! because of you all !!! Open source Java live Long live Java! Long live Harmony! Ivan from Malaysia On 5/16/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Come pre-celebrate the upcoming 1st Birthday of the Apache Harmony project at What : The 2nd Annual HarmonyOne Event When : Tueday, May 16th, 2006, 6pm-8pm Where : The Thirsty Bear 'Restaurant' 661 Howard St. San Francisco, CA 415-974-0905 There's some other event going on in the area (JavaSomething?) at the same time, so it may be crowded. :) Come meet each other, drink beer, and socialize... We did this last year. There were 4 of us at the table. We've come pretty far since then - we have a lot to be proud of. There will be lots of interesting people around, so it's well worth the trip. (I thought about doing this on thursday, but the Harmony BOF is then, and as May 18th is Harmony's birthday, we'll probably celebrate then too. I hope no one minds...) - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
Ivan, Good progress. Again, it would be helpful for planning if you could tell us what you would like to work on and how much time you can spend on it. Currently I am in the process of figuring out how to "borrow" a bunch of the DRLVM native methods for gnuclasspathadapter. It would be great if you can help. It may be as simple as 1) build drlvm, 2) copy DLLs to gnuclasspathadapter directory. Can you post your mods as a zip file to JIRA? On 5/15/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote: I've just wanted to check the problem with incorrect interfaces and... Looks like I suddenly made a good progress: === _200_check Finished in 0.012 secs **NOT VALID** === _209_db Finished in 43.748 secs **NOT VALID** === _222_mpegaudio Finished in 97.589 secs **NOT VALID** === _201_compress Finished in 106.233 secs **NOT VALID** As you can see I managed to run some of specjvm98 tests. :) There are a lot of validity errors, but its finally passed to the end. Changes done: Fixed Class.newInstance(), Constructor.newInstance() Fixed stack trace display in Throwable Implemented Runtime.getRuntime() What a wonderful thing is stack traces! :) -- Ivan 2006/5/16, Ivan Volosyuk <[EMAIL PROTECTED]>: > Weldon, > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
I've just wanted to check the problem with incorrect interfaces and... Looks like I suddenly made a good progress: === _200_check Finished in 0.012 secs **NOT VALID** === _209_db Finished in 43.748 secs **NOT VALID** === _222_mpegaudio Finished in 97.589 secs **NOT VALID** === _201_compress Finished in 106.233 secs **NOT VALID** As you can see I managed to run some of specjvm98 tests. :) There are a lot of validity errors, but its finally passed to the end. Changes done: Fixed Class.newInstance(), Constructor.newInstance() Fixed stack trace display in Throwable Implemented Runtime.getRuntime() What a wonderful thing is stack traces! :) -- Ivan 2006/5/16, Ivan Volosyuk <[EMAIL PROTECTED]>: Weldon, - 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] Layout of tests in crypto module
Hi Mikhail, I have a couple of minor comments about your proposal for a test layouts. I should have responded sooner, I know, but I have suffered from a number of hardware problems in the past few weeks that slowed things down somewhat for me. Anyway, it's all great but it would be nice to get answers to the following ... 1) The section on "Location of the tests in the directory tree" proposes /src/tests/impl for Harmony specific tests and /src/tests/api for implementation-independent tests. Where would tests go for Harmony API's that are not part of the J2SE spec but are still accessible ? Strictly speaking they are API as well as being specific to Harmony. What about the location of tests designed to run on the classpath and tests designed to run on the bootclasspath ? That does not seem to be addressed in this section. When the tests are run how are the "bootclasspath" and "classpath" tests distinguished ? Purely on package name ? Did you ever see the append I wrote to the list a couple of weeks ago on this topic ? [1] 2) Still in the "Location of the tests in the directory tree" section, shouldn't the suggested source folder names include "java" in there ? e.g. /src/tests/java/api ? What is wrong with the src/test/java (below here is Java code), src/test/resources (below here is non-code test artefacts) convention ? I notice that at present the page does not include any mention of where test resources would go. 3) What does the sentence "Tests are not separated by functionality under test, e.g. tests against clone() methods are not separated from tests against equals() methods" actually mean ? Best regards, George [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/[EMAIL PROTECTED] Mikhail Loenko wrote: Hello I would like to make some changes in the crypto module: - Separate implemetation-independent tests from implementation specific ones. - Fix layout according to the proposed scheme [1] Please let me know if you do any changes in that module then I'll delay restruct. Thanks, Mikhail [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [REMINDER] Harmony Talk at Java One - Thursday, May 18 - North Meeting Room 1:30 PM
I'll have to talk to Tim (it's a joint effort), but I figure we'll have no problem once they are done and we present them first :) geir Gregory Shimansky wrote: On Monday 15 May 2006 20:31 Geir Magnusson Jr wrote: Come hear Tim and I give a talk together about Harmony. The slides look great (thanks Tim!) and it's going to be exciting to be able to demo everything we've done in the last year. (Look ma! Working code!) https://www28.cplan.com/javaone06_cv_124_1/session_details.jsp?isid=277752&; ilocation_id=124-1&ilanguage=english Hello Geir I won't visit Java One (it's too far to travel from Moscow) so I decided to at least take a look at the slides and the link has none. Is there any place where I can find them online? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [REMINDER] Harmony Talk at Java One - Thursday, May 18 - North Meeting Room 1:30 PM
On Monday 15 May 2006 20:31 Geir Magnusson Jr wrote: > Come hear Tim and I give a talk together about Harmony. > > The slides look great (thanks Tim!) and it's going to be exciting to be > able to demo everything we've done in the last year. (Look ma! Working > code!) > > https://www28.cplan.com/javaone06_cv_124_1/session_details.jsp?isid=277752&; >ilocation_id=124-1&ilanguage=english Hello Geir I won't visit Java One (it's too far to travel from Moscow) so I decided to at least take a look at the slides and the link has none. Is there any place where I can find them online? -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
Neither, probably :) Chris Gray wrote: BTW is spec98jvm open-source these days, or is it still "send 50 bucks to this address and we will send you a floppy disk which only installs on windoze"? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
BTW is spec98jvm open-source these days, or is it still "send 50 bucks to this address and we will send you a floppy disk which only installs on windoze"? -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
Weldon, 2006/5/15, Weldon Washburn <[EMAIL PROTECTED]>: Ivan, It is great you are spending time on gnuclasspathadapter. As you have discovered, there is a lot of work remaining to be done. It would be really good if you can document the problems you had in when following my directions. Here is issues I've found: * There was no build instructions. I assumed that I should place the adapter separately, as it have 'doit.bat' kind of build files. * No build files for linux. * Changes to harmony tree happened so I need to fix some imports in patched java-files. * Java files has hardcoded absolute path for glue native library. * Loading of native libraries is disabled via "Runtime.load()", I used LD_PRELOAD and modified jchevm to search libraries via dlsym(RTLD_DEFAULT, ""). * For specjvm98 made number of stubs for java.awt.* classes. * Java_?_writeImpl() uses libvmi.so functionality which not implemented in classlib stub. Need to write my own implementation. * NewWeakGlobalRef used by nio. Changed jchevm to fallback to NewGlobalRef instead of crash. * Functionality from HyVMLSFunctionTable is used. Workaround: comment out java.io.File.oneTimeInitialization(). This was already done by you, but somehow I've lost the change when merging. * Problem with incorrect class interfaces looks like introduced by my quick replacement of awt classes. Going to investigate it. How much time will you be able to work on gnuclasspathadapter? It would be good to know so that we can figure out how to split the project efficiently. I am not planing to do much work on it. May be I'll spent some time in weekend. I gave up on specJVM98 for now because JCHEVM/SableVM eagerly resolves classes. It keeps trying to pull in a bunch of specJVM98 AWT classes. I tried hacking awt out of specJVM98 source code but it got way too convoluted. My current plan is to try to get Mauve's gnu/testlet/java/io/File test to run. I hope to post mods to the native methods that are needed to support gnu/testlet/java/io/File fairly soon. On 5/14/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote: > Sure, if I have some outstanding results I'll share it. As for now... > > It was quite challenging to run "hello world" using glue layer from Harmony-318. > Some changes was made to the classes layout, patched classes are a bit outdated. > I didn't found libvmi.so for jchevm, so I've taken modified version from drlvm. > There is no documentation about HyVMLSFunctionTable functions used by I was also thinking of stealing pieces of DRLVM. I started this project before DRLVM had been donated. Thus there were no pieces to steal. But now things have changed. Thus time to reassess how to move forward. > harmony classlib, and it is used quite strange way. Helpfully, Weldon > has commented out its usage. Interesting. Do you really mean, "helpfully"? Perhaps you mean, "hopefully"?? That's right. -- Regards, Ivan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-199 : Contribution of javax.crypto and java.math
Mark Hindess wrote: On 15 May 2006 at 13:13, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Are you kidding? Well, it was just a question. The "Personally ..." statement was just my opinion based on my (naive) assumptions about the voting process. :) I guess I'm just a pedant who likes to understand these thing, even when they don't matter, so there are no misunderstandings, when it does matter - if it was a deciding vote, for example. True. BTW, what you said about "no matter who posts it" was 100% right on. That said, if we're in a position where there's a single tiebreaker vote, in most cases where we'd be voting, IMO we have a problem. (I don't like contentious votes.. they aren't fun, and I'm doing this because it's fun...) IMO, any vote that makes it in before the votes are counted should count. The point of the 3 day (or n-day) time limit is to establish the minimum amount of time (or give someone a chance to offer an alternative) so that no one will be surprised. Fair enough. I'm interested in other opinions, though... Me too. Which is why I asked. Thanks for the explanation. Lets see what others say... I don't mind the slop in that direction because it lets people get their vote in if they accidentally forgot (like I did...) OTOH, if people feel strongly and want to adopt a mode where we have a listed expiration date/time, I'm happy for that too... I can usually follow directions :) geir -Mark. Mark Hindess wrote: On 15 May 2006 at 6:19, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: 10 +1 votes, no others. Excellent ... but ... The vote was supposed to run for 3 days. Should a vote submitted (long) after this time has elapsed still be counted? Personally, I don't think it should - no matter who posts it. ;-) Regards, Mark. Someone want to re-assign to themselves and bring this in? Please make sure that the initial commit is *identical* to what was contributed, and then do any tweaks, fixes, moves etc from there. geir Geir Magnusson Jr wrote: I have received the ACQs and the BCC for Harmony-199 in paper form and have reviewed them, so I can assert that the critical provenance paperwork is in order. It is not in SVN yet, but I wanted to get this vote going at the same time as the other contributions from ITC. I will get scanned and in SVN ASAP. This is the contribution from ITC. This is just a vote to accept or reject the codebase. What we do with the codebase - what parts and how we integrate - is up for discussion on the -dev list. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below Lets let this run 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-199 : Contribution of javax.crypto and java.math
On 15 May 2006 at 13:13, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > Are you kidding? Well, it was just a question. The "Personally ..." statement was just my opinion based on my (naive) assumptions about the voting process. I guess I'm just a pedant who likes to understand these thing, even when they don't matter, so there are no misunderstandings, when it does matter - if it was a deciding vote, for example. > IMO, any vote that makes it in before the votes are counted should > count. The point of the 3 day (or n-day) time limit is to establish > the minimum amount of time (or give someone a chance to offer an > alternative) so that no one will be surprised. Fair enough. > I'm interested in other opinions, though... Me too. Which is why I asked. Thanks for the explanation. -Mark. > Mark Hindess wrote: > > On 15 May 2006 at 6:19, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > >> 10 +1 votes, no others. > > > > Excellent ... but ... > > > > The vote was supposed to run for 3 days. Should a vote submitted (long) > > after this time has elapsed still be counted? Personally, I don't think > > it should - no matter who posts it. ;-) > > > > Regards, > > Mark. > > > >> Someone want to re-assign to themselves and bring this in? > >> > >> Please make sure that the initial commit is *identical* to what was > >> contributed, and then do any tweaks, fixes, moves etc from there. > >> > >> geir > >> > >> > >> Geir Magnusson Jr wrote: > >>> I have received the ACQs and the BCC for Harmony-199 in paper form and > >>> have reviewed them, so I can assert that the critical provenance > >>> paperwork is in order. It is not in SVN yet, but I wanted to get this > >>> vote going at the same time as the other contributions from ITC. > >>> I will get scanned and in SVN ASAP. > >>> > >>> This is the contribution from ITC. This is just a vote to accept or > >>> reject the codebase. What we do with the codebase - what parts and how > >>> we integrate - is up for discussion on the -dev list. > >>> > >>> Please vote to accept or reject this codebase into the Apache Harmony > >>> class library : > >>> > >>> [ ] + 1 Accept > >>> [ ] -1 Reject (provide reason below > >>> > >>> Lets let this run 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] > >>> > >>> > >> - > >> 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]
[drlvm] fyi -- what to try if "build.bat update...." is not working
FYI -- If you get "connection timed out" errors when trying to run "build.bat update...", it could be because http.proxyhost and http.proxyPort are not set correctly. -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-199 : Contribution of javax.crypto and java.math
Are you kidding? IMO, any vote that makes it in before the votes are counted should count. The point of the 3 day (or n-day) time limit is to establish the minimum amount of time (or give someone a chance to offer an alternative) so that no one will be surprised. I'm interested in other opinions, though... geir Mark Hindess wrote: On 15 May 2006 at 6:19, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: 10 +1 votes, no others. Excellent ... but ... The vote was supposed to run for 3 days. Should a vote submitted (long) after this time has elapsed still be counted? Personally, I don't think it should - no matter who posts it. ;-) Regards, Mark. Someone want to re-assign to themselves and bring this in? Please make sure that the initial commit is *identical* to what was contributed, and then do any tweaks, fixes, moves etc from there. geir Geir Magnusson Jr wrote: I have received the ACQs and the BCC for Harmony-199 in paper form and have reviewed them, so I can assert that the critical provenance paperwork is in order. It is not in SVN yet, but I wanted to get this vote going at the same time as the other contributions from ITC. I will get scanned and in SVN ASAP. This is the contribution from ITC. This is just a vote to accept or reject the codebase. What we do with the codebase - what parts and how we integrate - is up for discussion on the -dev list. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below Lets let this run 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] - 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]
[REMINDER] Harmony Talk at Java One - Thursday, May 18 - North Meeting Room 1:30 PM
Come hear Tim and I give a talk together about Harmony. The slides look great (thanks Tim!) and it's going to be exciting to be able to demo everything we've done in the last year. (Look ma! Working code!) https://www28.cplan.com/javaone06_cv_124_1/session_details.jsp?isid=277752&ilocation_id=124-1&ilanguage=english geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[announce] 2nd Annual HarmonyOne Event
Come pre-celebrate the upcoming 1st Birthday of the Apache Harmony project at What : The 2nd Annual HarmonyOne Event When : Tueday, May 16th, 2006, 6pm-8pm Where : The Thirsty Bear 'Restaurant' 661 Howard St. San Francisco, CA 415-974-0905 There's some other event going on in the area (JavaSomething?) at the same time, so it may be crowded. :) Come meet each other, drink beer, and socialize... We did this last year. There were 4 of us at the table. We've come pretty far since then - we have a lot to be proud of. There will be lots of interesting people around, so it's well worth the trip. (I thought about doing this on thursday, but the Harmony BOF is then, and as May 18th is Harmony's birthday, we'll probably celebrate then too. I hope no one minds...) - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-337 : Contribution of RMI framework
Hi Geir, I'll take it. Best regards, George Geir Magnusson Jr wrote: 9 +1 votes, no others. Someone want to re-assign to themselves and bring this in? Please make sure that the initial commit is *identical* to what was contributed, and then do any tweaks, fixes, moves etc from there. geir Geir Magnusson Jr wrote: I have received the ACQs and the BCC for Harmony-337, so I can assert that the critical provenance paperwork is in order and in SVN. This is the contribution from Intel. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below Lets let this run 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-199 : Contribution of javax.crypto and java.math
On 15 May 2006 at 6:19, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > 10 +1 votes, no others. Excellent ... but ... The vote was supposed to run for 3 days. Should a vote submitted (long) after this time has elapsed still be counted? Personally, I don't think it should - no matter who posts it. ;-) Regards, Mark. > Someone want to re-assign to themselves and bring this in? > > Please make sure that the initial commit is *identical* to what was > contributed, and then do any tweaks, fixes, moves etc from there. > > geir > > > Geir Magnusson Jr wrote: > > I have received the ACQs and the BCC for Harmony-199 in paper form and > > have reviewed them, so I can assert that the critical provenance > > paperwork is in order. It is not in SVN yet, but I wanted to get this > > vote going at the same time as the other contributions from ITC. > > I will get scanned and in SVN ASAP. > > > > This is the contribution from ITC. This is just a vote to accept or > > reject the codebase. What we do with the codebase - what parts and how > > we integrate - is up for discussion on the -dev list. > > > > Please vote to accept or reject this codebase into the Apache Harmony > > class library : > > > > [ ] + 1 Accept > > [ ] -1 Reject (provide reason below > > > > Lets let this run 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] > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-199 : Contribution of javax.crypto and java.math
Hi Geir, I'll take it. Best regards, George Geir Magnusson Jr wrote: 10 +1 votes, no others. Someone want to re-assign to themselves and bring this in? Please make sure that the initial commit is *identical* to what was contributed, and then do any tweaks, fixes, moves etc from there. geir Geir Magnusson Jr wrote: I have received the ACQs and the BCC for Harmony-199 in paper form and have reviewed them, so I can assert that the critical provenance paperwork is in order. It is not in SVN yet, but I wanted to get this vote going at the same time as the other contributions from ITC. I will get scanned and in SVN ASAP. This is the contribution from ITC. This is just a vote to accept or reject the codebase. What we do with the codebase - what parts and how we integrate - is up for discussion on the -dev list. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below Lets let this run 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] HARMONY vs. J2SE API source, binary compatibility: JAPI for 1.5 required
Thanks Leo for your input. It forces me to think about some aspects of compatibility again. On 5/6/06, Leo Simons <[EMAIL PROTECTED]> wrote: On Sat, May 06, 2006 at 12:33:52PM +0700, Vladimir Ivanov wrote: > Recently I thought about guaranteeing binary and source compatibility > between HARMONY API and other compatible J2SE API implementations, what is > our goal and how to check it, automation. Let me share my thoughts - for us > to understand clearly what we want and how to test it. Thanks, vladimir, very clear! === Some observations === > > Observation #1: I think, in general, binary compatibility is a weaker > requirement then source compatibility and is completely covered by source > compatibility. Hmm. For the "general" form of "general", this is not true, which stems from the use of preprocessors and non-deterministic transformations with which the non-java world is full. Eg when you do C development and change the definition of how big an int is, you lose binary compatibility but preserve source compatibility if this definition is inherited. In the specific, you might very well be very right here, which is quite interesting...how'd you come to these observations? Can I read more about them elsewhere? This observation based on another observation that compiler does linking (name resolution) in the same way as runtime (seems, for your example with C language it will not break linking, i.e. binary compatibility in terms of JLS). Of cause, if the compiler does not start linker or rules for compilation and runtime are different it will not work, but I know only some primitive assemblers that violate these rules. Sorry, I can't refer to articles just because I don't know any one related to source compatibility 'in general'. My observation based on the experience only. > Observation #2: I think, talking about 1.4, checking of 2-way binary > compatibility + throws clause + inheritance hierarchy will guarantee 2-way > source compatibility. I did not find any contra examples. + serialized form I can imagine naughty/hacky code that uses reflection would be able to violate that rule too. The AOP toolkits are a good example of pushing the limits, eg aspectwerkz @ codehaus.org. The JVMS defines for java runtime that linking includes verification, preparation and resolution. Conformat compiler generates valid code. The preparation phase is memory allocation + check for AbstractMethodError. The resolution phase include checks for IllegalAccessError, InstantiationError, NoSuchFieldError and NoSuchMethodError. But compiler does all these 5 checks so source compatibility include binary (for java). Correct serialized form is not required for source/ binary compatibility (it is not affect linking/ compilation), so harmony target may be extended to "2-way-source compatibility and 2-way-serialized form compatibility". As for reflection, seems, the linker does the same checks as compiler (elements are mirrored to the wrappers like java.lang.reflect.Method and both checks types of wrappers only). It will be very useful If your provide code example to think how it can be eliminated. === What is our (Harmony) goal? === > > In terms of these definitions, ideally, I suppose we want that Harmony is > 2-way source compatible with the conformant J2SE API implementation (RI API) > to make sure that any application compiled with RI API can be compiled with > Harmony and vice versa yep, 2-way-source compatible and 2-way-binary compatible. Agree. 2-way-source compatible and 2-way-serialized form compatible === Questions === > 2. What more checks should be added to JAPI to guarantee 2-way source > compatibility for 1.5? You know, I can't even think of a good way to do implement the checks for the generics, let alone think of more! Seems, it can be done for case with generic because all needed information stored to the class file. For example, additional checks for source compatibility may be implemented to convert information from the class file 'Signature' attribute to the textual representation of method's signature (with parameters rename for generic names). If we all agree that our target is "2-way source compatible and 2-way-serialized form compatible" it would be good to define the complete list of checks and, for example, extend JAPI by implementing all these checks to make complete 2 way source compatibility (with RI) testing tool. Thanks, Vladimir Ivanov cheers! Leo - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Supporting working on a single module?
Andrey Chernyshev wrote: I was thinking that platform specific directories would be laid out underneath each native component directory. So, for example, underneath the modules/luni/src/main/native/port directory there would be the following structure (avoiding ascii tree diagrams): modules/luni/src/main/native/port/shared modules/luni/src/main/native/port/linux modules/luni/src/main/native/port/windows with further platform specific directories being added as we expand. Yes, I was thinking about that too, but didn't mention :). I remember there was a discussion about this sometime in the past [1], it looked like most people agreed at that time that keeping OSes & platforms as the directory names is the preferred choice. Yes, I think you're right. At the moment the layout is quite simple since we only have two platforms. When we start to expand our platform list, I believe the layout that you linked in [1] is suitably descriptive and simple to use, with directory names incorporating OS as the first level of code specialization and architecture the second, separated by an underscore. I envisage that eventually we might have a layout similar to (hope this diagram works - all subdirs under are at the same level): modules//src/main/native// |--shared/ |--aix/ |--linux/ |--linux_amd/ |--linux_ppc/ |--linux_s390/ |--linux_x86/ |--solaris/ |--solaris_x86/ |--windows/ |--windows_amd/ |--windows_x86/ |--unix/ |--zos/ |--shared_include/ |--windows_include/ \--unix_include/ Regards, Oliver Thanks, Andrey. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/[EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Supporting working on a single module?
Mark Hindess wrote: On 15 May 2006 at 16:14, "Andrey Chernyshev" <[EMAIL PROTECTED]> wrote: Hi Oliver, I think using "src/main" and "src/test" to group our implementation and test code was a convention we agreed on a while back. Personally I dont have any problem with it, but it's something we can look at again The current layout is just fine with me as well, in general. I just thought that, once a big movement over a filesystem starts, it could be a good chance to remove a few extra levels, in case we find them redundant. If we don't think they are redundant, then let them leave as they are. modules/text/src/main/native/text/ modules/text/src/main/native/unicode/ I think this agrees with what you were saying - please let me know if I've misunderstood! Actually I thought of having the BidiWrapper.c, for example, directly under the modules/text/src/main/native dir (if not considering various OSes and platforms at this time:)). Since we already have a 'text' directory once in the beginning of the path, it may probably look a bit excessive to repeat it once again at the end. >From the perspective of that single file/module, then what you say might be reasonable. But I think it would be nice to have consistency between modules so that we can share common functionality between build files. Agreed - I think we should keep a consistent layout of the source across modules. It also keeps the source directly in a directory that matches the name of the library it will be used to build. Regards, Mark. -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Supporting working on a single module?
I was thinking that platform specific directories would be laid out underneath each native component directory. So, for example, underneath the modules/luni/src/main/native/port directory there would be the following structure (avoiding ascii tree diagrams): modules/luni/src/main/native/port/shared modules/luni/src/main/native/port/linux modules/luni/src/main/native/port/windows with further platform specific directories being added as we expand. Yes, I was thinking about that too, but didn't mention :). I remember there was a discussion about this sometime in the past [1], it looked like most people agreed at that time that keeping OSes & platforms as the directory names is the preferred choice. Thanks, Andrey. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/[EMAIL PROTECTED] On 5/15/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: Tim Ellison wrote: > Andrey Chernyshev wrote: > > > >> (1) Do we need to keep the 'main' directory in every module? If we >> need to have a distinction between tests and sources, may be just pull >> tests one level up and have something like: >> archive/ >>src/ >> native/ >> java/ >> tests/ >> native/ >> java/ >> I wonder if 'main' is an extra level of the directory tree we can >> actually avoid of (lazy people don't like typing cd too much :)) >> > > Really lazy people use path completion and don't care ;-) > > >> (2) Why do we need to have 'luni' two times in the path, e.g. >> modules/luni/src/main/native/luni/ ? If we need to put an additional >> stuff like 'port' to the luni module, perhaps it could be just enough >> to put it into a subdirectory within native, e.g: >> modules/luni/src/native/port/ ? >> > > Is it just the name of that path element that you object to? Seems a > bit cleaner to me if there is a bucket to put that source in. > > However, (comment to Oliver as well), I'm left wondering where the > platform-specific vs. common code distinction is made? > I was thinking that platform specific directories would be laid out underneath each native component directory. So, for example, underneath the modules/luni/src/main/native/port directory there would be the following structure (avoiding ascii tree diagrams): modules/luni/src/main/native/port/shared modules/luni/src/main/native/port/linux modules/luni/src/main/native/port/windows with further platform specific directories being added as we expand. > >> BTW, I've noticed that this proposal is very similar to the DRLVM >> source tree organization, which is like: >> > > Great minds and all that :-) > > >> - vm >>- include - top level include which contains h files exported by >> various VM components; >>- interpreter >>- jitrino >>- vmcore >>... >> >> >> The module vmcore, for example, contains both native and java code: >> vmcore/src/kernel_classes >> - native >> - javasrc >> >> The building system for DRLVM has been designed in a modular way as well: >> There is a "building engine part at the build/make and >> build/make/targets directory which is shared by all components, >> Each VM module has a building descriptor which is currently located at >> build/make/components directory, but can also be easily moved to the >> component source tree to support the idea of full independent checkout >> of a specific module. >> >> I think the building system provided with DRLVM can easily be used to >> support the source modularization approach, the proposed 'hdk' in that >> case would provide the developers, besides the "public includes", with >> the shared part of the building scripts as well. >> > > We should continue to collaborate on finding the best solution -- it has > worked very well so far! > Agreed! > Regards, > Tim > > > -- Oliver Deakin IBM United Kingdom Limited - 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]
[Stress tests] generator review I
Alex,
Thanks for an interesting code.
>http://issues.apache.org/jira/secure/attachment/12331903/StressTestGene
rator.zip
Review of three classes follows. The issues are mostly minor with
exception to the time keeper usage - from my current vision it should be
more sophisticated.
With best regards,
Alexei Fedotov,
Intel Middleware Products Division
Test1.java:17
Package name should be org.apache.harmony.test.
ReliabilityRunner.java:25
The reason for duplication between command line parameters and
org.apache.harmony.test.ReliabilityTest.params property is given in
ReliabilityRunner.java:55. Reading this javadoc for the first time I was
confused. Probably we need just repeat that statement, or use @see
javadoc tag. BTW, javadoc was successfully generated by Eclipse.
ReliabilityRunner.java:29
The property format contains extra brackets and quotes.
ReliabilityRunner.java:29
The name of the property is inconsistent with the class name (either the
class or the property should be renamed).
ReliabilityRunner.java:41
We can remove testArgs array. Since we already reserved
org.apache.harmony.test.ReliabilityTest.params for the configuration, we
can set it using command line arguments and use it as a global storage.
In other words, the whole if statement form ReliabilityRunner.java:76
can be moved here.
ReliabilityRunner.java:59
runners.Threads is no longer in the project, probably generator.Thread
is meant
ReliabilityRunner.java:86
Reusing parametersAsString for the list of packages is confusing -
probably we need to delegate JIT optimizations like this and keep the
code understandable.
ReliabilityRunner.java:119
The problem is that deadlocked tests are counted as passed - probably we
need to signal generators that they should stop execution, and if they
fail to stop particular tests, then we need to abort VM with error
status. Aborting VM does not allow to run any more tests in this VM. The
use case is questionable but introduction of
apache.harmony.test.ReliabilityTest.params makes it possible. If we want
to consider this use case we need to try to abort a thread group first.
Loop.java:30
produceContext, performAll - can we invent better names? produce =
perform, All adds nothing. If we are to implement signaling model, here
we should check for signaling flag instead of looping unconditionally.
Here is an example of my understanding.
public void generate(ITest t) {
while (ReliabilityRunner.isActive()) {
t.test();
}
}
BTW, using this approach we can use IGenerator interface for generators
instead of a parent class. I like interfaces more even if they are
slower. :-) They are more flexible.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Supporting working on a single module?
On 15 May 2006 at 16:14, "Andrey Chernyshev" <[EMAIL PROTECTED]> wrote: > Hi Oliver, > > > I think using "src/main" and "src/test" to group our implementation > > and test code was a convention we agreed on a while back. Personally > > I dont have any problem with it, but it's something we can look at again > > The current layout is just fine with me as well, in general. I just > thought that, once a big movement over a filesystem starts, it could > be a good chance to remove a few extra levels, in case we find them > redundant. If we don't think they are redundant, then let them leave > as they are. > > > modules/text/src/main/native/text/ > > modules/text/src/main/native/unicode/ > > > > I think this agrees with what you were saying - please let me know if > > I've misunderstood! > > Actually I thought of having the BidiWrapper.c, for example, directly > under the modules/text/src/main/native dir (if not considering > various OSes and platforms at this time:)). Since we already have a > 'text' directory once in the beginning of the path, it may probably > look a bit excessive to repeat it once again at the end. >From the perspective of that single file/module, then what you say might be reasonable. But I think it would be nice to have consistency between modules so that we can share common functionality between build files. Regards, Mark. > Thanks, > Andrey. > > > On 5/15/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: > > Hi Andrey, > > > > > > Andrey Chernyshev wrote: > > > On 5/12/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: > > >> Geir Magnusson Jr wrote: > > >> > > > > >> > > >> >> > > >> >> To do this there are at least three steps needed, as far as I can > > >> see: > > >> >> > > >> >> 1) Refactor the native code into the modular structure we currently > > >> >> have for Java code and tests. This has been spoken about before at > > >> >> [1]. The native code would be located within each module at > > >> >> modules//src/main/native. As a starting point, can I > > >> >> propose that the natives be broken down in the following way: > > >> >> > > >> >> modules/archive/src/main/native/ > > >> >>|---archive/ > > >> >>|---zip/ > > >> >> > > >> >> +--zlib/ modules/auth/src/main/native/ > > >> >>+---auth/ > > >> >> > > >> >> modules/luni/src/main/native/ > > >> >>|common/ > > >> >>|fdlibm/ > > >> >>|launcher/ > > >> >>|luni/ > > >> >>|pool/ > > >> >>|port/ > > >> >>|sig/ > > >> >>|thread/ > > >> >>|vmi/ > > >> >>+---vmls/ > > >> >> > > >> >> modules/prefs/src/main/native/ > > >> >> +---prefs/ > > >> >> > > >> >> modules/text/src/main/native/ > > >> >>|---text/ > > >> >>+--unicode/ (comes from > > >> >> the icu4c zips stored currently in depends) > > >> > > > >> > W/o thinking too hard about it, this works for me just fine. > > >> > > >> Great - I am starting to look at how shared includes can be handled > > >> across modules (as Mark alluded to in his earlier post in this thread > > >> [1]), and at what changes will be required to split the natives into > > >> these locations. I will be taking this in small steps, trying to get t= > he > > >> foundation and "easy" parts done first, and raising a JIRA for each st= > ep > > >> rather than in one monolithic change. > > > > > > Great! I think splitting the sources by modules at the top level > > > directory is a good idea. > > > A few questions before the big source tree reorganization starts: > > > > > >> >> modules/archive/src/main/native/ > > >> >>|---archive/ > > >> >>|---zip/ > > > > > > (1) Do we need to keep the 'main' directory in every module? If we > > > need to have a distinction between tests and sources, may be just pull > > > tests one level up and have something like: > > > archive/ > > >src/ > > > native/ > > > java/ > > > tests/ > > > native/ > > > java/ > > > I wonder if 'main' is an extra level of the directory tree we can > > > actually avoid of (lazy people don't like typing cd too much :)) > > > > I think using "src/main" and "src/test" to group our implementation > > and test code was a convention we agreed on a while back
Re: Supporting working on a single module?
Hi Oliver, I think using "src/main" and "src/test" to group our implementation and test code was a convention we agreed on a while back. Personally I dont have any problem with it, but it's something we can look at again The current layout is just fine with me as well, in general. I just thought that, once a big movement over a filesystem starts, it could be a good chance to remove a few extra levels, in case we find them redundant. If we don't think they are redundant, then let them leave as they are. modules/text/src/main/native/text/ modules/text/src/main/native/unicode/ I think this agrees with what you were saying - please let me know if I've misunderstood! Actually I thought of having the BidiWrapper.c, for example, directly under the modules/text/src/main/native dir (if not considering various OSes and platforms at this time:)). Since we already have a 'text' directory once in the beginning of the path, it may probably look a bit excessive to repeat it once again at the end. Thanks, Andrey. On 5/15/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: Hi Andrey, Andrey Chernyshev wrote: > On 5/12/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: >> Geir Magnusson Jr wrote: >> >> >> >> >> >> To do this there are at least three steps needed, as far as I can >> see: >> >> >> >> 1) Refactor the native code into the modular structure we currently >> >> have for Java code and tests. This has been spoken about before at >> >> [1]. The native code would be located within each module at >> >> modules//src/main/native. As a starting point, can I >> >> propose that the natives be broken down in the following way: >> >> >> >> modules/archive/src/main/native/ >> >>|---archive/ >> >>|---zip/ >> >> >> >> +--zlib/ modules/auth/src/main/native/ >> >>+---auth/ >> >> >> >> modules/luni/src/main/native/ >> >>|common/ >> >>|fdlibm/ >> >>|launcher/ >> >>|luni/ >> >>|pool/ >> >>|port/ >> >>|sig/ >> >>|thread/ >> >>|vmi/ >> >>+---vmls/ >> >> >> >> modules/prefs/src/main/native/ >> >> +---prefs/ >> >> >> >> modules/text/src/main/native/ >> >>|---text/ >> >>+--unicode/ (comes from >> >> the icu4c zips stored currently in depends) >> > >> > W/o thinking too hard about it, this works for me just fine. >> >> Great - I am starting to look at how shared includes can be handled >> across modules (as Mark alluded to in his earlier post in this thread >> [1]), and at what changes will be required to split the natives into >> these locations. I will be taking this in small steps, trying to get the >> foundation and "easy" parts done first, and raising a JIRA for each step >> rather than in one monolithic change. > > Great! I think splitting the sources by modules at the top level > directory is a good idea. > A few questions before the big source tree reorganization starts: > >> >> modules/archive/src/main/native/ >> >>|---archive/ >> >>|---zip/ > > (1) Do we need to keep the 'main' directory in every module? If we > need to have a distinction between tests and sources, may be just pull > tests one level up and have something like: > archive/ >src/ > native/ > java/ > tests/ > native/ > java/ > I wonder if 'main' is an extra level of the directory tree we can > actually avoid of (lazy people don't like typing cd too much :)) I think using "src/main" and "src/test" to group our implementation and test code was a convention we agreed on a while back. Personally I dont have any problem with it, but it's something we can look at again if people don't like it. I think that's something that would be fairly easy to alter once the natives are modularised, should we wish to do so. > > (2) Why do we need to have 'luni' two times in the path, e.g. > modules/luni/src/main/native/luni/ ? If we need to put an additional > stuff like 'port' to the luni module, perhaps it could be just enough > to put it into a subdirectory within native, e.g: > modules/luni/src/native/port/ ? Maybe I am missing something, but I think what you're suggesting (putting port etc. directly under the native directory) is the same as I laid out above - it's qui
RE: [admin] contrib policy (was: Re: Stress tests generator)
Tim, Geir, Thanks for explaining legal points! Ellison, Tim wrote: >IMHO anything other than code snippets should come in via JIRA >with the definitive grant so we know exactly what we got when and can >solicit ACQs etc. I've deleted the file from Wiki and added it in JIRA. To simplify things I also added block comments and LICENSE file. Please, find it here: http://issues.apache.org/jira/secure/attachment/12331903/StressTestGener ator.zip Thanks, Alexander Shipilov. 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]
[RESULT] Re: [VOTE] Acceptance of HARMONY-211 : Contribution of java.rmi
12 +1 votes, no others. Someone want to re-assign to themselves and bring this in? : Please make sure that the initial commit is *identical* to what was contributed, and then do any tweaks, fixes, moves etc from there. geir Geir Magnusson Jr wrote: I have received the ACQs and the BCC for Harmony-211 in paper form and have reviewed them, so I can assert that the critical provenance paperwork is in order. It is not in SVN yet, but I wanted to get this vote going at the same time as the Intel contribution in the same area. I will get scanned and in SVN ASAP. This is the contribution from ITC. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below Lets let this run 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Re: [VOTE] Acceptance of HARMONY-337 : Contribution of RMI framework
9 +1 votes, no others. Someone want to re-assign to themselves and bring this in? Please make sure that the initial commit is *identical* to what was contributed, and then do any tweaks, fixes, moves etc from there. geir Geir Magnusson Jr wrote: I have received the ACQs and the BCC for Harmony-337, so I can assert that the critical provenance paperwork is in order and in SVN. This is the contribution from Intel. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below Lets let this run 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Re: [VOTE] Acceptance of HARMONY-256 : Contribution of DNS service provider for JNDI classlibrary code
9 +1 votes, no others. Someone want to re-assign to themselves and bring this in? :) Please make sure that the initial commit is *identical* to what was contributed, and then do any tweaks, fixes, moves etc from there. geir Geir Magnusson Jr wrote: I have received the ACQs and the BCC for Harmony-256, so I can assert that the critical provenance paperwork is in order and in SVN. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below Lets let this run 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Re: [VOTE] Acceptance of HARMONY-199 : Contribution of javax.crypto and java.math
10 +1 votes, no others. Someone want to re-assign to themselves and bring this in? Please make sure that the initial commit is *identical* to what was contributed, and then do any tweaks, fixes, moves etc from there. geir Geir Magnusson Jr wrote: I have received the ACQs and the BCC for Harmony-199 in paper form and have reviewed them, so I can assert that the critical provenance paperwork is in order. It is not in SVN yet, but I wanted to get this vote going at the same time as the other contributions from ITC. I will get scanned and in SVN ASAP. This is the contribution from ITC. This is just a vote to accept or reject the codebase. What we do with the codebase - what parts and how we integrate - is up for discussion on the -dev list. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below Lets let this run 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] - 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] Acceptance of HARMONY-199 : Contribution of javax.crypto and java.math
+1 from me - it seems I didn't vote... Geir Magnusson Jr wrote: I have received the ACQs and the BCC for Harmony-199 in paper form and have reviewed them, so I can assert that the critical provenance paperwork is in order. It is not in SVN yet, but I wanted to get this vote going at the same time as the other contributions from ITC. I will get scanned and in SVN ASAP. This is the contribution from ITC. This is just a vote to accept or reject the codebase. What we do with the codebase - what parts and how we integrate - is up for discussion on the -dev list. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below Lets let this run 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OPEN Specification
Hi Tim, On 5/14/06, Tim Ellison <[EMAIL PROTECTED]> wrote: First a caveat that I have only read the OPEN document through quickly so far, so apologies if this is off-base. I do intend to go back an read more thoroughly. Is it fair to generalize the Accessors proposal to say that there should be internal APIs in the 'right place' within the class library to allow a good range of OS/CPU/VM architectures to optimize their implementation? Yes, this is a good abstract of the intention. The accessors are there to provide secure access to functionality hidden by Java design, but needed to implement some parts of the API (like NIO, graphics etc.) in efficient manner. It is also an attempt to standardize the API necessary to access underlying functionality for Harmony community so that the class library could solidly rely on a VM and work together well. Security is one of the most important aspects of the accessors. Neither do we not want to expose a security hole in the VM nor do we want to sacrifice performance by having massive security checks in the accessors implementation. Thanks, Arzhan The document describes some ideas about how the optimizations will occur (singleton classes, JIT recognized methods, etc.) but I just want to back-up a moment to check the rationale before looking at the solution. Regards, Tim -- Arzhan Intel Middleware Products Division Rana Dasgupta wrote: > Hi Andrew, > Thanks for your comments and interesting feedback. The ideas in this spec > are certainly open to debate and input from everyone. As we well know, > modularity is a great goal which has many merits...testability, ease of > development, plug and play etc. However it is less easy to achieve in a > pure > form...some degree of pollution creeps into an implementation when one > tries > to optimize on other goals like performance, footprint etc. I was hoping > that we could see this submission as a strawman for how one could > potentially modularize VM development. With input from knowledgeable people > in the community, maybe a standard for modular VM development can evolve > out > of this... > >For context, this proposal sees the accessor( platform and VM > ) mechanism as a tool to facilitate Classlibrary development in Java( as > you > obeserved below ). They are a set of singleton classes that class libraries > instantiate securely through a factory mechanism. Their implementation is > provided by the VM. Their default fully portable implementation could be > via > JNI, however there is potential for performance optimization...eg., once > instantiated, the per invocation security could be relaxed, the JIT could > recognize and aggressively inline them, etc. > I have tried to answer some more of your questions inline > >> I wonder who has the responsibility to provide such native-related and >> platform-independent interfaces to java classlib programmer? >> ...Then shall classlib programmer write native code to implement >> high-level > functions such as >> "findFirstDiff" and invoke them via JNI mode? or shall VM provide such >> high-level functions and classlib programmer only need call >> mem.findFirst? > > > These are VM components. The idea is that the VM provides them and the > Classlib programmer writes less native code. > >> As my understanding of the document, classlib programmer will avoid >> writing >> native code directly, and invoke corresponding interfaces defined in VM. > > That is correct > >> If I'm right, I think it's very hard for VM to provide so many > native-related >> APIs for classlib programmer. For example, java.net.Socket >> implementation. > Classlib >programmer still has to write native code to implement Socket > function. And I also think it's >> classlib programmer's responsibility > > The idea is that the VM provides some standardized functionality through VM > and Platform accessors. How much that is, is part of the standard > definition > that we need. I am not completely sure what you mean by the "classlib > programmer's responsibility". It is true that the classlib programmer will > need to implement whatever is not provided by the standardised accessor > components. > > Thanks, > Rana > > On 5/12/06, Andrew Zhang <[EMAIL PROTECTED]> wrote: >> >> Hello, Rana >> >> I took a quick view on the document, and I have some questions on Chapter >> 6. >> >> Let's take 6.9.1 "A.NM ACCESS TO NATIVE MEMORY" as example: >> >> The MemoryAccessor interface includes the following function >> groups: >> 1.Memory allocation and de-allocation: malloc, realloc, free >> 2.Operations over primitive types: getByte, getDouble,setBoolean >> 3.Operations over arrays of primitive types: getChar(char[] buf,..) >> 4.Search operations: findFirstDiff, findFirstDiffReorder >> >> For full description, please refer to " >> http://issues.apache.org/jira/browse/HARMONY-459"; or [1]. >> >> I wonder who has the responsibility to provide such native-related and >> platform-independent interfaces to
Re: Supporting working on a single module?
Tim Ellison wrote: Andrey Chernyshev wrote: (1) Do we need to keep the 'main' directory in every module? If we need to have a distinction between tests and sources, may be just pull tests one level up and have something like: archive/ src/ native/ java/ tests/ native/ java/ I wonder if 'main' is an extra level of the directory tree we can actually avoid of (lazy people don't like typing cd too much :)) Really lazy people use path completion and don't care ;-) (2) Why do we need to have 'luni' two times in the path, e.g. modules/luni/src/main/native/luni/ ? If we need to put an additional stuff like 'port' to the luni module, perhaps it could be just enough to put it into a subdirectory within native, e.g: modules/luni/src/native/port/ ? Is it just the name of that path element that you object to? Seems a bit cleaner to me if there is a bucket to put that source in. However, (comment to Oliver as well), I'm left wondering where the platform-specific vs. common code distinction is made? I was thinking that platform specific directories would be laid out underneath each native component directory. So, for example, underneath the modules/luni/src/main/native/port directory there would be the following structure (avoiding ascii tree diagrams): modules/luni/src/main/native/port/shared modules/luni/src/main/native/port/linux modules/luni/src/main/native/port/windows with further platform specific directories being added as we expand. BTW, I've noticed that this proposal is very similar to the DRLVM source tree organization, which is like: Great minds and all that :-) - vm - include - top level include which contains h files exported by various VM components; - interpreter - jitrino - vmcore ... The module vmcore, for example, contains both native and java code: vmcore/src/kernel_classes - native - javasrc The building system for DRLVM has been designed in a modular way as well: There is a "building engine part at the build/make and build/make/targets directory which is shared by all components, Each VM module has a building descriptor which is currently located at build/make/components directory, but can also be easily moved to the component source tree to support the idea of full independent checkout of a specific module. I think the building system provided with DRLVM can easily be used to support the source modularization approach, the proposed 'hdk' in that case would provide the developers, besides the "public includes", with the shared part of the building scripts as well. We should continue to collaborate on finding the best solution -- it has worked very well so far! Agreed! Regards, Tim -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Supporting working on a single module?
Hi Andrey, Andrey Chernyshev wrote: On 5/12/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: Geir Magnusson Jr wrote: >> >> To do this there are at least three steps needed, as far as I can see: >> >> 1) Refactor the native code into the modular structure we currently >> have for Java code and tests. This has been spoken about before at >> [1]. The native code would be located within each module at >> modules//src/main/native. As a starting point, can I >> propose that the natives be broken down in the following way: >> >> modules/archive/src/main/native/ >>|---archive/ >>|---zip/ >> >> +--zlib/ modules/auth/src/main/native/ >>+---auth/ >> >> modules/luni/src/main/native/ >>|common/ >>|fdlibm/ >>|launcher/ >>|luni/ >>|pool/ >>|port/ >>|sig/ >>|thread/ >>|vmi/ >>+---vmls/ >> >> modules/prefs/src/main/native/ >> +---prefs/ >> >> modules/text/src/main/native/ >>|---text/ >>+--unicode/ (comes from >> the icu4c zips stored currently in depends) > > W/o thinking too hard about it, this works for me just fine. Great - I am starting to look at how shared includes can be handled across modules (as Mark alluded to in his earlier post in this thread [1]), and at what changes will be required to split the natives into these locations. I will be taking this in small steps, trying to get the foundation and "easy" parts done first, and raising a JIRA for each step rather than in one monolithic change. Great! I think splitting the sources by modules at the top level directory is a good idea. A few questions before the big source tree reorganization starts: >> modules/archive/src/main/native/ >>|---archive/ >>|---zip/ (1) Do we need to keep the 'main' directory in every module? If we need to have a distinction between tests and sources, may be just pull tests one level up and have something like: archive/ src/ native/ java/ tests/ native/ java/ I wonder if 'main' is an extra level of the directory tree we can actually avoid of (lazy people don't like typing cd too much :)) I think using "src/main" and "src/test" to group our implementation and test code was a convention we agreed on a while back. Personally I dont have any problem with it, but it's something we can look at again if people don't like it. I think that's something that would be fairly easy to alter once the natives are modularised, should we wish to do so. (2) Why do we need to have 'luni' two times in the path, e.g. modules/luni/src/main/native/luni/ ? If we need to put an additional stuff like 'port' to the luni module, perhaps it could be just enough to put it into a subdirectory within native, e.g: modules/luni/src/native/port/ ? Maybe I am missing something, but I think what you're suggesting (putting port etc. directly under the native directory) is the same as I laid out above - it's quite likely that my ascii diagram of the directory layout hasnt come across as intended, so to clarify the resulting native directories will be: modules/archive/src/main/native/archive/ modules/archive/src/main/native/zip/ modules/archive/src/main/native/zlib/ modules/luni/src/main/native/common/ modules/luni/src/main/native/fdlibm/ modules/luni/src/main/native/launcher/ modules/luni/src/main/native/luni/ modules/luni/src/main/native/pool/ modules/luni/src/main/native/port/ modules/luni/src/main/native/sig/ modules/luni/src/main/native/thread/ modules/luni/src/main/native/vmi/ modules/luni/src/main/native/vmls/ modules/prefs/src/main/native/prefs/ modules/text/src/main/native/text/ modules/text/src/main/native/unicode/ I think this agrees with what you were saying - please let me know if I've misunderstood! BTW, I've noticed that this proposal is very similar to the DRLVM source tree organization, which is like: - vm - include - top level include which contains h files exported by various VM components; - interpreter - jitrino - vmcore ... The module vmcore, for example, contains both native and java code: vmcore/src/kernel_classes - native - javasrc The building system for DRLVM has been designed in a
Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer, CharBuffer, boolean) should set correct position in ByteBuffer
On 5/5/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: 2006/5/5, Vladimir Strigun <[EMAIL PROTECTED]>: > On 5/5/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > Vladimir, Andrew > > > > 2006/4/26, Andrew Zhang <[EMAIL PROTECTED]>: > > > Here I propose two solutions: > > > > > > 1. Set the ByteBuffer to the limit, and store the remaining ByteBuffer in > > > decoder. Invokers doesn't care the position of in. If the result is > > > UNDERFLOW and there're furthur input, just pass the new input to the > > > decoder. It's a typical streaming decoder. That's what Harmony does > > > currently. > > > > > > 2. Decoder doesn't store remaining ByteBuffer. Position of "in" is set to > > > indicate the remaining ByteBuffer. Invoker should take care to generate new > > > input ByteBuffer for next invocation. RI acts in this way. > > > > > > Both are acceptable. > > > > > > Did I get it right that both solutions do not contradict to the spec > > and that RI acts as the second one? > > Mikhail, > > you absolutely right. I think this issue could be closed, but possibly > it would be better to mark it as non-bug difference from RI. > Richard, what do you think? In this case according to our compatibility guidelines we should switch behavior to RI-like. Andrew, what do you think about it? I think we should mark it as compatibility bug and close it as wontfix. If we will switch to RI behaviour, we need to check all decoding operations in java.io package and possibly correct some methods. Thanks. Vladimir. Thanks, Mikhail > > > Thanks. > Vladimir. > > > Thanks, > > Mikhail > > > > > > > > > > However, I think solution 1 is more reasonable. > > > > > > "Is it possible to store bytes in decoder, support streaming decoding, and, > > > at the same time sets correct position in input buffer after each operation? > > > " > > > > > > Yes. In fact, your patch will make Harmony act as the description above. > > > > > > However, I don't think it solve the problem. Maybe invoker is more > > > confusable and may think: > > > > > > "Is the remaining bytebuffer maintained in decoder or in ? Shall I get the > > > remaining buffer from in and pass it for next invocation?" > > > > > > Anyway, we need a decision on this compatibility issue. > > > By the way, Vladimir, does solution one cause any problem on other classlib > > > implementation? > > > > > > Any comment? > > > > > > Thanks ! > > > > > > > > > Vladimir Strigun commented on HARMONY-410: > > > -- > > > > > > Hi Richard, > > > > > > Thanks for the clarification, I agree that streaming decode is good thing, > > > but I'd like to explain my understanding of specification :) > > > According to specification of CharsetDecoder decoding operation should > > > process by the following steps: > > > " > > > 2. Invoke the decode method zero or more times, as long as additional input > > > may be available, passing false for the endOfInput argument and filling the > > > input buffer and flushing the output buffer between invocations; > > > > > > 3. Invoke the decode method one final time, passing true for the endOfInput > > > argument; and then > > > " > > > spec also says: > > > "The buffers' positions will be advanced to reflect the bytes read and the > > > characters written, but their marks and limits will not be modified" > > > > > > I understand these sentences in the next way: > > > invoke decode with endOfInput = false if you have additional input, then > > > fill the buffer (i.e. add to buffer some additional input), invoke decode > > > again and pass correct endOfInput parameter dependent of availability of > > > input. > > > > > > Example you provided is very useful and, of course, 1st option looks better, > > > but what I'm suggest here is to reflect actual processed bytes in input. > > > After first invocation of decode, not all bytes processed actually, i.e. > > > almost all bytes processed, but some stored in decoder to further operation. > > > Is it possible to store bytes in decoder, support streaming decoding, and, > > > at the same time sets correct position in input buffer after each operation? > > > > > > Thanks. > > > Vladimir. > > > > > > > method decode(ByteBuffer, CharBuffer, boolean) should set correct position > > > in ByteBuffer > > > > > > > > > > > > > > > Key: HARMONY-410 > > > > URL: http://issues.apache.org/jira/browse/HARMONY-410 > > > > Project: Harmony > > > > Type: Bug > > > > > > > Components: Classlib > > > > Reporter: Vladimir Strigun > > > > Assignee: Mikhail Loenko > > > > Priority: Minor > > > > Attachments: Harmony-410_patch.txt, harmony-410_test.txt > > > > > > > > When ByteBuffer contain incomplete sequence of bytes for successful > > > decoding, position in ByteBuffer should be set to latest successful byte. I > > > will attach testcase and patch soo
[classlib]bug-to-bug incompatibility issue: java.util.Formatter's flag handling
RI's java.util.Formatter has inconsistent behavior on incompatible flags
handling: different kind of conversions has similar spec on this issue,
which only cover one flag "#" - "If the '#' flag is given, then a
FormatFlagsConversionMismatchException will be thrown", and most kind of
conversions in RI ignore other incompatible flags, but there is one kind
of conversion named as "general conversion" throws exception on all
incompatible flags.
For example, the sign flag of "+" is incompatible with both character
conversion and general conversion, and character conversion ignore it
while general conversion throws exception, the test case below shows the
difference:
public class FormatterTest extends TestCase {
public void testFormat() {
Formatter f = new Formatter(Locale.US);
//Character conversion, incompatible flag "+" is ignored
f.format("%+c", 'W');
assertEquals("W", f.toString());
f = new Formatter(Locale.US);
try {
//General conversion, incompatible flag "+" is reported
f.format("%+h", "hello");
fail("FormatFlagsConversionMismatchException is thrown on RI");
} catch (FormatFlagsConversionMismatchException e) {
// expected
}
}
}
Should we consider RI's behavior is not logical? or just make Harmony
comply with RI?
--
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]
