Re: [classlib][performance] performance improvement for luni and nio_char modules - Harmony-1980
Mikhail, Not yet. As I mentioned in the thread I'm still working on Dacapo. I'll let you know if I find any improvements for JIT. Thanks, Vladimir. On 10/27/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Vladimir, I see you removed some arraycopy operations in your patch as not effective. I'm Ok with your solution but what to know if JIT could solve the problem generating more effective code? Do you have any suggestions for JIT here? On 10/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: 10%-15%? That's amazing. How fast are we (DRLVM) compared to Sun 1.5 using decapo? geir Vladimir Strigun wrote: The optimization covers the following issues: - java.nio.charset.CharsetDecoder and java.nio.charset.CharsetEncoder Streaming decoding/encoding was removed. Analysis of API hotspots for Dacapo shows that CharsetDecoder is frequently used almost in all benchmark, especially in chart. We already discussed advantages of streaming decoding but the fix shows significant performance improvement on average for all Dacapo benchmarks. For instance, boost for chart benchmark is about 16%. Paulex, you recently worked in nio_char module and if I correctly remember you introduce streaming operations, so could you please review the changes and let me know? Since streaming operation was removed, tests have been slightly modified as well (previous version of tests fails on RI). - java.io.BufferedReader readLine() method was slightly modified. Additional check whether some characters available in cached buffer was added prior to main cycle. - java.io.InputStreamReader Cached char buffer was removed, read() , read(char[], int, int) methods were rewritten. Current implementation of read(char[], int, int) uses several invocation of System.arraycopy. Proposed solution wraps char[] arguments within char buffer and therefore doesn't use arraycopy. Decoding operation is also produced inside the method, so fillBuf() has been removed Thoughts? Comments? Thanks, Vladimir. On 10/26/06, Vladimir Strigun (JIRA) [EMAIL PROTECTED] wrote: [classlib][performance] performance improvement for luni and nio_char modules - Key: HARMONY-1980 URL: http://issues.apache.org/jira/browse/HARMONY-1980 Project: Harmony Issue Type: Improvement Components: Classlib Reporter: Vladimir Strigun Attachments: Harmony-1980.diff I've analyzed API frequently used in all Dacapo[1] benchmarks and found several places in luni and nio_char modules that can be improved. Suggested fix gives about 10-15% boost on average for Dacapo executed on DRLVM. I'll post more details to dev list. Attached fix contains modifications for the following classes: java.io.BufferedReader, java.io.InputStreamReader, java.nio.charset.CharsetDecoder and java.nio.charset.CharsetEncoder. Please have a look to the results of Dacapo execution (values are in millisec, so the less the better): Small workload OrigBuild Patched bloat 996,078 1024,85 chart 1240,7771068,112 fop 250,433 232,957 hsqldb 348,942 361,139 jython 831,143 824,775 lusearch1854,95 1870,969 luindex 339,45 231,314 pmd 29,704 23,638 default workload OrigBuild Patched bloat 168733,562 175493,467 chart 31651,792 25681,751 fop 2546,2892512,045 hsqldb 22873,608 13555,515 jython 128207,303 92863,28 lusearch29425,991 30064,153 luindex 17825,795 18083,898 pmd 44548,724 40225,694 [1] http://dacapobench.sourceforge.net -- 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 -- Mikhail Fursov
Re: [classlib][performance] performance improvement for luni and nio_char modules - Harmony-1980
On 10/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: This is a nice note to wake up to... Vladimir Strigun wrote: Here are the results: Small workload: OrigBuildFixedSun1.5.0_06 bloat996,0781024,85955,589 chart1240,7771068,112953,096 fop250,433232,957174,901 hsqldb348,942361,139540,45 jython831,143824,775571,292 lusearch1854,951870,9691830,589 luindex339,45231,314441,79 pmd29,70423,63861,638 Average449,91408,60471,71 default workload: OrigBuildFixedSun1.5.0_06 bloat16116,6911561813578,522 chart11701,54610036,6319790,247 fop2539,3862502,5182387,289 hsqldb3217,3383078,3315709,291 jython14639,27814064,1049456,167 lusearch14508,93816175,08513663,679 luindex16292,65215501,71315602,178 pmd10840,26412937,2559734,032 Average9337,739281,878787,42 large workload: OrigBuildFixedSun1.5.0_06 bloat168733,5175493,46 138468,277 chart31651,7925681,75125599,38 fop2546,2892512,0452412,487 hsqldb22873,60813555,51515751,873 jython128207,392863,2826183,716 lusearch29425,99130064,15326605,631 luindex17825,79518083,89814307,71 pmd44548,72440225,69446345,995 Average31345,2127334,7222348,3525 At first glace the results are pretty good, but antlr benchmark works incorrectly with DRLVM (Harmony-1906) and there are no results for eclipse and xalan benchmarks. I'm still working on Dacapo analysis. Pretty good? You're suggesting that DRLVM is faster than Sun 1.5. I would say Wow!, not pretty good... More info - what is OrigBuild and what is Fixed? Why is Fixed slower than OrigBuild? Fixed is the same build plus H-1980 included. As you can see from average rows Fixed build is faster. The values are in millisec, so the less the better, i.e. we are still slower that RI. Thanks, Vladimir. geir Thanks, Vladimir. On 10/26/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: 10%-15%? That's amazing. How fast are we (DRLVM) compared to Sun 1.5 using decapo? geir Vladimir Strigun wrote: The optimization covers the following issues: - java.nio.charset.CharsetDecoder and java.nio.charset.CharsetEncoder Streaming decoding/encoding was removed. Analysis of API hotspots for Dacapo shows that CharsetDecoder is frequently used almost in all benchmark, especially in chart. We already discussed advantages of streaming decoding but the fix shows significant performance improvement on average for all Dacapo benchmarks. For instance, boost for chart benchmark is about 16%. Paulex, you recently worked in nio_char module and if I correctly remember you introduce streaming operations, so could you please review the changes and let me know? Since streaming operation was removed, tests have been slightly modified as well (previous version of tests fails on RI). - java.io.BufferedReader readLine() method was slightly modified. Additional check whether some characters available in cached buffer was added prior to main cycle. - java.io.InputStreamReader Cached char buffer was removed, read() , read(char[], int, int) methods were rewritten. Current implementation of read(char[], int, int) uses several invocation of System.arraycopy. Proposed solution wraps char[] arguments within char buffer and therefore doesn't use arraycopy. Decoding operation is also produced inside the method, so fillBuf() has been removed Thoughts? Comments? Thanks, Vladimir. On 10/26/06, Vladimir Strigun (JIRA) [EMAIL PROTECTED] wrote: [classlib][performance] performance improvement for luni and nio_char modules - Key: HARMONY-1980 URL: http://issues.apache.org/jira/browse/HARMONY-1980 Project: Harmony Issue Type: Improvement Components: Classlib Reporter: Vladimir Strigun Attachments: Harmony-1980.diff I've analyzed API frequently used in all Dacapo[1] benchmarks and found several places in luni and nio_char modules that can be improved. Suggested fix gives about 10-15% boost on average for Dacapo executed on DRLVM. I'll post more details to dev list. Attached fix contains modifications for the following classes: java.io.BufferedReader, java.io.InputStreamReader, java.nio.charset.CharsetDecoder and java.nio.charset.CharsetEncoder. Please have a look to the results of Dacapo execution (values are in millisec, so the less the better): Small workload OrigBuild Patched bloat 996,078 1024,85 chart 1240,7771068,112 fop 250,433 232,957 hsqldb 348,942 361,139 jython 831,143
Re: [classlib][performance] performance improvement for luni and nio_char modules - Harmony-1980
Mikhail, It was pretty old build. Now I'm gathering info for the current DRLVM (antlr, eclipse, xalan are still not included). I've executed every benchmarks 10 times and the result is geometric mean of the last 5 executions. Machine: P4, 3Ghz, 1Gb RAM Build1 = current Harmony build, svn = r468353, (Oct 27 2006), Windows/ia32/msvc 1310, release build Build2 = Build1+Harmony-1980 RI: jdk1.5.0_06 Arguments for DRLVM: -Xem:server -Xms700m -Xmx700m Arguments for Sun: -XX:+AggressiveHeap -XX:+UseBiasedLocking -XX:+UseParallelGC -XX:ParallelGCThreads=4 -Xss64k -Xms700m -Xmx700m Results for small input: Build1 Build2 RI bloat 1014,3711024,618968,976 chart 1427,9121186,959956,125 fop 243,426 244,317 171,701 hsqldb 330,856 324,493 549,55 jython 1092,8691102,331568,088 lusearch1999,63 1971,8131830,707 luindex 421,703 225,073 594,78 pmd 27,332 26,981 53,319 Average 482,5168816 434,5997662 481,3767025 Here we can see that DRLVM is a little bit faster, but recommendations for Dacapo says that small workload is for testing and either reporting default or large in any performance analysis. Default input: Build1 Build2 RI bloat 17155,441 17131,6313718,637 chart 13342,101 10924,038 9755,926 fop 2621,1462584,3262353,304 hsqldb 3153,2123101,6915737,304 jython 16240,515 15632,528299,957 lusearch16280,762 16255,764 13518,751 luindex 12420,638 10730,491 15782,563 pmd 11027,172 11136,656 9689,841 Average 9538,259502 9063,946046 8638,4136 So, for default input we are 5-10% slower. I'll provide the results for large input as soon as performance run completed. Thanks, Vladimir. On 10/27/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Vladimir, +1 more question: between TM integration and HARMONY-1942 incorrect behaviour of BBP could significantly slow down the execution. Did you do your measurements with Harmony-1942 applied? On 10/27/06, Vladimir Strigun [EMAIL PROTECTED] wrote: Mikhail, Not yet. As I mentioned in the thread I'm still working on Dacapo. I'll let you know if I find any improvements for JIT. Thanks, Vladimir. On 10/27/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Vladimir, I see you removed some arraycopy operations in your patch as not effective. I'm Ok with your solution but what to know if JIT could solve the problem generating more effective code? Do you have any suggestions for JIT here? On 10/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: 10%-15%? That's amazing. How fast are we (DRLVM) compared to Sun 1.5 using decapo? geir Vladimir Strigun wrote: The optimization covers the following issues: - java.nio.charset.CharsetDecoder and java.nio.charset.CharsetEncoder Streaming decoding/encoding was removed. Analysis of API hotspots for Dacapo shows that CharsetDecoder is frequently used almost in all benchmark, especially in chart. We already discussed advantages of streaming decoding but the fix shows significant performance improvement on average for all Dacapo benchmarks. For instance, boost for chart benchmark is about 16%. Paulex, you recently worked in nio_char module and if I correctly remember you introduce streaming operations, so could you please review the changes and let me know? Since streaming operation was removed, tests have been slightly modified as well (previous version of tests fails on RI). - java.io.BufferedReader readLine() method was slightly modified. Additional check whether some characters available in cached buffer was added prior to main cycle. - java.io.InputStreamReader Cached char buffer was removed, read() , read(char[], int, int) methods were rewritten. Current implementation of read(char[], int, int) uses several invocation of System.arraycopy. Proposed solution wraps char[] arguments within char buffer and therefore doesn't use arraycopy. Decoding operation is also produced inside the method, so fillBuf() has been removed Thoughts? Comments? Thanks, Vladimir. On 10/26/06, Vladimir Strigun (JIRA) [EMAIL PROTECTED] wrote: [classlib][performance] performance improvement for luni and nio_char modules - Key: HARMONY-1980 URL: http://issues.apache.org/jira/browse/HARMONY-1980 Project: Harmony Issue Type: Improvement Components: Classlib Reporter: Vladimir Strigun Attachments: Harmony-1980.diff I've analyzed API frequently used in all Dacapo[1] benchmarks and found several places in luni and nio_char modules that can be improved. Suggested
[classlib][performance] performance improvement for luni and nio_char modules - Harmony-1980
The optimization covers the following issues: - java.nio.charset.CharsetDecoder and java.nio.charset.CharsetEncoder Streaming decoding/encoding was removed. Analysis of API hotspots for Dacapo shows that CharsetDecoder is frequently used almost in all benchmark, especially in chart. We already discussed advantages of streaming decoding but the fix shows significant performance improvement on average for all Dacapo benchmarks. For instance, boost for chart benchmark is about 16%. Paulex, you recently worked in nio_char module and if I correctly remember you introduce streaming operations, so could you please review the changes and let me know? Since streaming operation was removed, tests have been slightly modified as well (previous version of tests fails on RI). - java.io.BufferedReader readLine() method was slightly modified. Additional check whether some characters available in cached buffer was added prior to main cycle. - java.io.InputStreamReader Cached char buffer was removed, read() , read(char[], int, int) methods were rewritten. Current implementation of read(char[], int, int) uses several invocation of System.arraycopy. Proposed solution wraps char[] arguments within char buffer and therefore doesn't use arraycopy. Decoding operation is also produced inside the method, so fillBuf() has been removed Thoughts? Comments? Thanks, Vladimir. On 10/26/06, Vladimir Strigun (JIRA) [EMAIL PROTECTED] wrote: [classlib][performance] performance improvement for luni and nio_char modules - Key: HARMONY-1980 URL: http://issues.apache.org/jira/browse/HARMONY-1980 Project: Harmony Issue Type: Improvement Components: Classlib Reporter: Vladimir Strigun Attachments: Harmony-1980.diff I've analyzed API frequently used in all Dacapo[1] benchmarks and found several places in luni and nio_char modules that can be improved. Suggested fix gives about 10-15% boost on average for Dacapo executed on DRLVM. I'll post more details to dev list. Attached fix contains modifications for the following classes: java.io.BufferedReader, java.io.InputStreamReader, java.nio.charset.CharsetDecoder and java.nio.charset.CharsetEncoder. Please have a look to the results of Dacapo execution (values are in millisec, so the less the better): Small workload OrigBuild Patched bloat 996,078 1024,85 chart 1240,7771068,112 fop 250,433 232,957 hsqldb 348,942 361,139 jython 831,143 824,775 lusearch1854,95 1870,969 luindex 339,45 231,314 pmd 29,704 23,638 default workload OrigBuild Patched bloat 168733,562 175493,467 chart 31651,792 25681,751 fop 2546,2892512,045 hsqldb 22873,608 13555,515 jython 128207,303 92863,28 lusearch29425,991 30064,153 luindex 17825,795 18083,898 pmd 44548,724 40225,694 [1] http://dacapobench.sourceforge.net -- 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
Re: [build] can't run the tests with new VM
Mikhail, How do you solve the problem? I have the same error on my machine (Win XP SP2). Thanks, Vladimir. On 8/9/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Seems like it isn't related to the new VM - I see similar error message on svn move. But the problem with running the tests disappeared :) Thanks, Mikhail 2006/8/9, Mikhail Loenko [EMAIL PROTECTED]: I've completly removed not only VME but the whole workspace, restarted machine and reproduced the problem I'll try to create different project and check Thanks, Mikhail 2006/8/9, Oliver Deakin [EMAIL PROTECTED]: So you can completely delete the VME from your workspace (remove the default directory), unpack the zip again and recreate the problem? Regards, Oliver Mikhail Loenko wrote: I use WinXP SP2 too I have two workspaces one on a local drive and one on a network drive. Usually I use network workspace to build on linux. Tests run on network drive on windows just fine But I still cannot run the tests in the *local* workspace. I've tried to remove it and checkout again - the problem still exists. Thanks, Mikhail 2006/8/9, Tim Ellison [EMAIL PROTECTED]: Hmm, works for me on Win XP SP2. What are you using? Anyone else see this problem? Regards, Tim Mikhail Loenko wrote: I'm trying to build and run the tests with the new v4 VM and getting the following error no Windows: compile.tests: [echo] Compiling RMI api tests [javac] Compiling 6 source files to C:\WS\Harmony1\modules\rmi\bin\test\api [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. run.tests.api: [echo] Running RMI api tests [junit] Running org.apache.harmony.rmi.RegistryTest [junit] (c) Copyright 1991, 2006 The Apache Software Foundation or its licen sors, as applicable. [junit] java version 1.5 (subset) [junit] Failed to open JVM DLL: C:\WS\Harmony1\deploy\jdk\jre\bin\default\ha rmonyvm (Access is denied. ) Linux is OK Am I missing something? 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] -- 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] -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [performance] performance measurement of HDK
On 8/2/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Strigun wrote: Our project is now in a good shape and we started encouraging people to try real applications on top of Harmony. One of the important parts of the feedback will be general impression of stability, reliability and performance of the HDK. We are doing pretty good in fixing bugs and developing new functionality in HDK, and it might be a good time for us to start thinking of performance as well. It might be a little bit preliminary, but do we consider having any performance targets for us? If yes, we may need to focus at least some of our efforts on benchmarking and tuning overall performance of HDK. Well, I wouldn't say the HDK, as much as Harmony. One of the main questions here is what should be the targets for us and how should we measure our performance. There are several ways for measuring performance, such us commercial benchmarks, free benchmarks, application startup, small micro suites, etc. Some of free benchmarks have been mentioned in JIRA issues and dev list, nevertheless at the moment we don't have any goals for performance. In spite of application enabling initiative it might be good to consider publicly available benchmarks as the additional list of the software applications which we would enable on Harmony. Yep. So I suggest to start discussing performance techniques and methods that can be used for comparing performance between RI and HDK. I think s/HDK/Harmony in case we do not consider performance issues, we can get negative feedback from users even if application starts without any errors, exceptions, etc. One of the benchmarks that was mentioned is DaCapo[1]. It's a free open-source benchmark suite and I believe it can be used for regular performance measurement of HDK. I've tried to find other free suites and got the following list: Telco - this one mostly stresses BigInteger/BigDecimal functionality GcOld - the purpose of this one is clear from the name :) SciMark - java benchmark for scientific and numerical computing Linpack java - well-known benchmark solving linear equations The Plasma Benchmark - creates an animated display by continuously summing four sine waves in an applet JavaWorld Benchmark - benchmark for low-level operations: loops, accessing variables, method invocation, arithmetic operators, casting, instantiation, exception handling, thread creation and switching. CaffeineMark 3.0 - low-level benchmark suite, including sieve of Eratosthenes, sorting, logic ops, method invocation, floating point, simple graphics and GUI ops JavaGrande benchmark suite - a set of benchmarks stressing different areas of java. These are good. I it would be nice to just hook them into the build-test framework as optional parts. I'll try to hook them into build-test framework. Do you think that all of them should be added to the framework? I suppose benchmarks should be downloaded the same way as other dependencies in Harmony? Having in mind that the list of publicly available benchmarks is not too big, sometimes it will be necessary to create micro benches for some of patches (for instance, Harmony-935). IMO micro should be started in case we change some code that the bench covers. Sure Other interesting and possibly more productive way for comparing performance between different implementations are to use non-free benchmarks. For instance, we can use benchmarks from Spec[n], like SpecJVM, SpecJBB, SpecJAppserver. Unfortunately first we should get license for it, but I believe this issue can be solved within the help of companies participating in Harmony :) Maybe. What we want to have is those benchmarks available to anyone in the project, although we'll take what we can get for now... geir Thoughts? Comments? [1] http://dacapobench.org [2] http://www.spec.org -- Vladimir Strigun, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [performance] performance measurement of HDK
On 8/2/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Strigun wrote: [SNIP] JavaWorld Benchmark - benchmark for low-level operations: loops, accessing variables, method invocation, arithmetic operators, casting, instantiation, exception handling, thread creation and switching. Is this the Volano suite? I tried to run it, but it has hardwired locations for the JRE, and all popular implementations of 1.3. Very funny. By JavaWorld benchmark I meant this one : http://www.javaworld.com/javaworld/jw-04-1997/jw-04-optimize_p.html CaffeineMark 3.0 - low-level benchmark suite, including sieve of Eratosthenes, sorting, logic ops, method invocation, floating point, simple graphics and GUI ops I was able to get this to work. I was impressed that it actually worked. (Ok, there are graphics glitches...) With a debug build on Ubuntu6 on a T42 w/ 1G Ram, two runs gave me to following. NUmbers for Sun's JDK are in parens Sieve = 15347 / 17075(24830) Loop = 50043 / 50138 (55529) Logic = 32705 / 32699(34982) String = 12504 / 17341 (19216) Float = 29280 / 32209(45124) Method = 45405 / 45361 (37331) Graphics = 552 / 628 (9069) Image = 26 / 33 (7966) Dialog = 103 / 118 (1463) CaffineMark == 4399 / 4934 (17635) I'm quite impressed. IMO, we're holding our own everywhere except graphcs, and this is a debug build. This is fun. 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: [classlib][java.math] combination of math packages
Daniel, thank you for the analysis of our patch. Now I think we all should vote for our combined version and put it to SVN as default one. Thanks, Vladimir. On 8/2/06, Daniel Fridlender [EMAIL PROTECTED] wrote: Vladimir, thank you very much for reviewing H-935 and improving it. It shows significantly better performance for BigDecimal that fit in 64 bits with no harm for the remaining cases. I agree with the changes you have made and are willing to continue improving our common math from now on. Thanks a lot! Daniel On 8/1/06, Vladimir Strigun [EMAIL PROTECTED] wrote: Daniel, Thank you for the new optimized version. We've analyzed your version and found it's very good. We can accept you version as default for Harmony but we'd like to add some improvements. :) I've updated H-935 and attach diffs for your code. We added optimization for small BigDecimal's objects. Our patch doesn't break your design covers the following issues: - reduce amount of object created during initialization of BigDecimal. In our version we don't use BigInteger during BigDecimal creation for small values. - cached values for powers of tens and for powers of five were added. - additional branches in all calculation methods for supporting small value calculations as well. - toDecimalScaledString method was added to Conversion class. The method is intended only for processing 32-bits numbers. I've attached small micro bench that shows boost for BigDecimal that fits to 64 bits. I should mention that we can't see any degradation in all other performance tests with our patch. Daniel, could you please review our patch? If you agree with suggested changes, I believe we all will vote +1 for our common math :) Thanks, Vladimir. -- Vladimir Strigun, Intel Middleware Product Division On 7/21/06, Daniel Fridlender [EMAIL PROTECTED] wrote: Dear all, On behalf of ITC, I have submitted as H-935 a new implementation of java.math combining previously donated implementations. It includes what we think are the best features of H-380 (donated by Intel) and the best features of H-199 (donated by ITC). We have also fixed some bugs from both implementations and done some further optimizations on methods from both of them. We have also included a few optimizations from H-551, we expect to include the remaining optimizations soon. We have also improved the performance test suite from H-551 and included further tests, among them realistic applications from cryptography. Check the README file included in the package mathPerformanceTestsUpdate.zip (H-935) for some more details about the new features of the test suite. A sample of the output obtained with the performance test suite can be found at http://www.fitc.unc.edu.ar/javadev/math/benchmarking.html A comparative analysis on a method-by-method basis between H-380 and H-199 can be found at http://www.fitc.unc.edu.ar/javadev/math/docs.html We will include further documentation soon. In the meantime, a brief description of the main issues follows: Internal representation of BigInteger: taken from H-380 (Sign-magnitude representation). Design: taken from H-199 (well-defined static libraries grouped by functionality). Serialization: taken from H-380 (it was not implemented in H-199). Most methods and constructors were taken from one of the previous donations and then tuned for consistency with the internal representation, for bug removal and for further optimizations. Very often large parts were reprogrammed (e.g.: shiftRight, bitLength, bitCount, not, setTrueCoded, modInverse, and many more). Nevertheless we can roughly say that the new version started by taking: 1) Methods of BigDecimal: most of them from H-199 because of efficiency. 2) Representation-dependent methods of BigInteger: most of them from H-380. 3) Representation-independent methods of BigInteger: most of them from H-199 for efficiency. 4) From H-551: caches, BigInteger.compareArrays, BigInteger.valueOf, BigDecimal.valueOf, etc. We also took their performance test suite, improve it and added further benchmarks. We plan to introduce remaining optimizations from H-551 and to optimize other methods (modPow, modInverse, nextProbablePrime, etc.) in order to bridge the gap in efficiency with the RI. Best regards, Daniel Fridlender ITC http://issues.apache.org/jira/browse/HARMONY-935 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: [classlib][java.math] combination of math packages
Daniel, Thank you for the new optimized version. We've analyzed your version and found it's very good. We can accept you version as default for Harmony but we'd like to add some improvements. :) I've updated H-935 and attach diffs for your code. We added optimization for small BigDecimal's objects. Our patch doesn't break your design covers the following issues: - reduce amount of object created during initialization of BigDecimal. In our version we don't use BigInteger during BigDecimal creation for small values. - cached values for powers of tens and for powers of five were added. - additional branches in all calculation methods for supporting small value calculations as well. - toDecimalScaledString method was added to Conversion class. The method is intended only for processing 32-bits numbers. I've attached small micro bench that shows boost for BigDecimal that fits to 64 bits. I should mention that we can't see any degradation in all other performance tests with our patch. Daniel, could you please review our patch? If you agree with suggested changes, I believe we all will vote +1 for our common math :) Thanks, Vladimir. -- Vladimir Strigun, Intel Middleware Product Division On 7/21/06, Daniel Fridlender [EMAIL PROTECTED] wrote: Dear all, On behalf of ITC, I have submitted as H-935 a new implementation of java.math combining previously donated implementations. It includes what we think are the best features of H-380 (donated by Intel) and the best features of H-199 (donated by ITC). We have also fixed some bugs from both implementations and done some further optimizations on methods from both of them. We have also included a few optimizations from H-551, we expect to include the remaining optimizations soon. We have also improved the performance test suite from H-551 and included further tests, among them realistic applications from cryptography. Check the README file included in the package mathPerformanceTestsUpdate.zip (H-935) for some more details about the new features of the test suite. A sample of the output obtained with the performance test suite can be found at http://www.fitc.unc.edu.ar/javadev/math/benchmarking.html A comparative analysis on a method-by-method basis between H-380 and H-199 can be found at http://www.fitc.unc.edu.ar/javadev/math/docs.html We will include further documentation soon. In the meantime, a brief description of the main issues follows: Internal representation of BigInteger: taken from H-380 (Sign-magnitude representation). Design: taken from H-199 (well-defined static libraries grouped by functionality). Serialization: taken from H-380 (it was not implemented in H-199). Most methods and constructors were taken from one of the previous donations and then tuned for consistency with the internal representation, for bug removal and for further optimizations. Very often large parts were reprogrammed (e.g.: shiftRight, bitLength, bitCount, not, setTrueCoded, modInverse, and many more). Nevertheless we can roughly say that the new version started by taking: 1) Methods of BigDecimal: most of them from H-199 because of efficiency. 2) Representation-dependent methods of BigInteger: most of them from H-380. 3) Representation-independent methods of BigInteger: most of them from H-199 for efficiency. 4) From H-551: caches, BigInteger.compareArrays, BigInteger.valueOf, BigDecimal.valueOf, etc. We also took their performance test suite, improve it and added further benchmarks. We plan to introduce remaining optimizations from H-551 and to optimize other methods (modPow, modInverse, nextProbablePrime, etc.) in order to bridge the gap in efficiency with the RI. Best regards, Daniel Fridlender ITC http://issues.apache.org/jira/browse/HARMONY-935 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[performance] performance measurement of HDK
Our project is now in a good shape and we started encouraging people to try real applications on top of Harmony. One of the important parts of the feedback will be general impression of stability, reliability and performance of the HDK. We are doing pretty good in fixing bugs and developing new functionality in HDK, and it might be a good time for us to start thinking of performance as well. It might be a little bit preliminary, but do we consider having any performance targets for us? If yes, we may need to focus at least some of our efforts on benchmarking and tuning overall performance of HDK. One of the main questions here is what should be the targets for us and how should we measure our performance. There are several ways for measuring performance, such us commercial benchmarks, free benchmarks, application startup, small micro suites, etc. Some of free benchmarks have been mentioned in JIRA issues and dev list, nevertheless at the moment we don't have any goals for performance. In spite of application enabling initiative it might be good to consider publicly available benchmarks as the additional list of the software applications which we would enable on Harmony. So I suggest to start discussing performance techniques and methods that can be used for comparing performance between RI and HDK. I think in case we do not consider performance issues, we can get negative feedback from users even if application starts without any errors, exceptions, etc. One of the benchmarks that was mentioned is DaCapo[1]. It's a free open-source benchmark suite and I believe it can be used for regular performance measurement of HDK. I've tried to find other free suites and got the following list: Telco - this one mostly stresses BigInteger/BigDecimal functionality GcOld - the purpose of this one is clear from the name :) SciMark - java benchmark for scientific and numerical computing Linpack java - well-known benchmark solving linear equations The Plasma Benchmark - creates an animated display by continuously summing four sine waves in an applet JavaWorld Benchmark - benchmark for low-level operations: loops, accessing variables, method invocation, arithmetic operators, casting, instantiation, exception handling, thread creation and switching. CaffeineMark 3.0 - low-level benchmark suite, including sieve of Eratosthenes, sorting, logic ops, method invocation, floating point, simple graphics and GUI ops JavaGrande benchmark suite - a set of benchmarks stressing different areas of java. Having in mind that the list of publicly available benchmarks is not too big, sometimes it will be necessary to create micro benches for some of patches (for instance, Harmony-935). IMO micro should be started in case we change some code that the bench covers. Other interesting and possibly more productive way for comparing performance between different implementations are to use non-free benchmarks. For instance, we can use benchmarks from Spec[n], like SpecJVM, SpecJBB, SpecJAppserver. Unfortunately first we should get license for it, but I believe this issue can be solved within the help of companies participating in Harmony :) Thoughts? Comments? [1] http://dacapobench.org [2] http://www.spec.org -- Vladimir Strigun, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][math] Location of performance tests (was: Re: performance improvement for java.math package)
I think it's better to close Harmony-551. When Daniel and his team will prepare new version of java.math we can compare implementation using this suite and then decide, whether we need to put it into svn. Thanks, Vladimir. On 6/26/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Agreed. What I suggested is calculate golden values on the fly, so you'll have golden values for the given machine, VM, etc Anyway if you feel the tests should not go to any suite, I'll just close the JIRA issue. Thanks, Mikhail 2006/6/23, Vladimir Strigun [EMAIL PROTECTED]: Unfortunately it is not a regression test. It's just micro-benchmark for measure performance of particular methods from BigInteger and BigDecimal classes. So, the result of execution is ops/sec value for every method, and since it dependent on machine speed, VM, etc, comparison between actual and 'golden' values might be incorrect. Thanks, Vladimir. On 6/22/06, Mikhail Loenko [EMAIL PROTECTED] wrote: The first thing that came into my mind is as far as it is a regression test, put somewhere next to the test both old and new Math implementations, measure 'golden' performances and than measure where the current performance in comparison to the golden is. This scenario might be simplified. If your optimization works e.g. for numbers less than say 1'000'000, you can compare performance for 999'999 and 1'000'001 Thanks, Mikhail 2006/6/22, Vladimir Strigun [EMAIL PROTECTED]: Mikhail, I can convert it to JUnit, but I'm not pretty sure about returning pass/fail. When you think test should return fail? Results of test execution can be different on different VM's, it also dependent of machine speed, etc. Thanks, Vladimir. On 6/22/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I've confused all the things. Sorry. Of course the tests should go to math/src/test/performance Vladimir, is it possible to convert the test to JUnit format and make them report pass/fail status rather than printing log? Thanks, Mikhail 2006/6/21, Mikhail Loenko [EMAIL PROTECTED]: I'd like to bring it to common judgment. AFAIU we have two basic options for performance tests location: make them module level or make a top-level tests subtree that would contain all types of the tests except for unit tests BTW, In the testing convention my intent was to cover unit tests only. Though we did not agree which exactly tests are unit, so I avoided that word. But I definitely did not mean performance, stress and whatever special types of the tests. If no one objects I'll add some clarification to the conventions proposal. Thanks, Mikhail 2006/6/20, Vladimir Strigun [EMAIL PROTECTED]: On 6/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I think they are not unit tests and should go to a different (performance?) test suite. Right now we don't have one but it seems to be time to create it Of course, it's not unit tests, but my suggestion was based on our testing convention. What do you think about modulename/src/tests/performance ? Thanks, Vladimir. Thanks, Mikhail 2006/6/20, Vladimir Strigun [EMAIL PROTECTED]: Hi Mikhail, AFAIK, we haven't such kind of tests in svn yet. It's hard to define best place for it, but since this suite is intended for java.math testing only and it's implementation-independent tests, I believe modules/math/src/test/java/tests/api is appropriate place. If you agree with this I will create patch for suite, add copyright and change package definition of classes. What do you think about it? Thanks, Vladimir. On 6/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Vladimir What do you think the most appropriate location and suite for the tests in the HARMONY-551 are? Thanks, Mikhail 2006/6/2, Vladimir Strigun [EMAIL PROTECTED]: Our team has done some analysis of current Harmony implementation of java.math package. The implementation was considered from the performance point of view and I'd like to share results of our work with you. The analysis and tuning was made from the enterprise-level applications point of view which are known to use BigInteger and BigDecimal for storing numeric information. In most cases the numbers there fit well within 32 bits. So coming from the BigDecimal perspective which is really important for these applications and taking into account some specifics (small numbers) we made some optimizations in both BigDecimal and BigInteger. The latter
Re: [classlib][math] Location of performance tests (was: Re: performance improvement for java.math package)
Unfortunately it is not a regression test. It's just micro-benchmark for measure performance of particular methods from BigInteger and BigDecimal classes. So, the result of execution is ops/sec value for every method, and since it dependent on machine speed, VM, etc, comparison between actual and 'golden' values might be incorrect. Thanks, Vladimir. On 6/22/06, Mikhail Loenko [EMAIL PROTECTED] wrote: The first thing that came into my mind is as far as it is a regression test, put somewhere next to the test both old and new Math implementations, measure 'golden' performances and than measure where the current performance in comparison to the golden is. This scenario might be simplified. If your optimization works e.g. for numbers less than say 1'000'000, you can compare performance for 999'999 and 1'000'001 Thanks, Mikhail 2006/6/22, Vladimir Strigun [EMAIL PROTECTED]: Mikhail, I can convert it to JUnit, but I'm not pretty sure about returning pass/fail. When you think test should return fail? Results of test execution can be different on different VM's, it also dependent of machine speed, etc. Thanks, Vladimir. On 6/22/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I've confused all the things. Sorry. Of course the tests should go to math/src/test/performance Vladimir, is it possible to convert the test to JUnit format and make them report pass/fail status rather than printing log? Thanks, Mikhail 2006/6/21, Mikhail Loenko [EMAIL PROTECTED]: I'd like to bring it to common judgment. AFAIU we have two basic options for performance tests location: make them module level or make a top-level tests subtree that would contain all types of the tests except for unit tests BTW, In the testing convention my intent was to cover unit tests only. Though we did not agree which exactly tests are unit, so I avoided that word. But I definitely did not mean performance, stress and whatever special types of the tests. If no one objects I'll add some clarification to the conventions proposal. Thanks, Mikhail 2006/6/20, Vladimir Strigun [EMAIL PROTECTED]: On 6/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I think they are not unit tests and should go to a different (performance?) test suite. Right now we don't have one but it seems to be time to create it Of course, it's not unit tests, but my suggestion was based on our testing convention. What do you think about modulename/src/tests/performance ? Thanks, Vladimir. Thanks, Mikhail 2006/6/20, Vladimir Strigun [EMAIL PROTECTED]: Hi Mikhail, AFAIK, we haven't such kind of tests in svn yet. It's hard to define best place for it, but since this suite is intended for java.math testing only and it's implementation-independent tests, I believe modules/math/src/test/java/tests/api is appropriate place. If you agree with this I will create patch for suite, add copyright and change package definition of classes. What do you think about it? Thanks, Vladimir. On 6/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Vladimir What do you think the most appropriate location and suite for the tests in the HARMONY-551 are? Thanks, Mikhail 2006/6/2, Vladimir Strigun [EMAIL PROTECTED]: Our team has done some analysis of current Harmony implementation of java.math package. The implementation was considered from the performance point of view and I'd like to share results of our work with you. The analysis and tuning was made from the enterprise-level applications point of view which are known to use BigInteger and BigDecimal for storing numeric information. In most cases the numbers there fit well within 32 bits. So coming from the BigDecimal perspective which is really important for these applications and taking into account some specifics (small numbers) we made some optimizations in both BigDecimal and BigInteger. The latter was tuned specifically for BigDecimal: - Special handling for small numbers (fit within 32 bit) was added to all methods - Frequently used constants (0..10) were cached and reused by valueOf method (no need to create a new instance of BigInteger) - as well as were powers of 10 (0..10) - methods add(), divide(), divideAndRemainer() in BigInteger were optimized for short values if both arguments can fit in 32 bits the resulting BigInteger is created by valueOf method. If we consider enterprise level applications, we can imagine that toString() method is also frequently used. The method was analyzed and as a result we combined toString() methods
Re: [classlib][math] Location of performance tests (was: Re: performance improvement for java.math package)
Mikhail, I can convert it to JUnit, but I'm not pretty sure about returning pass/fail. When you think test should return fail? Results of test execution can be different on different VM's, it also dependent of machine speed, etc. Thanks, Vladimir. On 6/22/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I've confused all the things. Sorry. Of course the tests should go to math/src/test/performance Vladimir, is it possible to convert the test to JUnit format and make them report pass/fail status rather than printing log? Thanks, Mikhail 2006/6/21, Mikhail Loenko [EMAIL PROTECTED]: I'd like to bring it to common judgment. AFAIU we have two basic options for performance tests location: make them module level or make a top-level tests subtree that would contain all types of the tests except for unit tests BTW, In the testing convention my intent was to cover unit tests only. Though we did not agree which exactly tests are unit, so I avoided that word. But I definitely did not mean performance, stress and whatever special types of the tests. If no one objects I'll add some clarification to the conventions proposal. Thanks, Mikhail 2006/6/20, Vladimir Strigun [EMAIL PROTECTED]: On 6/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I think they are not unit tests and should go to a different (performance?) test suite. Right now we don't have one but it seems to be time to create it Of course, it's not unit tests, but my suggestion was based on our testing convention. What do you think about modulename/src/tests/performance ? Thanks, Vladimir. Thanks, Mikhail 2006/6/20, Vladimir Strigun [EMAIL PROTECTED]: Hi Mikhail, AFAIK, we haven't such kind of tests in svn yet. It's hard to define best place for it, but since this suite is intended for java.math testing only and it's implementation-independent tests, I believe modules/math/src/test/java/tests/api is appropriate place. If you agree with this I will create patch for suite, add copyright and change package definition of classes. What do you think about it? Thanks, Vladimir. On 6/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Vladimir What do you think the most appropriate location and suite for the tests in the HARMONY-551 are? Thanks, Mikhail 2006/6/2, Vladimir Strigun [EMAIL PROTECTED]: Our team has done some analysis of current Harmony implementation of java.math package. The implementation was considered from the performance point of view and I'd like to share results of our work with you. The analysis and tuning was made from the enterprise-level applications point of view which are known to use BigInteger and BigDecimal for storing numeric information. In most cases the numbers there fit well within 32 bits. So coming from the BigDecimal perspective which is really important for these applications and taking into account some specifics (small numbers) we made some optimizations in both BigDecimal and BigInteger. The latter was tuned specifically for BigDecimal: - Special handling for small numbers (fit within 32 bit) was added to all methods - Frequently used constants (0..10) were cached and reused by valueOf method (no need to create a new instance of BigInteger) - as well as were powers of 10 (0..10) - methods add(), divide(), divideAndRemainer() in BigInteger were optimized for short values if both arguments can fit in 32 bits the resulting BigInteger is created by valueOf method. If we consider enterprise level applications, we can imagine that toString() method is also frequently used. The method was analyzed and as a result we combined toString() methods in BigDecimal and BigInteger to one unified method in BigInteger. Method BigInteger.toDecimalScaledString(int scale) now is used from both BigInteger and BigDecimal. This way allows reducing amount of created objects and data copying. In addition, size calculation was modified for resulting array. In the new implementation the size is calculated with less precision. Because allocated char array will be copied into String and collected by GC after toString() then it is not a problem if the allocated char array will be slightly bigger then necessary. I've attached the changes we made for BigInteger and BigDecimal to Harmony-551 We also have created a set of micro benchmarks (which I'll to attach to JIRA as well) which shows that our special-case handling doesn't break the performance for other cases and we do not degrade in common, and, of course, all unit tests pass with new version. Below you can find several comparisons in performance between current version
Re: [classlib][java.math]performance improvement for java.math package
Hi Daniel, Thank you for your response and sorry for delay with my answer. Please find my comments inside. On 6/15/06, Daniel Fridlender [EMAIL PROTECTED] wrote: Hi Vladimir, thank you very much for this new optimization of math from, as you said, enterprise-level applications point of view. Of course we are considering this optimization (H551) as well for the combination of the different math implementations into a new and more efficient one. In fact we are already working on a new version combining H39+380 with H199 and are introducing some of H551 optimizations as well. On the other hand, we are for the moment postponing some other of your optimizations for a future version since introducing them now would break, in my opinion prematurely, a nice design property we have so far: BigDecimal depends only on public features of BigInteger. Thanks for doing this. What kind of optimization you planned to add first? I can agree that it's good to have such design, but nevertheless since BigDecimal internally represented though BigInteger, possibly it should be also good to use some non public features of BigInteger. So, we are following this plan: 1) integration of H39+H380 with H199 and with part of H551 2) optimization of this with more advanced algorithms 3) introducing remaining optimization from H551 For the point 2) above I would still like to have independence between BigDecimal and BigInteger. I hope you agree with this plan. Yes, this plan sounds good for me. Let's follow it and compare implementations after 1st integration. We can use microbench that attached to the issue, or, possibly we should find another benchmark for it. What benchmarks you have used for performance measurement? I would also be grateful if you could be more specific when you mention enterprise-level applications. We are looking for realistic applications of math in order to be able to get an idea of how the implementations will work in practice. So far we had only found a few applications in cryptography and in number factorization (actually, they are applications of BigInteger only). Could you point me to the applications you had in mind so that we can add them to our (so far) small collection of applications? Are those applications for which float or double are not enough? I have in mind some banking software, online payment processing, etc. Within these type of application values usually fit to 32 bit, that's why we have special case for small numbers. Also, these optimizations do not degrade in common. Thanks, Vladimir. Thanks again, Daniel On 6/2/06, Vladimir Strigun [EMAIL PROTECTED] wrote: Our team has done some analysis of current Harmony implementation of java.math package. The implementation was considered from the performance point of view and I'd like to share results of our work with you. The analysis and tuning was made from the enterprise-level applications point of view which are known to use BigInteger and BigDecimal for storing numeric information. In most cases the numbers there fit well within 32 bits. So coming from the BigDecimal perspective which is really important for these applications and taking into account some specifics (small numbers) we made some optimizations in both BigDecimal and BigInteger. The latter was tuned specifically for BigDecimal: - Special handling for small numbers (fit within 32 bit) was added to all methods - Frequently used constants (0..10) were cached and reused by valueOf method (no need to create a new instance of BigInteger) - as well as were powers of 10 (0..10) - methods add(), divide(), divideAndRemainer() in BigInteger were optimized for short values if both arguments can fit in 32 bits the resulting BigInteger is created by valueOf method. If we consider enterprise level applications, we can imagine that toString() method is also frequently used. The method was analyzed and as a result we combined toString() methods in BigDecimal and BigInteger to one unified method in BigInteger. Method BigInteger.toDecimalScaledString(int scale) now is used from both BigInteger and BigDecimal. This way allows reducing amount of created objects and data copying. In addition, size calculation was modified for resulting array. In the new implementation the size is calculated with less precision. Because allocated char array will be copied into String and collected by GC after toString() then it is not a problem if the allocated char array will be slightly bigger then necessary. I've attached the changes we made for BigInteger and BigDecimal to Harmony-551 We also have created a set of micro benchmarks (which I'll to attach to JIRA as well) which shows that our special-case handling doesn't break the performance for other cases and we do not degrade in common, and, of course, all unit tests pass with new version. Below you can find several comparisons in performance between current version and the fixed one
Re: [classlib][java.math]performance improvement for java.math package
Hi Mikhail, AFAIK, we haven't such kind of tests in svn yet. It's hard to define best place for it, but since this suite is intended for java.math testing only and it's implementation-independent tests, I believe modules/math/src/test/java/tests/api is appropriate place. If you agree with this I will create patch for suite, add copyright and change package definition of classes. What do you think about it? Thanks, Vladimir. On 6/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Vladimir What do you think the most appropriate location and suite for the tests in the HARMONY-551 are? Thanks, Mikhail 2006/6/2, Vladimir Strigun [EMAIL PROTECTED]: Our team has done some analysis of current Harmony implementation of java.math package. The implementation was considered from the performance point of view and I'd like to share results of our work with you. The analysis and tuning was made from the enterprise-level applications point of view which are known to use BigInteger and BigDecimal for storing numeric information. In most cases the numbers there fit well within 32 bits. So coming from the BigDecimal perspective which is really important for these applications and taking into account some specifics (small numbers) we made some optimizations in both BigDecimal and BigInteger. The latter was tuned specifically for BigDecimal: - Special handling for small numbers (fit within 32 bit) was added to all methods - Frequently used constants (0..10) were cached and reused by valueOf method (no need to create a new instance of BigInteger) - as well as were powers of 10 (0..10) - methods add(), divide(), divideAndRemainer() in BigInteger were optimized for short values if both arguments can fit in 32 bits the resulting BigInteger is created by valueOf method. If we consider enterprise level applications, we can imagine that toString() method is also frequently used. The method was analyzed and as a result we combined toString() methods in BigDecimal and BigInteger to one unified method in BigInteger. Method BigInteger.toDecimalScaledString(int scale) now is used from both BigInteger and BigDecimal. This way allows reducing amount of created objects and data copying. In addition, size calculation was modified for resulting array. In the new implementation the size is calculated with less precision. Because allocated char array will be copied into String and collected by GC after toString() then it is not a problem if the allocated char array will be slightly bigger then necessary. I've attached the changes we made for BigInteger and BigDecimal to Harmony-551 We also have created a set of micro benchmarks (which I'll to attach to JIRA as well) which shows that our special-case handling doesn't break the performance for other cases and we do not degrade in common, and, of course, all unit tests pass with new version. Below you can find several comparisons in performance between current version and the fixed one. === Ops/sec for toString() method of BigDecimal Number Current fixed one of digits version 2 11215354 4 774 7514 8 615 6748 12 743 5543 16 623 4494 24 389 4895 32 306 3496 48 232 5815 64 224 3761 128 91 87 Ops/sec for divide method of BigInteger Number Current fixed one of digits version 2 52476315 4 46236497 8 55607491 12 838 838 16 25332063 24 16891717 32 23972494 48 21432131 64 613 525 128 13991418 Ops/sec for subtract method of BigInteger Number Current fixed one of digits version 2 39204394 4 33003302 8 51785640 12 957 913 16 37942904 24 20571962 32 34213241 48 34692828 64 652 610 128 23182246 === Unfortunately we haven't look thoroughly to ITC contribution, so it may happen that some of the optimizations described in this letter were already implemented there. Daniel, could you please consider our new implementation when you start to merge implementations math packages. If optimization methods described above already have been implemented in ITC contribution it will be great to compare internal representation of BigInteger and try to measure affect of different approaches. On 6/2/06, Vladimir Strigun (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-551?page=all ] Vladimir Strigun updated HARMONY-551: - Attachment: Harmony-551.diffs Please try my patch. Several features were added: - special handling for small value - frequently used constans were cached - several methods were modified and optimized for small value. etc. [classlib][java.math] performance improvement
Re: [classlib][java.math]performance improvement for java.math package
On 6/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I think they are not unit tests and should go to a different (performance?) test suite. Right now we don't have one but it seems to be time to create it Of course, it's not unit tests, but my suggestion was based on our testing convention. What do you think about modulename/src/tests/performance ? Thanks, Vladimir. Thanks, Mikhail 2006/6/20, Vladimir Strigun [EMAIL PROTECTED]: Hi Mikhail, AFAIK, we haven't such kind of tests in svn yet. It's hard to define best place for it, but since this suite is intended for java.math testing only and it's implementation-independent tests, I believe modules/math/src/test/java/tests/api is appropriate place. If you agree with this I will create patch for suite, add copyright and change package definition of classes. What do you think about it? Thanks, Vladimir. On 6/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Vladimir What do you think the most appropriate location and suite for the tests in the HARMONY-551 are? Thanks, Mikhail 2006/6/2, Vladimir Strigun [EMAIL PROTECTED]: Our team has done some analysis of current Harmony implementation of java.math package. The implementation was considered from the performance point of view and I'd like to share results of our work with you. The analysis and tuning was made from the enterprise-level applications point of view which are known to use BigInteger and BigDecimal for storing numeric information. In most cases the numbers there fit well within 32 bits. So coming from the BigDecimal perspective which is really important for these applications and taking into account some specifics (small numbers) we made some optimizations in both BigDecimal and BigInteger. The latter was tuned specifically for BigDecimal: - Special handling for small numbers (fit within 32 bit) was added to all methods - Frequently used constants (0..10) were cached and reused by valueOf method (no need to create a new instance of BigInteger) - as well as were powers of 10 (0..10) - methods add(), divide(), divideAndRemainer() in BigInteger were optimized for short values if both arguments can fit in 32 bits the resulting BigInteger is created by valueOf method. If we consider enterprise level applications, we can imagine that toString() method is also frequently used. The method was analyzed and as a result we combined toString() methods in BigDecimal and BigInteger to one unified method in BigInteger. Method BigInteger.toDecimalScaledString(int scale) now is used from both BigInteger and BigDecimal. This way allows reducing amount of created objects and data copying. In addition, size calculation was modified for resulting array. In the new implementation the size is calculated with less precision. Because allocated char array will be copied into String and collected by GC after toString() then it is not a problem if the allocated char array will be slightly bigger then necessary. I've attached the changes we made for BigInteger and BigDecimal to Harmony-551 We also have created a set of micro benchmarks (which I'll to attach to JIRA as well) which shows that our special-case handling doesn't break the performance for other cases and we do not degrade in common, and, of course, all unit tests pass with new version. Below you can find several comparisons in performance between current version and the fixed one. === Ops/sec for toString() method of BigDecimal Number Current fixed one of digits version 2 11215354 4 774 7514 8 615 6748 12 743 5543 16 623 4494 24 389 4895 32 306 3496 48 232 5815 64 224 3761 128 91 87 Ops/sec for divide method of BigInteger Number Current fixed one of digits version 2 52476315 4 46236497 8 55607491 12 838 838 16 25332063 24 16891717 32 23972494 48 21432131 64 613 525 128 13991418 Ops/sec for subtract method of BigInteger Number Current fixed one of digits version 2 39204394 4 33003302 8 51785640 12 957 913 16 37942904 24 20571962 32 34213241 48 34692828 64 652 610 128 23182246 === Unfortunately we haven't look thoroughly to ITC contribution, so it may happen that some of the optimizations described in this letter were already implemented there. Daniel, could you please consider our new implementation when you start to merge implementations math packages. If optimization methods described above already have been
Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer, CharBuffer, boolean) should set correct position in ByteBuffer
Hi Andrew, Thanks for your answer, please see my comments inside. On 5/22/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi, Mikhail and Vladimir, I'd rather consider it as compatibility bug and close it as wontfix. Yes, we can close the issue as wontfix with compatibility comments, but I think we should put some description to Wiki. Or possible you can suggest more appropriate place for this. Did I get it right that both solutions do not contradict to the spec and that RI acts as the second one? Partly right. Vladimir, maybe as you know, deep studying on decode will show many RI's unreasonable behaviours. Since RI's behaviour is not logical and the spec description is very vague in some situations (e.g. decode state defination, in/out buffer poistion defination), I can't say that RI's behaviour is not logical, but I can agree that decoding process implemented in Harmony is more convenient for developers (you don't need to get undecoded part from buffer and put it to the next decoding operation). we finally decided not to follow RI's behaviour. IMO, current Harmony implementation complies with spec strictly, acts in logical way and also doesn't affect end-users. So I'd rather consider it as compatibility bug and close it as wontfix. Corresponding to my previous comment, I can't agree that Harmony strictly comply with the spec, it's just our understanding of the spec. That's why I'd like to document this behaviour. Thanks. Vladimir. What's your opnion? Thanks. On 5/15/06, Vladimir Strigun [EMAIL PROTECTED] wrote: 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
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 soon. -- 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 -- Andrew Zhang China
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: 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? 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 soon. -- 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 -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (HARMONY-33) java.nio.BufferOverflow exception while decoding ByteBuffer with UTF-16 charset
Andrew,
thanks for your comments. Looks like the bug in ICU is very simple and
I hope it will be fixed in the next ICU release. I just like to reopen
harmony-33 to correctly track issue status. At the moment it
reproduced with icu4jni3.4 , that's why I asked to reopen. As soon as
we get new version of ICU bug should be closed.
Thanks.
Vladimir.
On 5/5/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi, Vladimir
The bug has been raised in ICU bug tracking system serveral months ago[1].
ICU has noticed this bug and will fix the bug in next release version.
Thanks.
[1] (http://bugs.icu-project.org/cgi-bin/icu-bugs/conversion?id=5074)
On 5/4/06, Vladimir Strigun (JIRA) [EMAIL PROTECTED] wrote:
[
http://issues.apache.org/jira/browse/HARMONY-33?page=comments#action_12377817]
Vladimir Strigun commented on HARMONY-33:
-
Unfortunately the bug should be reopened. I have the next output with
Harmony33 class:
java.lang.IllegalArgumentException: The length must be positive.
at java.nio.charset.CoderResult.malformedForLength(CoderResult.java
:152)
at com.ibm.icu4jni.charset.CharsetDecoderICU.implFlush(Unknown
Source)
at java.nio.charset.CharsetDecoder.flush(CharsetDecoder.java:571)
at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:254)
at Harmony33.main(Harmony33.java:11)
It's not a regression, the problem here is inside implFlush method of
CharsetDecoderICU .
Corresponding bug was submitted to ICU already:
http://bugs.icu-project.org/cgi-bin/icu-bugs?findid=5074
So, we just need to wait until we get new version of ICU library.
java.nio.BufferOverflow exception while decoding ByteBuffer with UTF-16
charset
---
Key: HARMONY-33
URL: http://issues.apache.org/jira/browse/HARMONY-33
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Assignee: Tim Ellison
Priority: Minor
If I try to decode ByteBuffer with lengh 1 using UTF-16 decoder
unexpected java.nio.BufferOverflow exception occured. Please see testcase
below.
import java.nio.*;
import java.nio.charset.*;
import junit.framework.TestCase;
public class TestDecoder extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(TestDecoder.class);
}
public static void testDecoder(){
try{
ByteBuffer bb = ByteBuffer.allocate(1);
bb.put(0,(byte)77);
CharsetDecoder utf16D = Charset.forName
(UTF-16).newDecoder();
CharBuffer cb = utf16D.onMalformedInput(
CodingErrorAction.REPLACE).onUnmappableCharacter(CodingErrorAction.REPLACE
).decode(bb);
}catch(Exception e){
fail(Exception occured: +e);
}
}
}
Output on RI:
.
Time: 0,03
OK (1 test)
Output with Harmony:
.F
Time: 0,01
There was 1 failure:
1) testDecoder(TestDecoder)junit.framework.AssertionFailedError:
Exception occured: java.nio.BufferOverflowException
at TestDecoder.testDecoder(TestDecoder.java:20)
at java.lang.reflect.AccessibleObject.invokeV(
AccessibleObject.java:211)
at TestDecoder.main(TestDecoder.java:10)
FAILURES!!!
Tests run: 1, Failures: 1, Errors: 0
--
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
--
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]
[classlib] charset decoding
On 4/26/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi Vladimir, I think we both understand the spec :) 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. 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? I try to find best solution for Harmony-166 and during fix preparation I've found current issue. Method test_read from tests.api.java.io.InputStreamReaderTest failed and first fix I've created was with in.available() but I agree with Mikhail that it's possible not the best solution. In current implementation of InputStreamReader endOfInput variable sets to true if reader can't read less that 8192 bytes. When InputStreamReader try to read one character from LimitedByteArrayInputStream (A ByteArrayInputStream that only returns a single byte per read) true as a parameter passed to charset decoder, nevertheless we still have further input from LimitedByteArrayInputStream. 2 methods from tests.api.java.io.OutputStreamWriterTest also failed because of read() method implementation of InputStreamReader. IMO, we have 2 ways to fix Harmony-166 : 1. Don't change the behavior of CharsetDecoder, and use in.available() method for endOfInput variable. If in.available() 0 pass false to decoder, read additional one byte from input stream and try to decode again. If decoding operation can decode remaining portion + one additional byte to character, stop here, else try to read addition byte again. Function fillBuf will invoke with the next invocation of read() method and next portion of 8192 bytes will be read from input stream. 2. Change the behavior of CharsetDecoder and operate with bytes.remaining() for calculating endOfInput. In this case, we always pass false with first invocation of decode method. Algorithm further is almost the same as above, but we stop the cycle if all bytes decoded successfully (i.e if bytes.hasRemaining() is false). What do you think about it? Thanks. Vladimir. 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
Re: relying on 'available()' (was: RE: [jira] Updated: (HARMONY-166) method read() in InputStreamReader failed to read one character)
Mikhail,
OK, I'll prepare new patch. I've found other 2 issues that can affect
InputStreamReader and I'll submit it soon.
Thanks.
Vladimir.
On 4/25/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Vladimir,
Method available() is still used to determine endOfInput parameter.
According to specification the
method should be overridden by subclasses.
'should' does not mean 'must' , moreover it might be a user class who
does not care what the spec says. There could be cases when you do not
know how many bytes are available and you have to return 0.
So I think the patch should be modified to avoid 'available()'
Thanks,
Mikhail
-Original Message-
From: Vladimir Strigun (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Monday, April 24, 2006 5:14 PM
To: [EMAIL PROTECTED]
Subject: [jira] Updated: (HARMONY-166) method read() in
InputStreamReader failed to read one
character
[ http://issues.apache.org/jira/browse/HARMONY-166?page=all ]
Vladimir Strigun updated HARMONY-166:
-
Attachment: InputStreamReader.java.patch
Mikhail,
please review my patch. Now method read() is not modified. I just
add decoding operations to
fillBuf() method.
Method available() is still used to determine endOfInput parameter.
According to specification the
method should be overridden by subclasses.
method read() in InputStreamReader failed to read one character
---
Key: HARMONY-166
URL: http://issues.apache.org/jira/browse/HARMONY-166
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Attachments: InputStreamReader.java.patch, InputStreamReader.patch.txt,
InputStreamReaderTest.java
I've started to play with harmony-57 contribution and found bug in
InputStreamReader class.
Method read() should read a single character from input stream but it
works incorrectly for 2
bytes-per-char charsets. Example below shows that it failed to read
one character in UTF-16
charset. Sorry for so ugly test, it's just a part of
InputStreamReaderTest from Harmony-57
contribution.
import java.io.*;
import junit.framework.TestCase;
public class InputStreamReaderTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(InputStreamReaderTest.class);
}
public void test_ISR_read() throws Exception {
InputStream in;
InputStreamReader reader;
try {
in = new LimitedByteArrayInputStream(0);
reader = new InputStreamReader(in, UTF-16BE);
int xx = reader.read();
assertTrue(Incorrect byte UTF-16BE, xx == '\u6172');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
System.out.println(e);
} catch (IOException e) {
e.printStackTrace();
fail(UTF-16BE unexpected 1: + e);
}
try {
in = new LimitedByteArrayInputStream(0);
reader = new InputStreamReader(in, UTF-16LE);
int xx = reader.read();
assertTrue(Incorrect byte UTF-16BE, xx == '\u7261');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
} catch (IOException e) {
fail(UTF-16BE unexpected 2: + e);
}
try {
in = new LimitedByteArrayInputStream(1);
reader = new InputStreamReader(in, UTF-16);
assertTrue(Incorrect byte UTF-16BE, reader.read() == '\u7261');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
} catch (IOException e) {
fail(UTF-16BE unexpected 3: + e);
}
try {
in = new LimitedByteArrayInputStream(2);
reader = new InputStreamReader(in, ISO2022JP);
int ch = reader.read();
assertTrue(Incorrect byte ISO2022JP 1: + ch, ch == '\u4e5d');
ch = reader.read();
assertTrue(Incorrect byte ISO2022JP 2: + ch, ch == '\u7b2c');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
System.out.println(e);
} catch (IOException e) {
fail(ISO2022JP unexpected: + e);
}
}
static class LimitedByteArrayInputStream extends ByteArrayInputStream {
// A ByteArrayInputStream that only returns a single byte per read
byte[] bytes;
int count;
public LimitedByteArrayInputStream(int type) {
super(new byte[0]);
switch (type) {
case 0:
bytes = new byte[] { 0x61, 0x72 };
break;
case 1:
bytes = new byte[] { (byte) 0xff, (byte) 0xfe, 0x61, 0x72 };
break;
case 2:
bytes = new byte[] { '\u001b', '$', 'B', '6', 'e', 'B', 'h',
'\u001b', '(', 'B' };
break;
}
count = bytes.length;
}
public int read() {
if (count == 0)
return -1;
count--;
return bytes[bytes.length - count];
}
public int read(byte[] buffer, int offset, int length) {
if (count == 0)
return -1;
if (length == 0)
return 0;
buffer[offset] = bytes[bytes.length - count];
count--;
return 1;
}
public int available() {
return count;
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one
Re: downloading dependencies
Works for me also. Explicit call of setproxy can be removed. Thanks
Matt, and sorry for the misunderstanding.
Thanks,
Vladimir.
On 3/17/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
I've tried what Matt recommended and it works!
I think it is also README that should be updated
Thanks,
Mikhail
2006/3/16, Tim Ellison [EMAIL PROTECTED]:
d'oh -- got it, thanks Matt.
Vladimir: If you give me the all clear I'll back-out the explicit call
to setproxy (but leave the comments in the properties file to remind
us how to do it).
Regards,
Tim
Matt Benson wrote:
again, guys, to be sure it's not missed:
adding -Dhttp.proxyHost=proxy -Dhttp.proxyPort=8080
to the ANT_OPTS environment variable should be
sufficient for command-line Ant without explicitly
invoking setproxy.
-Matt
--- Vladimir Strigun [EMAIL PROTECTED] wrote:
Thanks Tim, everything works fine.
Thanks,
Vladimir.
On 3/16/06, Tim Ellison [EMAIL PROTECTED]
wrote:
Exactly, thanks Vladimir. I've put that in at
repo revision 386377
(with slightly modified property names).
Let me know if you need more.
Thanks,
Tim
Vladimir Strigun wrote:
For instance, we can add set-proxy target to
depends.xml:
Index: classlib/trunk/make/depends.xml
===
--- classlib/trunk/make/depends.xml
(revision 386350)
+++ classlib/trunk/make/depends.xml (working
copy)
@@ -59,6 +59,8 @@
target name=download
description=Download required jars
+antcall target=set-proxy/
+
mkdir dir=${xalan.dir} /
antcall target=download-one-jar
param name=src value=${xalan.url} /
@@ -93,6 +95,10 @@
get src=${src} dest=${dest}
usetimestamp=true verbose=true /
/target
+ target name=set-proxy if=proxy
+setproxy proxyhost=${proxy}
proxyport=${port}/
+ /target
+
target name=check-one-jar
available file=${dest} type=file
property=${dest}.exists /
fail
So, if you use proxy you just need to pass proxy
parameters in command line:
ant -Dproxy=proxy -Dport=80 -f depends.xml
download
Otherwise, it will try to download files without
proxy.
Thanks,
Vladimir.
On 3/16/06, Tim Ellison [EMAIL PROTECTED]
wrote:
Perhaps we can put the proxy properties into
the make/depends.properties
file and people can override on the
command-line or edit that file to
reflect their set-up.
The builds now check for dependencies so you
can add them into the right
structure manually and avoid all this.
Regards,
Tim
Vladimir Strigun wrote:
Mikhail,
You can use ant setproxy[1] task for resolving
the problem. It works
for me. On the other hand, I don't think we
should patch build files.
Perhaps, It will be useful to document this
somewhere.
Thanks,
Vladimir.
[1]
http://ant.apache.org/manual/OptionalTasks/setproxy.html
On 3/16/06, Mikhail Loenko [EMAIL PROTECTED]
wrote:
Tim, Mark
revisions 386087, 386171 of that file break
my build:
prepare-depends:
[get] Getting:
http://www.ibiblio.org/maven/xalan/jars/xalan-2.6.0.jar
[get] To:
C:\harmony\depends\jars\xalan-j_2.6.0\xalan.jar
[get] Error getting
http://www.ibiblio.org/maven/xalan/jars/xalan-2.6.0.jar
to C:\
depends\jars\xalan-j_2.6.0\xalan.jar
BUILD FAILED
C:\harmony\make\build.xml:36: The following
error occurred while
executing this line:
C:\harmony\make\build-java.xml:352:
java.net.NoRouteToHostException:
Operation timed out
The problem seems to be with proxy setting
Thanks,
Mikhail Loenko
Intel Middleware Products Division
2006/3/16, Mark Hindess
[EMAIL PROTECTED]:
Thanks Tim. I spotted that I'd missed that
one too.
-Mark.
On 3/15/06, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Author: tellison
Date: Wed Mar 15 13:37:44 2006
New Revision: 386171
URL:
http://svn.apache.org/viewcvs?rev=386171view=rev
Log:
Ensure the XML JARs go directly into the
boot dir
Modified:
incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
Modified:
incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
URL:
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/make/build-java.xml?rev=386171r1=386170r2=386171view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
(original)
+++
incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
Wed Mar 15 13:37:44 2006
@@ -282,7 +282,7 @@
!-- Copy across the dependency
jars --
copy
todir=${target.output}/jre/lib/boot
overwrite=yes
- verbose=yes
Re: svn commit: r386171 - /incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
Mikhail,
You can use ant setproxy[1] task for resolving the problem. It works
for me. On the other hand, I don't think we should patch build files.
Perhaps, It will be useful to document this somewhere.
Thanks,
Vladimir.
[1] http://ant.apache.org/manual/OptionalTasks/setproxy.html
On 3/16/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Tim, Mark
revisions 386087, 386171 of that file break my build:
prepare-depends:
[get] Getting: http://www.ibiblio.org/maven/xalan/jars/xalan-2.6.0.jar
[get] To: C:\harmony\depends\jars\xalan-j_2.6.0\xalan.jar
[get] Error getting
http://www.ibiblio.org/maven/xalan/jars/xalan-2.6.0.jar to C:\
depends\jars\xalan-j_2.6.0\xalan.jar
BUILD FAILED
C:\harmony\make\build.xml:36: The following error occurred while
executing this line:
C:\harmony\make\build-java.xml:352: java.net.NoRouteToHostException:
Operation timed out
The problem seems to be with proxy setting
Thanks,
Mikhail Loenko
Intel Middleware Products Division
2006/3/16, Mark Hindess [EMAIL PROTECTED]:
Thanks Tim. I spotted that I'd missed that one too.
-Mark.
On 3/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: tellison
Date: Wed Mar 15 13:37:44 2006
New Revision: 386171
URL: http://svn.apache.org/viewcvs?rev=386171view=rev
Log:
Ensure the XML JARs go directly into the boot dir
Modified:
incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
Modified: incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
URL:
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/make/build-java.xml?rev=386171r1=386170r2=386171view=diff
==
--- incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
(original)
+++ incubator/harmony/enhanced/classlib/trunk/make/build-java.xml Wed Mar
15 13:37:44 2006
@@ -282,7 +282,7 @@
!-- Copy across the dependency jars --
copy todir=${target.output}/jre/lib/boot overwrite=yes
- verbose=yes
+ verbose=yes flatten=yes
fileset dir=${depends.jars}
patternset includes=*.jar /
patternset includes=xerces_2.6.2/*.jar /
--
Mark Hindess [EMAIL PROTECTED]
IBM Java Technology Centre, UK.
Re: downloading dependencies (was: Re: svn commit: r386171 - /incubator/harmony/enhanced/classlib/trunk/make/build-java.xml)
For instance, we can add set-proxy target to depends.xml:
Index: classlib/trunk/make/depends.xml
===
--- classlib/trunk/make/depends.xml (revision 386350)
+++ classlib/trunk/make/depends.xml (working copy)
@@ -59,6 +59,8 @@
target name=download
description=Download required jars
+antcall target=set-proxy/
+
mkdir dir=${xalan.dir} /
antcall target=download-one-jar
param name=src value=${xalan.url} /
@@ -93,6 +95,10 @@
get src=${src} dest=${dest} usetimestamp=true verbose=true /
/target
+ target name=set-proxy if=proxy
+setproxy proxyhost=${proxy} proxyport=${port}/
+ /target
+
target name=check-one-jar
available file=${dest} type=file property=${dest}.exists /
fail
So, if you use proxy you just need to pass proxy parameters in command line:
ant -Dproxy=proxy -Dport=80 -f depends.xml download
Otherwise, it will try to download files without proxy.
Thanks,
Vladimir.
On 3/16/06, Tim Ellison [EMAIL PROTECTED] wrote:
Perhaps we can put the proxy properties into the make/depends.properties
file and people can override on the command-line or edit that file to
reflect their set-up.
The builds now check for dependencies so you can add them into the right
structure manually and avoid all this.
Regards,
Tim
Vladimir Strigun wrote:
Mikhail,
You can use ant setproxy[1] task for resolving the problem. It works
for me. On the other hand, I don't think we should patch build files.
Perhaps, It will be useful to document this somewhere.
Thanks,
Vladimir.
[1] http://ant.apache.org/manual/OptionalTasks/setproxy.html
On 3/16/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Tim, Mark
revisions 386087, 386171 of that file break my build:
prepare-depends:
[get] Getting: http://www.ibiblio.org/maven/xalan/jars/xalan-2.6.0.jar
[get] To: C:\harmony\depends\jars\xalan-j_2.6.0\xalan.jar
[get] Error getting
http://www.ibiblio.org/maven/xalan/jars/xalan-2.6.0.jar to C:\
depends\jars\xalan-j_2.6.0\xalan.jar
BUILD FAILED
C:\harmony\make\build.xml:36: The following error occurred while
executing this line:
C:\harmony\make\build-java.xml:352: java.net.NoRouteToHostException:
Operation timed out
The problem seems to be with proxy setting
Thanks,
Mikhail Loenko
Intel Middleware Products Division
2006/3/16, Mark Hindess [EMAIL PROTECTED]:
Thanks Tim. I spotted that I'd missed that one too.
-Mark.
On 3/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: tellison
Date: Wed Mar 15 13:37:44 2006
New Revision: 386171
URL: http://svn.apache.org/viewcvs?rev=386171view=rev
Log:
Ensure the XML JARs go directly into the boot dir
Modified:
incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
Modified: incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
URL:
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/make/build-java.xml?rev=386171r1=386170r2=386171view=diff
==
--- incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
(original)
+++ incubator/harmony/enhanced/classlib/trunk/make/build-java.xml Wed
Mar 15 13:37:44 2006
@@ -282,7 +282,7 @@
!-- Copy across the dependency jars --
copy todir=${target.output}/jre/lib/boot overwrite=yes
- verbose=yes
+ verbose=yes flatten=yes
fileset dir=${depends.jars}
patternset includes=*.jar /
patternset includes=xerces_2.6.2/*.jar /
--
Mark Hindess [EMAIL PROTECTED]
IBM Java Technology Centre, UK.
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Re: downloading dependencies
Thanks Tim, everything works fine.
Thanks,
Vladimir.
On 3/16/06, Tim Ellison [EMAIL PROTECTED] wrote:
Exactly, thanks Vladimir. I've put that in at repo revision 386377
(with slightly modified property names).
Let me know if you need more.
Thanks,
Tim
Vladimir Strigun wrote:
For instance, we can add set-proxy target to depends.xml:
Index: classlib/trunk/make/depends.xml
===
--- classlib/trunk/make/depends.xml (revision 386350)
+++ classlib/trunk/make/depends.xml (working copy)
@@ -59,6 +59,8 @@
target name=download
description=Download required jars
+antcall target=set-proxy/
+
mkdir dir=${xalan.dir} /
antcall target=download-one-jar
param name=src value=${xalan.url} /
@@ -93,6 +95,10 @@
get src=${src} dest=${dest} usetimestamp=true verbose=true /
/target
+ target name=set-proxy if=proxy
+setproxy proxyhost=${proxy} proxyport=${port}/
+ /target
+
target name=check-one-jar
available file=${dest} type=file property=${dest}.exists /
fail
So, if you use proxy you just need to pass proxy parameters in command line:
ant -Dproxy=proxy -Dport=80 -f depends.xml download
Otherwise, it will try to download files without proxy.
Thanks,
Vladimir.
On 3/16/06, Tim Ellison [EMAIL PROTECTED] wrote:
Perhaps we can put the proxy properties into the make/depends.properties
file and people can override on the command-line or edit that file to
reflect their set-up.
The builds now check for dependencies so you can add them into the right
structure manually and avoid all this.
Regards,
Tim
Vladimir Strigun wrote:
Mikhail,
You can use ant setproxy[1] task for resolving the problem. It works
for me. On the other hand, I don't think we should patch build files.
Perhaps, It will be useful to document this somewhere.
Thanks,
Vladimir.
[1] http://ant.apache.org/manual/OptionalTasks/setproxy.html
On 3/16/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Tim, Mark
revisions 386087, 386171 of that file break my build:
prepare-depends:
[get] Getting:
http://www.ibiblio.org/maven/xalan/jars/xalan-2.6.0.jar
[get] To: C:\harmony\depends\jars\xalan-j_2.6.0\xalan.jar
[get] Error getting
http://www.ibiblio.org/maven/xalan/jars/xalan-2.6.0.jar to C:\
depends\jars\xalan-j_2.6.0\xalan.jar
BUILD FAILED
C:\harmony\make\build.xml:36: The following error occurred while
executing this line:
C:\harmony\make\build-java.xml:352: java.net.NoRouteToHostException:
Operation timed out
The problem seems to be with proxy setting
Thanks,
Mikhail Loenko
Intel Middleware Products Division
2006/3/16, Mark Hindess [EMAIL PROTECTED]:
Thanks Tim. I spotted that I'd missed that one too.
-Mark.
On 3/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: tellison
Date: Wed Mar 15 13:37:44 2006
New Revision: 386171
URL: http://svn.apache.org/viewcvs?rev=386171view=rev
Log:
Ensure the XML JARs go directly into the boot dir
Modified:
incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
Modified: incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
URL:
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/make/build-java.xml?rev=386171r1=386170r2=386171view=diff
==
--- incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
(original)
+++ incubator/harmony/enhanced/classlib/trunk/make/build-java.xml Wed
Mar 15 13:37:44 2006
@@ -282,7 +282,7 @@
!-- Copy across the dependency jars --
copy todir=${target.output}/jre/lib/boot overwrite=yes
- verbose=yes
+ verbose=yes flatten=yes
fileset dir=${depends.jars}
patternset includes=*.jar /
patternset includes=xerces_2.6.2/*.jar /
--
Mark Hindess [EMAIL PROTECTED]
IBM Java Technology Centre, UK.
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
[jira] Created: (HARMONY-166) method read() in InputStreamReader failed to read one character
method read() in InputStreamReader failed to read one character
---
Key: HARMONY-166
URL: http://issues.apache.org/jira/browse/HARMONY-166
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
I've started to play with harmony-57 contribution and found bug in
InputStreamReader class. Method read() should read a single character from
input stream but it works incorrectly for 2 bytes-per-char charsets. Example
below shows that it failed to read one character in UTF-16 charset. Sorry for
so ugly test, it's just a part of InputStreamReaderTest from Harmony-57
contribution.
import java.io.*;
import junit.framework.TestCase;
public class InputStreamReaderTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(InputStreamReaderTest.class);
}
public void test_ISR_read() throws Exception {
InputStream in;
InputStreamReader reader;
try {
in = new LimitedByteArrayInputStream(0);
reader = new InputStreamReader(in, UTF-16BE);
int xx = reader.read();
assertTrue(Incorrect byte UTF-16BE, xx == '\u6172');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
System.out.println(e);
} catch (IOException e) {
e.printStackTrace();
fail(UTF-16BE unexpected 1: + e);
}
try {
in = new LimitedByteArrayInputStream(0);
reader = new InputStreamReader(in, UTF-16LE);
int xx = reader.read();
assertTrue(Incorrect byte UTF-16BE, xx == '\u7261');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
} catch (IOException e) {
fail(UTF-16BE unexpected 2: + e);
}
try {
in = new LimitedByteArrayInputStream(1);
reader = new InputStreamReader(in, UTF-16);
assertTrue(Incorrect byte UTF-16BE, reader.read() ==
'\u7261');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
} catch (IOException e) {
fail(UTF-16BE unexpected 3: + e);
}
try {
in = new LimitedByteArrayInputStream(2);
reader = new InputStreamReader(in, ISO2022JP);
int ch = reader.read();
assertTrue(Incorrect byte ISO2022JP 1: + ch, ch ==
'\u4e5d');
ch = reader.read();
assertTrue(Incorrect byte ISO2022JP 2: + ch, ch ==
'\u7b2c');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
System.out.println(e);
} catch (IOException e) {
fail(ISO2022JP unexpected: + e);
}
}
static class LimitedByteArrayInputStream extends ByteArrayInputStream {
// A ByteArrayInputStream that only returns a single byte per
read
byte[] bytes;
int count;
public LimitedByteArrayInputStream(int type) {
super(new byte[0]);
switch (type) {
case 0:
bytes = new byte[] { 0x61, 0x72 };
break;
case 1:
bytes = new byte[] { (byte) 0xff, (byte) 0xfe,
0x61, 0x72 };
break;
case 2:
bytes = new byte[] { '\u001b', '$', 'B', '6',
'e', 'B', 'h',
'\u001b', '(', 'B' };
break;
}
count = bytes.length;
}
public int read() {
if (count == 0)
return -1;
count--;
return bytes[bytes.length - count];
}
public int read(byte[] buffer, int offset, int length) {
if (count == 0)
return -1;
if (length == 0)
return 0;
buffer[offset] = bytes[bytes.length - count];
count
[jira] Commented: (HARMONY-166) method read() in InputStreamReader failed to read one character
[
http://issues.apache.org/jira/browse/HARMONY-166?page=comments#action_12368729
]
Vladimir Strigun commented on HARMONY-166:
--
The cause of problem is the following: if decode operation returns underflow,
and the input have available bytes we should read next byte and call decode
operation again. I'll attach fix for the issue soon.
method read() in InputStreamReader failed to read one character
---
Key: HARMONY-166
URL: http://issues.apache.org/jira/browse/HARMONY-166
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
I've started to play with harmony-57 contribution and found bug in
InputStreamReader class. Method read() should read a single character from
input stream but it works incorrectly for 2 bytes-per-char charsets. Example
below shows that it failed to read one character in UTF-16 charset. Sorry for
so ugly test, it's just a part of InputStreamReaderTest from Harmony-57
contribution.
import java.io.*;
import junit.framework.TestCase;
public class InputStreamReaderTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(InputStreamReaderTest.class);
}
public void test_ISR_read() throws Exception {
InputStream in;
InputStreamReader reader;
try {
in = new LimitedByteArrayInputStream(0);
reader = new InputStreamReader(in, UTF-16BE);
int xx = reader.read();
assertTrue(Incorrect byte UTF-16BE, xx == '\u6172');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
System.out.println(e);
} catch (IOException e) {
e.printStackTrace();
fail(UTF-16BE unexpected 1: + e);
}
try {
in = new LimitedByteArrayInputStream(0);
reader = new InputStreamReader(in, UTF-16LE);
int xx = reader.read();
assertTrue(Incorrect byte UTF-16BE, xx == '\u7261');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
} catch (IOException e) {
fail(UTF-16BE unexpected 2: + e);
}
try {
in = new LimitedByteArrayInputStream(1);
reader = new InputStreamReader(in, UTF-16);
assertTrue(Incorrect byte UTF-16BE, reader.read() ==
'\u7261');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
} catch (IOException e) {
fail(UTF-16BE unexpected 3: + e);
}
try {
in = new LimitedByteArrayInputStream(2);
reader = new InputStreamReader(in, ISO2022JP);
int ch = reader.read();
assertTrue(Incorrect byte ISO2022JP 1: + ch, ch ==
'\u4e5d');
ch = reader.read();
assertTrue(Incorrect byte ISO2022JP 2: + ch, ch ==
'\u7b2c');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
System.out.println(e);
} catch (IOException e) {
fail(ISO2022JP unexpected: + e);
}
}
static class LimitedByteArrayInputStream extends ByteArrayInputStream {
// A ByteArrayInputStream that only returns a single byte per
read
byte[] bytes;
int count;
public LimitedByteArrayInputStream(int type) {
super(new byte[0]);
switch (type) {
case 0:
bytes = new byte[] { 0x61, 0x72 };
break;
case 1:
bytes = new byte[] { (byte) 0xff, (byte) 0xfe,
0x61, 0x72 };
break;
case 2:
bytes = new byte[] { '\u001b', '$', 'B', '6',
'e', 'B', 'h',
'\u001b', '(', 'B' };
break;
}
count = bytes.length;
}
public int read() {
if (count == 0)
return -1;
count--;
return bytes[bytes.length - count];
}
public int read
[jira] Updated: (HARMONY-166) method read() in InputStreamReader failed to read one character
[ http://issues.apache.org/jira/browse/HARMONY-166?page=all ]
Vladimir Strigun updated HARMONY-166:
-
Attachment: InputStreamReader.patch.txt
Please try my patch.
method read() in InputStreamReader failed to read one character
---
Key: HARMONY-166
URL: http://issues.apache.org/jira/browse/HARMONY-166
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Attachments: InputStreamReader.patch.txt
I've started to play with harmony-57 contribution and found bug in
InputStreamReader class. Method read() should read a single character from
input stream but it works incorrectly for 2 bytes-per-char charsets. Example
below shows that it failed to read one character in UTF-16 charset. Sorry for
so ugly test, it's just a part of InputStreamReaderTest from Harmony-57
contribution.
import java.io.*;
import junit.framework.TestCase;
public class InputStreamReaderTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(InputStreamReaderTest.class);
}
public void test_ISR_read() throws Exception {
InputStream in;
InputStreamReader reader;
try {
in = new LimitedByteArrayInputStream(0);
reader = new InputStreamReader(in, UTF-16BE);
int xx = reader.read();
assertTrue(Incorrect byte UTF-16BE, xx == '\u6172');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
System.out.println(e);
} catch (IOException e) {
e.printStackTrace();
fail(UTF-16BE unexpected 1: + e);
}
try {
in = new LimitedByteArrayInputStream(0);
reader = new InputStreamReader(in, UTF-16LE);
int xx = reader.read();
assertTrue(Incorrect byte UTF-16BE, xx == '\u7261');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
} catch (IOException e) {
fail(UTF-16BE unexpected 2: + e);
}
try {
in = new LimitedByteArrayInputStream(1);
reader = new InputStreamReader(in, UTF-16);
assertTrue(Incorrect byte UTF-16BE, reader.read() ==
'\u7261');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
} catch (IOException e) {
fail(UTF-16BE unexpected 3: + e);
}
try {
in = new LimitedByteArrayInputStream(2);
reader = new InputStreamReader(in, ISO2022JP);
int ch = reader.read();
assertTrue(Incorrect byte ISO2022JP 1: + ch, ch ==
'\u4e5d');
ch = reader.read();
assertTrue(Incorrect byte ISO2022JP 2: + ch, ch ==
'\u7b2c');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
System.out.println(e);
} catch (IOException e) {
fail(ISO2022JP unexpected: + e);
}
}
static class LimitedByteArrayInputStream extends ByteArrayInputStream {
// A ByteArrayInputStream that only returns a single byte per
read
byte[] bytes;
int count;
public LimitedByteArrayInputStream(int type) {
super(new byte[0]);
switch (type) {
case 0:
bytes = new byte[] { 0x61, 0x72 };
break;
case 1:
bytes = new byte[] { (byte) 0xff, (byte) 0xfe,
0x61, 0x72 };
break;
case 2:
bytes = new byte[] { '\u001b', '$', 'B', '6',
'e', 'B', 'h',
'\u001b', '(', 'B' };
break;
}
count = bytes.length;
}
public int read() {
if (count == 0)
return -1;
count--;
return bytes[bytes.length - count];
}
public int read(byte[] buffer, int offset, int length) {
if (count == 0)
return -1
[jira] Updated: (HARMONY-166) method read() in InputStreamReader failed to read one character
[ http://issues.apache.org/jira/browse/HARMONY-166?page=all ]
Vladimir Strigun updated HARMONY-166:
-
Attachment: InputStreamReaderTest.java
test for this issue. it's the same as in description, but it's more comfortable
to read.
method read() in InputStreamReader failed to read one character
---
Key: HARMONY-166
URL: http://issues.apache.org/jira/browse/HARMONY-166
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Attachments: InputStreamReader.patch.txt, InputStreamReaderTest.java
I've started to play with harmony-57 contribution and found bug in
InputStreamReader class. Method read() should read a single character from
input stream but it works incorrectly for 2 bytes-per-char charsets. Example
below shows that it failed to read one character in UTF-16 charset. Sorry for
so ugly test, it's just a part of InputStreamReaderTest from Harmony-57
contribution.
import java.io.*;
import junit.framework.TestCase;
public class InputStreamReaderTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(InputStreamReaderTest.class);
}
public void test_ISR_read() throws Exception {
InputStream in;
InputStreamReader reader;
try {
in = new LimitedByteArrayInputStream(0);
reader = new InputStreamReader(in, UTF-16BE);
int xx = reader.read();
assertTrue(Incorrect byte UTF-16BE, xx == '\u6172');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
System.out.println(e);
} catch (IOException e) {
e.printStackTrace();
fail(UTF-16BE unexpected 1: + e);
}
try {
in = new LimitedByteArrayInputStream(0);
reader = new InputStreamReader(in, UTF-16LE);
int xx = reader.read();
assertTrue(Incorrect byte UTF-16BE, xx == '\u7261');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
} catch (IOException e) {
fail(UTF-16BE unexpected 2: + e);
}
try {
in = new LimitedByteArrayInputStream(1);
reader = new InputStreamReader(in, UTF-16);
assertTrue(Incorrect byte UTF-16BE, reader.read() ==
'\u7261');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
} catch (IOException e) {
fail(UTF-16BE unexpected 3: + e);
}
try {
in = new LimitedByteArrayInputStream(2);
reader = new InputStreamReader(in, ISO2022JP);
int ch = reader.read();
assertTrue(Incorrect byte ISO2022JP 1: + ch, ch ==
'\u4e5d');
ch = reader.read();
assertTrue(Incorrect byte ISO2022JP 2: + ch, ch ==
'\u7b2c');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
System.out.println(e);
} catch (IOException e) {
fail(ISO2022JP unexpected: + e);
}
}
static class LimitedByteArrayInputStream extends ByteArrayInputStream {
// A ByteArrayInputStream that only returns a single byte per
read
byte[] bytes;
int count;
public LimitedByteArrayInputStream(int type) {
super(new byte[0]);
switch (type) {
case 0:
bytes = new byte[] { 0x61, 0x72 };
break;
case 1:
bytes = new byte[] { (byte) 0xff, (byte) 0xfe,
0x61, 0x72 };
break;
case 2:
bytes = new byte[] { '\u001b', '$', 'B', '6',
'e', 'B', 'h',
'\u001b', '(', 'B' };
break;
}
count = bytes.length;
}
public int read() {
if (count == 0)
return -1;
count--;
return bytes[bytes.length - count];
}
public int read(byte[] buffer, int offset, int length
[jira] Commented: (HARMONY-137) CharsetDecoder should replace undefined bytes with replacement string
[
http://issues.apache.org/jira/browse/HARMONY-137?page=comments#action_12368301
]
Vladimir Strigun commented on HARMONY-137:
--
Tim, I agree with the resolution, please close it.
CharsetDecoder should replace undefined bytes with replacement string
-
Key: HARMONY-137
URL: http://issues.apache.org/jira/browse/HARMONY-137
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Priority: Minor
Corresponding to cp1250 mapping table, 0x81 byte is undefined. See
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1250.TXT
So, charset decoder should replace undefined bytes with default replacement,
i.e. 0xFFFD.
Testcase for reproducing this issue:
import java.nio.charset.*;
import java.nio.*;
public class Harmony137 {
public static void main(String[] args) throws Exception {
ByteBuffer bb = ByteBuffer.allocate(5);
bb.put((byte)0x81); bb.flip();
Charset cp1250 = Charset.forName(cp1250);
CharBuffer cb =
cp1250.newDecoder().onMalformedInput(CodingErrorAction.REPLACE).onUnmappableCharacter(CodingErrorAction.REPLACE).decode(bb);
if(cb.get(0)!=65533) {
System.out.println(FAIL: expected 0xFFFD but result is:
0x+Integer.toHexString(cb.get(0)).toUpperCase());
}
}
}
--
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
[jira] Created: (HARMONY-139) ICU - characters 0x0384 and 0xB7 are unmapped in ICU implementation of ISO8859-7
ICU - characters 0x0384 and 0xB7 are unmapped in ICU implementation of ISO8859-7
Key: HARMONY-139
URL: http://issues.apache.org/jira/browse/HARMONY-139
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Priority: Minor
Looks like characters 0x0384 and 0xB7 are unmapped in ICU implementation.
Mapping table could be found here:
http://www.unicode.org/Public/MAPPINGS/ISO8859/8859-7.TXT
Please use test below for reproducing:
import java.nio.*;
import java.nio.charset.*;
import com.ibm.icu4jni.charset.CharsetProviderICU;
import junit.framework.TestCase;
public class Harmony139 extends TestCase{
public static void main(String args[]){
junit.textui.TestRunner.run(Harmony139.class);
}
public void testEncode_JIRA139_1() throws Exception {
CharsetProviderICU provider = new CharsetProviderICU();
Charset iso8859_7 = provider.charsetForName(ISO-8859-7);
// Uncomment code below to use RI charset
//Charset iso8859_7 = Charset.forName(ISO-8859-7);
CharBuffer cb = CharBuffer.allocate(1);
cb.put((char)0x0384); cb.flip();
ByteBuffer bb = iso8859_7.newEncoder().replaceWith(new byte[]
{0x3F}).onMalformedInput(CodingErrorAction.REPLACE).onUnmappableCharacter(CodingErrorAction.REPLACE).encode(cb);
assertEquals((byte)0xB4, bb.get(0));
}
public void testEncode_JIRA139_2() throws Exception {
CharsetProviderICU provider = new CharsetProviderICU();
Charset iso8859_7 = provider.charsetForName(ISO-8859-7);
// Uncomment code below to use RI charset
//Charset iso8859_7 = Charset.forName(ISO-8859-7);
CharBuffer cb = CharBuffer.allocate(1);
cb.put((char)0xB7); cb.flip();
ByteBuffer bb = iso8859_7.newEncoder().replaceWith(new byte[]
{0x3F}).onMalformedInput(CodingErrorAction.REPLACE).onUnmappableCharacter(CodingErrorAction.REPLACE).encode(cb);
assertEquals((byte)0xB7, bb.get(0));
}
}
Both tests passed with RI, and failed with Harmony.
--
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
[jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
[ http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12367818 ] Vladimir Strigun commented on HARMONY-40: - Thanks, Tim. Can't reproduce with latest sources. FileChannel assotiated with FileOutputStream not closed after closing output stream --- Key: HARMONY-40 URL: http://issues.apache.org/jira/browse/HARMONY-40 Project: Harmony Type: Bug Components: Classlib Reporter: Vladimir Strigun Assignee: Tim Ellison When I receive FileChannel from file output stream, write something to stream and then close it, channel, assotiated with the stream is still open. I'll attach unit test for the issue. -- 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
[jira] Commented: (HARMONY-29) java.util.zip.ZipException while onening jar file on local machine
[
http://issues.apache.org/jira/browse/HARMONY-29?page=comments#action_12367823 ]
Vladimir Strigun commented on HARMONY-29:
-
Since path can contain + character, second parameter for decode method should
be false, i.e. Util.decode(fileString, true)
java.util.zip.ZipException while onening jar file on local machine
--
Key: HARMONY-29
URL: http://issues.apache.org/jira/browse/HARMONY-29
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Assignee: Geir Magnusson Jr
When I try to get entries from jar file I get java.util.zip.ZipException.
Here is testcase for reproducing the issue:
import java.net.JarURLConnection;
import java.net.URL;
import java.util.Enumeration;
public class TestZipFile {
public static void main(String argv[]) throws Throwable {
final String urlStr = jar:file:/C:/Documents%20and%20Settings/ +
user/test.jar!/Test.class;
JarURLConnection conn = (JarURLConnection)
new URL(urlStr).openConnection();
Enumeration enum = conn.getJarFile().entries();
System.out.println(PASS);
}
}
On RI test passed, but with Harmony classlibs I get following exception:
java.util.zip.ZipException: Unable to open:
C:\Documents%20and%20Settings\user\test.jar
at java.util.zip.ZipFile.openZip()
at java.util.zip.ZipFile.init()
at java.util.jar.JarFile.init()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.openJarFile()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.findJarFile()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.connect()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.getJarFile()
at TestZipFile.main(TestZipFile.java:9)
--
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
[jira] Commented: (HARMONY-29) java.util.zip.ZipException while onening jar file on local machine
[
http://issues.apache.org/jira/browse/HARMONY-29?page=comments#action_12367824 ]
Vladimir Strigun commented on HARMONY-29:
-
Sorry, I meant Util.decode(fileString, false)
java.util.zip.ZipException while onening jar file on local machine
--
Key: HARMONY-29
URL: http://issues.apache.org/jira/browse/HARMONY-29
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Assignee: Geir Magnusson Jr
When I try to get entries from jar file I get java.util.zip.ZipException.
Here is testcase for reproducing the issue:
import java.net.JarURLConnection;
import java.net.URL;
import java.util.Enumeration;
public class TestZipFile {
public static void main(String argv[]) throws Throwable {
final String urlStr = jar:file:/C:/Documents%20and%20Settings/ +
user/test.jar!/Test.class;
JarURLConnection conn = (JarURLConnection)
new URL(urlStr).openConnection();
Enumeration enum = conn.getJarFile().entries();
System.out.println(PASS);
}
}
On RI test passed, but with Harmony classlibs I get following exception:
java.util.zip.ZipException: Unable to open:
C:\Documents%20and%20Settings\user\test.jar
at java.util.zip.ZipFile.openZip()
at java.util.zip.ZipFile.init()
at java.util.jar.JarFile.init()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.openJarFile()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.findJarFile()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.connect()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.getJarFile()
at TestZipFile.main(TestZipFile.java:9)
--
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
[jira] Created: (HARMONY-137) CharsetDecoder should replace undefined bytes with replacement string
CharsetDecoder should replace undefined bytes with replacement string
-
Key: HARMONY-137
URL: http://issues.apache.org/jira/browse/HARMONY-137
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Priority: Minor
Corresponding to cp1250 mapping table, 0x81 byte is undefined. See
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1250.TXT
So, charset decoder should replace undefined bytes with default replacement,
i.e. 0xFFFD.
Testcase for reproducing this issue:
import java.nio.charset.*;
import java.nio.*;
public class Harmony137 {
public static void main(String[] args) throws Exception {
ByteBuffer bb = ByteBuffer.allocate(5);
bb.put((byte)0x81); bb.flip();
Charset cp1250 = Charset.forName(cp1250);
CharBuffer cb =
cp1250.newDecoder().onMalformedInput(CodingErrorAction.REPLACE).onUnmappableCharacter(CodingErrorAction.REPLACE).decode(bb);
if(cb.get(0)!=65533) {
System.out.println(FAIL: expected 0xFFFD but result is:
0x+Integer.toHexString(cb.get(0)).toUpperCase());
}
}
}
--
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
Re: Bug-to-bug compatibility - first issue
On 2/22/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I'd suggest splitting the issue into two different ones: The first one is interpreting the command line. I completely agree that we should do it similar to RI. The second one is as Vladimir said that behavior is caused by something in URLClassloader or kernel classes. Vladimir, if you could provide a piece of java code that shows difference in the behavoir of RI and Harmony in those classes, so we could discuss how to implement the classes the best. Looks like that it should be fixed only in kernel classes in parser of classpath string. ClassLoader invokes constructor of URLClassLoader with urls parameter length = 1, i.e it contains only the following url file:/P:/. Thanks, Vladimir. Thanks, Mikhail On 2/22/06, Paulex Yang [EMAIL PROTECTED] wrote: I agree with you that it is natural to copy RI behavior in this case, and I even don't think this is a bug, in the same reason with one of the bugs' evaluation [1], quoteAn empty path component is always (in both Unix/Posix-like and Windows systems) treated as ./quote Arzhan Kinzhalin wrote: URLClassLoader can't load this class because searchURLs parameter in findClassImpl does not contain current directory and includes only p:/. So, IMO problem is inside VM kernel classes. What do you think we should do with this issue? It actually has corresponding bug report [1] which provides some background to the story. Names and behaviour of command-line arguments is not a part of the spec. It's just that everyone follows well-established conventions. In this case it would seem natural to copy the behavior. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4515984 -- Arzhan Intel Middleware Products Division -- Paulex Yang China Software Development Lab IBM
Bug-to-bug compatibility - first issue
We had discussion about bug-to-bug compatibility and it was decided to solve problems at the moment when they appear. So I have the 1st problem (below you can find the steps for reproducing it): 1. Compile any java class and put it to jre/bin folder (I used Hello.class) 2. run java Hello (everything works fine) 3. run java -classpath p:; Hello Result: NoClassDefFoundError If I use same command with RI (Sun and BEA) this test passes. I've found in documentation [1] that if you want to include the current directory in the search path, you must include . in the new settings. So, it looks like that we have bug in RI, but our implementation works with strict correspondence to the documentation. URLClassLoader can't load this class because searchURLs parameter in findClassImpl does not contain current directory and includes only p:/. So, IMO problem is inside VM kernel classes. What do you think we should do with this issue? [1] http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/classpath.html Thanks, Vladimir Strigun, Intel Middleware Products Division
Re: Bug-to-bug compatibility - first issue
This issue can be fixed either in Harmony classlib or kernel classes in VM. Thanks, Vladimir Strigun, Intel Middleware Products Division On 2/21/06, Alexey Petrenko [EMAIL PROTECTED] wrote: IBM VM? If so it's probably not an issue for Harmony but for IBM :) 2006/2/21, Vladimir Strigun [EMAIL PROTECTED]: We had discussion about bug-to-bug compatibility and it was decided to solve problems at the moment when they appear. So I have the 1st problem (below you can find the steps for reproducing it): 1. Compile any java class and put it to jre/bin folder (I used Hello.class) 2. run java Hello (everything works fine) 3. run java -classpath p:; Hello Result: NoClassDefFoundError If I use same command with RI (Sun and BEA) this test passes. I've found in documentation [1] that if you want to include the current directory in the search path, you must include . in the new settings. So, it looks like that we have bug in RI, but our implementation works with strict correspondence to the documentation. URLClassLoader can't load this class because searchURLs parameter in findClassImpl does not contain current directory and includes only p:/. So, IMO problem is inside VM kernel classes. What do you think we should do with this issue? [1] http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/classpath.html Thanks, Vladimir Strigun, Intel Middleware Products Division -- Alexey A. Petrenko Intel Middleware Products Division
[jira] Commented: (HARMONY-70) java.io.FileInputStream.close() must close channel associated with this FileInputStream
[
http://issues.apache.org/jira/browse/HARMONY-70?page=comments#action_12367017 ]
Vladimir Strigun commented on HARMONY-70:
-
Look like this issue already have been fixed in Harmony-42. I can't reproduce
it with the latest sources.
java.io.FileInputStream.close() must close channel associated with this
FileInputStream
---
Key: HARMONY-70
URL: http://issues.apache.org/jira/browse/HARMONY-70
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Ivanov
J2SE 1.4 specification reads for the method java.io.FileInputStream.close() :
If this stream has an associated channel then the channel is closed as well.
But the channel is still opened.
Code to reproduce:
import java.io.*;
import java.nio.channels.*;
public class test29 {
public static void main(String[] args) {
try {
File f = File.createTempFile(temp, .txt);
f.deleteOnExit();
FileInputStream fis = new FileInputStream(f);
FileChannel fch = fis.getChannel();
fis.close();
System.out.println(fch.isOpen = + fch.isOpen());
} catch (Exception e) {
System.out.println(unex = + e);
}
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test29.java using BEA 1.4 javac
javac -d . test29.java
3. Run java using compatible VM (J9)
java -showversion test29
Output:
C:\tmp\tmp17C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test29
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
fch.isOpen = false
C:\tmp\tmp17C:\harmony\trunk\deploy\jre\bin\java -showversion test29
java version 1.4.2 (subset)
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
fch.isOpen = true
junit test:
FileInputStreamTest.java
-
import java.io.*;
import java.nio.channels.*;
import junit.framework.*;
public class FileInputStreamTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(FileInputStreamTest.class);
}
public void testClose() {
try {
File f = File.createTempFile(temp, .txt);
f.deleteOnExit();
FileInputStream fis = new FileInputStream(f);
FileChannel fch = fis.getChannel();
fis.close();
assertFalse(FAILED, channel still opened!, fch.isOpen());
} catch (Exception e) {
fail(Unexpected exception: + e);
}
}
}
--
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
[jira] Commented: (HARMONY-67) java.nio.charset.Charset.decode(ByteBuffer) throws unexpected BufferOverflowException for UTF-16BE, UTF-16LE, UTF-16 charsets.
[
http://issues.apache.org/jira/browse/HARMONY-67?page=comments#action_12366469 ]
Vladimir Strigun commented on HARMONY-67:
-
I don't think that this bug should be reopened. Possibly it's another
compatibility bug, and I'll try to explain why.
Specification of decode method says that A newly-allocated character buffer
containing the result of the decoding operation. will be returned. Harmony
implementation of decode buffer returns CharBuffer with length equal to 1.
Inside resulting buffer we can see one element: FFFD, i.e default replacement
for unmappable character. In compliance with spec Charset.decode(buffer)
method invoke following line:
cs.newDecoder().onMalformedInput(CodingErrorAction.REPLACE).onUnmappableCharacter(CodingErrorAction.REPLACE).decode(bb);
So, IMO Harmony implementation is fully correspond to the spec.
java.nio.charset.Charset.decode(ByteBuffer) throws unexpected
BufferOverflowException for UTF-16BE, UTF-16LE, UTF-16 charsets.
---
Key: HARMONY-67
URL: http://issues.apache.org/jira/browse/HARMONY-67
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Assignee: Tim Ellison
According to j2se 1.4.2 specification for Charset.decode(ByteBuffer b) the
method must not throw any exceptions.
The test listed below shows that there is unexpected BufferOverflowException
thrown if charset name is one in the following: UTF-16BE, UTF-16LE, UTF-16.
BEA does not throw any exceptions.
Code to reproduce:
import java.nio.charset.Charset;
import java.nio.ByteBuffer;
import java.nio.CharBuffer;
public class test2 {
public static void main(String[] args) throws Exception {
byte[] b = new byte[] {(byte)1};
ByteBuffer buf= ByteBuffer.wrap(b);
CharBuffer charbuf=Charset.forName(UTF-16).decode(buf);
System.out.println(CharBuffer.length()=+ charbuf.length());
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
CharBuffer.length()=0
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
java.nio.BufferOverflowException
at java.nio.CharBuffer.put(CharBuffer.java:662)
at java.nio.CharBuffer.put(CharBuffer.java:629)
at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:406)
at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:243)
at java.nio.charset.Charset.decode(Charset.java:630)
at test2.main(test2.java:8)
Suggested junit test case:
CharsetTest.java
-
import java.nio.charset.Charset;
import java.nio.ByteBuffer;
import java.nio.CharBuffer;
import junit.framework.*;
public class CharsetTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(CharsetTest.class);
}
public void test_decode() {
byte[] b = new byte[] {(byte)1};
ByteBuffer buf= ByteBuffer.wrap(b);
CharBuffer charbuf=Charset.forName(UTF-16).decode(buf);
assertEquals(Assert 0: charset UTF-16,0,charbuf.length());
charbuf=Charset.forName(UTF-16BE).decode(buf);
assertEquals(Assert 1: charset UTF-16BE,0, charbuf.length());
charbuf=Charset.forName(UTF-16LE).decode(buf);
assertEquals(Assert 2: charset UTF16LE,0, charbuf.length());
}
}
--
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
[jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
[ http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12366330 ] Vladimir Strigun commented on HARMONY-40: - This bug is a part of Harmony-42 issue. I can't reproduce it with latest sources. Anyway, I think suggested test can be added to tests/java/io . FileChannel assotiated with FileOutputStream not closed after closing output stream --- Key: HARMONY-40 URL: http://issues.apache.org/jira/browse/HARMONY-40 Project: Harmony Type: Bug Components: Classlib Reporter: Vladimir Strigun When I receive FileChannel from file output stream, write something to stream and then close it, channel, assotiated with the stream is still open. I'll attach unit test for the issue. -- 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
Re: running eclipse on Harmony classlib
On 2/10/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Vladimir Strigun wrote: I'm able to run eclipse on Harmony classlib + J9 VM. To run Eclipse you need to make following steps: - download xalan.jar, xercesImpl.jar, xml-apis.jar and serializer.jar from xml.apache.org and put it to deploy/jre/lib/boot/ - add next line to jre/lib/boot/bootclasspath.properties : bootclasspath.38=serializer.jar - download and build Intel contribution of beans, math and regex packages ( http://issues.apache.org/jira/browse/HARMONY-39 ) - copy beans.jar, math.jar, regex.jar to deploy/jre/lib/boot/ folder - launch deploy/jre/bin/java -cp $ECLIPSE_HOME/startup.jar org.eclipse.core.launcher.Main I've tried to create simple Java project and Hello class inside. Everything works fine without any exception or problems. Tim, in your movie I have seen new type for installed JRE in Eclipse: Apache Harmony VM. Do you have Eclipse plugin for Harmony already? Holy cow, this is awesome! Have you tried with our own VM? Unfortunately haven't tried yet. Thanks, Vladimir Strigun, Intel Middleware Products Division
[jira] Commented: (HARMONY-29) java.util.zip.ZipException while onening jar file on local machine
[
http://issues.apache.org/jira/browse/HARMONY-29?page=comments#action_12365891 ]
Vladimir Strigun commented on HARMONY-29:
-
another fix (using internal utils):
37a38
import com.ibm.oti.util.Util;
235c236
jar = new JarFile(new File(fileString), true, flags);
---
jar = new JarFile(new File(Util.decode(fileString,
true)), true, flags);
java.util.zip.ZipException while onening jar file on local machine
--
Key: HARMONY-29
URL: http://issues.apache.org/jira/browse/HARMONY-29
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Assignee: Geir Magnusson Jr
When I try to get entries from jar file I get java.util.zip.ZipException.
Here is testcase for reproducing the issue:
import java.net.JarURLConnection;
import java.net.URL;
import java.util.Enumeration;
public class TestZipFile {
public static void main(String argv[]) throws Throwable {
final String urlStr = jar:file:/C:/Documents%20and%20Settings/ +
user/test.jar!/Test.class;
JarURLConnection conn = (JarURLConnection)
new URL(urlStr).openConnection();
Enumeration enum = conn.getJarFile().entries();
System.out.println(PASS);
}
}
On RI test passed, but with Harmony classlibs I get following exception:
java.util.zip.ZipException: Unable to open:
C:\Documents%20and%20Settings\user\test.jar
at java.util.zip.ZipFile.openZip()
at java.util.zip.ZipFile.init()
at java.util.jar.JarFile.init()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.openJarFile()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.findJarFile()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.connect()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.getJarFile()
at TestZipFile.main(TestZipFile.java:9)
--
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
running eclipse on Harmony classlib
I'm able to run eclipse on Harmony classlib + J9 VM. To run Eclipse you need to make following steps: - download xalan.jar, xercesImpl.jar, xml-apis.jar and serializer.jar from xml.apache.org and put it to deploy/jre/lib/boot/ - add next line to jre/lib/boot/bootclasspath.properties : bootclasspath.38=serializer.jar - download and build Intel contribution of beans, math and regex packages ( http://issues.apache.org/jira/browse/HARMONY-39 ) - copy beans.jar, math.jar, regex.jar to deploy/jre/lib/boot/ folder - launch deploy/jre/bin/java -cp $ECLIPSE_HOME/startup.jar org.eclipse.core.launcher.Main I've tried to create simple Java project and Hello class inside. Everything works fine without any exception or problems. Tim, in your movie I have seen new type for installed JRE in Eclipse: Apache Harmony VM. Do you have Eclipse plugin for Harmony already?
[jira] Commented: (HARMONY-67) java.nio.charset.Charset.decode(ByteBuffer) throws unexpected BufferOverflowException for UTF-16BE, UTF-16LE, UTF-16 charsets.
[
http://issues.apache.org/jira/browse/HARMONY-67?page=comments#action_12365756 ]
Vladimir Strigun commented on HARMONY-67:
-
Looks like duplicate of Harmony-33
java.nio.charset.Charset.decode(ByteBuffer) throws unexpected
BufferOverflowException for UTF-16BE, UTF-16LE, UTF-16 charsets.
---
Key: HARMONY-67
URL: http://issues.apache.org/jira/browse/HARMONY-67
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
According to j2se 1.4.2 specification for Charset.decode(ByteBuffer b) the
method must not throw any exceptions.
The test listed below shows that there is unexpected BufferOverflowException
thrown if charset name is one in the following: UTF-16BE, UTF-16LE, UTF-16.
BEA does not throw any exceptions.
Code to reproduce:
import java.nio.charset.Charset;
import java.nio.ByteBuffer;
import java.nio.CharBuffer;
public class test2 {
public static void main(String[] args) throws Exception {
byte[] b = new byte[] {(byte)1};
ByteBuffer buf= ByteBuffer.wrap(b);
CharBuffer charbuf=Charset.forName(UTF-16).decode(buf);
System.out.println(CharBuffer.length()=+ charbuf.length());
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
CharBuffer.length()=0
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
java.nio.BufferOverflowException
at java.nio.CharBuffer.put(CharBuffer.java:662)
at java.nio.CharBuffer.put(CharBuffer.java:629)
at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:406)
at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:243)
at java.nio.charset.Charset.decode(Charset.java:630)
at test2.main(test2.java:8)
Suggested junit test case:
CharsetTest.java
-
import java.nio.charset.Charset;
import java.nio.ByteBuffer;
import java.nio.CharBuffer;
import junit.framework.*;
public class CharsetTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(CharsetTest.class);
}
public void test_decode() {
byte[] b = new byte[] {(byte)1};
ByteBuffer buf= ByteBuffer.wrap(b);
CharBuffer charbuf=Charset.forName(UTF-16).decode(buf);
assertEquals(Assert 0: charset UTF-16,0,charbuf.length());
charbuf=Charset.forName(UTF-16BE).decode(buf);
assertEquals(Assert 1: charset UTF-16BE,0, charbuf.length());
charbuf=Charset.forName(UTF-16LE).decode(buf);
assertEquals(Assert 2: charset UTF16LE,0, charbuf.length());
}
}
--
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
[jira] Commented: (HARMONY-72) java.net.URLConnection.setAllowUserInteraction (boolean b) throws unspecified SecurityException
[
http://issues.apache.org/jira/browse/HARMONY-72?page=comments#action_12365218 ]
Vladimir Strigun commented on HARMONY-72:
-
Fix is trivial:
@@ -733,7 +733,7 @@
*/
public void setAllowUserInteraction(boolean newValue) {
if (connected) {
- throw new SecurityException(Msg.getString(K0037));
+ throw new IllegalStateException(Msg.getString(K0037));
}
this.allowUserInteraction = newValue;
}
java.net.URLConnection.setAllowUserInteraction (boolean b) throws unspecified
SecurityException
---
Key: HARMONY-72
URL: http://issues.apache.org/jira/browse/HARMONY-72
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
According to j2se 1.4.2 spec
java.net.URLConnection.setAllowUserInteraction(boolean) throws
IllegalStateException - if already connected.
Harmony throws java.lang.SecurityException instead.
Code to reproduce:
import java.io.IOException;
import java.net.*;
public class test2 {
public static void main(String[] args) {
HttpURLConnection u=null;
try {
u=(HttpURLConnection)(new
URL(http://intel.com;).openConnection());
u.connect();
} catch (MalformedURLException e) {
System.out.println(unexpected MalformedURLException+e);
} catch (IOException f) {
System.out.println(unexpected IOException+f);
}
try {
u.setAllowUserInteraction(false);
} catch (IllegalStateException e) {
System.out.println(OK. Expected IllegalStateException);
e.printStackTrace();
};
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
OK. Expected IllegalStateException
java.lang.IllegalStateException: Already connected
at
java.net.URLConnection.setAllowUserInteraction(Z)V(URLConnection.java:765)
at test2.main([Ljava.lang.String;)V(test2.java:16)
at test2.main([Ljava.lang.String;)V(test2.java:18)
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
java.lang.SecurityException: Connection already established
at
java.net.URLConnection.setAllowUserInteraction(URLConnection.java:736)
at test2.main(test2.java:18)
Suggested junit test case:
URLConnectionTest.java
-
import java.io.IOException;
import java.net.*;
import junit.framework.*;
public class URLConnectionTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(URLConnectionTest.class);
}
public void test_setUseCaches () {
HttpURLConnection u=null;
try {
u=(HttpURLConnection)(new
URL(http://intel.com;).openConnection());
u.connect();
} catch (MalformedURLException e) {
fail(unexpected MalformedURLException+e);
} catch (IOException f) {
fail(unexpected IOException+f);
}
try {
u.setAllowUserInteraction(false);
} catch (IllegalStateException e) { //expected
};
}
}
--
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
[jira] Commented: (HARMONY-71) java.net.URLConnection.setUseCaches throws unspecified IllegalAccessError
[
http://issues.apache.org/jira/browse/HARMONY-71?page=comments#action_12365225 ]
Vladimir Strigun commented on HARMONY-71:
-
Trivial fix for the issue:
@@ -920,7 +920,7 @@
*/
public void setUseCaches(boolean newValue) {
if (connected) {
- throw new IllegalAccessError(Msg.getString(K0037));
+ throw new IllegalStateException(Msg.getString(K0037));
}
this.useCaches = newValue;
}
java.net.URLConnection.setUseCaches throws unspecified IllegalAccessError
--
Key: HARMONY-71
URL: http://issues.apache.org/jira/browse/HARMONY-71
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
According to j2se 1.4.2 specification method
java.net.URLConnection.setUseCaches(boolean) throws IllegalStateException, if
already connected. Harmony throws java.lang.IllegalAccessError instead, that
contradicts the specification.
Code to reproduce:
import java.io.IOException;
import java.net.*;
public class test2 {
public static void main(String[] args) {
HttpURLConnection u=null;
try {
u=(HttpURLConnection)(new
URL(http://intel.com;).openConnection());
u.connect();
} catch (MalformedURLException e) {
System.out.println(unexpected MalformedURLException+e);
} catch (IOException f) {
System.out.println(unexpected IOException+f);
}
try {
u.setUseCaches(true);
} catch (IllegalStateException e) {
System.out.println(OK. Expected IllegalStateException);
e.printStackTrace();
};
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
OK. Expected IllegalStateException
java.lang.IllegalStateException: Already connected
at java.net.URLConnection.setUseCaches(Z)V(URLConnection.java:828)
at test2.main([Ljava.lang.String;)V(test2.java:17)
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
java.lang.IllegalAccessError: Connection already established
at java.net.URLConnection.setUseCaches(URLConnection.java:923)
at test2.main(test2.java:17)
Suggested junit test case:
URLConnectionTest.java
-
import java.io.IOException;
import java.net.*;
import junit.framework.*;
public class URLConnectionTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(URLConnectionTest.class);
}
public void test_setUseCaches () {
HttpURLConnection u=null;
try {
u=(HttpURLConnection)(new
URL(http://intel.com;).openConnection());
u.connect();
} catch (MalformedURLException e) {
fail(unexpected MalformedURLException+e);
} catch (IOException f) {
fail(unexpected IOException+f);
}
try {
u.setUseCaches(true);
} catch (IllegalStateException e) { //expected
};
}
}
--
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
[jira] Commented: (HARMONY-45) Charset.isRegistered() method always return true
[ http://issues.apache.org/jira/browse/HARMONY-45?page=comments#action_12364478 ] Vladimir Strigun commented on HARMONY-45: - I'm ok with this fix. Charset.isRegistered() method always return true Key: HARMONY-45 URL: http://issues.apache.org/jira/browse/HARMONY-45 Project: Harmony Type: Bug Components: Classlib Reporter: Vladimir Strigun Assignee: Tim Ellison Priority: Trivial In accordance with J2SE specification method isRegistered() should return true only if charset is registered with IANA. As well, if a supported charset is not listed in the IANA registry then its canonical name must begin with one of the strings X- or x- Testcase shows that even if charset name begin with x- isRegistered returns true; -- 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
[jira] Commented: (HARMONY-52) java.io.ByteArrayOutputStream.toString(String) throws IllegalCharsetNameException instead of UnsupportedEncodingException
[
http://issues.apache.org/jira/browse/HARMONY-52?page=comments#action_12364201 ]
Vladimir Strigun commented on HARMONY-52:
-
Ive found small testcase for the issue:
public static void main(String[] args) throws Exception{
byte[] arr = {'a', 'b', 'c'};
new String(arr, 0, 2, some charset);
}
The behaviour of this test is the same as original. But charset name some
charset is illegal because only following letters are allowed in charset names:
The uppercase letters 'A' through 'Z' ('\u0041' through '\u005a'),
The lowercase letters 'a' through 'z' ('\u0061' through '\u007a'),
The digits '0' through '9' ('\u0030' through '\u0039'),
The dash character '-' ('\u002d', HYPHEN-MINUS),
The period character '.' ('\u002e', FULL STOP),
The colon character ':' ('\u003a', COLON), and
The underscore character '_' ('\u005f', LOW LINE).
So, if we pass to String(byte[], int, int, String) constructor illegal charset
name, it should anyway throws UnsupportedEncodingException, not
IllegalCharsetNameException .
java.io.ByteArrayOutputStream.toString(String) throws
IllegalCharsetNameException instead of UnsupportedEncodingException
-
Key: HARMONY-52
URL: http://issues.apache.org/jira/browse/HARMONY-52
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Ivanov
java.io.ByteArrayOutputStream.toString(String) throws
IllegalCharsetNameException instead of UnsupportedEncodingException
j2se 1.4.2 and 1.5.0 says, that method
java.io.ByteArrayOutputStream.toString(String)
throws UnsupportedEncodingException, if the named encoding is not supported.
Code to reproduce:
import java.io.*;
public class test29 {
public static void main(String[] args) {
ByteArrayOutputStream os = new ByteArrayOutputStream();
try {
os.write(ababa.getBytes());
os.toString(this is the name \n of a nonexistent encoding
+ Math.random());
} catch(UnsupportedEncodingException e) {
System.out.println(PASSED);
} catch(Exception e) {
System.out.println(FAILED: + e);
}
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-25) j2se subset as described in
README.txt.
2. Compile test29.java using BEA 1.4 javac
javac -d . test29.java
3. Run java using compatible VM (J9)
java -showversion test29
Output:
C:\tmp\tmp17C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test29
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32,
Native Threads, GC strategy: parallel)
PASSED
C:\tmp\tmp17C:\harmony\trunk\deploy\jre\bin\java -showversion test29
java version 1.4.2 (subset)
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
app
licable.
FAILED: java.nio.charset.IllegalCharsetNameException: The illegal charset
name i
s this is the name
of a nonexistent encoding0.4487506282752648.
C:\tmp\tmp17C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test29
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
PASSED
C:\tmp\tmp17
junit test:
ByteArrayOutputStreamTest.java
-
import java.io.*;
import junit.framework.*;
public class ByteArrayOutputStreamTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(ByteArrayOutputStreamTest.class);
}
public void testToString_String() {
ByteArrayOutputStream os = new ByteArrayOutputStream();
try {
os.write(ababa.getBytes());
os.toString(this is the name \n of a nonexistent encoding
+ Math.random());
} catch(UnsupportedEncodingException e) {
} catch(Exception e) {
fail(Unexpected exception: + e);
}
}
}
--
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
[jira] Created: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
FileChannel assotiated with FileOutputStream not closed after closing output stream --- Key: HARMONY-40 URL: http://issues.apache.org/jira/browse/HARMONY-40 Project: Harmony Type: Bug Components: Classlib Reporter: Vladimir Strigun When I receive FileChannel from file output stream, write something to stream and then close it, channel, assotiated with the stream is still open. I'll attach unit test for the issue. -- 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
[jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
[
http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12363701 ]
Vladimir Strigun commented on HARMONY-40:
-
I can't attach testcase, so posting it as a comment:
/* Copyright 2005 The Apache Software Foundation or its licensors, as applicable
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.harmony.tests.java.io;
import java.io.File;
import java.io.FileOutputStream;
import java.nio.channels.FileChannel;
import junit.framework.TestCase;
public class FileOutputStreamTest extends TestCase {
/**
* @tests java.io.FileOutputStream#close()
*/
public void test_close() throws Exception {
File logFile = File.createTempFile(out, tmp);
logFile.deleteOnExit();
FileOutputStream out = new FileOutputStream(logFile, true);
FileChannel channel = out.getChannel();
out.write(1);
out.close();
assertFalse(Channel is still open, channel.isOpen());
}
}
FileChannel assotiated with FileOutputStream not closed after closing output
stream
---
Key: HARMONY-40
URL: http://issues.apache.org/jira/browse/HARMONY-40
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
When I receive FileChannel from file output stream, write something to stream
and then close it, channel, assotiated with the stream is still open. I'll
attach unit test for the issue.
--
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
[jira] Commented: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
[
http://issues.apache.org/jira/browse/HARMONY-40?page=comments#action_12363705 ]
Vladimir Strigun commented on HARMONY-40:
-
Forced close of file current file channel in file output stream can be added
(diff for current FileOutputStream)
173a174,177
if (channel != null) {
channel.close();
channel = null;
}
FileChannel assotiated with FileOutputStream not closed after closing output
stream
---
Key: HARMONY-40
URL: http://issues.apache.org/jira/browse/HARMONY-40
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
When I receive FileChannel from file output stream, write something to stream
and then close it, channel, assotiated with the stream is still open. I'll
attach unit test for the issue.
--
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
[jira] Commented: (HARMONY-37) remove() method of IdentityHashMap works incorrectly
[
http://issues.apache.org/jira/browse/HARMONY-37?page=comments#action_12363586 ]
Vladimir Strigun commented on HARMONY-37:
-
Tim, thanks for the fix. Everything works fine.
remove() method of IdentityHashMap works incorrectly
Key: HARMONY-37
URL: http://issues.apache.org/jira/browse/HARMONY-37
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Assignee: Tim Ellison
Attachments: IdentityHashMapTest.java, IdentityHashMapTest.java
When user try to remove unexisting key from empty hashmap, size of object
decreased to -1.
Testcase for reproducing:
import java.util.IdentityHashMap;
public class Harmony37 {
public static void main(String args[]) {
IdentityHashMap hashMap = new IdentityHashMap();
hashMap.remove(unexist);
if (hashMap.size() != 0) {
System.out.println(FAILED, because size=+hashMap.size());
}
}
}
--
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
[jira] Created: (HARMONY-37) remove() method of IdentityHashMap works incorrectly
remove() method of IdentityHashMap works incorrectly
Key: HARMONY-37
URL: http://issues.apache.org/jira/browse/HARMONY-37
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
When user try to remove unexisting key from empty hashmap, size of object
decreased to -1.
Testcase for reproducing:
import java.util.IdentityHashMap;
public class Harmony37 {
public static void main(String args[]) {
IdentityHashMap hashMap = new IdentityHashMap();
hashMap.remove(unexist);
if (hashMap.size() != 0) {
System.out.println(FAILED, because size=+hashMap.size());
}
}
}
--
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
[jira] Commented: (HARMONY-37) remove() method of IdentityHashMap works incorrectly
[
http://issues.apache.org/jira/browse/HARMONY-37?page=comments#action_12363416 ]
Vladimir Strigun commented on HARMONY-37:
-
I'll attach regression test for this bug. Here is diff for
/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/tests/java/util/AllTests.java
:
32a33
suite.addTestSuite(IdentityHashMapTest.class);
remove() method of IdentityHashMap works incorrectly
Key: HARMONY-37
URL: http://issues.apache.org/jira/browse/HARMONY-37
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
When user try to remove unexisting key from empty hashmap, size of object
decreased to -1.
Testcase for reproducing:
import java.util.IdentityHashMap;
public class Harmony37 {
public static void main(String args[]) {
IdentityHashMap hashMap = new IdentityHashMap();
hashMap.remove(unexist);
if (hashMap.size() != 0) {
System.out.println(FAILED, because size=+hashMap.size());
}
}
}
--
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
[jira] Updated: (HARMONY-37) remove() method of IdentityHashMap works incorrectly
[ http://issues.apache.org/jira/browse/HARMONY-37?page=all ]
Vladimir Strigun updated HARMONY-37:
Attachment: IdentityHashMapTest.java
regression test
remove() method of IdentityHashMap works incorrectly
Key: HARMONY-37
URL: http://issues.apache.org/jira/browse/HARMONY-37
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Attachments: IdentityHashMapTest.java
When user try to remove unexisting key from empty hashmap, size of object
decreased to -1.
Testcase for reproducing:
import java.util.IdentityHashMap;
public class Harmony37 {
public static void main(String args[]) {
IdentityHashMap hashMap = new IdentityHashMap();
hashMap.remove(unexist);
if (hashMap.size() != 0) {
System.out.println(FAILED, because size=+hashMap.size());
}
}
}
--
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
[jira] Commented: (HARMONY-24) java.net.URLEncoder.encode(String s, String enc) doesn't throw UnsupportedEncodingException
[
http://issues.apache.org/jira/browse/HARMONY-24?page=comments#action_12363269 ]
Vladimir Strigun commented on HARMONY-24:
-
Current implementation of encode(String, String) method use getBytes(encoding)
method for encoding special characters. My testcase haven't some special
characters, thatswhy we can't see exception. To fix it, we can add check that
charset is supported:
19a20
import java.nio.charset.Charset;
93a95,96
if(!Charset.isSupported(enc))
throw new UnsupportedEncodingException(enc);
java.net.URLEncoder.encode(String s, String enc) doesn't throw
UnsupportedEncodingException
---
Key: HARMONY-24
URL: http://issues.apache.org/jira/browse/HARMONY-24
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Assignee: Geir Magnusson Jr
Corresponding to API specification method encode(String, String) of
java.net.URLEncoder should throw UnsupportedEncodingException - If the named
encoding is not supported. But the test shows that Harmony implementation
doesn't throw an exception.
import java.io.UnsupportedEncodingException;
import java.net.URLEncoder;
public class Test {
public static void main(String[] args) {
try {
System.out.println(URLEncoder.encode=+URLEncoder.encode(str,unknown_enc));
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}
}
}
--
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
[jira] Created: (HARMONY-33) java.nio.BufferOverflow exception while decoding ByteBuffer with UTF-16 charset
java.nio.BufferOverflow exception while decoding ByteBuffer with UTF-16 charset
---
Key: HARMONY-33
URL: http://issues.apache.org/jira/browse/HARMONY-33
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Assigned to: Geir Magnusson Jr
Priority: Minor
If I try to decode ByteBuffer with lengh 1 using UTF-16 decoder unexpected
java.nio.BufferOverflow exception occured. Please see testcase below.
import java.nio.*;
import java.nio.charset.*;
import junit.framework.TestCase;
public class TestDecoder extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(TestDecoder.class);
}
public static void testDecoder(){
try{
ByteBuffer bb = ByteBuffer.allocate(1);
bb.put(0,(byte)77);
CharsetDecoder utf16D = Charset.forName(UTF-16).newDecoder();
CharBuffer cb =
utf16D.onMalformedInput(CodingErrorAction.REPLACE).onUnmappableCharacter(CodingErrorAction.REPLACE).decode(bb);
}catch(Exception e){
fail(Exception occured: +e);
}
}
}
Output on RI:
.
Time: 0,03
OK (1 test)
Output with Harmony:
.F
Time: 0,01
There was 1 failure:
1) testDecoder(TestDecoder)junit.framework.AssertionFailedError: Exception
occured: java.nio.BufferOverflowException
at TestDecoder.testDecoder(TestDecoder.java:20)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:211)
at TestDecoder.main(TestDecoder.java:10)
FAILURES!!!
Tests run: 1, Failures: 1, Errors: 0
--
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
[jira] Commented: (HARMONY-33) java.nio.BufferOverflow exception while decoding ByteBuffer with UTF-16 charset
[
http://issues.apache.org/jira/browse/HARMONY-33?page=comments#action_12363005 ]
Vladimir Strigun commented on HARMONY-33:
-
The reason of the issue is invocation of put(replacement) method for CharBuffer
with zero capacity. First, during decoding byte buffer, char buffer should be
created with initial capacity equals to remaining bytes in byte buffer
multiplied by average chars per byte value. For the current testcase initial
capacity for char buffer is 0 ( int length = (int) (in.remaining() * averChars)
). And when CodingErrorAction = CodingErrorAction.REPLACE decoder try to put
replacement string to zero-sized char buffer.
Please review fix for the issue (diff for revision 367369 of
/incubator/harmony/enhanced/classlib/trunk/modules/nio_char/src/main/java/java/nio/charset/CharsetDecoder.java):
405a406,408
if(out.remaining() replace.length() ) {
return CoderResult.OVERFLOW;
}
407d409
continue;
java.nio.BufferOverflow exception while decoding ByteBuffer with UTF-16
charset
---
Key: HARMONY-33
URL: http://issues.apache.org/jira/browse/HARMONY-33
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Assignee: Geir Magnusson Jr
Priority: Minor
If I try to decode ByteBuffer with lengh 1 using UTF-16 decoder unexpected
java.nio.BufferOverflow exception occured. Please see testcase below.
import java.nio.*;
import java.nio.charset.*;
import junit.framework.TestCase;
public class TestDecoder extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(TestDecoder.class);
}
public static void testDecoder(){
try{
ByteBuffer bb = ByteBuffer.allocate(1);
bb.put(0,(byte)77);
CharsetDecoder utf16D = Charset.forName(UTF-16).newDecoder();
CharBuffer cb =
utf16D.onMalformedInput(CodingErrorAction.REPLACE).onUnmappableCharacter(CodingErrorAction.REPLACE).decode(bb);
}catch(Exception e){
fail(Exception occured: +e);
}
}
}
Output on RI:
.
Time: 0,03
OK (1 test)
Output with Harmony:
.F
Time: 0,01
There was 1 failure:
1) testDecoder(TestDecoder)junit.framework.AssertionFailedError: Exception
occured: java.nio.BufferOverflowException
at TestDecoder.testDecoder(TestDecoder.java:20)
at
java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:211)
at TestDecoder.main(TestDecoder.java:10)
FAILURES!!!
Tests run: 1, Failures: 1, Errors: 0
--
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
[jira] Created: (HARMONY-29) java.util.zip.ZipException while onening jar file on local machine
java.util.zip.ZipException while onening jar file on local machine
--
Key: HARMONY-29
URL: http://issues.apache.org/jira/browse/HARMONY-29
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Assigned to: Geir Magnusson Jr
When I try to get entries from jar file I get java.util.zip.ZipException. Here
is testcase for reproducing the issue:
import java.net.JarURLConnection;
import java.net.URL;
import java.util.Enumeration;
public class TestZipFile {
public static void main(String argv[]) throws Throwable {
final String urlStr = jar:file:/C:/Documents%20and%20Settings/ +
user/test.jar!/Test.class;
JarURLConnection conn = (JarURLConnection)
new URL(urlStr).openConnection();
Enumeration enum = conn.getJarFile().entries();
System.out.println(PASS);
}
}
On RI test passed, but with Harmony classlibs I get following exception:
java.util.zip.ZipException: Unable to open:
C:\Documents%20and%20Settings\user\test.jar
at java.util.zip.ZipFile.openZip()
at java.util.zip.ZipFile.init()
at java.util.jar.JarFile.init()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.openJarFile()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.findJarFile()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.connect()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.getJarFile()
at TestZipFile.main(TestZipFile.java:9)
--
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
[jira] Commented: (HARMONY-21) File constructor produces wrong path to absolute path specified relative to root
[
http://issues.apache.org/jira/browse/HARMONY-21?page=comments#action_12361427 ]
Vladimir Strigun commented on HARMONY-21:
-
Unfortunately, I have regression with my fix. Next test is failed with my fix:
import java.io.*;
public class Test {
public static void main(String[] args) throws Exception {
System.err.println(new File(\\a\b).isAbsolute() ? PASSED :
FAILED);
}
}
===
But I have another fix for it. I've check it with different scenarions and it
looks like fix doesn't broke anything. Anyway, we should add additional
regression test for the issue.
Here is the fix:
254c254
if ((foundSlash i == uncIndex
path.charAt(0) == '/' pathChar != '\\') || !foundSlash) {
---
if ((foundSlash i == uncIndex) ||
!foundSlash) {
256a257
if(path.charAt(0) == '/' pathChar ==
'\\' separatorChar == '\\' i == 1) newLength--;
Sorry about it.
File constructor produces wrong path to absolute path specified relative to
root
Key: HARMONY-21
URL: http://issues.apache.org/jira/browse/HARMONY-21
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Tim Ellison
Assignee: Tim Ellison
Specifying an absolute path relative to the root directory produces the wrong
final pathname.
Here's a simple test illustrating the problem:
public void test_File_Constructor() {
File path = new File(/dir/file);
File root = new File(/);
File file = new File(root, /dir/file);
assertEquals(wrong path result , path.getPath(),
file.getPath());
}
--
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
regression test suite
We already discussed several questions about tests. But I'd like to open a new topic about regression test suite. Some API bugs have been fixed (or patch suggested) and I think it will be useful to have regression tests for all these bugs to avoid them reappearing in the future. I think the natural place for the regression tests should be together with the unit tests. I am not sure, however, if the regression tests should be marked explicitly or differ from the unit tests in any other specific way. What do you think about it? Any preferences? Thank you, Vladimir Strigun, Intel Middleware Products Division.
[jira] Created: (HARMONY-24) java.net.URLEncoder.encode(String s, String enc) doesn't throw UnsupportedEncodingException
java.net.URLEncoder.encode(String s, String enc) doesn't throw
UnsupportedEncodingException
---
Key: HARMONY-24
URL: http://issues.apache.org/jira/browse/HARMONY-24
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Assigned to: Geir Magnusson Jr
Corresponding to API specification method encode(String, String) of
java.net.URLEncoder should throw UnsupportedEncodingException - If the named
encoding is not supported. But the test shows that Harmony implementation
doesn't throw an exception.
import java.io.UnsupportedEncodingException;
import java.net.URLEncoder;
public class Test {
public static void main(String[] args) {
try {
System.out.println(URLEncoder.encode=+URLEncoder.encode(str,unknown_enc));
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}
}
}
--
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
[jira] Commented: (HARMONY-23) java.net.URI(String s) for invalid escaped characters throw IllegalArgumentException
[
http://issues.apache.org/jira/browse/HARMONY-23?page=comments#action_12360570 ]
Vladimir Strigun commented on HARMONY-23:
-
The cause of the IllegalArgument exception is creating of URISyntaxException
with index = -2.
Here is a part of spec for URISyntaxException: IllegalArgumentException - If
the error index is less than -1
So, we need just check if the index variable =-1 .
Fix for the issue is very simple (file URI.java):
326a327
if(index + e.getIndex() -1) index = 0;
java.net.URI(String s) for invalid escaped characters throw
IllegalArgumentException
Key: HARMONY-23
URL: http://issues.apache.org/jira/browse/HARMONY-23
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Assignee: Geir Magnusson Jr
Priority: Minor
When I use URI(String) constructor with invalid escaped characters I get
IllegalArgumentException instead of URISyntaxException.
Small testcase for reproducing this issue:
import java.net.*;
public class URIBug{
public static void main(String[] args) {
try {
new URI(%3);
} catch (URISyntaxException e) {
System.out.println(PASSED);
} catch (Exception e) {
System.out.println(FAILED: illegal exception occured: +e);
}
}
}
--
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
[jira] Created: (HARMONY-23) java.net.URI(String s) for invalid escaped characters throw IllegalArgumentException
java.net.URI(String s) for invalid escaped characters throw
IllegalArgumentException
Key: HARMONY-23
URL: http://issues.apache.org/jira/browse/HARMONY-23
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Assigned to: Geir Magnusson Jr
Priority: Minor
When I use URI(String) constructor with invalid escaped characters I get
IllegalArgumentException instead of URISyntaxException.
Small testcase for reproducing this issue:
import java.net.*;
public class URIBug{
public static void main(String[] args) {
try {
new URI(%3);
} catch (URISyntaxException e) {
System.out.println(PASSED);
} catch (Exception e) {
System.out.println(FAILED: illegal exception occured: +e);
}
}
}
--
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
[jira] Commented: (HARMONY-21) File constructor produces wrong path to absolute path specified relative to root
[
http://issues.apache.org/jira/browse/HARMONY-21?page=comments#action_12359731 ]
Vladimir Strigun commented on HARMONY-21:
-
I've found that my fix isn't good for Linux. When I try to create file using
File(//usr) I get incorrect absolute path: //usr instead of /usr.
To fix this additional check of of separatorChar should be added.
Here is updated fix:
254c254
if ((foundSlash i == uncIndex) || !foundSlash) {
---
if ((foundSlash i == uncIndex path.charAt(0) == '/' pathChar != '\\'
separatorChar == '\\') || !foundSlash) {
File constructor produces wrong path to absolute path specified relative to
root
Key: HARMONY-21
URL: http://issues.apache.org/jira/browse/HARMONY-21
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Tim Ellison
Assignee: Geir Magnusson Jr
Specifying an absolute path relative to the root directory produces the wrong
final pathname.
Here's a simple test illustrating the problem:
public void test_File_Constructor() {
File path = new File(/dir/file);
File root = new File(/);
File file = new File(root, /dir/file);
assertEquals(wrong path result , path.getPath(),
file.getPath());
}
--
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
[jira] Commented: (HARMONY-21) File constructor produces wrong path to absolute path specified relative to root
[
http://issues.apache.org/jira/browse/HARMONY-21?page=comments#action_12359243 ]
Vladimir Strigun commented on HARMONY-21:
-
The cause of problem is realization of fixSlashes() method of java.io.File.
Another testcase for this bug is almost the same (but reroduced with another
constructor):
public void test_File_Constructor() {
File path = new File(/dir/file);
File file = new File(/, dir/file);
assertEquals(wrong path result , path.getPath(), file.getPath());
}
I've try create the fix for the issue and I can suggest not very elegant, but
very efficient fix for it:
254c254
if ((foundSlash i == uncIndex) ||
!foundSlash) {
---
if ((foundSlash i == uncIndex
path.charAt(0) == '/' pathChar != '\\') || !foundSlash) {
fixSlashes functions converts all slashes to default separator. So, on Windows
it converts first '/' to '\' and after next iteration we receive UNC path
instead of path to root folder. Additional check of first symbol fix this
problem.
File constructor produces wrong path to absolute path specified relative to
root
Key: HARMONY-21
URL: http://issues.apache.org/jira/browse/HARMONY-21
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Tim Ellison
Assignee: Geir Magnusson Jr
Specifying an absolute path relative to the root directory produces the wrong
final pathname.
Here's a simple test illustrating the problem:
public void test_File_Constructor() {
File path = new File(/dir/file);
File root = new File(/);
File file = new File(root, /dir/file);
assertEquals(wrong path result , path.getPath(),
file.getPath());
}
--
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
