Re: JDK10 RFR of JDK-8185841:Values from getFirstDayOfWeek() are inconsistent with CLDR

2017-10-27 Thread Naoto Sato
Looks fine. Naoto On 10/26/17 11:24 PM, Rachna Goel wrote: Hi, Kindly review the fix to JDK-8185841. Bug : https://bugs.openjdk.java.net/browse/JDK-8185841. patch : http://cr.openjdk.java.net/~rgoel/JDK-8185841/webrev.08/ Fix is to relocate this region dependent data. New Bundle will be

Re: RFR 8189319 : Add a java.util.Properties constructor that takes an initial capacity

2017-10-27 Thread Roger Riggs
+1 On 10/27/17 5:39 PM, mandy chung wrote: On 10/27/17 2:37 PM, Brent Christian wrote: On 10/27/2017 11:19 AM, mandy chung wrote: It may be cleaner to initialize the map in a single place e.g. a private constructor taking Properties and initialCapacity. Yeah, that's a good idea.  See new

Re: RFR 8189319 : Add a java.util.Properties constructor that takes an initial capacity

2017-10-27 Thread mandy chung
On 10/27/17 2:37 PM, Brent Christian wrote: On 10/27/2017 11:19 AM, mandy chung wrote: It may be cleaner to initialize the map in a single place e.g. a private constructor taking Properties and initialCapacity. Yeah, that's a good idea.  See new webrev:

Re: RFR 8189319 : Add a java.util.Properties constructor that takes an initial capacity

2017-10-27 Thread Brent Christian
On 10/27/2017 11:19 AM, mandy chung wrote: It may be cleaner to initialize the map in a single place e.g. a private constructor taking Properties and initialCapacity. Yeah, that's a good idea. See new webrev: http://cr.openjdk.java.net/~bchristi/8189319/webrev.02/index.html Thanks, -Brent

Confusion (or bugs) regarding the 'UNORDERED' Collector Characteristic

2017-10-27 Thread Chris Dennis
Hi All, I’m very confused about what was intended with the ‘UNORDERED’ Collector characteristic. My logical inference was that unordered as a Collector characteristic meant that the result of this collector applied to any stream was independent of the order of element delivery. This means

Re: [Proposal/Question] Provide mechanism to monitor thread states more efficiently

2017-10-27 Thread mandy chung
serviceability-dev is the mailing list for discussing java.lang.management APIs. Getting the stack trace is expensive. ThreadMXBean.getThreadInfos(ids) does not get the stack trace and locks information and is less expensive. A typical lightweight monitoring application does BCI and call

Re: RFR 8189319 : Add a java.util.Properties constructor that takes an initial capacity

2017-10-27 Thread Martin Buchholz
I completely missed the fact that Properties continues to inherit from Hashtable but the data is actually stored in a CHM. I would have been afraid to make that change ... Looks good! On Thu, Oct 26, 2017 at 6:43 PM, Brent Christian wrote: > Hi, > > It would be

Fwd: Re: [Proposal/Question] Provide mechanism to monitor thread states more efficiently

2017-10-27 Thread Roger Riggs
Hi, (A bit too quick on the send button; need to reallocate if the array is not big enough). I was just pointing out there already is access to the information you are requesting without adding a new API. ThreadGroup.activeCount() provides the number of active threads. Of course, threads

Re: [Proposal/Question] Provide mechanism to monitor thread states more efficiently

2017-10-27 Thread Roger Riggs
Hi, I was just pointing out there already is access to the information you are requesting without adding a new API. ThreadGroup.activeCount() provides the number of active threads. Of course, threads come and go asynchronously. Yes, the Thread array has to be allocated by the caller and may

Re: RFR 8189319 : Add a java.util.Properties constructor that takes an initial capacity

2017-10-27 Thread mandy chung
On 10/26/17 6:43 PM, Brent Christian wrote: Hi, It would be useful to have a Properties constructor that takes an argument to set the initial capacity. Such a constructor is present on many of the other Map implementations in the JDK, including Hashtable, the superclass of Properties. In

RFR: 8190287: Update JDK's internal ASM to ASMv6

2017-10-27 Thread Kumar Srinivasan
Hello Remi, Sundar and others, Please review the webrev [1] to update JDK's internal ASM to v6. To help with review areas, you can use the browser to search for mq patches commented with // Highlights of changes: 1. updated ASMv6 // jdk-new-asmv6.patch 2. changes to jlink and jar to add

RE: [Proposal/Question] Provide mechanism to monitor thread states more efficiently

2017-10-27 Thread Christoph Dreis
Hi Roger, > You might use ThreadGroup.enumerate(Thread[], recurse) after walking up > the parents to the root ThreadGroup. Thanks. Isn't this method silently dropping threads in case it can't hold what you specified upfront as an array? Apart from that: Would it be a candidate for

Re: [Proposal/Question] Provide mechanism to monitor thread states more efficiently

2017-10-27 Thread Roger Riggs
Hi Christoph, You might use ThreadGroup.enumerate(Thread[], recurse) after walking up the parents to the root ThreadGroup. $.02, Roger On 10/27/2017 11:23 AM, Christoph Dreis wrote: Hey, I don't know if this is the correct mailing list for this specific topic. Please let me know in case

[Proposal/Question] Provide mechanism to monitor thread states more efficiently

2017-10-27 Thread Christoph Dreis
Hey, I don't know if this is the correct mailing list for this specific topic. Please let me know in case it isn't. I'm currently trying to improve the live-monitoring of an application and would like to get a simple overview of how many threads are in state RUNNABLE, BLOCKED and so on. For this

Re: RFR: 8188858: Caching latestUserDefinedLoader() results in ObjectInputStream.readObject()

2017-10-27 Thread Kazunori Ogata
Hi Alan, Thank you for your review and comments. I updated webrev based on your comments: http://cr.openjdk.java.net/~horii/8188858/webrev.05/ Alan Bateman wrote on 2017/10/26 19:31:53: > I've read through webrev.03 and webrev.04 and they seem correct. Are > there

RE: tzdata2017c is out

2017-10-27 Thread Ramanand Patil
Hi Martin, Thank you very much for the heads-up. I have filed a bug for the same: https://bugs.openjdk.java.net/browse/JDK-8190259 Thank you for the patch as well. This will be integrated into JDK along with the tzdata2017c.   Regards, Ramanand.   From: Martin Buchholz

JDK10 RFR of JDK-8185841:Values from getFirstDayOfWeek() are inconsistent with CLDR

2017-10-27 Thread Rachna Goel
Hi, Kindly review the fix to JDK-8185841. Bug : https://bugs.openjdk.java.net/browse/JDK-8185841. patch : http://cr.openjdk.java.net/~rgoel/JDK-8185841/webrev.08/ Fix is to relocate this region dependent data. New Bundle will be generated when Locale id has non empty script and country code