From volker.simonis at gmail.com Tue Sep 11 14:39:50 2007 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 11 Sep 2007 16:39:50 +0200 Subject: JDK GNU/Linux SPARC and MIPS In-Reply-To: <46E69C50.4020609@sun.com> References: <46CC326D.1030101@gmail.com> <1188250373.3823.44.camel@localhost.localdomain> <46DD59E6.3080900@gmail.com> <46DD8F75.6030801@reservoir.com> <46E454AD.60700@gmail.com> <46E562F4.5000908@gmail.com> <46E69C50.4020609@sun.com> Message-ID: On 9/11/07, steve goldman 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 into both and 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 From Steve.Goldman at Sun.COM Tue Sep 11 14:59:59 2007 From: Steve.Goldman at Sun.COM (steve goldman) Date: Tue, 11 Sep 2007 10:59:59 -0400 Subject: JDK GNU/Linux SPARC and MIPS In-Reply-To: References: <46CC326D.1030101@gmail.com> <1188250373.3823.44.camel@localhost.localdomain> <46DD59E6.3080900@gmail.com> <46DD8F75.6030801@reservoir.com> <46E454AD.60700@gmail.com> <46E562F4.5000908@gmail.com> <46E69C50.4020609@sun.com> Message-ID: <46E6AD6F.1040707@sun.com> Volker Simonis wrote: > On 9/11/07, steve goldman 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 into both and or >> not. I suspect it does. >> > > This sounds like nice to have, although it will be probably quite a lot of work. It's probably not that bad it's just never been much of a priority around here. > > 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. yeah that is kind of gross. I only work on hotspot so I can't do much on that front. Maybe someone on the libraries team that you cc'd will comment. -- Steve From richard.warburton at gmail.com Tue Sep 11 21:40:27 2007 From: richard.warburton at gmail.com (Richard Warburton) Date: Tue, 11 Sep 2007 22:40:27 +0100 Subject: Improved List initialisation Message-ID: <749b5dd60709111440h4ba892bfob41f8fdab6691cd7@mail.gmail.com> 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 intList = new ArrayList(); 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 intList = new ArrayList(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 From matthias at mernst.org Wed Sep 12 07:47:57 2007 From: matthias at mernst.org (Matthias Ernst) Date: Wed, 12 Sep 2007 09:47:57 +0200 Subject: Improved List initialisation In-Reply-To: <749b5dd60709111440h4ba892bfob41f8fdab6691cd7@mail.gmail.com> References: <749b5dd60709111440h4ba892bfob41f8fdab6691cd7@mail.gmail.com> Message-ID: <22ec15240709120047l388ac1denc551db3f527276b@mail.gmail.com> On 9/11/07, Richard Warburton wrote: > 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 intList = new ArrayList(1,2,3); Most welcome! The one-liner I use is new ArrayList(Arrays.asList(1,2,3)); but it goes on my nerves. On a side note, I would be interested in the history of var-args in this context - in the tiger release we were given var-args and at the same time shunned away from arrays. Was List considered for varargs? Nowadays I code many methods twice: void f(X...x) { f(Arrays.asList(x)); } void f(List x) { ... } From keiths at redhat.com Tue Sep 25 19:42:43 2007 From: keiths at redhat.com (Keith Seitz) Date: Tue, 25 Sep 2007 12:42:43 -0700 Subject: [PATCH] java.math/4428022 Float/Double.toString trailing zeros Message-ID: <46F964B3.9090807@redhat.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-float-double-toString-trailing-zeros.patch Type: text/x-patch Size: 1072 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FloatDoubleTrailingZeros.java Type: text/x-java Size: 2676 bytes Desc: not available URL: From keiths at redhat.com Tue Sep 25 19:48:47 2007 From: keiths at redhat.com (Keith Seitz) Date: Tue, 25 Sep 2007 12:48:47 -0700 Subject: [PATCH] java.nio/6593946 ByteBuffer.compact does not clear mark Message-ID: <46F9661F.60800@redhat.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: bytebuffer-compact-clear-mark.patch Type: text/x-patch Size: 2597 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ByteBufferCompactMark.java Type: text/x-java Size: 804 bytes Desc: not available URL: From roman at kennke.org Thu Sep 27 18:50:30 2007 From: roman at kennke.org (Roman Kennke) Date: Thu, 27 Sep 2007 20:50:30 +0200 Subject: Bug#6546113 StringCharBuffer fix Message-ID: <1190919030.7478.10.camel@mercury> 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/ From roman at kennke.org Thu Sep 27 18:51:33 2007 From: roman at kennke.org (Roman Kennke) Date: Thu, 27 Sep 2007 20:51:33 +0200 Subject: Bug#6546113 StringCharBuffer fix In-Reply-To: <1190919030.7478.10.camel@mercury> References: <1190919030.7478.10.camel@mercury> Message-ID: <1190919093.7478.12.camel@mercury> I definitely need this new Evolution thingy. Forgot the actual attachement.. Am Donnerstag, den 27.09.2007, 20:50 +0200 schrieb Roman Kennke: > 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.txt Type: text/x-patch Size: 625 bytes Desc: not available URL: