Re: Floating Point and Arithmetic Changes for Java SE Lnguage

Hello Anon, It is impossible to Change the Java behavior for already existing Features like the simple Floating Point types. I would not expect much in this area. There was a JSR to add a new mode, but it seems to be abandoned: https://jcp.org/en/jsr/detail?id=84 I think there was some

Re: RFR 8198970: jnu_util.c compilation error on Solaris

On 3/03/2018 8:56 AM, Roger Riggs wrote: Please review a correction to the jni_util.c native code that does not compile on Solaris. Declarations must precede assignments. Wow! I didn't think Solaris Studio compiler was subject to such anachronisms! We must be compiling in a really old mode.

Re: RFR: JDK-8197594: String#repeat

On 2/28/18 6:34 PM, James Laskey wrote: Thanks Stuart. RE apinote, I was trying to follow the pattern of other older method comments (Roman-style.) Comments/Javadoc in most of these older classes are a mix of styles. Question: if you update/clean-up a method in an older class, should you bring

Re: [11] RFR: 4993841: (str) java.lang.Character should have a toString(int) method

Thanks - looks good. On Fri, Mar 2, 2018 at 3:37 PM, wrote: > Thanks for comments, Martin, Roger. Updated the fix as follows: > > http://cr.openjdk.java.net/~naoto/4993841/webrev.04/ > > Naoto > > > On 3/1/18 6:47 PM, naoto.s...@oracle.com wrote: > >> Hi, >> >> Please

Re: [11] RFR: 4993841: (str) java.lang.Character should have a toString(int) method

Looks good. I note that other codepoint-consuming methods, such as Character.UnicodeBlock.of(cp) Character.UnicodeScript.of(cp) Character.toChars(cp, char[], int) Character.toChars(cp) Character.getName(cp) all throw IAE with no message. It would be nice to add messages to

Re: [11] RFR: 4993841: (str) java.lang.Character should have a toString(int) method

On 3/2/18 4:42 PM, Remi Forax wrote: Just to be sure, it now means that a code like this will work String s = "hello".chars() .mapToObj(Character::toString) .collect(Collectors.joining()); Yes, this will work, as Naoto mentioned, but I don't recommend it -- this will

Re: [11] RFR: 4993841: (str) java.lang.Character should have a toString(int) method

Hi Rémi, I'm sure I've misunderstood something, but AFAIK the code example you gave is already valid code and was valid as far back as Java 8 (I don't have an IDE at hand to confirm this). Did you perhaps mean to ask instead that the code snippet below would work with the resolution of

Re: [11] RFR: 4993841: (str) java.lang.Character should have a toString(int) method

+1 On 3/2/18, 3:37 PM, naoto.s...@oracle.com wrote: Thanks for comments, Martin, Roger. Updated the fix as follows: http://cr.openjdk.java.net/~naoto/4993841/webrev.04/ Naoto On 3/1/18 6:47 PM, naoto.s...@oracle.com wrote: Hi, Please review the fix to the following issue:

Re: [11] RFR: 4993841: (str) java.lang.Character should have a toString(int) method

Yes. With a private build: jshell> "hello".chars().mapToObj(Character::toString).collect(Collectors.joining()) $1 ==> "hello" Naoto On 03/02/2018 04:42 PM, Remi Forax wrote: Just to be sure, it now means that a code like this will work String s = "hello".chars()

Re: [11] RFR: 4993841: (str) java.lang.Character should have a toString(int) method

Just to be sure, it now means that a code like this will work String s = "hello".chars() .mapToObj(Character::toString) .collect(Collectors.joining()); Rémi - Mail original - > De: "naoto sato" > À: "Stuart Marks" ,

Floating Point and Arithmetic Changes for Java SE Lnguage

I have found that double and float types in java are heirs to arithmetic underflow and overflow at any use. I have found that presently, floating point is an arithmetic approximation. My problem is that the java language needs to be changed here, so that one may have arithmetic accuracy with

Re: [11] RFR: 4993841: (str) java.lang.Character should have a toString(int) method

Thanks for comments, Martin, Roger. Updated the fix as follows: http://cr.openjdk.java.net/~naoto/4993841/webrev.04/ Naoto On 3/1/18 6:47 PM, naoto.s...@oracle.com wrote: Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-4993841 The proposed

Re: RFR 8198970: jnu_util.c compilation error on Solaris

Thanks, Mandy, Claes, On 3/2/2018 6:02 PM, mandy chung wrote: +1 Mandy On 3/2/18 2:56 PM, Roger Riggs wrote: Please review a correction to the jni_util.c native code that does not compile on Solaris. Declarations must precede assignments. Issue: 8198970 jnu_util.c compilation error on

Re: RFR 8198970: jnu_util.c compilation error on Solaris

Looks ok to me. /Claes On 2018-03-02 23:56, Roger Riggs wrote: Please review a correction to the jni_util.c native code that does not compile on Solaris. Declarations must precede assignments. Issue: 8198970 jnu_util.c compilation error on Solaris

Re: RFR 8198970: jnu_util.c compilation error on Solaris

+1 Mandy On 3/2/18 2:56 PM, Roger Riggs wrote: Please review a correction to the jni_util.c native code that does not compile on Solaris. Declarations must precede assignments. Issue: 8198970 jnu_util.c compilation error on Solaris diff

Re: RFR 8198697: Simplify platform encoding initialization tweak

On 2018-03-02 20:21, Roger Riggs wrote: I reordered as the suggested the checks for encoding type to put utf-8, most common first in JNU_NewStringPlatform() and JNU_GetStringPlatformChars(). Webrev updated in place: http://cr.openjdk.java.net/~rriggs/webrev-simplify-jnu-8198697/ Thanks,

RFR 8198970: jnu_util.c compilation error on Solaris

Please review a correction to the jni_util.c native code that does not compile on Solaris. Declarations must precede assignments. Issue: 8198970 jnu_util.c compilation error on Solaris diff --git

Re: RFR JDK-8187653: Lock in CoderResult.Cache becomes performance bottleneck

One less (benign) race - and possibly more efficient, too :-) If we really worry about the startup costs here, we could make it so that the three Cache classes themselves aren't loaded until someone actually has a need for them:

Re: [JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater

On Fri, Mar 2, 2018 at 2:34 PM, David Lloyd wrote: > On Fri, Mar 2, 2018 at 12:49 PM, Xueming Shen wrote: >> Hi David, >> >> (1) Deflater.deflate(Bytebuffer) >> the api doc regarding "no_flush" appears to be the copy/paste of the >> byte[]

Re: RFR: JDK-8198955 - String#repeat loop optimization

This looks good, thank you! On 3/2/18 6:43 AM, Jim Laskey wrote: Verified to work on edge cases. JBS: https://bugs.openjdk.java.net/browse/JDK-8198955 Webrev: http://cr.openjdk.java.net/~jlaskey/8198955/webrev/index.html

Re: [JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater

On Fri, Mar 2, 2018 at 12:49 PM, Xueming Shen wrote: > Hi David, > > (1) Deflater.deflate(Bytebuffer) > the api doc regarding "no_flush" appears to be the copy/paste of the > byte[] version > without being updated to the corresponding ByteBuffer? You're right,

Re: RFR JDK-8187653: Lock in CoderResult.Cache becomes performance bottleneck

To follow Claes's suggestion to make the CoderResult.Cache.cache field final and allocate early. issue: https://bugs.openjdk.java.net/browse/JDK-8198966 webrev: http://cr.openjdk.java.net/~sherman/8198966/webrev/ Thanks, -Sherman

Re: RFR 8198697: Simplify platform encoding initialization tweak

Hi Claes, Sherman, Thanks for the reviews: I reordered as the suggested the checks for encoding type to put utf-8, most common first in JNU_NewStringPlatform() and JNU_GetStringPlatformChars(). Webrev updated in place:   http://cr.openjdk.java.net/~rriggs/webrev-simplify-jnu-8198697/

Re: [JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater

Hi David, (1) Deflater.deflate(Bytebuffer) the api doc regarding "no_flush" appears to be the copy/paste of the byte[] version without being updated to the corresponding ByteBuffer? (2) Inflater.inflate() a "inputConsumed" field is added to handle the "bytes-read" if a DFE is

Re: RFR: Here are some URLClassPath patches

Thanks! Delivered without further changes. That should be the end of this batch of classloader changes. On Fri, Mar 2, 2018 at 7:00 AM, Roger Riggs wrote: > Hi Martin, > > I created the subtask for the release note[1], please review and update > the summary and

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

Thanks! Paul. > On Mar 2, 2018, at 9:11 AM, Vladimir Ivanov > wrote: > > > > On 3/2/18 8:01 PM, Paul Sandoz wrote: >> Here’s an update Ben and I tweaked: >> >> http://cr.openjdk.java.net/~psandoz/jdk/buffer-reachability-fence/webrev/index.html >> I think this

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

On 3/2/18 8:01 PM, Paul Sandoz wrote: Here’s an update Ben and I tweaked: http://cr.openjdk.java.net/~psandoz/jdk/buffer-reachability-fence/webrev/index.html I think this looks good but would still like to double check with Vladimir that the @ForceInline is not problematic. I confirm

Re: RFR 8198697: Simplify platform encoding initialization tweak

+1 On 03/02/2018 07:49 AM, Roger Riggs wrote: Please review... On 2/28/2018 9:45 AM, Roger Riggs wrote: Hi, In an effort to untangle some of the issues with property initialization I was looking at the platform encoding initialization and found a simplification. Currently, the

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

Here’s an update Ben and I tweaked: http://cr.openjdk.java.net/~psandoz/jdk/buffer-reachability-fence/webrev/index.html I think this looks good but would still like to double check with Vladimir that the @ForceInline is not problematic. Paul. > On Feb 26, 2018, at 6:50 PM, Paul Sandoz

Re: RFR: JDK-8198955 - String#repeat loop optimization

+1 On 2018-03-02 15:43, Jim Laskey wrote: Verified to work on edge cases. JBS: https://bugs.openjdk.java.net/browse/JDK-8198955 Webrev: http://cr.openjdk.java.net/~jlaskey/8198955/webrev/index.html

Re: RFR 8198697: Simplify platform encoding initialization tweak

Hi, looks good to me, although part of me can't help wonder if we'd profit ever so little from rearranging if statements so that we test for UTF8 first and move the should-be-asserts tests for NO_ENCODING_YET down. /Claes On 2018-02-28 15:45, Roger Riggs wrote: Hi, In an effort to

Re: [JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater

> On Mar 2, 2018, at 8:07 AM, David Lloyd wrote: > > The third... and hopefully final... version of this patch is attached. > It is the same as V2, however it also uses > Reference.reachabilityFence() defensively on buffers. This may be > necessary because there are

[JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater

The third... and hopefully final... version of this patch is attached. It is the same as V2, however it also uses Reference.reachabilityFence() defensively on buffers. This may be necessary because there are code paths which may allow such buffers to be GCed after their address is acquired but

Re: RFR 8198697: Simplify platform encoding initialization tweak

Please review... On 2/28/2018 9:45 AM, Roger Riggs wrote: Hi, In an effort to untangle some of the issues with property initialization I was looking at the platform encoding initialization and found a simplification. Currently, the initialization occurs as a side effect of the first call

Re: RFR: JDK-8198955 - String#repeat loop optimization

+1 On 3/2/2018 9:43 AM, Jim Laskey wrote: Verified to work on edge cases. JBS: https://bugs.openjdk.java.net/browse/JDK-8198955 Webrev: http://cr.openjdk.java.net/~jlaskey/8198955/webrev/index.html

Re: [11] RFR: 4993841: (str) java.lang.Character should have a toString(int) method

Hi Naoto, String.java: 3129: Please add a message to the throw IAE.  "Not a valid Unicode code point". Roger On 3/1/2018 9:47 PM, naoto.s...@oracle.com wrote: Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-4993841 The proposed changeset is

Re: RFR: Here are some URLClassPath patches

Hi Martin, I created the subtask for the release note[1], please review and update the summary and description. When it is done, close it as 'delivered'. Thanks, Roger [1] https://bugs.openjdk.java.net/browse/JDK-8198956 On 3/1/2018 10:32 PM, Martin Buchholz wrote: On Wed, Feb 28, 2018 at

RFR: JDK-8198955 - String#repeat loop optimization

Verified to work on edge cases. JBS: https://bugs.openjdk.java.net/browse/JDK-8198955 Webrev: http://cr.openjdk.java.net/~jlaskey/8198955/webrev/index.html

Re: RFR: JDK-8190187: C++ code calling JNI_CreateJavaVM can be killed by Java

Hi Alan Thanks for getting back to me on this. :) I've changed the hg_diff as described below, see the attached. > On 27/02/2018 15:04, Adam Farley8 wrote: > > Resending. Bump. :) > > On 14/02/2018 14:13, Adam Farley8 wrote: >>> Hi All, >>> >>> -- Short version -- >>> >>> Could a

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

On 28/02/2018 19:54, Lance Andersen wrote: : Is there any XA text from the original JTA spec that should be added to the module description as part of this? Another way to ask this is whether the JTA 1.3 drops any text dealing with the XA part. Still waiting to see what changes are made to

Re: RFR JDK-8187653: Lock in CoderResult.Cache becomes performance bottleneck

Hi Sherman, On 03/02/18 03:20, David Holmes wrote: Also this: 195 private Map cache = null; should now be volatile. Either that, or you should load the 'cache' field only once per method call into a local variable unless you want reorderings of reads and