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 [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: 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: 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: 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: [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: [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 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: 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: 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: 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 [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: 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. >>

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: 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

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

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: 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: 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: OpenJDK Forum: Core Libraries Round Table

2009/5/28 Gary Benson : > Dalibor Topic wrote: >> Date/Time: Friday May 29th, 8 AM Pacific, 1600 GMT, 5 PM Germany > > Is that 1600 GMT or 1600 BST (ie 1500 GMT)? > > Cheers, > Gary > > -- > http://gbenson.net/ > Dalibor, it's looks like you copied and pasted the wrong line again... ;) If it's 5p

Re: Request for approval: fix 4428022, System.out.println(0.001) outputs 0.0010

2009/5/28 Andrew Haley : > Joseph D. Darcy wrote: >> Andrew Haley wrote: >>> Joseph D. Darcy wrote: >>> Alan Bateman wrote: > Andrew Haley wrote: > >> : >> OK, here it is.  I put the test in java/lang/Double/ToString.java >> rather than sun/misc/FloatingDecimal because

Re: timsort

2009/6/30 Martin Buchholz : > Thanks, Alan.  You're a good reviewer. > > As you suggested, I added the Classpath exception wording > to TimSort.java and ComparableTimSort.java. > > I excised the old mergesort code from Arrays.java. > > webrev regenerated. > > Adding all-or-nothing wording would be

Re: timsort

2009/6/30 Andrew Haley : > Martin Buchholz wrote: >> Thanks, Alan.  You're a good reviewer. >> >> As you suggested, I added the Classpath exception wording >> to TimSort.java and ComparableTimSort.java. >> >> I excised the old mergesort code from Arrays.java. >> >> webrev regenerated. >> >> Adding

Re: timsort

2009/6/30 Martin Buchholz : > > > On Tue, Jun 30, 2009 at 09:24, Andrew John Hughes > wrote: >> >> 2009/6/30 Martin Buchholz : >> >> > (There is the deeper governance issue of who gets to make >> > such decisions.  I would like most of such decis

Re: timsort

2009/7/7 Christopher Hegarty -Sun Microsystems Ireland : > Hi Martin, > > Sorry for joining the party late... > > I think adding the system property should take care of the compatibility > issues, at least giving the user the ability to revert to the old behavior > if they so choose. > > I have a f

Re: timsort

2009/7/7 Christopher Hegarty -Sun Microsystems Ireland : > > > Andrew John Hughes wrote: >> >> [snip] >> >> Forgive the naivety, but what is a 'CCC request'?  Is this process of >> requesting and approving specification changes public?  I'm sur

Re: patch to address sun bug 6562614

2009/7/9 Jon VanAlten : > Hi, > > I've put up a webrev at > http://icedtea.classpath.org/~vanaltj/webrevs/tl/patch1/index.html to address > http://bugs.sun.com/view_bug.do?bug_id=6562614, also referenced on Icedtea > bugzilla as http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=289 .   > Com

Re: patch to address sun bug 6562614

2009/7/9 Andrew John Hughes : > 2009/7/9 Jon VanAlten : >> Hi, >> >> I've put up a webrev at >> http://icedtea.classpath.org/~vanaltj/webrevs/tl/patch1/index.html to >> address http://bugs.sun.com/view_bug.do?bug_id=6562614, also referenc

Fwd: Reg : How to contribute

2009/7/15 Ulf Zibis : > Am 15.07.2009 16:26, Neal Gafter schrieb: >> >> On Wed, Jul 15, 2009 at 4:01 AM, Dalibor Topic > > wrote: >> >>    A good start is the OpenJDK developer guide - see >>    http://openjdk.java.net/guide/ to learn how the project works. >> >> >> Th

Re: Reg : How to contribute

2009/7/15 Neal Gafter : > 2009/7/15 Dalibor Topic >> >> Neal, >> >> Are you interested in improving the developer guide? > > Unfortunately, I have no special access to what Sun is putting in place, so > I'm not the right person to be documenting things.  I still haven't figured > out, for example,

Re: Reg : How to contribute

2009/7/15 Ulf Zibis : > Am 15.07.2009 16:55, Dalibor Topic schrieb: >> >> Ulf Zibis wrote: >> >>> >>> but what to do with this script to make it work for me? >>> >> >> I'm not sure I understand the question correctly - webrev is a shell >> script >> that uses ksh, so you could mark it as executable

Re: How to contribute - webrev question

2009/7/16 Ulf Zibis : > Now I have installed the Microsoft "Windows Services for UNIX" and can run a > Korn Shell: > > Running the script, I get following output: > <== > $ dir > Datenträger in Laufwerk C: ist STANDARD > Volumeseriennummer: 14AD-C

Re: My first webrev review request: 6850337 Hasher.java interprets given option value badly

2009/7/19 Ulf Zibis : > Martin, Sherman, Neal, > > do you like to sponsor and review my CR ? > > Don't worry, it's very simple and small, best for getting familiar with the > workflow. > > See: > https://bugs.openjdk.java.net/show_bug.cgi?id=100090 > > Thanks, > > Ulf > > > > As this bug is about

Re: execvpe and glibc 2.10

2009/7/9 Martin Buchholz : > Sorry, I should never have named a function (not even a static one) > 'execvpe'.  It's amusing that I broke myself by requesting that glibc > implement 'execvpe'. > > Here's the webrev: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk7/rename-execvpe/ > > For thos

Re: execvpe and glibc 2.10

2009/7/28 Michael McMahon : > Andrew John Hughes wrote: >> >> 2009/7/9 Martin Buchholz : >> >>> >>> Sorry, I should never have named a function (not even a static one) >>> 'execvpe'.  It's amusing that I broke myself by requestin

Re: execvpe and glibc 2.10

2009/7/28 Martin Buchholz : > On Tue, Jul 28, 2009 at 06:08, Michael McMahon wrote: >> Andrew John Hughes wrote: >>> >>> 2009/7/28 Michael McMahon : >>> >>>> >>>> Andrew John Hughes wrote: >>>> >>>>>

Re: execvpe and glibc 2.10

Rename execvpe to avoid symbol clash with glibc 2.10. >>>> Description: >>>> glibc 2.10 added the long-awaited "missing link" function execvpe >>>> (thank you!  No really!) >>>> But the JDK already has a function of that name,

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

When java.lang.ReflectiveOperationException was added in: http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/aaf0cb20646e it wasn't added to make/java/java/FILES_java.gmk. Although it still seems to end up in rt.jar when building with IcedTea as the bootstrap JDK, it fails when using gcj+ecj (which we

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 >>> &

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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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: 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: [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 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: 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: 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: 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: 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: 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/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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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

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

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

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

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 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

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 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: Is third party code included in langtools sources?

On 05/08/2008, Yulia Novozhilova <[EMAIL PROTECTED]> wrote: > Hi, > > Could you please, help me to answer a question: > Is third party code included in langtools sources? > If "no" then _why_ the THIRD_PARTY_README and ASSEMBLY_EXCEPTION files are > included into the repository? > > Actually I

Re: Is third party code included in langtools sources?

On 18/08/2008, Yulia Novozhilova <[EMAIL PROTECTED]> wrote: > Hi, > > Andrew John Hughes wrote: > > > The more obvious question for me is why NetBeans needs a fork of this > > in the first place. The Debian OpenJDK team have already gone through > > the e

Re: Is third party code included in langtools sources?

K. I think you need to keep the ASSEMBLY_EXCEPTION as it allows pure GPL code to be linked with GPL+Classpath exception code, and most of the code uses the Classpath exception. 'it allows licensees and sublicensees of Sun's GPL2 OpenJDK Code to build an executable that includes those

Re: Is com.sun.image.codec.jpeg.JPEGCodec Included in OpenJDK?

2008/10/9 Ole Ersoy <[EMAIL PROTECTED]>: > Hi, > > Hope this is the right list (If not please let me know). Anyone know if > com.sun.image.codec.jpeg.JPEGCodec is included in OpenJDK? > Thanks, > - Ole > > It's been removed from 1.7 AFAIK. You should now be using the javax.imageio API introduced

Re: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor

2009/3/13 Dalibor Topic : > David M. Lloyd wrote: >> On 03/12/2009 05:41 PM, Mark Reinhold wrote: >>> You might want to have a look at the new contribution process [1]. >>> Using that will increase the probability that someone will evaluate >>> your patch sooner rather than later. >>> >>> - Mark >>

Re: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor

2009/3/12 Martin Buchholz : > This looks fine, as long as there is no dependency of the implementation > on the two atomic counters being incremented in concert, as seems likely. > > Martin > > On Thu, Mar 12, 2009 at 15:35, David M. Lloyd wrote: >> Switch to atomic ops for the various sequence nu

Re: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor

2009/3/13 David M. Lloyd : > On 03/12/2009 07:01 PM, Dalibor Topic wrote: >> >> David M. Lloyd wrote: >>> >>> On 03/12/2009 05:41 PM, Mark Reinhold wrote: You might want to have a look at the new contribution process [1]. Using that will increase the probability that someone will eva

Re: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor

2009/3/13 David M. Lloyd : > On 03/12/2009 07:13 PM, Andrew John Hughes wrote: >> >> This is actually an interesting rare case where two atomic variables >> can replace a synchronised block.  Looking at the code, there seems to >> be no issue with the thread being d

Re: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor

2009/3/13 Dalibor Topic : > David M. Lloyd wrote: >> >>> It seems that the change would break serialization, by changing the type >>> of a serialized field (in both classes) away from a primitive one. See >>> http://java.sun.com/javase/6/docs/platform/serialization/spec/version.html >>> >>> for det

Re: OpenJDK Forum: Core Libraries Round Table

2009/4/9 Dalibor Topic : > Dalibor Topic wrote: >> Hi core libraries developers, >> >> I'd like to carry on doing these, as the last one we did for >> contributing into OpenJDK 6 was fun and productive, so per >> Alan Bateman's suggestion, it's time again tomorrow, on >> Thursday, for the >> >>    

Re: OpenJDK Forum: Core Libraries Round Table

2009/4/9 Tom Hawtin : > Dalibor Topic wrote: >> >> A recording of the call is available on >> http://mediacast.sun.com/users/robilad/media/openjdk6-core-libs.ogg > > Any chance of getting that in a mainstream format? Windows doesn't > understand it. Rhythmbox under VirtualBox freezes. > > Tom Hawti

Re: OpenJDK Forum: Core Libraries Round Table

2009/4/9 Jeff Dinkins : > > VLC plays ogg. > > What? You don't have VLC? Well time to grab a copy! > >  http://www.videolan.org/vlc > > jeff > > p.s. I vote to keep it ogg only to promote more people to use it :-) > +1 :) Personally, I think there was already a compromise by going with Ogg Vorbis

Re: OpenJDK Forum: Core Libraries Round Table

2009/4/9 Mark Thornton : > Jeff Dinkins wrote: >> >> VLC plays ogg. >> >> What? You don't have VLC? Well time to grab a copy! >> >>  http://www.videolan.org/vlc >> >> jeff >> >> p.s. I vote to keep it ogg only to promote more people to use it :-) >> > Shouldn't you be using a format supported by Ja

Re: OpenJDK Forum: Core Libraries Round Table

2009/4/14 Max (Weijun) Wang : > > On Apr 14, 2009, at 7:44 PM, Dalibor Topic wrote: > >> Kevin Bourrillion wrote: >>> >>> Curious if anyone is transcribing the call into text yet?  Word-for-word >>> not necessary, but understandable?  If no one says they've already done >>> that or at least started

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: 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

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: 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: 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

  1   2   >