Re: RFR: 8285523: Improve test java/io/FileOutputStream/OpenNUL.java

On Mon, 25 Apr 2022 04:35:13 GMT, Sergey Bylokhov wrote: > The new test added as part of the > [JDK-8285445](https://bugs.openjdk.java.net/browse/JDK-8285445) cannot > trigger that bug and pass w/ and w/o fix. > > An updated test validates the "default" case when the `jdk.io.File.enableADS` >

Re: RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked

On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao wrote: > I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to > the state previous to JDK-8160768, where an authentication failure stops from > trying other LDAP servers with the same credentials [1]. After JDK-8160768 we >

Re: RFR: JDK-8276572: Fake libsyslookup.so library causes tooling issues

On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes wrote: > The lack of anything to compile in `syslookup.c` is leading to a number of > issues in our tooling, on some architectures more than others (s390x seems to > be the most problematic). They expect to be able to retrieve debu

Integrated: JDK-8276572: Fake libsyslookup.so library causes tooling issues

On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes wrote: > The lack of anything to compile in `syslookup.c` is leading to a number of > issues in our tooling, on some architectures more than others (s390x seems to > be the most problematic). They expect to be able to retrieve debu

Re: RFR: JDK-8276572: Fake libsyslookup.so library causes tooling issues

On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes wrote: > The lack of anything to compile in `syslookup.c` is leading to a number of > issues in our tooling, on some architectures more than others (s390x seems to > be the most problematic). They expect to be able to retrieve debu

Re: RFR: JDK-8276572: Fake libsyslookup.so library causes tooling issues

On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes wrote: > The lack of anything to compile in `syslookup.c` is leading to a number of > issues in our tooling, on some architectures more than others (s390x seems to > be the most problematic). They expect to be able to retrieve debu

Re: RFR: JDK-8276572: Fake libsyslookup.so library causes tooling issues

On Thu, 4 Nov 2021 12:40:15 GMT, Maurizio Cimadamore wrote: > Looks ok. As long as we don't introduce more dependencies. > > One question: would introducing a static function (so, not visible in the > resulting DLL) be good enough? I did wonder about this too. I'll have to check it still reso

RFR: JDK-8276572: Fake libsyslookup.so library causes tooling issues

The lack of anything to compile in `syslookup.c` is leading to a number of issues in our tooling, on some architectures more than others (s390x seems to be the most problematic). They expect to be able to retrieve debuginfo and compiler flags from generated .so files and fail with libsyslookup.

Re: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"

On Thu, 9 Sep 2021 14:31:19 GMT, Magnus Ihse Bursie wrote: >> Currently, the build system defaults the libjvm.so location to "server". >> This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We >> need to see if moving the libjvm.so to a proper location breaks anything. >>

Re: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection [v5]

On Fri, 12 Feb 2021 12:49:01 GMT, Severin Gehwolf wrote: >> This is an enhancement which solves two issues: >> >> 1. Multiple reads of relevant cgroup interface files. Now interface files >> are only read once per file (just like Hotspot). >> 2. Proxies creation of the impl specific subsystem v

Re: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection [v4]

On Fri, 12 Feb 2021 12:49:19 GMT, Severin Gehwolf wrote: >> Setting reviewers to 2 since I want @gnu-andrew to be OK with it too. > > Hi Harold, > >> Thanks for doing this! Sorry for taking so long to review this change. The >> change looks good. > > Thanks for the review! > >> Before pushing

Re: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection

On Tue, 12 Jan 2021 14:29:28 GMT, Severin Gehwolf wrote: > Anybody willing to review this? I can have a go. I have two main concerns: 1. There seems to be little documentation on the new additions. I'm particularly concerned about things like CgroupV1Subsystem.java where a big chunk of docum

Re: RFR: 8254177: (tz) Upgrade time-zone data to tzdata2020b

On Tue, 13 Oct 2020 11:32:54 GMT, Kiran Sidhartha Ravikumar wrote: >> Looks good. I think we should release-note the removal of the >> "US/Pacific-New" Link on the off chance that some >> production/testing system is looking for such a zone. > > Thanks for the review everyone, I have added a re

Re: RFR [15] 8243541: (tz) Upgrade time-zone data to tzdata2020a

On 27/04/2020 19:19, Kiran Ravikumar wrote: > Hi Martin and Andrew, > > > Thanks for the review and providing a direction towards updating the > translations. > > > Here is an updated webrev with the changes: > > http://cr.openjdk.java.net/~kravikumar/8243541/webrev/ > > > All associated

Re: RFR [15] 8243541: (tz) Upgrade time-zone data to tzdata2020a

On 27/04/2020 12:13, Kiran Ravikumar wrote: > Hello All, > > > Please review the patch for tzdata2020a integration into jdk. > > Release details can be found here: > > http://mm.icann.org/pipermail/tz-announce/2020-April/58.html > > > Webrev: http://cr.openjdk.java.net/~kravikumar/8243

Re: RFR: 8224560: (tz) Upgrade time-zone data to tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk-13

On 05/07/2019 15:16, Ramanand Patil wrote: > Hi all, > Please review the patch for tzdata2019a integration into jdk project. > Webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.00/ > Bugs: https://bugs.openjdk.java.net/browse/JDK-8224560 > https://bugs.openjdk.java.net/browse/JDK-8225580

Re: [8u] 8226392: Launcher should not enable legacy stdio streams on GNU/Linux (glibc)

On 24/06/2019 15:52, Florian Weimer wrote: > * Andrew John Hughes: > >> On 24/06/2019 14:54, Florian Weimer wrote: >>> * Severin Gehwolf: >>> >>>> Could I please get reviews for this 8u only change? The JDK 8u build >>>> logic for laun

Re: [8u] 8226392: Launcher should not enable legacy stdio streams on GNU/Linux (glibc)

On 24/06/2019 14:48, Severin Gehwolf wrote: > Hi, > > Could I please get reviews for this 8u only change? The JDK 8u build > logic for launcher files includes linker version script files (a.k.a > mapfiles). The script file for x86 (32bit) marks symbol _IO_stdin_used > as local. When the symbol

Re: [8u] 8226392: Launcher should not enable legacy stdio streams on GNU/Linux (glibc)

On 24/06/2019 14:54, Florian Weimer wrote: > * Severin Gehwolf: > >> Could I please get reviews for this 8u only change? The JDK 8u build >> logic for launcher files includes linker version script files (a.k.a >> mapfiles). The script file for x86 (32bit) marks symbol _IO_stdin_used >> as local

Re: RFR: JDK-8225213: Backport jsr166 tck tests to jdk8u

On 05/06/2019 02:35, Martin Buchholz wrote: > > > On Tue, Jun 4, 2019 at 6:07 PM Andrew John Hughes <mailto:gnu.and...@redhat.com>> wrote: > > > I don't think this is the best approach. JDK-8146467 looks like a pretty > clean snapshot of the

Re: RFR: JDK-8225213: Backport jsr166 tck tests to jdk8u

On 05/06/2019 01:15, Martin Buchholz wrote: > (Trying to correct my mistake of not having cc'ed jdk8u-dev) > > On Mon, Jun 3, 2019 at 5:15 PM Martin Buchholz > wrote: > > > > -- Forwarded message - > From: *Martin Buchholz (JBS)*

Re: [8u] 8205432: Replace the placeholder Japanese era name

On 09/04/2019 18:18, Hohensee, Paul wrote: > I meant the current webrev > > https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.02/ > > is fine. Just backport what's in tip and fix whatever's wrong later as > another backport or backports. > > Paul Thanks. I've pushed based on the revi

Re: RFR: [8u] 8205432: Replace the placeholder Japanese era name

On 08/04/2019 09:25, Deepak Kejriwal wrote: > Hi Andrew, > > Thanks for working on this. Please find below few minor comments:- > > 1>. For "src/share/classes/java/util/JapaneseImperialCalendar.java" and > "src/share/classes/sun/util/calendar/Era.java" please changes the date time > format to b

RFR: [8u] 8205432: Replace the placeholder Japanese era name

Bug: https://bugs.openjdk.java.net/browse/JDK-8205432 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.01/ This is a relatively clean backport, with a few exceptions, mostly due to unneeded copyright changes or moved files: * 8u has FormatData_ja.java and JavaTimeSupplementary_

Re: Add Look&Feel support for AIX platform

On 14:45 Tue 13 Dec , Neil Richards wrote: > On Tue, 2011-12-13 at 14:42 +, Neil Richards wrote: > > On Tue, 2011-12-13 at 10:36 +0800, Sean Chou wrote: > > > On Mon, Dec 12, 2011 at 7:33 PM, Neil Richards > > > wrote: > > > On Tue, 2011-12-06 at 11:14 +0800, Sean Chou wrote: > > >

Re: Request for review: More cause-chaining for InternalError

On 14:16 Tue 23 Aug , Sebastian Sickelmann wrote: > Am 22.08.2011 21:19, schrieb Joe Darcy: > > Sebastian Sickelmann wrote: > >> Am 17.08.2011 03:11, schrieb joe.da...@oracle.com: > >>> Hello. > >>> > >>> On 8/14/2011 11:17 PM, Sebastian Sickelmann wrote: > Hi, > > some time ago,

Re: Enhance toString() to return structured info, for certificate and probably more

On 10:41 Thu 25 Aug , Weijun Wang wrote: > Hi All > > I was talking with Xuelei on how to better display certificate info. > There are 3 cases we can currently think of: > > 1. debug output > 2. keytool/jarsigner output > 3. Java plugin display > > The 1st one is the most primitive one and

Re: hg: jdk8/tl/jdk: 7082727: VirtualMachineError should declare its serialVersionUID

On 16:43 Thu 25 Aug , joe.da...@oracle.com wrote: > Changeset: 624cc18a6cf9 > Author:darcy > Date: 2011-08-25 09:42 -0700 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/624cc18a6cf9 > > 7082727: VirtualMachineError should declare its serialVersionUID > Reviewed-by: alanb > >

Re: Request for Review: Chain more Exceptions (RuntimeException)

On 07:01 Thu 18 Aug , Sebastian Sickelmann wrote: > Hi, > > i have created a fix for fixing Exception-Chains in case of an rethrown > RuntimeException. > > I am not quite sure if this is inside the scope of what i > discussed[0][1] with Joe. But it is > fixed in the same manner as the patch

Re: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror]

On 17:11 Tue 02 Aug , Alan Bateman wrote: > Xuelei Fan wrote: > > : > > 1. I noticed the copyright date of a few files are unchanged, please > > update them before you push the changes. > > > This has come up a few times but I don't think it is strictly required. > Kelly or one of the relea

Re: Are the faster versions of HashMap and BigInteger going into jdk7?

On 02:39 Mon 15 Aug , Alan Eliasen wrote: > On 10/27/2009 01:12 AM, Alan Eliasen wrote: > > On 10/23/2009 11:01 AM, Andrew John Hughes wrote: > >> 6622432 is the one of the ones I just pointed to i.e. it's in JDK7. > >> If Alan has a further patch

Re: JDK 8 code review request for 7075098: Remove unused fdlibm files

On 13:09 Thu 04 Aug , Joe Darcy wrote: > > The JDK makefiles specially compile the FDLIBM sources under lower > optimization levels to try to avoid such problems. Over the years, we > have had our share of C compiler bugs tripping up FDLIBM, which have > been caught by our testing. One of

Re: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror]

