Re: RFR: 8200129 : Remove D3D Performance Counter.

+1 Mandy On 3/22/18 1:33 PM, Phil Race wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8200129 webrev: http://cr.openjdk.java.net/~prr/8200129/ It was noted in another thread [1] that we had a couple of qualified exports from java.base to java.desktop that are platform-specific but are

Re: RFR 8200118: [test] String concat tests should test toString() application order

> On Mar 22, 2018, at 2:46 PM, Aleksey Shipilev wrote: > > On 03/22/2018 10:37 PM, Paul Sandoz wrote: >> Test looks good, but do you need to declare the source/target for >> compilation? > > Thanks! source/target are from the times when default source/target was not > 9,

Re: RFR 8200118: [test] String concat tests should test toString() application order

On 03/22/2018 10:37 PM, Paul Sandoz wrote: > Test looks good, but do you need to declare the source/target for compilation? Thanks! source/target are from the times when default source/target was not 9, all other tests have it (I copypasted the test from the existing ones). We should probably

Re: RFR 8200118: [test] String concat tests should test toString() application order

Test looks good, but do you need to declare the source/target for compilation? Paul. > On Mar 22, 2018, at 10:56 AM, Aleksey Shipilev wrote: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8200118 > > Webrev: > http://cr.openjdk.java.net/~shade/8200118/webrev.01/ > >

Re: RFR: 8196750 [Testbug] tools/launcher tests need to tolerate unrelated warnings

On 23/03/2018 12:18 AM, Kumar Srinivasan wrote: David, Why would the VM emit these warnings if the deprecated vm flag is not being used ? The warnings are not deprecation warnings. The warnings are for flags that should have been made obsolete in this version but are still present. It is a

Re: RFR: 8200129 : Remove D3D Performance Counter.

On 22/03/2018 20:33, Phil Race wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8200129 webrev: http://cr.openjdk.java.net/~prr/8200129/ This looks okay to me. -Alan

Re: RFR: 8200129 : Remove D3D Performance Counter.

Looks fine. On 22/03/2018 13:33, Phil Race wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8200129 webrev: http://cr.openjdk.java.net/~prr/8200129/ It was noted in another thread [1] that we had a couple of qualified exports from java.base to java.desktop that are platform-specific but

RFR: 8200129 : Remove D3D Performance Counter.

bug: https://bugs.openjdk.java.net/browse/JDK-8200129 webrev: http://cr.openjdk.java.net/~prr/8200129/ It was noted in another thread [1] that we had a couple of qualified exports from java.base to java.desktop that are platform-specific but are in the main module-info.java. It was suggested to

Re: [PATCH] unnecessary null check inside of java.lang.Boolean.valueOf(String)

Сергей: Thanks for the benchmarking. I would always do benchmarking with latest available jdk, i.e. jdk11. You don't say which variant is better and which is best! But the difference is small enough we should go with the simpler one you originally suggested return "true".equalsIgnoreCase(s); I

Re: [11] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

On 2018-03-22 19:03, Stuart Marks wrote: One small issue is with this comment:  295  * Constructs a sublist of an arbitrary AbstractList, which is  296  * not a SubList itself. This supports sublists of an arbitrary AbstractImmutableList, not AbstractList. Other than

Re: RFR 8199756 : Simplify language, country, script, and variant property initialization

The performance concern is a fair point and it'll need the benchmark and proper perf measurement.  It's okay with me to follow up as a separate clean up and you already have the work started any way. Mandy On 3/22/18 12:01 PM, Roger Riggs wrote: Hi Mandy, This is just one step in untangling

Re: RFR 8199756 : Simplify language, country, script, and variant property initialization

Hi Mandy, This is just one step in untangling and improving property initialization. I'm also working on a change similar to what you suggest to remove some/more of the upcalls and replace them with setting fields. In that case, the adjustments to the values would be handled in java. I have

Re: revisiting MDC in slf4j broken because of CompletableFuture

To be clear, SLF4J only provides an MDC API and doesn’t implement the MDC. It delegates that to an implementation - Log4j 2 or Logback. Obviously, my concern would be to get Log4j 2 to work the way it needs to. If it requires additional help from the JDK library then there is only so much I can

Re: RFR: 8200072: Remove un-needed qualified export from java.base to java.desktop

Seems you need to run it on all platforms to be sure. This one is used on Windows : exports jdk.internal.perf to java.desktop This one is used on Linux + Solaris : exports sun.nio.cs to java.desktop -phil. On 03/22/2018 11:01 AM, mandy chung wrote: On 3/22/18 10:44 AM, Alan Bateman

Re: RFR: 8200072: Remove un-needed qualified export from java.base to java.desktop

I already pushed 8200072 but I'll file a new bug. -phil. On 03/22/2018 11:28 AM, mandy chung wrote: Yes it needs to run all platforms because some qualified exports are platform-specific. On 3/22/18 11:22 AM, Phil Race wrote: Seems you need to run it on all platforms to be sure. This one

Re: RFR: 8200072: Remove un-needed qualified export from java.base to java.desktop

Yes it needs to run all platforms because some qualified exports are platform-specific. On 3/22/18 11:22 AM, Phil Race wrote: Seems you need to run it on all platforms to be sure. This one is used on Windows :     exports jdk.internal.perf to java.desktop This one is used on Linux + Solaris

Re: revisiting MDC in slf4j broken because of CompletableFuture

My point is that I don’t think this is the only place the problem occurs. I have seen similar questions on the Log4j mailing list where users want to be able to do this for thread pools they create via Executors and don’t want to have to do the ThreadLocal propagation themselves. If a

