On 16/09/2014 12:12, Pavel Rappo wrote:
Hi everyone,
Could you please review my change for JDK-8044627?
Pavel - are you planning to send an updated webrev based on the
discussion so far?
The other thing that I meant to ask is whether this change will add
service configuration files for the
On 11/09/2014 17:23, Pavel Rappo wrote:
:
We don't think it is widely used. And will become even less useful with
upcoming modularization. Are there any good reasons to keep this thing in the
JDK?
Searching for usages on stackoverflow and other sites doesn't come up
with much, it would be
Hi all,
A long-standing issue with Strings in Java is the ease and performance of
creating a String from a ByteBuffer. People who are using nio to bring in
data off the network will be receiving that data in the form of bytebuffers
and converting it to some form of String. For example restful
On 22/09/2014 12:25, Richard Warburton wrote:
:
I've put together a patch that implements this to demonstrate the overall
direction.
http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-5/
I'm happy to take any feedback on direction or the patch itself or the
overall idea/approach. I
Compare with https://bugs.openjdk.java.net/browse/JDK-6695386
Maybe that would help a little.
-Ulf
Am 22.09.2014 um 13:25 schrieb Richard Warburton:
Hi all,
A long-standing issue with Strings in Java is the ease and performance of
creating a String from a ByteBuffer. People who are using nio
Hi William,
Thanks a lot for your time and checks !
On 19/09/2014 22:02, William Price wrote:
Hi Oliver,
First, sorry about mistyping your name, Olivier!
I copied your patch into my shim locally and ran my test cases and
still get a couple failures (see output below). Your patch and my
Hi again,
On 09/17/2014 06:28 PM, Aleksey Shipilev wrote:
Can I have a review and a sponsorship for this tiny readability cleanup
in String.hashCode()?
http://cr.openjdk.java.net/~shade/8058643/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8058643
I think we have enough reviews? Here
On 09/22/2014 06:06 PM, Aleksey Shipilev wrote:
Hi again,
On 09/17/2014 06:28 PM, Aleksey Shipilev wrote:
Can I have a review and a sponsorship for this tiny readability cleanup
in String.hashCode()?
http://cr.openjdk.java.net/~shade/8058643/webrev.01/
On 09/22/2014 06:13 PM, Aleksey Shipilev wrote:
On 09/22/2014 06:06 PM, Aleksey Shipilev wrote:
Hi again,
On 09/17/2014 06:28 PM, Aleksey Shipilev wrote:
Can I have a review and a sponsorship for this tiny readability cleanup
in String.hashCode()?
Hi,
can I have a review and sponsor for this trivial fix to make the jtreg
test generator script jdk/test/java/util/Formatter/genBasic.sh work in
the new build system?
bug: https://bugs.openjdk.java.net/browse/JDK-8058887
webrev: http://cr.openjdk.java.net/~redestad/8058887/webrev.01/
Hi Brian,
Thanks a lot for your thorough review of the fix !
Please see comments inlined.
On 20/09/2014 00:50, Brian Burkhalter wrote:
Hello Olivier,
By inspection I think that the fix and the test update look good. I
verified that the test hits all five branches contained in the else-if
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 blocks (see
below). Comment #2 is nit-picky.
I tried to keep the same flavour of writing as in HALF_DOWN and HALF_EVEN
cases, i.e. don't use brace for
Hi Joe,
Yes, and then some. There are two cases which fail before applying the patch
and neither fails thereafter. One of these cases matches the test in the
original patch. The remaining cases pass both before and after but I added them
as edges cases anyway.
Thanks,
Brian
On Sep 21, 2014,
Hi Brian,
Okay; looks good to go back.
Thanks,
-Joe
On 9/22/2014 8:53 AM, Brian Burkhalter wrote:
Hi Joe,
Yes, and then some. There are two cases which fail before applying the
patch and neither fails thereafter. One of these cases matches the
test in the original patch. The remaining
Hi,
previous attempt was considered too trivial a fix, so how about actually
improving the test coverage, fixing the link issue in genBasic and
upgrade Spp.java to not add thousands of empty lines while we're at it?
Rejoice!
webrev: http://cr.openjdk.java.net/~redestad/8058887/webrev.03/
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[], simplified for the specific usage case
(the
Hello!
The UTF-8 encoding allows characters that are 4 bytes long.
However, CharsetEncoder.maxBytesPerChar() currently returns 3.0, which
is not always enough.
Would you please review the simple fix for this issue?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8058875
WEBREV:
On 09/22/2014 07:35 AM, Claes Redestad wrote:
Hi,
can I have a review and sponsor for this trivial fix to make the jtreg test
generator script jdk/test/java/util/Formatter/genBasic.sh work in the new build
system?
bug: https://bugs.openjdk.java.net/browse/JDK-8058887
webrev:
It was on purpose to keep those blank lines when I wrote the Spp to replace the
original
script. it serves the purpose of preserving the line number the generated
source code
(identical to the ln# of the same code line in template file). This is
convenient/import
when debugging those
On 09/22/2014 02:00 PM, Xueming Shen wrote:
It was on purpose to keep those blank lines when I wrote the Spp to replace the
original
script. it serves the purpose of preserving the line number the generated
source code
(identical to the ln# of the same code line in template file). This is
I think you are mistaken. It's maxBytesPerChar, not maxBytesPerCodepoint!
changeset: 3116:b44704ce8a08
user:sherman
date:2010-11-19 12:58 -0800
6957230: CharsetEncoder.maxBytesPerChar() reports 4 for UTF-8; should be 3
Summary: changged utf-8's CharsetEncoder.maxBytesPerChar to
Looks fine.
I think it is always important note when a change may result in different
results for some inputs. I will reiterate for the record what's mentioned in
the bug:
However, one caveat is that this may affect the results of some calculations.
For example, some range of numbers that
On 22/09/2014 22:23, Martin Buchholz wrote:
I think you are mistaken. It's maxBytesPerChar, not maxBytesPerCodepoint!
You are going to have to explain that some more. The Javadoc for
CharsetEncoder.maxBytesPerChar() is explicit:
quote
Returns the maximum number of bytes that will be produced for
Indeed these considerations made me a little nervous about the change. For the
edge cases which would have previously overflowed or underflowed this does not
seem like a problem, i.e., to obtain a valid result where one would not have
done before. For the cases in between however I suppose that
On 22/09/2014 22:46, Xueming Shen wrote:
On 09/22/2014 01:14 PM, Ivan Gerasimov wrote:
Hello!
The UTF-8 encoding allows characters that are 4 bytes long.
However, CharsetEncoder.maxBytesPerChar() currently returns 3.0, which
is not always enough.
Would you please review the simple fix for
Hi Brian,
Looks OK.
On 09/23/2014 01:10 AM, Brian Burkhalter wrote:
Summary: Change constructs like “a * B / C” and “u / V * W” to “x *
(Y / Z)” where lower case denotes a variable and upper case a
constant. This forces the constant value (Y / Z) to be evaluated only
once per VM instance,
Hi Brian;
I thought it was worth mentioning because I had had to deal with the underflow
issue in the mapping software for the Audi/Stanford autonomous. For various
reasons that system ends up with many very-tiny-but-non-zero quantities in it's
mapping and heading component and I initially had
Hi Aleksey,
On Sep 22, 2014, at 2:43 PM, Aleksey Shipilev aleksey.shipi...@oracle.com
wrote:
I would probably just go and declare the private compile-time constants.
This is safer, since: a) you are not at the mercy of optimizing compiler
anymore (have you tried the benchmark with C1?); b)
Hi Mike,
It’s definitely worth mentioning and something which should be taken into
consideration when considering the change.
Thanks,
Brian
On Sep 22, 2014, at 2:48 PM, Mike Duigou mike.dui...@oracle.com wrote:
I thought it was worth mentioning because I had had to deal with the
underflow
Fair enough! I removed the Spp changes and and regenerated the test
files using the original script:
http://cr.openjdk.java.net/~redestad/8058887/webrev.04/
Thanks!
/Claes
On 2014-09-22 23:00, Xueming Shen wrote:
It was on purpose to keep those blank lines when I wrote the Spp to
replace
Hi Aleksey,
On Sep 22, 2014, at 2:43 PM, Aleksey Shipilev aleksey.shipi...@oracle.com
wrote:
Hm, and this compiler transformation works in strictfp context? I hope
compilers do the constant folding in strictfp/fdlibm mode…
Yes.
I would probably just go and declare the private compile-time
Looks fine to me!
Mike
On Sep 22 2014, at 15:34 , Brian Burkhalter brian.burkhal...@oracle.com wrote:
Hi Aleksey,
On Sep 22, 2014, at 2:43 PM, Aleksey Shipilev aleksey.shipi...@oracle.com
wrote:
Hm, and this compiler transformation works in strictfp context? I hope
compilers do the
Hi Mike,
Thanks for the review.
For the sake of completeness I tested converting 89.0 * Double.MIN_VALUE to
radians and Double.MAX_VALUE / 89.0 to degrees. The old version gives 0.0 and
Double.POSITIVE_INFINITY, respectively, whereas the webrev.01 version gives the
respective results
Hi core-libs-dev,
Quick note that it seems that the Javadoc for Clock$TickClock has copypasta
from Clock$OffsetClock.
Not a huge deal for a non-public class but probably worth fixing.
http://hg.openjdk.java.net/jdk9/client/jdk/file/5edbebb72540/src/java.base/share/classes/java/time/Clock.java
34 matches
Mail list logo
