Re: Review: lamda expressions and bulk data operations on collections.

I see nobody using mangled (comparing&map) methods (even oracle guys) and this is the thing that I already have expected, just since we all lazy and this would hurt performance. This issue would be a candidate topic for next edition of Joshua Bloch's Effective Java. So to prevent this I propose fo

hg: jdk8/tl/jdk: 8023765: Improve MaxPathLength.java testcase and reduce its test load; ...

Changeset: 5b01c851bb1d Author:dxu Date: 2013-08-30 16:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b01c851bb1d 8023765: Improve MaxPathLength.java testcase and reduce its test load 7160013: java/io/File/MaxPathLength.java fails Reviewed-by: alanb ! test/ProblemList.tx

hg: jdk8/tl/langtools: 8015663: Need to supply tests to provide javadoc for profiles support code coverage

Changeset: 7993cfab8610 Author:jjg Date: 2013-08-30 17:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7993cfab8610 8015663: Need to supply tests to provide javadoc for profiles support code coverage Reviewed-by: jjg Contributed-by: evgeniya.stepan...@oracle.com ! t

hg: jdk8/tl/langtools: 8022738: doclet should only generate functional interface text if source >= 8

Changeset: b25e387481dc Author:bpatel Date: 2013-08-30 16:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b25e387481dc 8022738: doclet should only generate functional interface text if source >= 8 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javadoc/ClassDocImp

hg: jdk8/tl/langtools: 8008367: Sub-packages missing from Profiles javadoc

Changeset: f050c714b556 Author:jjg Date: 2013-08-30 16:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f050c714b556 8008367: Sub-packages missing from Profiles javadoc Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java

hg: jdk8/tl/langtools: 8015882: Javadoc prints NPE when using Taglet

Changeset: 7a2fe98cb0e6 Author:bpatel Date: 2013-08-30 16:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7a2fe98cb0e6 8015882: Javadoc prints NPE when using Taglet Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LegacyTaglet.java

hg: jdk8/tl/langtools: 7198273: RFE : Javadoc Accessibility : Hyperlinks should contain text or an image with alt text

Changeset: dd64288f5659 Author:bpatel Date: 2013-08-30 15:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dd64288f5659 7198273: RFE : Javadoc Accessibility : Hyperlinks should contain text or an image with alt text Reviewed-by: jjg ! src/share/classes/com/sun/tools/

hg: jdk8/tl/langtools: 8024093: Two *.rej files checked in to langtools/test directory

Changeset: 3dd40e5715fb Author:jjg Date: 2013-08-30 15:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3dd40e5715fb 8024093: Two *.rej files checked in to langtools/test directory Reviewed-by: mchung - test/tools/javac/diags/examples/MrefStat.java.rej - test/tools/ja

Re: RFR: 8024014 & 8024015 : (xs) TEST.groups updates

On Aug 29 2013, at 22:37 , Alan Bateman wrote: > On 30/08/2013 01:13, Mike Duigou wrote: >> Hello all; >> >> This is a review for two changesets. The first change (JDK-8024014) splits >> up the jdk_util test group a bit by introducing three sub-groups, >> jdk_collections, jdk_stream and jdk_co

Re: State of Reflection.getCallerClass replacement in Java 8

On 8/30/13 7:56 AM, Nick Williams wrote: On Aug 30, 2013, at 9:12 AM, Alan Bateman wrote: You are on the right list. Mandy Chung is planning to re-start the discussion with a proposal very soon. Yes - I'm planning to restart the discussion soon. It is very important to get the conclusion a

Re: State of Reflection.getCallerClass replacement in Java 8

On 30. August 2013 at 16:56:31, Nick Williams (nicholas+open...@nicholaswilliams.net) wrote: On Aug 30, 2013, at 9:12 AM, Alan Bateman wrote:  > On 30/08/2013 15:01, Jörn Huxhorn wrote:  >> Has there been a decision about a replacement for Reflection.getCallerClass >> in Java 8?  >>  >> The las

hg: jdk8/tl/langtools: 8023700: Use non breaking space in various labels

Changeset: 240f424cc0d5 Author:jjg Date: 2013-08-30 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/240f424cc0d5 8023700: Use non breaking space in various labels Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.

RE: RFR: JDK-6823527: java.util.logging.Handler has thread safety issues