On 09:24 Wed 03 Aug , Joe Darcy wrote: > On 8/3/2011 12:42 AM, David Holmes wrote: > > Alexandre Boulgakov said the following on 08/03/11 04:44: > >> On 8/2/2011 2:19 AM, Xuelei Fan wrote: > >>> 3017 Vector temp = (Vector)extractURLs(res.errorMessage); > >>> You may not need the conversion

Re: hg: jdk8/tl/jdk: 7068616: NIO libraries do not build with javac -Xlint:all, -deprecation -Werror

On 16:47 Thu 28 Jul , Alexandre Boulgakov wrote: > > On 7/28/2011 4:43 PM, Dr Andrew John Hughes wrote: > > On 21:44 Thu 28 Jul , jonathan.gibb...@oracle.com wrote: > >> Changeset: 7525866a4046 > >> Author:jjg > >> Date: 2011

Re: hg: jdk8/tl/jdk: 7068616: NIO libraries do not build with javac -Xlint:all, -deprecation -Werror

On 21:44 Thu 28 Jul , jonathan.gibb...@oracle.com wrote: > Changeset: 7525866a4046 > Author:jjg > Date: 2011-07-28 13:34 -0700 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7525866a4046 > > 7068616: NIO libraries do not build with javac -Xlint:all,-deprecation -Werror > Revi

