Java Float and Double changes, BigDecimal maths class, BigDecimal operators?

'There was a JSR to add a new mode' Citation about problems with Java floating point: https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf I suppose I would be asking for that change on float and double, that being the case, as well as an extra mathematics class for BigDecimal. People abso

Re: trivial patch to reduce allocations in nio open* methods

Hello, Redirecting to nio-dev. Please reply omitting core-libs-dev. If the patch is small you can include it in e-mail to the mailing list as attachments are generally scrubbed. Thanks, Brian On Mar 5, 2018, at 4:35 PM, Michael Skells wrote: > I have a trivial patch to reduce allocation of

trivial patch to reduce allocations in nio open* methods

Hi I have a trivial patch to reduce allocation of OpenOption sets where no args are supplied Spotted this while working on scala compiler, trying to reduce allocations I cannot build JDK due to visual studio issues Can someone progress the patch for me? Dont want to send a patch to this m

Re: RFR (JDK11) 8183554: Add constructors with Charset parameter for FileReader and FileWriter

Thanks Alan, Roger! Less is better. Removed the ones that take FileDescriptors, now we're only adding Constructors that take String+Charset and File+Charset. Tests are updated accordingly. Build/Test may take a while, but expected to pass since it was simply removing the FileDescriptor from th

Re: RFR: 8197538 Remove mention of hotjava paths in MimeTable.java

On Mar 5, 2018, at 1:32 PM, Roger Riggs wrote: > Please review a change to a location where mailcap entries may appear. +1 > The mention of "hotjava.home" is ancient history. Quite so. Brian

Re: RFR: 8197538 Remove mention of hotjava paths in MimeTable.java

+1 > On Mar 5, 2018, at 4:32 PM, Roger Riggs wrote: > > Please review a change to a location where mailcap entries may appear. > The mention of "hotjava.home" is ancient history. > > BTW, if you know whether "user.mailcap" System property is used, I'd be > interested if anyone is using it. >

RFR 8196298 Add null Reader and Writer with latest changes

I tried to incorporate all feedback I received so far and updated the webrev accordingly: http://cr.openjdk.java.net/~reinhapa/reviews/8196298/webrev.01 -Patrick

RFR: 8197538 Remove mention of hotjava paths in MimeTable.java

Please review a change to a location where mailcap entries may appear. The mention of "hotjava.home" is ancient history. BTW, if you know whether  "user.mailcap" System property is used, I'd be interested if anyone is using it. I may need a CSR to make it official. diff --git a/src/java.base/

Re: RFR (JDK11) 8183554: Add constructors with Charset parameter for FileReader and FileWriter

Hi Joe, For files by name and File these are useful additions.  The new constructors with FileDescriptors don't have a strong use case for them and re-using file descriptors is something that developers need to be more careful about.  They don't need the added convenience constructors and can

Re: GetPrimitiveArrayCritical vs GetByteArrayRegion: 140x slow-down using -Xcheck:jni and java.util.zip.DeflaterOutputStream

On 3/5/18, 12:45 PM, Xueming Shen wrote: On 3/5/18, 11:15 AM, Ian Rogers wrote: Thanks! Changing the DeflaterOutputStream buffer size to be something other than the default reduces the number of JNI native calls and is a possible work around here, as this is an implementation detail could it b

Re: RFR 8198899: Compilation errors in java.prefs with VS 2017

On 05/03/2018 18:29, Brian Burkhalter wrote: https://bugs.openjdk.java.net/browse/JDK-8198899 http://cr.openjdk.java.net/~bpb/8198899/webrev.00/ This code currently represents a 64-bit Windows HKEY as an int at the Java level. The proposed change is to represent the HKEY as a long. All existing

Re: GetPrimitiveArrayCritical vs GetByteArrayRegion: 140x slow-down using -Xcheck:jni and java.util.zip.DeflaterOutputStream

On 3/5/18, 11:15 AM, Ian Rogers wrote: Thanks! Changing the DeflaterOutputStream buffer size to be something other than the default reduces the number of JNI native calls and is a possible work around here, as this is an implementation detail could it be made in the JDK? Unfortunately larger in

Re: RFR (JDK11) 8183554: Add constructors with Charset parameter for FileReader and FileWriter

On 05/03/2018 19:25, Joe Wang wrote: Hi, Adding constructors with a Charset parameter for FileReader and FileWriter. Please review. JBS: https://bugs.openjdk.java.net/browse/JDK-8183554 webrev: http://cr.openjdk.java.net/~joehw/jdk11/8183554/webrev/ The constructors that take String+Charset a