> I'm not sure I'd want to attempt that. Modifications in logging code > have a tendency to come back and bite you ;-(... I understand. Maybe a future RFE. I'm happy with your changes then. > isLoggable() is not synchronized and no longer calls synchronized > methods since we're now using vola

Re: RFR: JDK-6823527: java.util.logging.Handler has thread safety issues

On 8/30/13 7:04 PM, Jason Mehrens wrote: The coarse grain locking in FileHandler, MemoryHandler, SocketHandler, and StreamHandler publish could/should be relaxed so we are not calling isLoggable while holding the lock. Hi Jason, I'm not sure I'd want to attempt that. Modifications in logging c

RE: RFR: JDK-6823527: java.util.logging.Handler has thread safety issues

The coarse grain locking in FileHandler, MemoryHandler, SocketHandler, and StreamHandler publish could/should be relaxed so we are not calling isLoggable while holding the lock. Jason > Date: Fri, 30 Aug 2013 13:50:56 +0200 > From: daniel.fu...@oracle.com > To: david.hol...@oracle.com > Subje

Re: State of Reflection.getCallerClass replacement in Java 8

On Aug 30, 2013, at 9:12 AM, Alan Bateman wrote: > On 30/08/2013 15:01, Jörn Huxhorn wrote: >> Has there been a decision about a replacement for Reflection.getCallerClass >> in Java 8? >> >> The last info I know of is that it will be reactivated in j7u40 but will be >> gone in j8. >> >> There

Re: State of Reflection.getCallerClass replacement in Java 8

On 30/08/2013 15:01, Jörn Huxhorn wrote: Has there been a decision about a replacement for Reflection.getCallerClass in Java 8? The last info I know of is that it will be reactivated in j7u40 but will be gone in j8. There has also been some discussion about doing a proper public API since all

State of Reflection.getCallerClass replacement in Java 8

Has there been a decision about a replacement for Reflection.getCallerClass in Java 8? The last info I know of is that it will be reactivated in j7u40 but will be gone in j8. There has also been some discussion about doing a proper public API since all alternatives are way slower. The latest

Re: RFR: JDK-6823527: java.util.logging.Handler has thread safety issues

Hi, Please find below an updated patch for solution (c) best regards, -- daniel >>> It seems we have 5 choices: >>> >>> a. Not fixing >>> b. Using regular 'synchronized' pattern [1] >>> c. Using volatiles, synchronize setters only

hg: jdk8/tl/jdk: 6566891: RMIConnector: map value referencing map key in WeakHashMap prevents map entry to be removed

Changeset: 2d51653d9b4b Author:sjiang Date: 2013-08-30 12:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2d51653d9b4b 6566891: RMIConnector: map value referencing map key in WeakHashMap prevents map entry to be removed Reviewed-by: egahlin, jbachorik, dfuchs, dholmes ! s

Re: RFR: JDK-6823527: java.util.logging.Handler has thread safety issues

On 30/08/2013 6:38 PM, Daniel Fuchs wrote: On 8/30/13 9:21 AM, David Holmes wrote: StreamHandler.java writer doesn't need to be volatile - AFAICS it is only accessed within synchronized methods. Ah - no - it's called in isLoggable() actually. The whole point of using volatiles instead of regu

Re: Potential issue with CHM.toArray

On Aug 29, 2013, at 1:44 PM, Doug Lea wrote: > On 08/28/2013 09:13 AM, Peter Levart wrote: > >> It seems that the iteration can traverse through the same tables multiple >> times >> (back and forth) by following ForwardingNode.nextTable links. Aren't >> nextTable >> links supposed to be only

Re: RFR: JDK-6823527: java.util.logging.Handler has thread safety issues

On 8/30/13 9:21 AM, David Holmes wrote: Hi Daniel, I'm fine with the approach in (c), just wanted to highlight the performance considerations (volatile and synchronized need not be equivalent in the uncontended case - biased-locking can mean there are no barriers emitted.) A few specific commen

Re: RFR: 8023997 : j.l.String.join(java.lang.CharSequence, java.lang.Iterable) sample doesn't compile and is incorrect

On 30/08/2013 07:44, Henry Jen wrote: Hi, Please kindly review a simple webrev that just fixes a sample in the javadoc of String.join(). http://cr.openjdk.java.net/~henryjen/tl/8023997/0/webrev/ This looks okay to me. I note in the bug report that the example is considered normative but tha

Re: RFR: JDK-6823527: java.util.logging.Handler has thread safety issues

Hi Daniel, I'm fine with the approach in (c), just wanted to highlight the performance considerations (volatile and synchronized need not be equivalent in the uncontended case - biased-locking can mean there are no barriers emitted.) A few specific comments on [2]: Handler.java: reportErro