Re: Regression in OpenJDK8 Makefiles

On 17:12 Wed 27 Jul , Kelly O'Hair wrote: > > On Jul 27, 2011, at 4:28 PM, Dr Andrew John Hughes wrote: > > > On 11:58 Wed 27 Jul , Kelly O'Hair wrote: > >> > >> On Jul 27, 2011, at 11:04 AM, Dr Andrew John Hughes wrote: > >> &

Re: Regression in OpenJDK8 Makefiles

On 11:58 Wed 27 Jul , Kelly O'Hair wrote: > > On Jul 27, 2011, at 11:04 AM, Dr Andrew John Hughes wrote: > > > Hi, > > > > Can someone please tell me why: > > > > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf4edfcd7119 > > > > reve

Regression in OpenJDK8 Makefiles

Hi, Can someone please tell me why: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf4edfcd7119 reverted my earlier fix: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80368890a2a0 without any discussion? The correct fix would have been to bump the boot source language/target class versions to 7, not

Re: JDK 8 code review request for 7007535: (reflect) Please generalize Constructor and Method

On 12:49 Tue 19 Jul , Joe Darcy wrote: > Agreed; I've posted a BlenderRev corresponding to the current patch at: > > http://cr.openjdk.java.net/~darcy/7007535.4/BR-7007535.html > What is BlenderRev? Google finds others posted by Oracle employees but not how to generate them. > Thanks,

