September 2007 - core-libs-dev

Bug#6546113 StringCharBuffer fix
by Roman Kennke 11 Mar '08

11 Mar '08

This fixes a problem with sliced StringCharBuffers. See: http://bugs.sun.com/view_bug.do?bug_id=6546113 Feel free to integrate this in the repository. Cheers, Roman -- http://kennke.org/blog/

3 6

[PATCH] java.math/4428022 Float/Double.toString trailing zeros
by Keith Seitz 06 Oct '07

06 Oct '07

Hi, I believe the attached patch fixes the trailing zero problem mentioned in several bugs (in addition to $SUBJECT), including 4511638, 6575880, and 4191279. The problem arises because sun.misc.FloatingDecimal.getChars and sun.misc.FloatingDecimal.dtoa disagree about when numbers are represented in E-form and when they are not. As a result, dtoa stuffs one too many numbers (a '0' in this case) into digits[], and getChars blindly returns them to FloatingDecimal.toJavaFormatString. I have also attached a jtreg test for this, based on various testcases given in several bug requests. Keith

2 1

fdlibm behaviour on non-HotSpot platforms
by gnu_andrew＠member.fsf.org 04 Oct '07

04 Oct '07

Hi, Christian Thalinger (twisti) of the CACAO project has recently been looking at using the OpenJDK libraries with CACAO as the VM (via a suitable libjvm.so) to allow it to be built on non-HotSpot supported platforms (e.g. ppc, ppc64, alpha). I've just been testing this on ppc64 this morning. The trigonometric functions (sin, cos, tan) seem to run into difficulties on these new platforms. On x86, x86_64 and sparc, sin(0.7) returns the correct answer of 0.644217687237691. On alpha, the same test gives -0.9589410493575494 while it returns the input value of 0.7 on both ppc and ppc64. Ironically, gij on ppc64 gives the correct answer. This was spotted when running SPECs check: 5$ cacao -cp ./check.jar spec/jbb/validity/PepTest LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_FindSignal: name=HUP LOG: [0x30021cd0] JVM_RegisterSignal: sig=0, handler=0x2, IMPLEMENT ME! LOG: [0x30021cd0] JVM_FindSignal: name=INT LOG: [0x30021cd0] JVM_RegisterSignal: sig=0, handler=0x2, IMPLEMENT ME! LOG: [0x30021cd0] JVM_FindSignal: name=TERM LOG: [0x30021cd0] JVM_RegisterSignal: sig=0, handler=0x2, IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetSystemPackage: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetSystemPackage: IMPLEMENT ME! testIf: OK testArray: OK testBitOps: OK testFor: OK testDiv: OK testTableSwitch: OK testLookupSwitch: OK testHiddenField: OK checkRemainders: long double OK checkMathFcts: sin(0.7) evaluated to: 0.7, expected: 0.644218 cos(0.7) evaluated to: 1.0, expected: 0.764842 acos(0.7) evaluated to: 1.5707963267948966, expected: 0.795399 atan(0.7) evaluated to: 0.7, expected: 0.610726 ****************************************** Some math function failed ****************************************** Primes less than 50: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 testExc1(simple throw/catch): OK testExc2(skip catch clauses): OK testExc3(catch in inner): OK testExc4(catch in outer): OK testExc5(rethrow): OK testExc6(throw accross call): OK testExc7(throw accr. 2 calls): OK loopExitContinueInExceptionHandler: OK testStringHash: OK testClone: OK testObjectArray: OK checkInstanceOf: OK checkInterfaceInstanceOf: OK testWaitNull: OK testVarAndMethodNameClash: OK testMisk: OK testGC: OK testRandom : OK PepTest: error Any idea what the problem may be and when this may be rectified? Thanks, -- Andrew :)

3 2

[PATCH] java.nio/6593946 ByteBuffer.compact does not clear mark
by Keith Seitz 04 Oct '07

04 Oct '07

Hi, The attached patch should fix the mark problem with ByteBuffer.compact, which simply was not following the API specification. I'm also attaching a simple jtreg testcase for this. Keith

2 1

Improved List initialisation
by Richard Warburton 12 Sep '07

12 Sep '07

I hope this is the correct mailing list to discuss such an idea, please correct me if I'm wrong, but core-libs sounded like it included collections api. Within Java we have a sugared syntax for initialising arrays, so for example we can write this: int[] intArray = {1,2,3}; However, list initialisation requires a very handed approach, for example: List<Integer> intList = new ArrayList<Integer>(); intList.add(1); intList.add(2); intList.add(3); Certain other languages have some sugar for this kind of thing, the general jist of: List l = [1,2,3]; In java we could get a similarly concise effect, with no hacking in syntactic sugar to solve these problems, I am thinking of a syntax along the lines of: List<Integer> intList = new ArrayList<Integer>(1,2,3); This could be trivially implemented as such: public ArrayList(T ... args) { for (T t : args) { this.add(t); } } The same approach could be used for Vector and the Set collections classes I am also not aware of the process of proposing library changes, eg would I need to do something in conjunction with the JCP? Perhaps someone more knowledgable could advise me. Awaiting commentary with interest. Richard Warburton

2 1

Re: JDK GNU/Linux SPARC and MIPS
by Volker Simonis 11 Sep '07

11 Sep '07

On 9/11/07, steve goldman <Steve.Goldman(a)sun.com> wrote: > Sunil Amitkumar Janki wrote: > > Am I naive to think that Solaris and Linux SPARC should be > > almost the same? I have copied the solaris_sparc directory > > to linux_sparc and changed all references to Solaris to Linux. > > That is certainly how thing usually go. > > Now if I can put a project in someone's head one of the things we've > wanted to for a long time is to have an os directory "*nix" where most > os the solaris/linux code would go and eliminate the redundancy. Then > add something like os_flavor to the MakeDeps macros and platform files > to cover the place where linux and solaris differ. I don't know if this > then causes factoring <os_cpu> into both <os_cpu> and <os_flavor_cpu> or > not. I suspect it does. > This sounds like nice to have, although it will be probably quite a lot of work. Perhaps it would be a better idea to clean up the native parts in the j2se/src/solaris directory first. It currently contains the native Solaris AND the Linux sources, separeted only by '#ifdef'. (Notice that j2se/src/linux only contains the Linux man-pages). As OpenJDK will be ported to more "*nix"-like os-platforms, this will be probably a major point of confusion. Volker

2 1