Re: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return 4 for UTF-8

Martin, Sherman thanks for clarification! Closing the bug as not a bug. The "character" in the nio Charset and CharDe/Encoder is specified as "sixteen-bit Unicode code unit", so it is reasonable to interpret the "character" in the "maximum number of bytes that will be produced for each charact

Re: Urgent [9] RFR (S) : JDK-8039915 NumberFormat.format() does not consider required no. of fraction digits properly

Thanks Brian, Will take into account your wording remarks. Olivier. On 22/09/2014 17:50, Brian Burkhalter wrote: Hi Olivier, On Sep 22, 2014, at 7:56 AM, olivier.lagn...@oracle.com wrote: and 2) use braces around all the statements contained in if/else

Re: Urgent [9] RFR (S) : JDK-8039915 NumberFormat.format() does not consider required no. of fraction digits properly

Hi Joe, Thanks a lot for taking the time to review ! Please see comments inlined. On 23/09/2014 04:51, Joe Darcy wrote: Hello, I've looked over the proposed changeset as well. I don't see a problem with the code, but I'm not (yet) convinced it is right. For future work, I think be clearer

Re: java.time.Clock$TickClock wrong javadoc

Hi, Filed https://bugs.openjdk.java.net/browse/JDK-8058957 Given the review and testing cycle overhead; its probably not worth fixing (at least by itself). Thanks, Roger On 9/22/2014 7:52 PM, Steven Schlansker wrote: Hi core-libs-dev, Quick note that it seems that the Javadoc for Clock$Ti

RE: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return 4 for UTF-8

This response confuses me. Are you saying that the UTF8 encoder is not really producing UTF8? RFC 2279 and 3629 both clearly state that surrogates must be combined to form a 32-bit value which is then encoded as a 4-byte sequence. In fact, the RFCs refer to the alternate encoding CESU_8 defin

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Aleksey, On Sep 22, 2014, at 11:42 PM, Aleksey Shipilev wrote: > On 09/23/2014 02:34 AM, Brian Burkhalter wrote: >> I created an alternate webrev using compile-time constants per your >> suggestion: >> >> http://cr.openjdk.java.net/~bpb/4477961/webrev.01/ >>

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

On 09/23/2014 07:12 PM, Brian Burkhalter wrote: >> Ah, sorry for confusing language about "compile-time constants", I meant >> "compile-time constant expression", as per JLS 15.28. Constant >> expressions are FP-strict, so it should be just fine correctness- and >> performance-wise, and less crypti

Re: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return 4 for UTF-8

Again, it's maxBytes per java "char", not maxBytes per Unicode character. Allocating a big enough buffer is pretty much the only reason for maxBytesPerChar' existence. On Tue, Sep 23, 2014 at 7:58 AM, Salter, Thomas A wrote: > This response confuses me. Are you saying that the UTF8 encoder is

Re: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes

Hi, I updated the webrev at http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.07 * @implNote If more than one listener terminates with an uncaught error or * exception, an implementation may record the additional errors or * exceptions as {@linkplain Throwable#addSuppr

Re: RFR [9]: 8050142: Optimize java.util.Formatter

On 09/22/2014 12:43 PM, Claes Redestad wrote: Hi, Sherman pointed out that there was a path that could actually take a minor performance hit from this patch, which would be unacceptable. This version takes the minimal approach to addressing this by adding back a method operating on a char[], s

Re: RFR [9]: 8050142: Optimize java.util.Formatter

On 2014-09-23 21:14, Xueming Shen wrote: On 09/22/2014 12:43 PM, Claes Redestad wrote: Hi, Sherman pointed out that there was a path that could actually take a minor performance hit from this patch, which would be unacceptable. This version takes the minimal approach to addressing this by add

Re: RFR [9]: 8050142: Optimize java.util.Formatter

Also the logic in the loop of localizedMagnitudeExp() does not look correct. Shouldn't it be char c= value[j]; if (c == '.') { append l10n dot... } else { sb.append(c - '0' + zero); } it appears the 'else" is missing? or I read it wrong? -Sherman On 09/23/2014 12:27 PM, Claes Redestad wrote

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Brian Le 23/09/14 00:34, Brian Burkhalter a écrit : > I created an alternate webrev using compile-time constants per your > suggestion: > > http://cr.openjdk.java.net/~bpb/4477961/webrev.01/ On a very minor formatting detail, the change in StrictMath has a misplaced empty line (before the RAD

Re: RFR [9]: 8050142: Optimize java.util.Formatter

Ouch... but wait... the char[] returned from sun.misc.FormattedFloatingDecimal.getExponent() can never contain a '.', so we'll never find a dot here. Remove the dead code or fix the logic? /Claes On 2014-09-23 21:30, Xueming Shen wrote: Also the logic in the loop of localizedMagnitudeExp() doe

Re: RFR [9]: 8050142: Optimize java.util.Formatter

I don''t think an exponent should ever have a "dot', it always a signed integer. I think we can just remove the dead code, maybe put some wording to explain why no group, no dot here. -Sherman On 09/23/2014 12:42 PM, Claes Redestad wrote: Ouch... but wait... the char[] returned from sun.misc

Re: RFR [9]: 8050142: Optimize java.util.Formatter

How about: // Specialized localization of exponents, where the source value can only // contain characters '0' through '9', starting at index offset, and no // group separators is added for any locale. private void localizedMagnitudeExp(StringBuilder sb, char[] value,