Re: JDK 8 code review request for 7007535: (reflect) Please generalize Constructor and Method

On 19:21 Wed 13 Jul , joe.da...@oracle.com wrote: > Hello. > > Please code review my JDK 8 changes for > > 7007535: (reflect) Please generalize Constructor and Method > http://cr.openjdk.java.net/~darcy/7007535.3 > > To summarize the changes, a new superclass is defined to capture th

Re: Heads up, new jaxp source drop

On 07:26 Fri 20 May , Kelly O'Hair wrote: > As soon as we figure out how to restrict changes to particular source files > and protect > them from intentional or accidental edits. I just have not had the time to > deal with this kind of > change. > I thought that's what our existing review

Re: Heads up, new jaxp source drop

On 17:53 Thu 19 May , Kelly O'Hair wrote: > Heads up. The jdk7/tl forest has a new jaxp source drop dependency. > > 7044493: Incorrectly formated GPL headers in JDK7 JAXP source drop > http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/bdf77cbd9958 > > The new source drop bundle is called: > ja

Re: Reviewer needed - fix for regression test LastErrorString

On 5 May 2011 20:45, Alan Bateman wrote: > Pavel Tisnovsky wrote: >> >> Hi all, >> >> I'd like to push fix for regression test >> java/io/IOException/LastErrorString.java to OpenJDK7 and OpenJDK6. This >> fix ensures that no system-important files can be erased and/or >> rewritten by this test eve

Re: Need reviewers: Update of jaxp 1.4.5 source drop bundle

On 07/04/2011, Dalibor Topic wrote: > On 3/3/11 3:01 AM, Dr Andrew John Hughes wrote: >> How do we know what the actual changes are between these tarballs? Is >> there some JAXP repository somewhere these are derived from, with >> appropriate tagging? > > Afaik, the

Re: Trivial review: 7032364 Add jvm.cfg file for ARM and PPC architectures

On 30 March 2011 08:09, David Holmes wrote: > http://cr.openjdk.java.net/~dholmes/7032364/webrev/ > > More pieces to support SE Embedded. > > David > When are these files installed? Will they interfere with Zero/Shark installs on ARM & PPC? Thanks, -- Andrew :-) Free Java Software Engineer Re

Re: Need reviewers: Update of jaxp 1.4.5 source drop bundle

On 2 March 2011 19:48, Alan Bateman wrote: > Kelly O'Hair wrote: >> >> Need reviewer for change in jaxp source drop bundle >> >> 7023289: jaxp 1.4.5 development jdk7 2nd integration >> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxp-145dev1/webrev/ >> >> Joe or someone from the JAXP team m

Re: How to find IBM's contributions?

On 25 February 2011 20:15, Paul Benedict wrote: > To the community, > > Is there any easily identifiable way to determine when IBM contributes > fixes/patches to the repositories? I know all Oracle employees have Oracle > email addresses. What about those from IBM? I was hoping to see what they >

Re: Zlib level in JDK7

On 22 February 2011 17:26, Phil Race wrote: > On 2/20/2011 9:39 AM, Dr Andrew John Hughes wrote: >> >> On 15 February 2011 20:23, Phil Race  wrote: >>> >>> On 2/15/2011 6:07 AM, Dr Andrew John Hughes wrote: >>>> >>>> Yes, IcedTea uses s

Re: Zlib level in JDK7

On 15 February 2011 20:23, Phil Race wrote: > On 2/15/2011 6:07 AM, Dr Andrew John Hughes wrote: >> >> Yes, IcedTea uses system libraries for everything bar LCMS, where >> local changes in OpenJDK mean we are still forced to use the in-tree >> version.  There hasn

Re: Zlib level in JDK7

On 15 February 2011 13:57, Alan Bateman wrote: > Steve Poole wrote: >> >> Hi all, >> JDK7 is using zlib 1.2.3 (which was added to JDK7 back in 2009.) >> Zlib's latest version is 1.2.5 - is there any expectation to move to >> 1.2.5 in JDK7?   It seems a real shame to ship JDK7 with a version of >>

Re: sun.cpu.isalist

2011/2/15 Dmytro Sheyko : > Sure, we can parse /proc/cpuinfo output on Linux in order to provide valid > isalist, but it seems it's not worth doing. Maybe we can just get rid of it. > > >> Date: Mon, 14 Feb 2011 20:44:23 -0600 >> From: david.ll...@redhat.com >> To: core-libs-dev@openjdk.java.net >>

