RE: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.

Hi, > This draft JEP contains a proposal to use UTF-8 as the default charset > for the JVM, so that > APIs that depend on the default charset behave consistently cross all > platforms. > > For more details, please see: > https://bugs.openjdk.java.net/browse/JDK-8187041 Thanks for finally adding

Re: RFR: Here are some URLClassPath patches

On 21/02/2018 06:08, Martin Buchholz wrote: : 8198480: Improve ClassLoaders static init block http://cr.openjdk.java.net/~martin/webrevs/jdk/ClassLoaders-static/ https://bugs.openjdk.java.net/browse/JDK-8198480 This

RE: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.

Hi, Thanks Alan for the link to this issue about FileReader/Writer! Uwe - Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -Original Message- > From: core-libs-dev

Re: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.

On 21/02/2018 13:41, Stephen Colebourne wrote: On 21 February 2018 at 13:37, Alan Bateman wrote: The proposal is to eventually get to the point that the default charset cannot be changed. It will take several releases to get there due to the potential compatibility

Re: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.

On 21/02/2018 08:53, Uwe Schindler wrote: : The Java 7+ methods in java.nio.file.Files already ignore the default charset and always use UTF-8. How to proceed with those? Should they be changed to behave to the new mechanisms? I'd suggest to not do this, as its part of the spec (to use UTF-8)

Re: RFR: Here are some URLClassPath patches

On 21/02/2018 06:08, Martin Buchholz wrote: : 8198485: Simplify a URLClassPath constructor http://cr.openjdk.java.net/~martin/webrevs/jdk/URLClassPath-simplify-constructor/

Re: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.

On Wed, Feb 21, 2018 at 8:55 AM, Alan Bateman wrote: > Good progress was made via JDK-8183743 [1] in Java SE 10 to add constructors > and methods that take a Charset and eliminate the historical > inconsistencies. The issue of legacy FileReader/FileWriter is linked from

Re: RFR 8189330 Cleanup FileDescriptor implementation

Hi Roger, I think that this looks fine. I assume the issue should be labelled “noreg-cleanup." Brian On Feb 16, 2018, at 2:28 PM, Roger Riggs wrote: > Please review a cleanup and refactoring of FileDescriptor.java. > The Unix and Windows versions are merged to ease

Reactive Streams utility API

Hi all, This is an email to give people a heads up that we'd like to look at creating an API, in the same vein as the JDK8 Streams API, for building reactive streams (a la JDK9 juc.Flow). Our goals for this are: * To fill a gap in the JDK where if a developer wants to do even the simplest of

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

Hi Mandy, tl;dr: I think this is now good to go. On 22/02/2018 5:58 AM, mandy chung wrote: Here is the updated webrev: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198249/webrev.04/ I added some comments to clarify the implementation. src/java.base/share/classes/java/lang/Shutdown.java

Re: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers

Hi Adam, While the burden is minimal there is a principle here that i think we should adhere to regarding additions to the code base: additions should have value within OpenJDK itself otherwise it can become a thin end of the wedge to more stuff (“well you added these things, why not just add

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

Hi Ben, Much better :-) thanks for doing this. Before preceding with replacing @DontInline with @ForceInline i would like to appeal to Vladimir to confirm this is ok. If you send me an attached patch directly in email i can upload it as a webrev for you, it should be easier to review. (When

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

On 2/21/18 6:08 PM, David Holmes wrote: Hi Mandy, tl;dr: I think this is now good to go. On 22/02/2018 5:58 AM, mandy chung wrote: Here is the updated webrev: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198249/webrev.04/ I added some comments to clarify the implementation.

Re: [11] RFR: JDK-8198385: Remove property sun.locale.formatasdefault

Hi Naoto, +1 Brian On Feb 21, 2018, at 1:13 PM, naoto.s...@oracle.com wrote: > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8198385 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8198385/webrev.00/ > > The

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

Roger, Thanks. Pushed. On Wed, Feb 21, 2018 at 2:00 PM, Roger Riggs wrote: > Hi Yumin, > > Use your OpenJDK id "minqi" for the Author instead of your email. > > Roger > > > > On 2/21/2018 4:54 PM, yumin qi wrote: > >> Alan, >> >>Somehow there is a problem for me

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

Alan, Somehow there is a problem for me to push the changeset: pushing to ssh://mi...@hg.openjdk.java.net/jdk/jdk searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 3 changes to 3 files remote: [jcheck

Re: RFR: 8198523: Refactor BootstrapMethodInvoker to further avoid runtime type checks

+1 Paul. > On Feb 21, 2018, at 1:00 PM, Claes Redestad wrote: > > Hi, > > BootstrapMethodInvoker can be improved a bit further by providing > static information about the type argument, and additionally > teaching it about StringConcatFactory BSM: > > Patch:

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

Hi Yumin, Use your OpenJDK id  "minqi" for the Author instead of your email. Roger On 2/21/2018 4:54 PM, yumin qi wrote: Alan, Somehow there is a problem for me to push the changeset: pushing to ssh://mi...@hg.openjdk.java.net/jdk/jdk searching for changes remote: adding changesets

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

Hi Mandy, On 22/02/2018 12:28 PM, mandy chung wrote: On 2/21/18 6:08 PM, David Holmes wrote: Hi Mandy, tl;dr: I think this is now good to go. On 22/02/2018 5:58 AM, mandy chung wrote: Here is the updated webrev: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198249/webrev.04/ I added

RE: Oracle Java 8u161 regression in XML Schema Factory

Hi Bernd, would your test still fail with system property "-Djdk.xml.overrideDefaultParser=true"? I debugged a similar issue (if not the same) today and found that with change http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jaxp/rev/08a44c164993 the default behavior for Xalan changed a bit.

Re: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.

Hi Sherman, the tricky part is really "sun.jnu.encoding" and how the VM interacts with the underlying OS. You may remember that we had an interesting discussion about this topic some time ago [1]. As far as I understand, the JEP doesn't plan to change the handling of "sun.jnu.encoding". So does

Re: RFR: Here are some URLClassPath patches

Hi Martin, Generally, I would leave code alone that does not have a good reason for changing. That goes for commenting conventions (// vs /*) too. On the style changes in URLClassPath-ArrayDeque, about declarations like: ArrayList path = new ArrayList<>(); It had been a recommended style to

Re: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.

Hi Volker, Yes, the handing of sun.jnu.encoding will not be changed. It will remain as a read-only/informative system property. sun.jnu.encoding is really an implementation details (as well as file.encoding, though in this JEP file.encoding might be used to provide a mechanism to fallback to

Re: RFR: Here are some URLClassPath patches

Hi Martin, I checked this one... On 02/21/2018 07:08 AM, Martin Buchholz wrote: 8198484: URLClassPath should use an ArrayDeque instead of a Stack http://cr.openjdk.java.net/~martin/webrevs/jdk/URLClassPath-ArrayDeque/ https://bugs.openjdk.java.net/browse/JDK-8198484 I admit I had to study

Re: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.

On 21 February 2018 at 13:37, Alan Bateman wrote: > The proposal is to eventually get to the point that the default charset > cannot be changed. It will take several releases to get there due to the > potential compatibility impact. This seems like a reasonable strategy

RE: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.

I agree with Uwe, we should deprecate all methods/constructors that relies on the default charset. And we should do that before changing to use UTF-8 by default. Remi On February 21, 2018 8:53:54 AM UTC, Uwe Schindler wrote: >Hi, > >> This draft JEP contains a

Re: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.

I agree with Uwe and Remi; if the default is still changeable, the problem doesn't go away, it simply becomes slightly more insidious. On Wed, Feb 21, 2018 at 12:31 AM, Xueming Shen wrote: > This draft JEP contains a proposal to use UTF-8 as the default charset for > the

Re: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.

On 21/02/2018 13:19, David Lloyd wrote: I agree with Uwe and Remi; if the default is still changeable, the problem doesn't go away, it simply becomes slightly more insidious. The proposal is to eventually get to the point that the default charset cannot be changed. It will take several

Re: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.

On 2/21/18, 6:26 AM, Robert Muir wrote: On Wed, Feb 21, 2018 at 8:55 AM, Alan Bateman wrote: Good progress was made via JDK-8183743 [1] in Java SE 10 to add constructors and methods that take a Charset and eliminate the historical inconsistencies. The issue of legacy

Re: RFR: Here are some URLClassPath patches

2018/2/21 2:28:19 -0500, alan.bate...@oracle.com: > On 21/02/2018 06:08, Martin Buchholz wrote: >> : >> >> 8198481: Coding style cleanups for >> src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java >> http://cr.openjdk.java.net/~martin/webrevs/jdk/loader-style/ >>

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

Hi David, I think I'm clear on the implementation now (my mistake that I neglected ApplicationShutdownHooks).  Shutdown class keeps the "system shutdown hooks".  ApplicationShutdownHooks is one system hook that starts all application shutdown hooks and waits until they finish.  

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

Here is the updated webrev: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198249/webrev.04/ I added some comments to clarify the implementation. Mandy On 2/21/18 11:34 AM, mandy chung wrote: Hi David, I think I'm clear on the implementation now (my mistake that I neglected

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

Joe, AbstractStringBuilder is a mutable class. You might need to take a local copy and do the explicit boundary check before going into the StringLatin1/UTF16, especially StringUTF16. Some intrinsics, UTF16.getChar(byte[], int) for example, assume the caller performs bounds check (for

Re: Oracle Java 8u161 regression in XML Schema Factory

Hallo Christoph, Yes the Tests fail with -Djdk.xml.overrideDefaultParser=true (and false) as well. Gruss Bernd -- http://bernd.eckenfels.net Von: Langer, Christoph Gesendet: Mittwoch, 21. Februar 2018 16:16 An: Bernd; OpenJDK Dev list; huizhe.w...@oracle.com Betreff: RE: Oracle Java 8u161

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

Hi Stuart, Thanks for the apiNote! Joe re-approved the CSR with the added apiNote. For a test that compares Latin1 vs UTF16 coders, I added tests to the compact string's CompareTo test[1], basically running the original test for String with StringBuilder/Buffer. A build with jdk_core tests

Re: RFR: Here are some URLClassPath patches

OK, we have a reworked set of patches. (In my corner of openjdk we generally use real javadoc on private elements.) I reverted private doc comment style to the current maddening inconsistency, except I couldn't restrain myself from fixing -// ACC used when loading classes and resources */ +

RFR: 8198523: Refactor BootstrapMethodInvoker to further avoid runtime type checks

Hi, BootstrapMethodInvoker can be improved a bit further by providing static information about the type argument, and additionally teaching it about StringConcatFactory BSM: Patch: http://cr.openjdk.java.net/~redestad/8198523/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8198523 This

[11] RFR: JDK-8198385: Remove property sun.locale.formatasdefault

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8198385 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8198385/webrev.00/ The property was introduced in JDK7 for the backward compatibility, which at this point is no

Re: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.

On Wed, Feb 21, 2018 at 1:16 PM, Xueming Shen wrote: > > Hi Robert, > > Understood a silent replacement might not be the desired behavior in > some use scenarios. Anymore details regarding what "most apps want" > when there is/are malformed/unmappable? It appears the

Re: RFR: Here are some URLClassPath patches

On Wed, Feb 21, 2018 at 7:48 AM, Roger Riggs wrote: > > On the style changes in URLClassPath-ArrayDeque, about declarations like: > > ArrayList path = new ArrayList<>(); > > It had been a recommended style to use the abstract type (List) on the > left hand side > and only

RE: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.

Hi Alan, > > The Java 7+ methods in java.nio.file.Files already ignore the default > > charset > and always use UTF-8. How to proceed with those? Should they be changed > to behave to the new mechanisms? I'd suggest to not do this, as its part of > the spec (to use UTF-8) and should not rely on

Re: Oracle Java 8u161 regression in XML Schema Factory

@Joe: Is there some documentation for this change in default behavior that came with JDK8u161? I assume it is for higher security and cannot be reverted (e.g. by setting the feature default for Djdk.xml.overrideDefaultParser to true). It is indeed. It was a customer's request. Customers'