Re: RFR 8199756 : Simplify language, country, script, and variant property initialization

Hi Roger, Thanks for adding the test that should have created when JDK-4700857 was resolved. Since this fix changes the setting of those i18n properties to later after JVM_InitProperties is called, it would be a good opportunity to set these properties in Java and remove the native

Re: [11] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Great, thanks for doing those cleanups! They're small, but I think they make a big difference in the comprehensibility of the code, because of all the little classes in this file. Looks like you went ahead and consolidated everything into ListItr, which is used by the iterator() and

Re: RFR: 8200072: Remove un-needed qualified export from java.base to java.desktop

On 3/22/18 10:44 AM, Alan Bateman wrote: On 22/03/2018 17:41, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8200072 webrev: http://cr.openjdk.java.net/~prr/8200072/ jdk.internal.math is exported to java.desktop but it has never been needed, except briefly, in the jake

RFR 8200118: [test] String concat tests should test toString() application order

Bug: https://bugs.openjdk.java.net/browse/JDK-8200118 Webrev: http://cr.openjdk.java.net/~shade/8200118/webrev.01/ This adds the relevant test to StringConcat family of tests, which asserts all strategies do the right thing. There was a bug in MH_* strategies caused by the already fixed bug

Re: RFR: 8200072: Remove un-needed qualified export from java.base to java.desktop

+1 Mandy On 3/22/18 10:41 AM, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8200072 webrev: http://cr.openjdk.java.net/~prr/8200072/ jdk.internal.math is exported to java.desktop but it has never been needed, except briefly, in the jake forest during JDK 9 development.

Re: RFR: 8200072: Remove un-needed qualified export from java.base to java.desktop

On 22/03/2018 17:41, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8200072 webrev: http://cr.openjdk.java.net/~prr/8200072/ jdk.internal.math is exported to java.desktop but it has never been needed, except briefly, in the jake forest during JDK 9 development. History is in

Re: revisiting MDC in slf4j broken because of CompletableFuture

Having read several of the threads I think I have a better understanding of the problem. This sounds similar to problems that occur with any application that has a way of doing asynchronous processing with with thread pools. Java has unfortunately not provided a good way that I know of to pass

RFR: 8200072: Remove un-needed qualified export from java.base to java.desktop

Bug: https://bugs.openjdk.java.net/browse/JDK-8200072 webrev: http://cr.openjdk.java.net/~prr/8200072/ jdk.internal.math is exported to java.desktop but it has never been needed, except briefly, in the jake forest during JDK 9 development. History is in the bug. -phil.

Re: [PATCH] unnecessary null check inside of java.lang.Boolean.valueOf(String)

If parseBoolean is worth optimizing (barely, but only because Boolean is very popular), then let's do the usual ASCII bit-twiddling: public static boolean parseBoolean(String s) { // return "true".equalsIgnoreCase(s); return s != null && s.length() == 4

Re: revisiting MDC in slf4j broken because of CompletableFuture

Log4j 2 supports a ThreadContext which is analogous to the SLF4J MDC. Both are based on ThreadLocal variables. If I understand what you are saying, the problem is that ThreadLocals do not work as you you would expect when using CompleteableFutures? Ralph > On Mar 22, 2018, at 7:05 AM, Dean

revisiting MDC in slf4j broken because of CompletableFuture

slf4j is pretty much the defacto logging standard these days allowing one to bring in libraries using any logging framework. (commons logging fell short and had classloading bugs). Summary: MDC works fine in twitter scala Futures but not java CompletableFutures. Unfortunately, one of the best

Re: RFR 8199756 : Simplify language, country, script, and variant property initialization

Looks good. Thanks Roger for the clean up. Naoto On 3/22/18 8:24 AM, Roger Riggs wrote: Hi, The webrev[1] has been updated with a new test added to verify that if a user.* property is defined on the command line, then corresponding property has the same value and correctly overrides any

Re: [11] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Hi Stuart, On 2018-03-22 01:51, Stuart Marks wrote: Hi Claes, I'm finally finally getting back to this. I reviewed the current state of the patch located here:     http://cr.openjdk.java.net/~redestad/8193128/open.06/ I think this is mostly fine as it is. thanks! There are some things

Re: RFR 8199756 : Simplify language, country, script, and variant property initialization

Hi, The webrev[1] has been updated with a new test added to verify that if a user.* property is defined on the command line, then corresponding property has the same value and correctly overrides any value from the platform. After verification, the comment (line 304) has been corrected to

Re: RFR 8180410: ByteArrayOutputStream should not throw IOExceptions

Hi Roger, Thanks for the comments. It seems like we have agreement on using @apiNote instead of @implSpec. Brian On Mar 22, 2018, at 8:02 AM, Roger Riggs wrote: > The use of the word 'equivalent' regardless of the context, only says the > behavior is the same > it

Re: RFR 8180410: ByteArrayOutputStream should not throw IOExceptions

Hi Brian, The use of the word 'equivalent' regardless of the context, only says the behavior is the same it does not mandate the implementation except that it behaves the same. Since the behavior of the method is already specified, adding the 'equivalent' statement only makes it easier for

Re: RFR: 8196750 [Testbug] tools/launcher tests need to tolerate unrelated warnings

David, Why would the VM emit these warnings if the deprecated vm flag is not being used ? Andrey, As for the reviews I am ok with InfoStreams, wrt. ToolOpts it is not at all apparent, maybe more comments explaining what is going on ? Kumar Hi Andrei, On 22/03/2018 11:12 AM, Andrey