Re: sun.cpu.isalist

2011/2/14 Dmytro Sheyko : > Hi, > > I can see that such system property as "sun.cpu.isalist" is not set on > Linux, but it is set on Solaris and Windows. > What is the purpose of this property and shouldn't it be set on Linux as > well? > > Thanks, > Dmytro > > On Solaris, it includes the results

Re: Fix for JDK Double.parseDouble infinite loop

On 7 February 2011 21:48, Mark Wielaard wrote: > On Wed, February 2, 2011 17:16, Andrew Haley wrote: >> The post on >> http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/ > > This is hitting more and more media. e.g. > http://www.channelregister.co.uk/2011/02/07/java

Re: Fix for JDK Double.parseDouble infinite loop

On 2 February 2011 20:30, Mark Wielaard wrote: > On Wed, 2011-02-02 at 20:02 +, Alan Bateman wrote: >> Andrew Haley wrote: >> > The post on >> > http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/ >> > >> > describes a (on first sight) trivial bug when parsing st

Re: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock

On 16 December 2010 16:39, Neil Richards wrote: > On 13 December 2010 20:04, Neil Richards wrote: >> On 13 December 2010 18:46, Alan Bateman wrote: >>> I haven't looked at your patch in detail yet but I suspect there may be >>> similar issues in other places (like j.u.Hashtable) once you are don

Re: Improved Java Collection APIs

On 19 November 2010 15:49, John Platts wrote: > > Here are improvements that I really want to see to Java Collection APIs: > - Addition of an equality comparator interface. > - An wrapper that wraps a java.util.Comparator as a equality comparator. > - Map and set classes that allow an equality com

Re: 6989466: Miscellaneous compiler warnings in java/lang, java/util, java/io, sun/misc native code

On 6 October 2010 21:56, Dr Andrew John Hughes wrote: > On 6 October 2010 21:37, Alan Bateman wrote: >> >> This batch eliminates a bunch of compiler warnings from the native code: >>  http://cr.openjdk.java.net/~alanb/6989466/webrev/ >> >> It also fixes an inco

Re: 6989466: Miscellaneous compiler warnings in java/lang, java/util, java/io, sun/misc native code

On 6 October 2010 21:37, Alan Bateman wrote: > > This batch eliminates a bunch of compiler warnings from the native code: >  http://cr.openjdk.java.net/~alanb/6989466/webrev/ > > It also fixes an incorrect usage of memset found along the way. > > -Alan. > This looks good from reading the patch.

Re: jvm load too many classes

On 31 July 2010 21:31, Rémi Forax wrote: > Le 30/07/2010 21:59, Mandy Chung a écrit : >> >> Osvaldo Doederlein wrote: >>> >>> I wonder if these numbers have some variation per platform? >> >> Yes, there are some platform-dependent classes and so some loaded >> classes are different on different pl

Re: PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in sun/nio/cs

On 9 June 2010 18:22, Xueming Shen wrote: > Andrew John Hughes wrote: >> >> On 9 June 2010 07:55, Florian Weimer wrote: >> >>> >>> * Andrew John Hughes: >>> >>> >>>> >>>> On 7 June 2010 23:04, Xueming

Re: PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in sun/nio/cs

dk/rev/c849dc20dc85 > Sherman > > > Andrew John Hughes wrote: >> >> On 9 June 2010 18:22, Xueming Shen wrote: >> >>> >>> Andrew John Hughes wrote: >>> >>>> >>>> On 9 June 2010 07:55, Florian Wei

Re: PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in sun/nio/cs

On 9 June 2010 07:55, Florian Weimer wrote: > * Andrew John Hughes: > >> On 7 June 2010 23:04, Xueming Shen wrote: >>> Hi Andrew, >>> >>> 6959197: When building with JAVAC_MAX_WARNINGS=true, the build fails in >>> sun/nio/cs due to the use of -W

Re: PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in sun/nio/cs

.nio.cs.ext.PCK.java > >   JIS_X_0208_Solaris_Encoder jis0208 is no longer needed > Fixed. New webrev: http://cr.openjdk.java.net/~andrew/warnings/webrev.04/ Thanks for such a detailed review. I just fixed the issues that came up from javac and didn't review the resulting classes in d

Re: PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in sun/nio/cs

On 7 June 2010 19:06, Xueming Shen wrote: > > Andrew, I'm going through the webrev now.  Need a little more time. > > -sherman > > Andrew John Hughes wrote: >> >> On 2 June 2010 18:57, Andrew John Hughes wrote: >> >>> >>> When building w

PING: Re: Fix build failure with JAVAC_MAX_WARNINGS=true in sun/nio/cs