Re: RFR 8198899: Compilation errors in java.prefs with VS 2017https://bugs.openjdk.java.net/browse/JDK-8198899 http://javaweb.us.oracle.com/~bburkhal/jdk/review/8198899/webrev.00 This code currently r

> On Mar 5, 2018, at 10:50 AM, Brian Burkhalter > wrote: > > On Mar 5, 2018, at 10:39 AM, Paul Sandoz > wrote: > >> Did you consider keeping this contained within the JNI code if that is at >> all possible? > > No. I think that a Java variable to contain the

Re: RFR 8198899: Compilation errors in java.prefs with VS 2017

Hi Roger, I’ll look into doing this before pushing the change. I assume there would be no need for further review for that. Thanks, Brian On Mar 5, 2018, at 10:54 AM, Roger Riggs wrote: > Some re-formatting to put spaces before "=" and after "," would be useful but > its good to review only

RFR (JDK11) 8183554: Add constructors with Charset parameter for FileReader and FileWriter

Hi, Adding constructors with a Charset parameter for FileReader and FileWriter. Please review. JBS: https://bugs.openjdk.java.net/browse/JDK-8183554 webrev: http://cr.openjdk.java.net/~joehw/jdk11/8183554/webrev/ Thanks, Joe

Re: RFR 8198899: Compilation errors in java.prefs with VS 2017

Hi, (Trimmed the subject line). Looks fine. Some re-formatting to put spaces before "=" and after "," would be useful but its good to review only the real changes. Thanks, Roger On 3/5/2018 1:50 PM, Brian Burkhalter wrote: On Mar 5, 2018, at 10:39 AM, Paul Sandoz wrote: Did you conside

Re: RFR 8198899: Compilation errors in java.prefs with VS 2017https://bugs.openjdk.java.net/browse/JDK-8198899 http://javaweb.us.oracle.com/~bburkhal/jdk/review/8198899/webrev.00 This code currently r

On Mar 5, 2018, at 10:39 AM, Paul Sandoz wrote: > Did you consider keeping this contained within the JNI code if that is at all > possible? No. I think that a Java variable to contain the HKEY might be inevitable. This is similar to the FileDescriptor holding the Windows HANDLE as a long. > I

Re: GetPrimitiveArrayCritical vs GetByteArrayRegion: 140x slow-down using -Xcheck:jni and java.util.zip.DeflaterOutputStream

On 03/05/2018 10:28 AM, Xueming Shen wrote: On 03/05/2018 08:34 AM, Ian Rogers wrote: Firstly, we're not running -Xcheck:jni in production code :-) During development and testing it doesn't seem an unreasonable flag to enable, but a 140x regression is too much to get developers to swallow. Ther

Re: RFR 8198899: Compilation errors in java.prefs with VS 2017https://bugs.openjdk.java.net/browse/JDK-8198899 http://javaweb.us.oracle.com/~bburkhal/jdk/review/8198899/webrev.00 This code currently r

Looks like a fairly routine translation. Did you consider keeping this contained within the JNI code if that is at all possible? I don’t know whether that would just push the compiler error around e.g. converting from jint to jlong then to HKEY? 747 int maxValueNameLength = (int)result

RFR 8198899: Compilation errors in java.prefs with VS 2017https://bugs.openjdk.java.net/browse/JDK-8198899 http://javaweb.us.oracle.com/~bburkhal/jdk/review/8198899/webrev.00 This code currently repre

https://bugs.openjdk.java.net/browse/JDK-8198899 http://cr.openjdk.java.net/~bpb/8198899/webrev.00/ This code currently represents a 64-bit Windows HKEY as an int at the Java level. The proposed change is to represent the HKEY as a long. All existing regression tests passed on Windows-x64. Than

Re: GetPrimitiveArrayCritical vs GetByteArrayRegion: 140x slow-down using -Xcheck:jni and java.util.zip.DeflaterOutputStream

On 03/05/2018 08:34 AM, Ian Rogers wrote: Firstly, we're not running -Xcheck:jni in production code :-) During development and testing it doesn't seem an unreasonable flag to enable, but a 140x regression is too much to get developers to swallow. There are 2 performance considerations: 1) the pe

Re: GetPrimitiveArrayCritical vs GetByteArrayRegion: 140x slow-down using -Xcheck:jni and java.util.zip.DeflaterOutputStream

On 05/03/2018 06:33, David Holmes wrote: Hi Ian, Do you run with -Xcheck:jni in production mode because you load unknown native code libraries? It's mainly intended as a diagnostic option to turn on if you encounter a possible JNI problem. It does unusual to be running with -Xcheck:jni in