On 2 June 2010 18:57, Andrew John Hughes wrote: > When building with JAVAC_MAX_WARNINGS=true, the build fails in > sun/nio/cs due to the use of -Werror. > > The following webrev: > > http://cr.openjdk.java.net/~andrew/warnings/webrev.03/ > > fixes the remai

Fix build failure with JAVAC_MAX_WARNINGS=true in sun/nio/cs

When building with JAVAC_MAX_WARNINGS=true, the build fails in sun/nio/cs due to the use of -Werror. The following webrev: http://cr.openjdk.java.net/~andrew/warnings/webrev.03/ fixes the remaining warnings exposed by JAVAC_MAX_WARNINGS by: * Removing redundant casts * Adding generic types to a

Re: Math.log(17197) produces inconsistent results between javac, jit, Math and StrictMath on various architectures.

On 24 May 2010 13:55, Xerxes Rånby wrote: > Hi > > Im hoping to find someone who can enlighten me how to resolve a bug > where some hotspot JITs > fails the hotspot/test/compiler/6539464 jtreg regression test. > > The testcase looks like: > > public class Test { >    static double log_value = 1719

Re: Need reviewer for forward port of 6815768 (File.getXXXSpace) and 6815768 (String.hashCode)

On 25 February 2010 18:19, Kelly O'Hair wrote: > Looks fine to me. > > -kto > > On 2/25/10 9:51 AM, Alan Bateman wrote: >> >> There are two fixes in Sun's proprietary jdk6 updates that should also >> be fixed in OpenJDK. >> >> The first one is that the File.getXXXSpace methods use statvfs instead

Re: Please review changes in regression test test/java/security/Provider/Turkish.java

2010/1/18 Alan Bateman : > Andrew John Hughes wrote: >> >> : >> As mentioned by Joe >> (http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-January/001135.html) >> patches for jdk6 should be sent to the jdk6-dev list before being >> pushed to the jdk6 tre

Re: Please review changes in regression test test/java/security/Provider/Turkish.java

2010/1/18 Alan Bateman : > Pavel Tisnovsky wrote: >> >> Hi, >> >> please review changes in regression test >> jtest/java/security/Provider/Turkish.java. >> >> Webrev is available at http://cr.openjdk.java.net/~ptisnovs/Turkish/ >> >> We already discussed similar issue on jdk6-dev mailing list, conc

Re: Request for approval: Allow Java's ELF symtab reader to use separate debuginfo files

2010/1/8 Kelly O'Hair : > > > Andrew John Hughes wrote: >> >> 2010/1/8 Kelly O'Hair : >>> >>> Andrew Haley wrote: >>>> >>>> On 12/09/2009 03:36 PM, Andrew Haley wrote: >>>>> >>>>> This is https:

Re: Request for approval: Allow Java's ELF symtab reader to use separate debuginfo files

2010/1/8 Kelly O'Hair : > > > Andrew Haley wrote: >> >> On 12/09/2009 03:36 PM, Andrew Haley wrote: >>> >>> This is https://bugzilla.redhat.com/show_bug.cgi?id=541548 >>> The symptom is that jmap doesn't work because target libraries are >>> stripped. >>> The fix is to allow the symtab reader to us

Re: Code review request for 4891262 "API spec, javax/accessibility: few invalid javadoc tags"

2009/12/10 Joseph D. Darcy : > Andrew John Hughes wrote: >> >> 2009/12/10 Joe Darcy : >> >>> >>> Hello. >>> >>> While doing a coredocs build, I noticed once again some javadoc warnings >>> coming out of the javax.accessibility pac

Re: Code review request for 4891262 "API spec, javax/accessibility: few invalid javadoc tags"

2009/12/10 Joe Darcy : > Hello. > > While doing a coredocs build, I noticed once again some javadoc warnings > coming out of the javax.accessibility package and I decided to fix them; the > patch is below and the full webrev is at > > http://cr.openjdk.java.net/~darcy/4891262.0/ > Again, good to s

Re: hg: jdk7/tl/jdk: 6907177: Update jdk tests to remove unncessary -source and -target options

2009/12/4 : > Changeset: 1755493c5774 > Author:    darcy > Date:      2009-12-03 18:19 -0800 > URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1755493c5774 > > 6907177: Update jdk tests to remove unncessary -source and -target options > Reviewed-by: ohair > > ! test/demo/jvmti/hprof/CpuOldTe

Re: Gap Buffer based AbstractStringBuilder implementation

2009/11/20 Osvaldo Doederlein : > Hi Goktug, > > Looks like good stuff. And it remembers me from another old issue: patterns > of code that demand data copying that could often be avoided. Every > StringBuffer/StringBuilder is ultimately consumed by a toString() invocation > to produce the result S

Re: Code review request for 6897550 BigInteger constructor should use local cached String length

2009/11/3 Joseph D. Darcy : > Hello. > > Please review this simple change to replace several calls to val.length() > with an already cached copy of val.length(); patch below. > > 6897550 BigInteger constructor should use local cached String length > http://cr.openjdk.java.net/~darcy/6897550.0/ > >

Re: Are the faster versions of HashMap and BigInteger going into jdk7?

2009/10/27 Alan Eliasen : > On 10/23/2009 11:01 AM, Andrew John Hughes wrote: >> >> 6622432 is the one of the ones I just pointed to i.e. it's in JDK7. >> If Alan has a further patch and hasn't even submitted it for >> inclusion, it's obviously not in.

Re: Are the faster versions of HashMap and BigInteger going into jdk7?

2009/10/23 Paulo Levi : > Yes. Different implementations with better performance. > > http://gcc.gnu.org/ml/java/2009-06/msg00019.html > 6622432 is the one of the ones I just pointed to i.e. it's in JDK7. If Alan has a further patch and hasn't even submitted it for inclusion, it's obviously not in

Re: Are the faster versions of HashMap and BigInteger going into jdk7?

2009/10/23 Paulo Levi : > Just a question. > The only relevant changes I see are: changeset: 1246:8d2efec31d78 user:xlu date:Sun May 24 16:29:57 2009 -0700 summary: 6622432: RFE: Performance improvements to java.math.BigDecimal http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/8

Re: Review request #1: 6863566 (Java should support the freedesktop.org startup notification specification)

2009/10/15 Michael McMahon : > It doesn't seem right to filter out arbitrary environment variables > like that (inside ProcessEnvironment). Sorry, I haven't been following this > issue closely, > but is it not possible to unset this variable somewhere else? > I concur. That's a nasty hack that's

Re: Fix for 5015163, and my first webrev

2009/10/14 Ulf Zibis : > Am 14.10.2009 17:01, Rémi Forax schrieb: >> >> Le 14/10/2009 16:47, Ulf Zibis a écrit : >>> >>> Rémi, >>> >>> can you tell me how you got the cr.openjdk.java.net account ? >>> Is there any registration link? >>> >>> Thanks, >>> >>> Ulf >> >> I've got it because I've the rig

Re: Patch for JTreg test java/net/MulticastSocket/SetOutgoingIf.java

2009/9/23 Andrew Haley : > Andrew John Hughes wrote: >> 2009/9/23 Andrew Haley : >>> Christopher Hegarty -Sun Microsystems Ireland wrote: >>>> [cc'ing net-dev] >>>> >>>> I see you have push access, so if you make the appropriate changes

Re: Patch for JTreg test java/net/MulticastSocket/SetOutgoingIf.java

2009/9/23 Andrew Haley : > Christopher Hegarty -Sun Microsystems Ireland wrote: >> [cc'ing net-dev] >> >> Alan Bateman wrote: >>> Pavel Tisnovsky wrote: Hi, two-lines patch for regression test java/net/MulticastSocket/SetOutgoingIf.java is exposed at http://cr.openjdk.java.

Re: [OpenJDK 2D-Dev] Review Request for 6879044

2009/9/14 Mandy Chung : > 6879044: Eliminate the dependency of logging from the JRE core/awt/swing > classes > > Webrev: >  http://cr.openjdk.java.net/~mchung/6879044/webrev.00/ > > Summary: > 1. A new sun.util.logging.PlatformLogger class that will handle the log > messages in a similar way as Log

Re: PATCH: Tired of waiting for rt.jar to build?

d the prodding was aimed more at the authors of the missing messages in that thread... :) FWIW, I'm pretty sure I'm not alone in saying I'd much prefer to receive these 'uninteresting' mails. There are plenty of mailing lists and mail filters to allow us to cherry-pi

Re: What methods should go into a java.util.Objects class in JDK 7?

2009/9/10 Ulf Zibis : > Am 10.09.2009 01:54, Stephen Colebourne schrieb: >> >> There is also a case for methods to convert arrays of wrappers to >> arrays of primitives. >> > > +1 > - I guess, you mean also vice versa > - Maybe would become superfluous, if HotSpot internally would compile to > prim

Re: What methods should go into a java.util.Objects class in JDK 7?

2009/9/10 Ulf Zibis : > Am 10.09.2009 02:04, Rémi Forax schrieb: >> >> Le 10/09/2009 01:43, Andrew John Hughes a écrit :  I agree about the >> debugging purpose, that why I don't agree >> with Kevin when he said that java.util.Objects should not use >> refle

Re: PATCH: Tired of waiting for rt.jar to build?

2009/4/29 Martin Buchholz : > Since writing this, I have learned, to my horror, that the > behavior of the -C flag differs from the behavior in tar in that > > - -C is not sticky - it applies only to the one following argument > > - the path is relative to the JDK's current directory, not the > pre

Re: What methods should go into a java.util.Objects class in JDK 7?

2009/9/10 Rémi Forax : > Le 09/09/2009 23:22, Andrew John Hughes a écrit : >> >> Given you've listed utility methods for two Object methods, equals and >> hashCode, toString seems an obvious one to handle as well: >> >> public static String toString(Object

Re: What methods should go into a java.util.Objects class in JDK 7?

2009/9/9 Joe Darcy : > Hello. > > For JDK 7, I think it is high-time the platform included a class like > java.util.Objects to hold commonly-written utility methods.  For example, a > two-argument static equals method that returned true if both arguments are > null, returns false is one argument is

Re: Review Request for 6878481: Add performance counters in the JDK

2009/9/3 Mandy Chung : > Alan Bateman wrote: >> >> Andrew John Hughes wrote: >>> >>> : >>> The use of synchronized at present seems flawed as only the set >>> methods are protected and not the get.  So lb.get could be called >>>

Re: Review Request for 6878481: Add performance counters in the JDK

2009/9/3 Rémi Forax : > Le 03/09/2009 10:54, Alan Bateman a écrit : >> >> Mandy Chung wrote: >>> >>> This is related to 6857194: Add hotspot new perf counters to aid class >>> loading performance measurement. >>> >>> It's useful to add performance counters in the library code so that perf >>> data

Re: Regex named-group and backreference syntax

2009/9/2 Mark Reinhold : >> Date: Wed, 02 Sep 2009 01:58:46 -0700 >> From: uncle.al...@gmail.com > >... > I'd say ${name} is the best option here given that it will be familiar, > at least, to Perl and .NET developers. > It's also used for substitution in shell and Makefiles :) > - Mark > --

Re: Code review request to remove javadoc build warnings from javax.sql.rowset.BaseRowSet.java

2009/8/28 Joseph D. Darcy : > Hello. > > More cleanup of docs build warnings; this time from > javax.sql.rowset.BaseRowSet.java where non-existent getter methods are > repeatedly referenced.  Assuming someone approves the change, I'll file a > bug and commit the fix. > > -Joe > > --- old/src/share/

Re: hg: jdk7/tl/jdk: 6843995: Added RowsetFactory and Deprecate COMMIT_ON_ACCEPT_CHANGES, make constants final that needed to be.

2009/8/22 Mark Wielaard : > Hi Andrew, > > On Fri, 2009-08-21 at 20:35 +0100, Andrew John Hughes wrote: >> 2009/8/21 Mark Wielaard : >> > On Thu, 2009-08-20 at 15:40 -0700, Mark Reinhold wrote: >> >> This change was integrated prematurely.  I've rolled it

Re: hg: jdk7/tl/jdk: 6843995: Added RowsetFactory and Deprecate COMMIT_ON_ACCEPT_CHANGES, make constants final that needed to be.

2009/8/21 Mark Wielaard : > Hi Mark, > > On Thu, 2009-08-20 at 15:40 -0700, Mark Reinhold wrote: >> This change was integrated prematurely.  I've rolled it back in the >> jdk7/tl/jdk repository. > > If at all possible, please don't do this. It plays havoc with already > checked out repos and/or aut

Re: Core review request for 6378701 "(enum) Unclear purpose of EnumConstantNotPresentException "

2009/8/21 Lance J. Andersen : > Hi Joe, > > The changes are fine and make things clearer. > > Regards > Lance > > Joseph D. Darcy wrote: >> >> Hello. >> >> Please review the patch below is clarify the use of certain exception >> types to address bug 6378701 "(enum) Unclear purpose of >> EnumConstan

Re: [PATCH FOR APPROVAL]: ReflectiveOperationException missing from FILES_java.gmk

2009/8/7 Kelly O'Hair : > > > Andrew John Hughes wrote: >> >> 2009/8/7 Kelly O'Hair : >>> >>> Joseph D. Darcy wrote: >>>> >>>> Andrew John Hughes wrote: >>>>> >>>>> When java.lang.Reflectiv

Re: [PATCH FOR APPROVAL]: ReflectiveOperationException missing from FILES_java.gmk

2009/8/7 Kelly O'Hair : > > > Joseph D. Darcy wrote: >> >> Andrew John Hughes wrote: >>> >>> When java.lang.ReflectiveOperationException was added in: >>> >>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/aaf0cb20646e >>> &

  1   2   >