From jhuxhorn at googlemail.com Thu Aug 1 06:31:45 2013 From: jhuxhorn at googlemail.com (=?UTF-8?Q?J=C3=B6rn_Huxhorn?=) Date: Thu, 1 Aug 2013 08:31:45 +0200 Subject: =?UTF-8?Q?Re=3A_problems_with_sun.reflect.Reflection.getCallerClass(int)?= In-Reply-To: <20130731134211.948357@eggemoggin.niobe.net> References: <51DE6B0A.1010207@gmx.org> <20130731134211.948357@eggemoggin.niobe.net> Message-ID: Thank you! On 31. Juli 2013 at 22:43:39, mark.reinhold at oracle.com (mark.reinhold at oracle.com) wrote: FYI, we're going to revert this method to its previous behavior in JDK 7u40: http://bugs.sun.com/view_bug.do?bug_id=8021946 . What will happen to this method in JDK 8 requires further thought. - Mark From chris.hegarty at oracle.com Thu Aug 1 10:34:56 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 01 Aug 2013 11:34:56 +0100 Subject: RFR doclint issues in j.u.Deque & Queue Message-ID: <51FA39D0.1060309@oracle.com> These changes are already committed in the jsr166 CVS, this is a request to pull them into jdk8. Specdiff has been run, and there is nothing surprising. The doclint issues are specifically around the addition of a caption to the tables, the remaining changes are cleanup, -> {@code ..}, etc. Note: there are some minor doc updates around throwing an IllegalStateException if no space is currently available in Deque, which is already part of the spec. Martin, Doug, The 166 CVS is trivially missing 6546713, http://cr.openjdk.java.net/~mduigou/6546713/0/webrev/src/share/classes/java/util/Deque.java.sdiff.html. Once the changes below are in jdk8, you can easily sync with the 8 version, or apply the diffs from the webrev link above. I have already reviewed these changes, but more reviewers are welcome. diff -r 4bd51f6268f4 src/share/classes/java/util/Deque.java --- a/src/share/classes/java/util/Deque.java Wed Jul 24 10:57:02 2013 +0200 +++ b/src/share/classes/java/util/Deque.java Thu Aug 01 11:24:48 2013 +0100 @@ -38,7 +38,7 @@ package java.util; /** * A linear collection that supports element insertion and removal at * both ends. The name deque is short for "double ended queue" - * and is usually pronounced "deck". Most Deque + * and is usually pronounced "deck". Most {@code Deque} * implementations place no fixed limits on the number of elements * they may contain, but this interface supports capacity-restricted * deques as well as those with no fixed size limit. @@ -47,10 +47,10 @@ package java.util; * ends of the deque. Methods are provided to insert, remove, and * examine the element. Each of these methods exists in two forms: * one throws an exception if the operation fails, the other returns a - * special value (either null or false, depending on + * special value (either {@code null} or {@code false}, depending on * the operation). The latter form of the insert operation is * designed specifically for use with capacity-restricted - * Deque implementations; in most implementations, insert + * {@code Deque} implementations; in most implementations, insert * operations cannot fail. * *

The twelve methods described above are summarized in the @@ -58,6 +58,7 @@ package java.util; * *

* + * * * * @@ -72,38 +73,39 @@ package java.util; * * * - * - * - * - * + * + * + * + * * * * - * - * - * - * + * + * + * + * * * * - * - * - * - * + * + * + * + * * *
Summary of Deque methods
First Element (Head)
Insert{@link #addFirst addFirst(e)}{@link #offerFirst offerFirst(e)}{@link #addLast addLast(e)}{@link #offerLast offerLast(e)}{@link Deque#addFirst addFirst(e)}{@link Deque#offerFirst offerFirst(e)}{@link Deque#addLast addLast(e)}{@link Deque#offerLast offerLast(e)}
Remove{@link #removeFirst removeFirst()}{@link #pollFirst pollFirst()}{@link #removeLast removeLast()}{@link #pollLast pollLast()}{@link Deque#removeFirst removeFirst()}{@link Deque#pollFirst pollFirst()}{@link Deque#removeLast removeLast()}{@link Deque#pollLast pollLast()}
Examine{@link #getFirst getFirst()}{@link #peekFirst peekFirst()}{@link #getLast getLast()}{@link #peekLast peekLast()}{@link Deque#getFirst getFirst()}{@link Deque#peekFirst peekFirst()}{@link Deque#getLast getLast()}{@link Deque#peekLast peekLast()}
* *

This interface extends the {@link Queue} interface. When a deque is * used as a queue, FIFO (First-In-First-Out) behavior results. Elements are * added at the end of the deque and removed from the beginning. The methods - * inherited from the Queue interface are precisely equivalent to - * Deque methods as indicated in the following table: + * inherited from the {@code Queue} interface are precisely equivalent to + * {@code Deque} methods as indicated in the following table: * *

* + * * - * - * + * + * * * * @@ -135,13 +137,14 @@ package java.util; * interface should be used in preference to the legacy {@link Stack} class. * When a deque is used as a stack, elements are pushed and popped from the * beginning of the deque. Stack methods are precisely equivalent to - * Deque methods as indicated in the table below: + * {@code Deque} methods as indicated in the table below: * *

*

Comparison of Queue and Deque methods
Queue Method Equivalent Deque Method {@code Queue} Method Equivalent {@code Deque} Method
{@link java.util.Queue#add add(e)}
+ * * * - * + * * * * @@ -168,18 +171,18 @@ package java.util; *

Unlike the {@link List} interface, this interface does not * provide support for indexed access to elements. * - *

While Deque implementations are not strictly required + *

While {@code Deque} implementations are not strictly required * to prohibit the insertion of null elements, they are strongly - * encouraged to do so. Users of any Deque implementations + * encouraged to do so. Users of any {@code Deque} implementations * that do allow null elements are strongly encouraged not to * take advantage of the ability to insert nulls. This is so because - * null is used as a special return value by various methods + * {@code null} is used as a special return value by various methods * to indicated that the deque is empty. * - *

Deque implementations generally do not define - * element-based versions of the equals and hashCode + *

{@code Deque} implementations generally do not define + * element-based versions of the {@code equals} and {@code hashCode} * methods, but instead inherit the identity-based versions from class - * Object. + * {@code Object}. * *

This interface is a member of the Java Collections @@ -190,13 +193,13 @@ package java.util; * @since 1.6 * @param the type of elements held in this collection */ - public interface Deque extends Queue { /** * Inserts the specified element at the front of this deque if it is - * possible to do so immediately without violating capacity restrictions. - * When using a capacity-restricted deque, it is generally preferable to - * use method {@link #offerFirst}. + * possible to do so immediately without violating capacity restrictions, + * throwing an {@code IllegalStateException} if no space is currently + * available. When using a capacity-restricted deque, it is generally + * preferable to use method {@link #offerFirst}. * * @param e the element to add * @throws IllegalStateException if the element cannot be added at this @@ -212,9 +215,10 @@ public interface Deque extends Queue< /** * Inserts the specified element at the end of this deque if it is - * possible to do so immediately without violating capacity restrictions. - * When using a capacity-restricted deque, it is generally preferable to - * use method {@link #offerLast}. + * possible to do so immediately without violating capacity restrictions, + * throwing an {@code IllegalStateException} if no space is currently + * available. When using a capacity-restricted deque, it is generally + * preferable to use method {@link #offerLast}. * *

This method is equivalent to {@link #add}. * @@ -237,8 +241,8 @@ public interface Deque extends Queue< * which can fail to insert an element only by throwing an exception. * * @param e the element to add - * @return true if the element was added to this deque, else - * false + * @return {@code true} if the element was added to this deque, else + * {@code false} * @throws ClassCastException if the class of the specified element * prevents it from being added to this deque * @throws NullPointerException if the specified element is null and this @@ -255,8 +259,8 @@ public interface Deque extends Queue< * which can fail to insert an element only by throwing an exception. * * @param e the element to add - * @return true if the element was added to this deque, else - * false + * @return {@code true} if the element was added to this deque, else + * {@code false} * @throws ClassCastException if the class of the specified element * prevents it from being added to this deque * @throws NullPointerException if the specified element is null and this @@ -288,17 +292,17 @@ public interface Deque extends Queue< /** * Retrieves and removes the first element of this deque, - * or returns null if this deque is empty. + * or returns {@code null} if this deque is empty. * - * @return the head of this deque, or null if this deque is empty + * @return the head of this deque, or {@code null} if this deque is empty */ E pollFirst(); /** * Retrieves and removes the last element of this deque, - * or returns null if this deque is empty. + * or returns {@code null} if this deque is empty. * - * @return the tail of this deque, or null if this deque is empty + * @return the tail of this deque, or {@code null} if this deque is empty */ E pollLast(); @@ -325,31 +329,31 @@ public interface Deque extends Queue< /** * Retrieves, but does not remove, the first element of this deque, - * or returns null if this deque is empty. + * or returns {@code null} if this deque is empty. * - * @return the head of this deque, or null if this deque is empty + * @return the head of this deque, or {@code null} if this deque is empty */ E peekFirst(); /** * Retrieves, but does not remove, the last element of this deque, - * or returns null if this deque is empty. + * or returns {@code null} if this deque is empty. * - * @return the tail of this deque, or null if this deque is empty + * @return the tail of this deque, or {@code null} if this deque is empty */ E peekLast(); /** * Removes the first occurrence of the specified element from this deque. * If the deque does not contain the element, it is unchanged. - * More formally, removes the first element e such that + * More formally, removes the first element {@code e} such that * (o==null ? e==null : o.equals(e)) * (if such an element exists). - * Returns true if this deque contained the specified element + * Returns {@code true} if this deque contained the specified element * (or equivalently, if this deque changed as a result of the call). * * @param o element to be removed from this deque, if present - * @return true if an element was removed as a result of this call + * @return {@code true} if an element was removed as a result of this call * @throws ClassCastException if the class of the specified element * is incompatible with this deque * (optional) @@ -362,14 +366,14 @@ public interface Deque extends Queue< /** * Removes the last occurrence of the specified element from this deque. * If the deque does not contain the element, it is unchanged. - * More formally, removes the last element e such that + * More formally, removes the last element {@code e} such that * (o==null ? e==null : o.equals(e)) * (if such an element exists). - * Returns true if this deque contained the specified element + * Returns {@code true} if this deque contained the specified element * (or equivalently, if this deque changed as a result of the call). * * @param o element to be removed from this deque, if present - * @return true if an element was removed as a result of this call + * @return {@code true} if an element was removed as a result of this call * @throws ClassCastException if the class of the specified element * is incompatible with this deque * (optional) @@ -385,15 +389,15 @@ public interface Deque extends Queue< * Inserts the specified element into the queue represented by this deque * (in other words, at the tail of this deque) if it is possible to do so * immediately without violating capacity restrictions, returning - * true upon success and throwing an - * IllegalStateException if no space is currently available. + * {@code true} upon success and throwing an + * {@code IllegalStateException} if no space is currently available. * When using a capacity-restricted deque, it is generally preferable to * use {@link #offer(Object) offer}. * *

This method is equivalent to {@link #addLast}. * * @param e the element to add - * @return true (as specified by {@link Collection#add}) + * @return {@code true} (as specified by {@link Collection#add}) * @throws IllegalStateException if the element cannot be added at this * time due to capacity restrictions * @throws ClassCastException if the class of the specified element @@ -409,7 +413,7 @@ public interface Deque extends Queue< * Inserts the specified element into the queue represented by this deque * (in other words, at the tail of this deque) if it is possible to do so * immediately without violating capacity restrictions, returning - * true upon success and false if no space is currently + * {@code true} upon success and {@code false} if no space is currently * available. When using a capacity-restricted deque, this method is * generally preferable to the {@link #add} method, which can fail to * insert an element only by throwing an exception. @@ -417,8 +421,8 @@ public interface Deque extends Queue< *

This method is equivalent to {@link #offerLast}. * * @param e the element to add - * @return true if the element was added to this deque, else - * false + * @return {@code true} if the element was added to this deque, else + * {@code false} * @throws ClassCastException if the class of the specified element * prevents it from being added to this deque * @throws NullPointerException if the specified element is null and this @@ -444,11 +448,11 @@ public interface Deque extends Queue< /** * Retrieves and removes the head of the queue represented by this deque * (in other words, the first element of this deque), or returns - * null if this deque is empty. + * {@code null} if this deque is empty. * *

This method is equivalent to {@link #pollFirst()}. * - * @return the first element of this deque, or null if + * @return the first element of this deque, or {@code null} if * this deque is empty */ E poll(); @@ -469,12 +473,12 @@ public interface Deque extends Queue< /** * Retrieves, but does not remove, the head of the queue represented by * this deque (in other words, the first element of this deque), or - * returns null if this deque is empty. + * returns {@code null} if this deque is empty. * *

This method is equivalent to {@link #peekFirst()}. * * @return the head of the queue represented by this deque, or - * null if this deque is empty + * {@code null} if this deque is empty */ E peek(); @@ -484,9 +488,8 @@ public interface Deque extends Queue< /** * Pushes an element onto the stack represented by this deque (in other * words, at the head of this deque) if it is possible to do so - * immediately without violating capacity restrictions, returning - * true upon success and throwing an - * IllegalStateException if no space is currently available. + * immediately without violating capacity restrictions, throwing an + * {@code IllegalStateException} if no space is currently available. * *

This method is equivalent to {@link #addFirst}. * @@ -520,16 +523,16 @@ public interface Deque extends Queue< /** * Removes the first occurrence of the specified element from this deque. * If the deque does not contain the element, it is unchanged. - * More formally, removes the first element e such that + * More formally, removes the first element {@code e} such that * (o==null ? e==null : o.equals(e)) * (if such an element exists). - * Returns true if this deque contained the specified element + * Returns {@code true} if this deque contained the specified element * (or equivalently, if this deque changed as a result of the call). * - *

This method is equivalent to {@link #removeFirstOccurrence}. + *

This method is equivalent to {@link #removeFirstOccurrence(Object)}. * * @param o element to be removed from this deque, if present - * @return true if an element was removed as a result of this call + * @return {@code true} if an element was removed as a result of this call * @throws ClassCastException if the class of the specified element * is incompatible with this deque * (optional) @@ -540,13 +543,13 @@ public interface Deque extends Queue< boolean remove(Object o); /** - * Returns true if this deque contains the specified element. - * More formally, returns true if and only if this deque contains - * at least one element e such that + * Returns {@code true} if this deque contains the specified element. + * More formally, returns {@code true} if and only if this deque contains + * at least one element {@code e} such that * (o==null ? e==null : o.equals(e)). * * @param o element whose presence in this deque is to be tested - * @return true if this deque contains the specified element + * @return {@code true} if this deque contains the specified element * @throws ClassCastException if the type of the specified element * is incompatible with this deque * (optional) diff -r 4bd51f6268f4 src/share/classes/java/util/Queue.java --- a/src/share/classes/java/util/Queue.java Wed Jul 24 10:57:02 2013 +0200 +++ b/src/share/classes/java/util/Queue.java Thu Aug 01 11:24:48 2013 +0100 @@ -41,14 +41,15 @@ package java.util; * queues provide additional insertion, extraction, and inspection * operations. Each of these methods exists in two forms: one throws * an exception if the operation fails, the other returns a special - * value (either null or false, depending on the + * value (either {@code null} or {@code false}, depending on the * operation). The latter form of the insert operation is designed - * specifically for use with capacity-restricted Queue + * specifically for use with capacity-restricted {@code Queue} * implementations; in most implementations, insert operations cannot * fail. * *

*

Comparison of Stack and Deque methods
Stack Method Equivalent Deque Method Equivalent {@code Deque} Method
{@link #push push(e)}
+ * * * * @@ -56,18 +57,18 @@ package java.util; * * * - * - * + * + * * * * - * - * + * + * * * * - * - * + * + * * *
Summary of Queue methods
Throws exception
Insert{@link #add add(e)}{@link #offer offer(e)}{@link Queue#add add(e)}{@link Queue#offer offer(e)}
Remove{@link #remove remove()}{@link #poll poll()}{@link Queue#remove remove()}{@link Queue#poll poll()}
Examine{@link #element element()}{@link #peek peek()}{@link Queue#element element()}{@link Queue#peek peek()}
* @@ -79,15 +80,15 @@ package java.util; * Whatever the ordering used, the head of the queue is that * element which would be removed by a call to {@link #remove() } or * {@link #poll()}. In a FIFO queue, all new elements are inserted at - * the tail of the queue. Other kinds of queues may use - * different placement rules. Every Queue implementation + * the tail of the queue. Other kinds of queues may use + * different placement rules. Every {@code Queue} implementation * must specify its ordering properties. * *

The {@link #offer offer} method inserts an element if possible, - * otherwise returning false. This differs from the {@link + * otherwise returning {@code false}. This differs from the {@link * java.util.Collection#add Collection.add} method, which can fail to * add an element only by throwing an unchecked exception. The - * offer method is designed for use when failure is a normal, + * {@code offer} method is designed for use when failure is a normal, * rather than exceptional occurrence, for example, in fixed-capacity * (or "bounded") queues. * @@ -95,32 +96,32 @@ package java.util; * return the head of the queue. * Exactly which element is removed from the queue is a * function of the queue's ordering policy, which differs from - * implementation to implementation. The remove() and - * poll() methods differ only in their behavior when the - * queue is empty: the remove() method throws an exception, - * while the poll() method returns null. + * implementation to implementation. The {@code remove()} and + * {@code poll()} methods differ only in their behavior when the + * queue is empty: the {@code remove()} method throws an exception, + * while the {@code poll()} method returns {@code null}. * *

The {@link #element()} and {@link #peek()} methods return, but do * not remove, the head of the queue. * - *

The Queue interface does not define the blocking queue + *

The {@code Queue} interface does not define the blocking queue * methods, which are common in concurrent programming. These methods, * which wait for elements to appear or for space to become available, are * defined in the {@link java.util.concurrent.BlockingQueue} interface, which * extends this interface. * - *

Queue implementations generally do not allow insertion - * of null elements, although some implementations, such as - * {@link LinkedList}, do not prohibit insertion of null. - * Even in the implementations that permit it, null should - * not be inserted into a Queue, as null is also - * used as a special return value by the poll method to + *

{@code Queue} implementations generally do not allow insertion + * of {@code null} elements, although some implementations, such as + * {@link LinkedList}, do not prohibit insertion of {@code null}. + * Even in the implementations that permit it, {@code null} should + * not be inserted into a {@code Queue}, as {@code null} is also + * used as a special return value by the {@code poll} method to * indicate that the queue contains no elements. * - *

Queue implementations generally do not define - * element-based versions of methods equals and - * hashCode but instead inherit the identity based versions - * from class Object, because element-based equality is not + *

{@code Queue} implementations generally do not define + * element-based versions of methods {@code equals} and + * {@code hashCode} but instead inherit the identity based versions + * from class {@code Object}, because element-based equality is not * always well-defined for queues with the same elements but different * ordering properties. * @@ -145,11 +146,11 @@ public interface Queue extends Collec /** * Inserts the specified element into this queue if it is possible to do so * immediately without violating capacity restrictions, returning - * true upon success and throwing an IllegalStateException + * {@code true} upon success and throwing an {@code IllegalStateException} * if no space is currently available. * * @param e the element to add - * @return true (as specified by {@link Collection#add}) + * @return {@code true} (as specified by {@link Collection#add}) * @throws IllegalStateException if the element cannot be added at this * time due to capacity restrictions * @throws ClassCastException if the class of the specified element @@ -169,8 +170,8 @@ public interface Queue extends Collec * by throwing an exception. * * @param e the element to add - * @return true if the element was added to this queue, else - * false + * @return {@code true} if the element was added to this queue, else + * {@code false} * @throws ClassCastException if the class of the specified element * prevents it from being added to this queue * @throws NullPointerException if the specified element is null and @@ -192,9 +193,9 @@ public interface Queue extends Collec /** * Retrieves and removes the head of this queue, - * or returns null if this queue is empty. + * or returns {@code null} if this queue is empty. * - * @return the head of this queue, or null if this queue is empty + * @return the head of this queue, or {@code null} if this queue is empty */ E poll(); @@ -210,9 +211,9 @@ public interface Queue extends Collec /** * Retrieves, but does not remove, the head of this queue, - * or returns null if this queue is empty. + * or returns {@code null} if this queue is empty. * - * @return the head of this queue, or null if this queue is empty + * @return the head of this queue, or {@code null} if this queue is empty */ E peek(); } -Chris. From chris.hegarty at oracle.com Thu Aug 1 11:38:33 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 01 Aug 2013 11:38:33 +0000 Subject: hg: jdk8/tl/jdk: 8022061: More ProblemList.txt updates (7/2013) Message-ID: <20130801113906.30C9B484F7@hg.openjdk.java.net> Changeset: c49b538ef054 Author: chegar Date: 2013-08-01 12:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c49b538ef054 8022061: More ProblemList.txt updates (7/2013) Reviewed-by: alanb, psandoz ! test/ProblemList.txt From bugeaud at gmail.com Thu Aug 1 12:28:19 2013 From: bugeaud at gmail.com (Jean-Baptiste Bugeaud) Date: Thu, 1 Aug 2013 14:28:19 +0200 Subject: FunctionalInterface as a rule in the matching interfaces ? Message-ID: Hello, As a follow-up from Joe Darcy's proposal (2013-02-06) to add @FunctionalInterface to some interfaces matching the requirements of FI. I propose that this improvement is applied to all the VM Java libs. Doing a quick search, I've found some interfaces are not tagged as FunctionaInterfaces but clearly look good candidates : Here is the list of public API I have found so far : java.security.PriviledgeAction java.awt.event.ActionListener java.lang.util.concurrent.Callable java.util.Formattable javax.management.remote.JMXAddressable javax.naming.Referenceable java.awt.print.Printable Private packages also have some : sun.nio.ch.Cancelable sun.nio.ch.Groupable sun.net.www.http.Hurryable sun.misc.Timeable sun.awt.image.ImageFetchable sun.jvm.hotspot.utilities.soql.Callable com.sun.jdi.Locatable Tier lib used/derivated are also impacted (just FYI as it might be out of scope of OpenJDK) : com.sun.xml.internal.ws.api.config.management.Reconfigurable com.sun.xml.internal.ws.api.config.management com.sun.corba.se.spi.ior.MakeImmutable jdk.internal.org.objectweb.asm.util.ASMifiable jdk.internal.org.objectweb.asm.util.Textifiable Some interfaces got two methods 1 "functional like" and 1 getter. I propose to put the getter with a default and let the function unimplemented so matching with the lambda. Hence, the changes should be : javax.security.auth.Destroyable : remove the default from destroy() javax.security.auth.Refreshable : add a default to false to isCurrent() javax.script.Compilable : add a default to the version with String parameter (or the Reader version ?) java.nio.file.Watchable : add a default on the method without modifiers calling the method with modifiers but with empty array javax.accessibility.AccessibleStreamable : add a default version to getMimeTypes() returning a default raw byte stream mime type like application/octet-stream for instance sun.awt.SubRegionShowable : add a default to showIfNotLost() More complex cases exists like : java.lang.Appendable, lot of methods but for the same semantics, should we provide defaults for variants and make it @FI ? java.lang.Cloneable : clearly here it would be nice to get a defaulted clone() as it will improve/ease the clonable semantics (implementing Clonable will bring the default requirement). Here I am assuming there is no side effect of droping cases where you declare Clonable but did not implement clone(). Is it so ? Please forgive my post if this suggestion has not already been debatted but I neither found it in the ML search on GG nor in the hg revs. Also, please not that if the idea is followed, we should performe a more comprehensive search, as mine is only done starting on all "*able.java" files at this time. Best Regards, JB (bjb at dev.java.net) From dmitry.degrave at oracle.com Thu Aug 1 12:59:17 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Thu, 01 Aug 2013 12:59:17 +0000 Subject: hg: jdk8/tl/corba: 8015987: The corba repo contains unneeded .sjava files Message-ID: <20130801125918.9222C48507@hg.openjdk.java.net> Changeset: cc11a0efb4f9 Author: aefimov Date: 2013-08-01 14:59 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cc11a0efb4f9 8015987: The corba repo contains unneeded .sjava files Reviewed-by: alanb, chegar, coffeys - src/share/classes/com/sun/corba/se/impl/copyobject/JavaInputStream.sjava - src/share/classes/com/sun/corba/se/impl/copyobject/JavaOutputStream.sjava - src/share/classes/com/sun/corba/se/impl/interceptors/ThreadCurrentStack.sjava - src/share/classes/com/sun/corba/se/impl/orbutil/DefineWrapper.sjava - src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl_save.sjava - src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLTypesUtil_save.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientRequestImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientResponseImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerRequestImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerResponseImpl.sjava - src/share/classes/com/sun/corba/se/impl/transport/BufferConnectionImpl.sjava From dalibor.topic at oracle.com Thu Aug 1 13:01:56 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 01 Aug 2013 15:01:56 +0200 Subject: Classes on the stack trace In-Reply-To: References: <51F7191C.9000909@oracle.com> <51F7221C.8080302@redhat.com> <51F741B1.7020008@oracle.com> <51F7481B.1080903@oracle.com> <4C7F7BA9-F099-49BE-BC1D-C7ADD0F4850A@nicholaswilliams.net> Message-ID: <51FA5C44.5000103@oracle.com> On 7/30/13 2:01 PM, J?rn Huxhorn wrote: > See http://code.ohloh.net/search?s=Reflection.getCallerClass for a rough estimate about the impact of this change. Eh, no. Try http://code.ohloh.net/search?s=%22Reflection.getCallerClass%28%22&pp=0&fl=Java&ff=1&mp=1&ml=1&me=1&md=1&filterChecked=true instead. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From nicholas+openjdk at nicholaswilliams.net Thu Aug 1 13:58:51 2013 From: nicholas+openjdk at nicholaswilliams.net (Nick Williams) Date: Thu, 1 Aug 2013 08:58:51 -0500 Subject: Classes on the stack trace In-Reply-To: <51FA5C44.5000103@oracle.com> References: <51F7191C.9000909@oracle.com> <51F7221C.8080302@redhat.com> <51F741B1.7020008@oracle.com> <51F7481B.1080903@oracle.com> <4C7F7BA9-F099-49BE-BC1D-C7ADD0F4850A@nicholaswilliams.net> <51FA5C44.5000103@oracle.com> Message-ID: <9111E9F8-8E54-41F4-AC75-9842E0310876@nicholaswilliams.net> On Aug 1, 2013, at 8:01 AM, Dalibor Topic wrote: > On 7/30/13 2:01 PM, J?rn Huxhorn wrote: >> See http://code.ohloh.net/search?s=Reflection.getCallerClass for a rough estimate about the impact of this change. > > Eh, no. Try > http://code.ohloh.net/search?s=%22Reflection.getCallerClass%28%22&pp=0&fl=Java&ff=1&mp=1&ml=1&me=1&md=1&filterChecked=true > instead. I think the number is probably somewhere in between these two (I'm not sure where). Dalibor's filter appears to exclude uses via reflection (Class.forName("sun.reflect.Reflection"), c.getMethod("getCallerClass")). Nick From dalibor.topic at oracle.com Thu Aug 1 14:16:18 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 01 Aug 2013 16:16:18 +0200 Subject: Classes on the stack trace In-Reply-To: <9111E9F8-8E54-41F4-AC75-9842E0310876@nicholaswilliams.net> References: <51F7191C.9000909@oracle.com> <51F7221C.8080302@redhat.com> <51F741B1.7020008@oracle.com> <51F7481B.1080903@oracle.com> <4C7F7BA9-F099-49BE-BC1D-C7ADD0F4850A@nicholaswilliams.net> <51FA5C44.5000103@oracle.com> <9111E9F8-8E54-41F4-AC75-9842E0310876@nicholaswilliams.net> Message-ID: <51FA6DB2.5090803@oracle.com> On 8/1/13 3:58 PM, Nick Williams wrote: > > On Aug 1, 2013, at 8:01 AM, Dalibor Topic wrote: > >> On 7/30/13 2:01 PM, J?rn Huxhorn wrote: >>> See http://code.ohloh.net/search?s=Reflection.getCallerClass for a rough estimate about the impact of this change. >> >> Eh, no. Try >> http://code.ohloh.net/search?s=%22Reflection.getCallerClass%28%22&pp=0&fl=Java&ff=1&mp=1&ml=1&me=1&md=1&filterChecked=true >> instead. > > I think the number is probably somewhere in between these two (I'm not sure where). Dalibor's filter appears to exclude uses via reflection (Class.forName("sun.reflect.Reflection"), c.getMethod("getCallerClass")). > Yep. Searching for the names individually gives a slightly higher number (and covers reflection use as mentioned above): http://code.ohloh.net/search?s=%22Reflection%22%20%22getCallerClass%22%20%22sun.reflect%22&pp=0&fl=Java&ff=1&mp=0&ml=1&me=1&md=1&filterChecked=true cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From dmitry.degrave at oracle.com Thu Aug 1 14:20:44 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Thu, 01 Aug 2013 14:20:44 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130801142116.CDC4A4850C@hg.openjdk.java.net> Changeset: 36f4cf8872f3 Author: igerasim Date: 2013-07-30 21:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/36f4cf8872f3 7192942: (coll) Inefficient calculation of power of two in HashMap Reviewed-by: mduigou ! src/share/classes/java/util/HashMap.java Changeset: 54329c24c2f4 Author: igerasim Date: 2013-07-29 12:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/54329c24c2f4 8020669: (fs) Files.readAllBytes() does not read any data when Files.size() is 0 Reviewed-by: alanb, chegar, martin, rriggs ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/BytesAndLines.java From xuelei.fan at oracle.com Thu Aug 1 14:35:37 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Thu, 01 Aug 2013 14:35:37 +0000 Subject: hg: jdk8/tl/jdk: 7127524: P11TlsPrfGenerator has anonymous inner class with serialVersionUID Message-ID: <20130801143551.326ED4850E@hg.openjdk.java.net> Changeset: d6de149b9f20 Author: xuelei Date: 2013-08-01 07:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d6de149b9f20 7127524: P11TlsPrfGenerator has anonymous inner class with serialVersionUID Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java From joe.darcy at oracle.com Thu Aug 1 14:39:56 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 01 Aug 2013 07:39:56 -0700 Subject: RFR doclint issues in j.u.Deque & Queue In-Reply-To: <51FA39D0.1060309@oracle.com> References: <51FA39D0.1060309@oracle.com> Message-ID: <51FA733C.1050906@oracle.com> Hi Chris, All the changes look good. Thanks, -Joe On 08/01/2013 03:34 AM, Chris Hegarty wrote: > These changes are already committed in the jsr166 CVS, this is a > request to pull them into jdk8. > > Specdiff has been run, and there is nothing surprising. > The doclint issues are specifically around the addition of a caption > to the tables, the remaining changes are cleanup, -> {@code > ..}, etc. > > Note: there are some minor doc updates around throwing an > IllegalStateException if no space is currently available in Deque, > which is already part of the spec. > > Martin, Doug, > The 166 CVS is trivially missing 6546713, > > http://cr.openjdk.java.net/~mduigou/6546713/0/webrev/src/share/classes/java/util/Deque.java.sdiff.html. > Once the changes below are in jdk8, you can easily sync with the 8 > version, or apply the diffs from the webrev link above. > > I have already reviewed these changes, but more reviewers are welcome. > > From zhong.j.yu at gmail.com Thu Aug 1 15:14:04 2013 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Thu, 1 Aug 2013 10:14:04 -0500 Subject: FunctionalInterface as a rule in the matching interfaces ? In-Reply-To: References: Message-ID: Some of these don't feel like "functions", e.g. Formattable, it's unlikely that anyone would use lambda expression to instantiate them. What is the general guideline to apply @FunctionalInterface? For example, why should AutoCloseable be marked as @FI? Zhong Yu On Thu, Aug 1, 2013 at 7:28 AM, Jean-Baptiste Bugeaud wrote: > Hello, > > As a follow-up from Joe Darcy's proposal (2013-02-06) to add > @FunctionalInterface to some interfaces matching the requirements of > FI. > > I propose that this improvement is applied to all the VM Java libs. > > Doing a quick search, I've found some interfaces are not tagged as > FunctionaInterfaces but clearly look good candidates : > > Here is the list of public API I have found so far : > > java.security.PriviledgeAction > java.awt.event.ActionListener > java.lang.util.concurrent.Callable > java.util.Formattable > javax.management.remote.JMXAddressable > javax.naming.Referenceable > java.awt.print.Printable > > Private packages also have some : > > sun.nio.ch.Cancelable > sun.nio.ch.Groupable > sun.net.www.http.Hurryable > sun.misc.Timeable > sun.awt.image.ImageFetchable > sun.jvm.hotspot.utilities.soql.Callable > com.sun.jdi.Locatable > > Tier lib used/derivated are also impacted (just FYI as it might be out > of scope of OpenJDK) : > > com.sun.xml.internal.ws.api.config.management.Reconfigurable > com.sun.xml.internal.ws.api.config.management > com.sun.corba.se.spi.ior.MakeImmutable > jdk.internal.org.objectweb.asm.util.ASMifiable > jdk.internal.org.objectweb.asm.util.Textifiable > > Some interfaces got two methods 1 "functional like" and 1 getter. > > I propose to put the getter with a default and let the function > unimplemented so matching with the lambda. > > Hence, the changes should be : > javax.security.auth.Destroyable : remove the default from destroy() > javax.security.auth.Refreshable : add a default to false to isCurrent() > javax.script.Compilable : add a default to the version with String > parameter (or the Reader version ?) > > java.nio.file.Watchable : add a default on the method without > modifiers calling the method with modifiers but with empty array > > javax.accessibility.AccessibleStreamable : add a default version to > getMimeTypes() returning a default raw byte stream mime type like > application/octet-stream for instance > > sun.awt.SubRegionShowable : add a default to showIfNotLost() > > More complex cases exists like : > > java.lang.Appendable, lot of methods but for the same semantics, > should we provide defaults for variants and make it @FI ? > > java.lang.Cloneable : clearly here it would be nice to get a defaulted > clone() as it will improve/ease the clonable semantics (implementing > Clonable will bring the default requirement). Here I am assuming there > is no side effect of droping cases where you declare Clonable but did > not implement clone(). Is it so ? > > Please forgive my post if this suggestion has not already been > debatted but I neither found it in the ML search on GG nor in the hg > revs. > Also, please not that if the idea is followed, we should performe a > more comprehensive search, as mine is only done starting on all > "*able.java" files at this time. > > Best Regards, > JB (bjb at dev.java.net) From paul.sandoz at oracle.com Thu Aug 1 15:32:06 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 1 Aug 2013 16:32:06 +0100 Subject: RFR 8020016 Numerous splitereator impls do not throw NPE for null Consumers Message-ID: <7ABB30F0-853F-4762-BE52-E60F2515C696@oracle.com> Hi, This patch fixes numerous spliterators that do not throw NPEs for null consumers: http://cr.openjdk.java.net/~psandoz/tl/JDK-8020016-spltr-traverse-npe/webrev/ Paul. From henry.jen at oracle.com Thu Aug 1 15:45:50 2013 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 1 Aug 2013 08:45:50 -0700 Subject: RFR 8020016 Numerous splitereator impls do not throw NPE for null Consumers In-Reply-To: <7ABB30F0-853F-4762-BE52-E60F2515C696@oracle.com> References: <7ABB30F0-853F-4762-BE52-E60F2515C696@oracle.com> Message-ID: <51429852-3F0F-429E-B6A8-4EAD1FC361B6@oracle.com> In StremSpliterator:366, I assume the NULL check should be before if. There are a couple if { } else if and try { } catch Isn't the style recommended to be on the same line? Cheers, Henry On Aug 1, 2013, at 8:32 AM, Paul Sandoz wrote: > Hi, > > This patch fixes numerous spliterators that do not throw NPEs for null consumers: > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8020016-spltr-traverse-npe/webrev/ > > Paul. From paul.sandoz at oracle.com Thu Aug 1 15:49:42 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 1 Aug 2013 16:49:42 +0100 Subject: RFR 8020016 Numerous splitereator impls do not throw NPE for null Consumers In-Reply-To: <51429852-3F0F-429E-B6A8-4EAD1FC361B6@oracle.com> References: <7ABB30F0-853F-4762-BE52-E60F2515C696@oracle.com> <51429852-3F0F-429E-B6A8-4EAD1FC361B6@oracle.com> Message-ID: <9AA438B4-70EE-4BF8-8D01-DBF94CE94A4D@oracle.com> On Aug 1, 2013, at 4:45 PM, Henry Jen wrote: > In StremSpliterator:366, I assume the NULL check should be before if. > It saves a redundant check if the wrapping spliterator uses buffering, since the tryAdvance will also check: public void forEachRemaining(IntConsumer consumer) { if (buffer == null && !finished) { Objects.requireNonNull(consumer); init(); ph.wrapAndCopyInto((Sink.OfInt) consumer::accept, spliterator); finished = true; } else { do { } while (tryAdvance(consumer)); } } > There are a couple > > if { > } > else if > > and > > try { > } > catch > > Isn't the style recommended to be on the same line? > Depends who you talk to :-) It's a style that is used in much of the stream implementation. Paul. From chris.hegarty at oracle.com Thu Aug 1 15:54:13 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 01 Aug 2013 15:54:13 +0000 Subject: hg: jdk8/tl/jdk: 8022087: Fix doclint issues in j.u.Deque & Queue Message-ID: <20130801155429.B1FE048510@hg.openjdk.java.net> Changeset: cd13a4a45a37 Author: chegar Date: 2013-08-01 16:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd13a4a45a37 8022087: Fix doclint issues in j.u.Deque & Queue Reviewed-by: chegar, darcy Contributed-by: Doug Lea

! src/share/classes/java/util/Deque.java ! src/share/classes/java/util/Queue.java From Alan.Bateman at oracle.com Thu Aug 1 15:57:56 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 01 Aug 2013 08:57:56 -0700 Subject: RFR: 8021591 : (s) Additional explicit null checks In-Reply-To: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com> References: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com> Message-ID: <51FA8584.1000702@oracle.com> On 26/07/2013 16:31, Mike Duigou wrote: > Hello all; > > This patch adds some missing checks for null that, according to interface contract, should be throwing NPE. It also improves the existing tests to check for these cases. > > http://cr.openjdk.java.net/~mduigou/JDK-8021591/0/webrev/ > > The changes to src/share/classes/java/util/concurrent/ConcurrentHashMap.java will be synchronized separately with the jsr166 workspace. They are part of this review to avoid test failures. > > Mike As retainAll and removeAll are long standing methods, are there are cases where we might now throw NPE when we didn't previously? I'm just wondering if any of these need to be looked at more closely, minimally to get into release/compatibility notes. -Alan From alexey.utkin at oracle.com Thu Aug 1 16:06:15 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Thu, 01 Aug 2013 20:06:15 +0400 Subject: Review request: JDK-8020191 System.getProperty( " os.name " ) returns " Windows NT (unknown) " on Windows 8.1 (v.1) In-Reply-To: References: <51F908CA.1070502@oracle.com> <51F91BE7.70403@oracle.com> Message-ID: <51FA8777.3050902@oracle.com> I did the Windows 8.1 Preview installation and faced with the same problem as described in the article: http://social.msdn.microsoft.com/forums/windowsazure/zh-tw/c471de52-611f-435d-ab44-56064e5fd7d5/windows-81-preview-getversionex-reports-629200 To fix the problem, java executable modules need to upgrade the manifest. That is in new fix version http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8020191/webrev.01/ The bug https://jbs.oracle.com/bugs/browse/JDK-8020191 contains the attachment with screen shot proof. Regards, -uta On 7/31/2013 7:14 PM, Kurchi Subhra Hazra wrote: > Changes look good to me (once Alan's point is verified). > > Thanks, > > - Kurchi > > > > On Wed, Jul 31, 2013 at 7:15 AM, Alan Bateman > wrote: > > > The changes in the webrev look okay to me but the reference to the > "app compatibility shim" in the MS article is a bit confusing and > not clear to me (with checking into it more) whether this might > consider java.exe as something that isn't targeted to Windows 8.1. > So can you verify that you have checked it on the latest 8.1 preview? > > As regards the helper library then this could be useful in the > future (for now then it probably complicates things because the > JDK still has to run on older versions of Windows). > > -Alan. > > > > On 31/07/2013 05:53, Alexey Utkin wrote: > > Bug description: > https://jbs.oracle.com/bugs/browse/JDK-8020191 > http://bugs.sun.com/view_bug.do?bug_id=8020191 > > Here is the suggested fix: > http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8020191/webrev.00/ > > > Summary: > We need to be consistent with the rest of OS, so I extend the > case for 6.3 internal version number by values "Windows 8.1" > for workstation OS, and "Windows Server 2012 R2" for server OS. > (http://msdn.microsoft.com/en-us/library/windows/desktop/dn302074.aspx) > > But we get a chance to have a wrong OS name due to MS > compatibility problems. > > Here is the problem description: > > http://social.msdn.microsoft.com/forums/windowsazure/zh-tw/c471de52-611f-435d-ab44-56064e5fd7d5/windows-81-preview-getversionex-reports-629200 > > > and MS respond: > http://msdn.microsoft.com/en-us/library/windows/desktop/dn302074.aspx > > Quotations: > "In Windows 8.1 Preview, we have introduced a new API, > Versionhelpers API, that deprecates the need for using > GetVersion(Ex) APIs. This addresses difficulties in > interpreting the numerical value returned by the > GetVersion(Ex) APIs." > > "The internal version number for Windows 8.1 Preview and > Windows Server 2012 R2 Preview is 6.3. Only apps that are > targeting Windows 8.1 will receive a return value of 6.3. > Those apps that are not targeted for Windows 8.1 will receive > a return value of 6.2 unless previously shimmed as discussed > below." > > > Regards, > -uta > > > From henry.jen at oracle.com Thu Aug 1 16:33:33 2013 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 1 Aug 2013 09:33:33 -0700 Subject: RFR 8020016 Numerous splitereator impls do not throw NPE for null Consumers In-Reply-To: <9AA438B4-70EE-4BF8-8D01-DBF94CE94A4D@oracle.com> References: <7ABB30F0-853F-4762-BE52-E60F2515C696@oracle.com> <51429852-3F0F-429E-B6A8-4EAD1FC361B6@oracle.com> <9AA438B4-70EE-4BF8-8D01-DBF94CE94A4D@oracle.com> Message-ID: <4B3BA4BE-F246-468C-965A-30B60BC59F69@oracle.com> I see, thanks. Looks good to me. Cheers, Henry On Aug 1, 2013, at 8:49 AM, Paul Sandoz wrote: > On Aug 1, 2013, at 4:45 PM, Henry Jen wrote: >> In StremSpliterator:366, I assume the NULL check should be before if. >> > > It saves a redundant check if the wrapping spliterator uses buffering, since the tryAdvance will also check: > > public void forEachRemaining(IntConsumer consumer) { > if (buffer == null && !finished) { > Objects.requireNonNull(consumer); > init(); > > ph.wrapAndCopyInto((Sink.OfInt) consumer::accept, spliterator); > finished = true; > } > else { > do { } while (tryAdvance(consumer)); > } > } > > >> There are a couple >> >> if { >> } >> else if >> >> and >> >> try { >> } >> catch >> >> Isn't the style recommended to be on the same line? >> > > Depends who you talk to :-) It's a style that is used in much of the stream implementation. > > Paul. From Alan.Bateman at oracle.com Thu Aug 1 16:34:59 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 01 Aug 2013 09:34:59 -0700 Subject: Review request: JDK-8020191 System.getProperty( " os.name " ) returns " Windows NT (unknown) " on Windows 8.1 (v.1) In-Reply-To: <51FA8777.3050902@oracle.com> References: <51F908CA.1070502@oracle.com> <51F91BE7.70403@oracle.com> <51FA8777.3050902@oracle.com> Message-ID: <51FA8E33.1030906@oracle.com> On 01/08/2013 09:06, Alexey Utkin wrote: > I did the Windows 8.1 Preview installation and faced with the same > problem as described in the article: > http://social.msdn.microsoft.com/forums/windowsazure/zh-tw/c471de52-611f-435d-ab44-56064e5fd7d5/windows-81-preview-getversionex-reports-629200 > > > To fix the problem, java executable modules need to upgrade the manifest. > That is in new fix version > http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8020191/webrev.01/ > > The bug > https://jbs.oracle.com/bugs/browse/JDK-8020191 > contains the attachment with screen shot proof. Thanks for doing the manifest, the updated webrev looks good to me. -Alan. From martinrb at google.com Thu Aug 1 16:34:42 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 1 Aug 2013 09:34:42 -0700 Subject: RFR: 8021591 : (s) Additional explicit null checks In-Reply-To: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com> References: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com> Message-ID: Overall, I hate these kinds of changes to be super-pedantically correct, at the cost of a small performance loss and a small compatibility hit. I resisted doing them when I was maintaining these classes. So there's an edge case where an NPE isn't thrown - who cares? Are there users asking for this? On Fri, Jul 26, 2013 at 4:31 PM, Mike Duigou wrote: > Hello all; > > This patch adds some missing checks for null that, according to interface > contract, should be throwing NPE. It also improves the existing tests to > check for these cases. > > http://cr.openjdk.java.net/~mduigou/JDK-8021591/0/webrev/ > > The changes to > src/share/classes/java/util/concurrent/ConcurrentHashMap.java will be > synchronized separately with the jsr166 workspace. They are part of this > review to avoid test failures. > > Mike From mike.duigou at oracle.com Thu Aug 1 17:15:46 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 1 Aug 2013 10:15:46 -0700 Subject: RFR: 8021591 : (s) Additional explicit null checks In-Reply-To: References: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com> Message-ID: <06EAEBEF-5DEB-499F-8ACA-644EBFCB5799@oracle.com> On Aug 1 2013, at 09:34 , Martin Buchholz wrote: > Overall, I hate these kinds of changes to be super-pedantically correct, at the cost of a small performance loss and a small compatibility hit. I resisted doing them when I was maintaining these classes. So there's an edge case where an NPE isn't thrown - who cares? The problem comes up when moving between interface implementations. The problem in removeAll/retainAll is that we have a diversity of behaviours in implementations with some throwing the NPE and some not. The interface has always indicated that the NPE is thrown and while I agree that it's probably not very important if the NPE isn't thrown in singular cases the lack of consistency makes it harder to switch between implementations. This showed up in users switching from ArrayList (which didn't throw the NPE) to CopyOnWriteArrayList (which does since Java 7 throw the NPE). The goal here is to improve conformance to the interface not strictly for pedantry but to foster greater interoperability among implementations. > Are there users asking for this? As mentioned it has most frequently been expressed as a barrier to swapping implementations. There have been a few reports where we were chastised for failing to detect a user's error. "I know I shouldn't have been passing null but I was surprised that the method didn't signal an error." Mike > On Fri, Jul 26, 2013 at 4:31 PM, Mike Duigou wrote: > Hello all; > > This patch adds some missing checks for null that, according to interface contract, should be throwing NPE. It also improves the existing tests to check for these cases. > > http://cr.openjdk.java.net/~mduigou/JDK-8021591/0/webrev/ > > The changes to src/share/classes/java/util/concurrent/ConcurrentHashMap.java will be synchronized separately with the jsr166 workspace. They are part of this review to avoid test failures. > > Mike > From mike.duigou at oracle.com Thu Aug 1 17:29:32 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 1 Aug 2013 10:29:32 -0700 Subject: RFR 8020016 Numerous splitereator impls do not throw NPE for null Consumers In-Reply-To: <7ABB30F0-853F-4762-BE52-E60F2515C696@oracle.com> References: <7ABB30F0-853F-4762-BE52-E60F2515C696@oracle.com> Message-ID: <62E0C652-5456-4F30-AE16-1806EA1617BC@oracle.com> Looks OK to me with the clarifications in your response to Henry. Mike On Aug 1 2013, at 08:32 , Paul Sandoz wrote: > Hi, > > This patch fixes numerous spliterators that do not throw NPEs for null consumers: > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8020016-spltr-traverse-npe/webrev/ > > Paul. From mike.duigou at oracle.com Thu Aug 1 17:35:28 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 1 Aug 2013 10:35:28 -0700 Subject: RFR doclint issues in j.u.Deque & Queue In-Reply-To: <51FA39D0.1060309@oracle.com> References: <51FA39D0.1060309@oracle.com> Message-ID: Looks good to me. Thanks for incorporating the 6546713 changes. Can we also incorporate the changes in JDK-7178639: http://cr.openjdk.java.net/~mduigou/JDK-7178639/0/webrev/ into this changeset? It seems like an an opportune time. Mike On Aug 1 2013, at 03:34 , Chris Hegarty wrote: > These changes are already committed in the jsr166 CVS, this is a request to pull them into jdk8. > > Specdiff has been run, and there is nothing surprising. > The doclint issues are specifically around the addition of a caption to the tables, the remaining changes are cleanup, -> {@code ..}, etc. > > Note: there are some minor doc updates around throwing an IllegalStateException if no space is currently available in Deque, which is already part of the spec. > > Martin, Doug, > The 166 CVS is trivially missing 6546713, > http://cr.openjdk.java.net/~mduigou/6546713/0/webrev/src/share/classes/java/util/Deque.java.sdiff.html. Once the changes below are in jdk8, you can easily sync with the 8 version, or apply the diffs from the webrev link above. > > I have already reviewed these changes, but more reviewers are welcome. > > > diff -r 4bd51f6268f4 src/share/classes/java/util/Deque.java > --- a/src/share/classes/java/util/Deque.java Wed Jul 24 10:57:02 2013 +0200 > +++ b/src/share/classes/java/util/Deque.java Thu Aug 01 11:24:48 2013 +0100 > @@ -38,7 +38,7 @@ package java.util; > /** > * A linear collection that supports element insertion and removal at > * both ends. The name deque is short for "double ended queue" > - * and is usually pronounced "deck". Most Deque > + * and is usually pronounced "deck". Most {@code Deque} > * implementations place no fixed limits on the number of elements > * they may contain, but this interface supports capacity-restricted > * deques as well as those with no fixed size limit. > @@ -47,10 +47,10 @@ package java.util; > * ends of the deque. Methods are provided to insert, remove, and > * examine the element. Each of these methods exists in two forms: > * one throws an exception if the operation fails, the other returns a > - * special value (either null or false, depending on > + * special value (either {@code null} or {@code false}, depending on > * the operation). The latter form of the insert operation is > * designed specifically for use with capacity-restricted > - * Deque implementations; in most implementations, insert > + * {@code Deque} implementations; in most implementations, insert > * operations cannot fail. > * > *

The twelve methods described above are summarized in the > @@ -58,6 +58,7 @@ package java.util; > * > *

> * > + * > * > * > * > @@ -72,38 +73,39 @@ package java.util; > * > * > * > - * > - * > - * > - * > + * > + * > + * > + * > * > * > * > - * > - * > - * > - * > + * > + * > + * > + * > * > * > * > - * > - * > - * > - * > + * > + * > + * > + * > * > *
Summary of Deque methods
First Element (Head)
Insert{@link #addFirst addFirst(e)}{@link #offerFirst offerFirst(e)}{@link #addLast addLast(e)}{@link #offerLast offerLast(e)}{@link Deque#addFirst addFirst(e)}{@link Deque#offerFirst offerFirst(e)}{@link Deque#addLast addLast(e)}{@link Deque#offerLast offerLast(e)}
Remove{@link #removeFirst removeFirst()}{@link #pollFirst pollFirst()}{@link #removeLast removeLast()}{@link #pollLast pollLast()}{@link Deque#removeFirst removeFirst()}{@link Deque#pollFirst pollFirst()}{@link Deque#removeLast removeLast()}{@link Deque#pollLast pollLast()}
Examine{@link #getFirst getFirst()}{@link #peekFirst peekFirst()}{@link #getLast getLast()}{@link #peekLast peekLast()}{@link Deque#getFirst getFirst()}{@link Deque#peekFirst peekFirst()}{@link Deque#getLast getLast()}{@link Deque#peekLast peekLast()}
> * > *

This interface extends the {@link Queue} interface. When a deque is > * used as a queue, FIFO (First-In-First-Out) behavior results. Elements are > * added at the end of the deque and removed from the beginning. The methods > - * inherited from the Queue interface are precisely equivalent to > - * Deque methods as indicated in the following table: > + * inherited from the {@code Queue} interface are precisely equivalent to > + * {@code Deque} methods as indicated in the following table: > * > *

> * > + * > * > - * > - * > + * > + * > * > * > * > @@ -135,13 +137,14 @@ package java.util; > * interface should be used in preference to the legacy {@link Stack} class. > * When a deque is used as a stack, elements are pushed and popped from the > * beginning of the deque. Stack methods are precisely equivalent to > - * Deque methods as indicated in the table below: > + * {@code Deque} methods as indicated in the table below: > * > *

> *

Comparison of Queue and Deque methods
Queue Method Equivalent Deque Method {@code Queue} Method Equivalent {@code Deque} Method
{@link java.util.Queue#add add(e)}
> + * > * > * > - * > + * > * > * > * > @@ -168,18 +171,18 @@ package java.util; > *

Unlike the {@link List} interface, this interface does not > * provide support for indexed access to elements. > * > - *

While Deque implementations are not strictly required > + *

While {@code Deque} implementations are not strictly required > * to prohibit the insertion of null elements, they are strongly > - * encouraged to do so. Users of any Deque implementations > + * encouraged to do so. Users of any {@code Deque} implementations > * that do allow null elements are strongly encouraged not to > * take advantage of the ability to insert nulls. This is so because > - * null is used as a special return value by various methods > + * {@code null} is used as a special return value by various methods > * to indicated that the deque is empty. > * > - *

Deque implementations generally do not define > - * element-based versions of the equals and hashCode > + *

{@code Deque} implementations generally do not define > + * element-based versions of the {@code equals} and {@code hashCode} > * methods, but instead inherit the identity-based versions from class > - * Object. > + * {@code Object}. > * > *

This interface is a member of the * href="{@docRoot}/../technotes/guides/collections/index.html"> Java Collections > @@ -190,13 +193,13 @@ package java.util; > * @since 1.6 > * @param the type of elements held in this collection > */ > - > public interface Deque extends Queue { > /** > * Inserts the specified element at the front of this deque if it is > - * possible to do so immediately without violating capacity restrictions. > - * When using a capacity-restricted deque, it is generally preferable to > - * use method {@link #offerFirst}. > + * possible to do so immediately without violating capacity restrictions, > + * throwing an {@code IllegalStateException} if no space is currently > + * available. When using a capacity-restricted deque, it is generally > + * preferable to use method {@link #offerFirst}. > * > * @param e the element to add > * @throws IllegalStateException if the element cannot be added at this > @@ -212,9 +215,10 @@ public interface Deque extends Queue< > > /** > * Inserts the specified element at the end of this deque if it is > - * possible to do so immediately without violating capacity restrictions. > - * When using a capacity-restricted deque, it is generally preferable to > - * use method {@link #offerLast}. > + * possible to do so immediately without violating capacity restrictions, > + * throwing an {@code IllegalStateException} if no space is currently > + * available. When using a capacity-restricted deque, it is generally > + * preferable to use method {@link #offerLast}. > * > *

This method is equivalent to {@link #add}. > * > @@ -237,8 +241,8 @@ public interface Deque extends Queue< > * which can fail to insert an element only by throwing an exception. > * > * @param e the element to add > - * @return true if the element was added to this deque, else > - * false > + * @return {@code true} if the element was added to this deque, else > + * {@code false} > * @throws ClassCastException if the class of the specified element > * prevents it from being added to this deque > * @throws NullPointerException if the specified element is null and this > @@ -255,8 +259,8 @@ public interface Deque extends Queue< > * which can fail to insert an element only by throwing an exception. > * > * @param e the element to add > - * @return true if the element was added to this deque, else > - * false > + * @return {@code true} if the element was added to this deque, else > + * {@code false} > * @throws ClassCastException if the class of the specified element > * prevents it from being added to this deque > * @throws NullPointerException if the specified element is null and this > @@ -288,17 +292,17 @@ public interface Deque extends Queue< > > /** > * Retrieves and removes the first element of this deque, > - * or returns null if this deque is empty. > + * or returns {@code null} if this deque is empty. > * > - * @return the head of this deque, or null if this deque is empty > + * @return the head of this deque, or {@code null} if this deque is empty > */ > E pollFirst(); > > /** > * Retrieves and removes the last element of this deque, > - * or returns null if this deque is empty. > + * or returns {@code null} if this deque is empty. > * > - * @return the tail of this deque, or null if this deque is empty > + * @return the tail of this deque, or {@code null} if this deque is empty > */ > E pollLast(); > > @@ -325,31 +329,31 @@ public interface Deque extends Queue< > > /** > * Retrieves, but does not remove, the first element of this deque, > - * or returns null if this deque is empty. > + * or returns {@code null} if this deque is empty. > * > - * @return the head of this deque, or null if this deque is empty > + * @return the head of this deque, or {@code null} if this deque is empty > */ > E peekFirst(); > > /** > * Retrieves, but does not remove, the last element of this deque, > - * or returns null if this deque is empty. > + * or returns {@code null} if this deque is empty. > * > - * @return the tail of this deque, or null if this deque is empty > + * @return the tail of this deque, or {@code null} if this deque is empty > */ > E peekLast(); > > /** > * Removes the first occurrence of the specified element from this deque. > * If the deque does not contain the element, it is unchanged. > - * More formally, removes the first element e such that > + * More formally, removes the first element {@code e} such that > * (o==null ? e==null : o.equals(e)) > * (if such an element exists). > - * Returns true if this deque contained the specified element > + * Returns {@code true} if this deque contained the specified element > * (or equivalently, if this deque changed as a result of the call). > * > * @param o element to be removed from this deque, if present > - * @return true if an element was removed as a result of this call > + * @return {@code true} if an element was removed as a result of this call > * @throws ClassCastException if the class of the specified element > * is incompatible with this deque > * (optional) > @@ -362,14 +366,14 @@ public interface Deque extends Queue< > /** > * Removes the last occurrence of the specified element from this deque. > * If the deque does not contain the element, it is unchanged. > - * More formally, removes the last element e such that > + * More formally, removes the last element {@code e} such that > * (o==null ? e==null : o.equals(e)) > * (if such an element exists). > - * Returns true if this deque contained the specified element > + * Returns {@code true} if this deque contained the specified element > * (or equivalently, if this deque changed as a result of the call). > * > * @param o element to be removed from this deque, if present > - * @return true if an element was removed as a result of this call > + * @return {@code true} if an element was removed as a result of this call > * @throws ClassCastException if the class of the specified element > * is incompatible with this deque > * (optional) > @@ -385,15 +389,15 @@ public interface Deque extends Queue< > * Inserts the specified element into the queue represented by this deque > * (in other words, at the tail of this deque) if it is possible to do so > * immediately without violating capacity restrictions, returning > - * true upon success and throwing an > - * IllegalStateException if no space is currently available. > + * {@code true} upon success and throwing an > + * {@code IllegalStateException} if no space is currently available. > * When using a capacity-restricted deque, it is generally preferable to > * use {@link #offer(Object) offer}. > * > *

This method is equivalent to {@link #addLast}. > * > * @param e the element to add > - * @return true (as specified by {@link Collection#add}) > + * @return {@code true} (as specified by {@link Collection#add}) > * @throws IllegalStateException if the element cannot be added at this > * time due to capacity restrictions > * @throws ClassCastException if the class of the specified element > @@ -409,7 +413,7 @@ public interface Deque extends Queue< > * Inserts the specified element into the queue represented by this deque > * (in other words, at the tail of this deque) if it is possible to do so > * immediately without violating capacity restrictions, returning > - * true upon success and false if no space is currently > + * {@code true} upon success and {@code false} if no space is currently > * available. When using a capacity-restricted deque, this method is > * generally preferable to the {@link #add} method, which can fail to > * insert an element only by throwing an exception. > @@ -417,8 +421,8 @@ public interface Deque extends Queue< > *

This method is equivalent to {@link #offerLast}. > * > * @param e the element to add > - * @return true if the element was added to this deque, else > - * false > + * @return {@code true} if the element was added to this deque, else > + * {@code false} > * @throws ClassCastException if the class of the specified element > * prevents it from being added to this deque > * @throws NullPointerException if the specified element is null and this > @@ -444,11 +448,11 @@ public interface Deque extends Queue< > /** > * Retrieves and removes the head of the queue represented by this deque > * (in other words, the first element of this deque), or returns > - * null if this deque is empty. > + * {@code null} if this deque is empty. > * > *

This method is equivalent to {@link #pollFirst()}. > * > - * @return the first element of this deque, or null if > + * @return the first element of this deque, or {@code null} if > * this deque is empty > */ > E poll(); > @@ -469,12 +473,12 @@ public interface Deque extends Queue< > /** > * Retrieves, but does not remove, the head of the queue represented by > * this deque (in other words, the first element of this deque), or > - * returns null if this deque is empty. > + * returns {@code null} if this deque is empty. > * > *

This method is equivalent to {@link #peekFirst()}. > * > * @return the head of the queue represented by this deque, or > - * null if this deque is empty > + * {@code null} if this deque is empty > */ > E peek(); > > @@ -484,9 +488,8 @@ public interface Deque extends Queue< > /** > * Pushes an element onto the stack represented by this deque (in other > * words, at the head of this deque) if it is possible to do so > - * immediately without violating capacity restrictions, returning > - * true upon success and throwing an > - * IllegalStateException if no space is currently available. > + * immediately without violating capacity restrictions, throwing an > + * {@code IllegalStateException} if no space is currently available. > * > *

This method is equivalent to {@link #addFirst}. > * > @@ -520,16 +523,16 @@ public interface Deque extends Queue< > /** > * Removes the first occurrence of the specified element from this deque. > * If the deque does not contain the element, it is unchanged. > - * More formally, removes the first element e such that > + * More formally, removes the first element {@code e} such that > * (o==null ? e==null : o.equals(e)) > * (if such an element exists). > - * Returns true if this deque contained the specified element > + * Returns {@code true} if this deque contained the specified element > * (or equivalently, if this deque changed as a result of the call). > * > - *

This method is equivalent to {@link #removeFirstOccurrence}. > + *

This method is equivalent to {@link #removeFirstOccurrence(Object)}. > * > * @param o element to be removed from this deque, if present > - * @return true if an element was removed as a result of this call > + * @return {@code true} if an element was removed as a result of this call > * @throws ClassCastException if the class of the specified element > * is incompatible with this deque > * (optional) > @@ -540,13 +543,13 @@ public interface Deque extends Queue< > boolean remove(Object o); > > /** > - * Returns true if this deque contains the specified element. > - * More formally, returns true if and only if this deque contains > - * at least one element e such that > + * Returns {@code true} if this deque contains the specified element. > + * More formally, returns {@code true} if and only if this deque contains > + * at least one element {@code e} such that > * (o==null ? e==null : o.equals(e)). > * > * @param o element whose presence in this deque is to be tested > - * @return true if this deque contains the specified element > + * @return {@code true} if this deque contains the specified element > * @throws ClassCastException if the type of the specified element > * is incompatible with this deque > * (optional) > diff -r 4bd51f6268f4 src/share/classes/java/util/Queue.java > --- a/src/share/classes/java/util/Queue.java Wed Jul 24 10:57:02 2013 +0200 > +++ b/src/share/classes/java/util/Queue.java Thu Aug 01 11:24:48 2013 +0100 > @@ -41,14 +41,15 @@ package java.util; > * queues provide additional insertion, extraction, and inspection > * operations. Each of these methods exists in two forms: one throws > * an exception if the operation fails, the other returns a special > - * value (either null or false, depending on the > + * value (either {@code null} or {@code false}, depending on the > * operation). The latter form of the insert operation is designed > - * specifically for use with capacity-restricted Queue > + * specifically for use with capacity-restricted {@code Queue} > * implementations; in most implementations, insert operations cannot > * fail. > * > *

> *

Comparison of Stack and Deque methods
Stack Method Equivalent Deque Method Equivalent {@code Deque} Method
{@link #push push(e)}
> + * > * > * > * > @@ -56,18 +57,18 @@ package java.util; > * > * > * > - * > - * > + * > + * > * > * > * > - * > - * > + * > + * > * > * > * > - * > - * > + * > + * > * > *
Summary of Queue methods
Throws exception
Insert{@link #add add(e)}{@link #offer offer(e)}{@link Queue#add add(e)}{@link Queue#offer offer(e)}
Remove{@link #remove remove()}{@link #poll poll()}{@link Queue#remove remove()}{@link Queue#poll poll()}
Examine{@link #element element()}{@link #peek peek()}{@link Queue#element element()}{@link Queue#peek peek()}
> * > @@ -79,15 +80,15 @@ package java.util; > * Whatever the ordering used, the head of the queue is that > * element which would be removed by a call to {@link #remove() } or > * {@link #poll()}. In a FIFO queue, all new elements are inserted at > - * the tail of the queue. Other kinds of queues may use > - * different placement rules. Every Queue implementation > + * the tail of the queue. Other kinds of queues may use > + * different placement rules. Every {@code Queue} implementation > * must specify its ordering properties. > * > *

The {@link #offer offer} method inserts an element if possible, > - * otherwise returning false. This differs from the {@link > + * otherwise returning {@code false}. This differs from the {@link > * java.util.Collection#add Collection.add} method, which can fail to > * add an element only by throwing an unchecked exception. The > - * offer method is designed for use when failure is a normal, > + * {@code offer} method is designed for use when failure is a normal, > * rather than exceptional occurrence, for example, in fixed-capacity > * (or "bounded") queues. > * > @@ -95,32 +96,32 @@ package java.util; > * return the head of the queue. > * Exactly which element is removed from the queue is a > * function of the queue's ordering policy, which differs from > - * implementation to implementation. The remove() and > - * poll() methods differ only in their behavior when the > - * queue is empty: the remove() method throws an exception, > - * while the poll() method returns null. > + * implementation to implementation. The {@code remove()} and > + * {@code poll()} methods differ only in their behavior when the > + * queue is empty: the {@code remove()} method throws an exception, > + * while the {@code poll()} method returns {@code null}. > * > *

The {@link #element()} and {@link #peek()} methods return, but do > * not remove, the head of the queue. > * > - *

The Queue interface does not define the blocking queue > + *

The {@code Queue} interface does not define the blocking queue > * methods, which are common in concurrent programming. These methods, > * which wait for elements to appear or for space to become available, are > * defined in the {@link java.util.concurrent.BlockingQueue} interface, which > * extends this interface. > * > - *

Queue implementations generally do not allow insertion > - * of null elements, although some implementations, such as > - * {@link LinkedList}, do not prohibit insertion of null. > - * Even in the implementations that permit it, null should > - * not be inserted into a Queue, as null is also > - * used as a special return value by the poll method to > + *

{@code Queue} implementations generally do not allow insertion > + * of {@code null} elements, although some implementations, such as > + * {@link LinkedList}, do not prohibit insertion of {@code null}. > + * Even in the implementations that permit it, {@code null} should > + * not be inserted into a {@code Queue}, as {@code null} is also > + * used as a special return value by the {@code poll} method to > * indicate that the queue contains no elements. > * > - *

Queue implementations generally do not define > - * element-based versions of methods equals and > - * hashCode but instead inherit the identity based versions > - * from class Object, because element-based equality is not > + *

{@code Queue} implementations generally do not define > + * element-based versions of methods {@code equals} and > + * {@code hashCode} but instead inherit the identity based versions > + * from class {@code Object}, because element-based equality is not > * always well-defined for queues with the same elements but different > * ordering properties. > * > @@ -145,11 +146,11 @@ public interface Queue extends Collec > /** > * Inserts the specified element into this queue if it is possible to do so > * immediately without violating capacity restrictions, returning > - * true upon success and throwing an IllegalStateException > + * {@code true} upon success and throwing an {@code IllegalStateException} > * if no space is currently available. > * > * @param e the element to add > - * @return true (as specified by {@link Collection#add}) > + * @return {@code true} (as specified by {@link Collection#add}) > * @throws IllegalStateException if the element cannot be added at this > * time due to capacity restrictions > * @throws ClassCastException if the class of the specified element > @@ -169,8 +170,8 @@ public interface Queue extends Collec > * by throwing an exception. > * > * @param e the element to add > - * @return true if the element was added to this queue, else > - * false > + * @return {@code true} if the element was added to this queue, else > + * {@code false} > * @throws ClassCastException if the class of the specified element > * prevents it from being added to this queue > * @throws NullPointerException if the specified element is null and > @@ -192,9 +193,9 @@ public interface Queue extends Collec > > /** > * Retrieves and removes the head of this queue, > - * or returns null if this queue is empty. > + * or returns {@code null} if this queue is empty. > * > - * @return the head of this queue, or null if this queue is empty > + * @return the head of this queue, or {@code null} if this queue is empty > */ > E poll(); > > @@ -210,9 +211,9 @@ public interface Queue extends Collec > > /** > * Retrieves, but does not remove, the head of this queue, > - * or returns null if this queue is empty. > + * or returns {@code null} if this queue is empty. > * > - * @return the head of this queue, or null if this queue is empty > + * @return the head of this queue, or {@code null} if this queue is empty > */ > E peek(); > } > > -Chris. From nicholas+openjdk at nicholaswilliams.net Thu Aug 1 17:38:38 2013 From: nicholas+openjdk at nicholaswilliams.net (Nick Williams) Date: Thu, 1 Aug 2013 12:38:38 -0500 Subject: Try to run core libs tests -- All IO tests failing In-Reply-To: <51F92947.70402@oracle.com> References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net> <51F80198.4050209@oracle.com> <51F8262A.3060809@oracle.com> <51F922D2.4030305@oracle.com> <51F92947.70402@oracle.com> Message-ID: <437338A3-91DE-4ABB-A89A-B9104090410B@nicholaswilliams.net> That was the ticket! All the tests run with this command, despite the fact that some of them fail. Thanks! You might want to update the readme with this command, at least as an alternative to the one there now. Nick On Jul 31, 2013, at 10:12 AM, Chris Hegarty wrote: > > try: > make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ *jdk_core* > > -Chris. > > On 31/07/2013 15:49, Nick Williams wrote: >> That's how I'm running it. >> >> $ pwd >> /foo/bar/jdk8/jdk8 >> $ cd test >> $ make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ all >> >> If one test fails in a batch, none of the following batches run. So if one test fails in java.io, java.lang won't run. Makes it difficult to run all of the tests, especial since there are two tests in java.lang (ThreadLocalSupplierTests due to java.lang.VerifyError: Bad local variable type, and DefaultMethodModeling due to java.lang.NullPointerException at java.util.Objects.requireNonNull when checking class B) that fail consistently (on Mac OS X at least) that I haven't been able to solve by identifying issues with the testing environment. >> >> Nick >> >> On Jul 31, 2013, at 9:44 AM, Chris Hegarty wrote: >> >>> I believe if you run the tests from the top-level test/Makefile, not jdk/test/Makefile, all individual test batches ( invocations of jtreg ) get run. >>> >>> -Chris. >>> >>> On 30/07/2013 21:46, Jonathan Gibbons wrote: >>>> >>>> jtreg itself does not "stop on error". If you're driving the tests >>>> through the makefiles, the makefiles may partition the work into >>>> separate jtreg runs on separate parts of the test suite. >>>> >>>> -- Jon >>>> >>>> >>>> On 07/30/2013 01:13 PM, Nick Williams wrote: >>>>> Okay, this is indeed very interesting. After two hours it was only >>>>> about half-way through the java.io tests and all of them had failed so >>>>> far. On a sheer hunch and nothing more, I unplugged my ethernet cable, >>>>> thus disconnecting me from any/all networks and the Internet. BOOM. >>>>> The rest of the java.io tests finished (and passed) in a few seconds, >>>>> leaving 137 that had failed. I then re-ran the tests while still >>>>> disconnected from the Internet and 312 of the java.io tests passed >>>>> this time, leaving only 1 failure (java/io/BufferedReader/Lines.java, >>>>> output below). >>>>> >>>>> I plugged my Ethernet back in and ran the tests again and java.io >>>>> started failing every test again, timing out after 60 seconds each. >>>>> Curiously extending my hunch I remained connected over Ethernet and >>>>> connected to a remote network via OpenVPN. Now all of the java.io test >>>>> pass again (except that same one, with the same output). >>>>> >>>>> What on Earth??? (If it helps, I'm on Mac OS X 10.7.5.) >>>>> >>>>> Unfortunately, the one failed java.io test prevents jtreg from >>>>> continuing on to the next set of tests (java.lang). Anyone know how to >>>>> tell jtreg to continue running on error? >>>>> >>>>> Nick >>>>> >>>>> #Test Results (version 2) >>>>> #Tue Jul 30 14:53:42 CDT 2013 >>>>> #-----testdescription----- >>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedReader/Lines.java >>>>> >>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test >>>>> keywords=bug8003258 >>>>> run=USER_SPECIFIED testng Lines\n >>>>> source=Lines.java >>>>> title=\ >>>>> >>>>> #-----environment----- >>>>> >>>>> #-----testresult----- >>>>> end=Tue Jul 30 14\:53\:42 CDT 2013 >>>>> execStatus=Error. Unexpected exception caught from test >>>>> java/io/BufferedReader/Lines.java\: java.lang.NullPointerException >>>>> sections=script_messages Details >>>>> >>>>> #section:script_messages >>>>> ----------messages:(0/0)---------- >>>>> >>>>> #section:Details >>>>> ----------messages:(0/0)---------- >>>>> ----------Stack trace:(10/672)---------- >>>>> java.lang.NullPointerException >>>>> at >>>>> com.sun.javatest.regtest.TestNGReporter.getMatcher(TestNGReporter.java:97) >>>>> >>>>> at com.sun.javatest.regtest.TestNGReporter.add(TestNGReporter.java:80) >>>>> at com.sun.javatest.regtest.TestNGAction.endAction(TestNGAction.java:131) >>>>> at com.sun.javatest.regtest.MainAction.run(MainAction.java:260) >>>>> at >>>>> com.sun.javatest.regtest.RegressionScript.run(RegressionScript.java:149) >>>>> at com.sun.javatest.Script.run(Script.java:228) >>>>> at com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174) >>>>> at >>>>> com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43) >>>>> at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66) >>>>> result: Not run. Test running... >>>>> >>>>> >>>>> test result: Error. Unexpected exception caught from test >>>>> java/io/BufferedReader/Lines.java: java.lang.NullPointerException >>>>> >>>>> >>>>> On Jul 30, 2013, at 1:39 PM, Nick Williams wrote: >>>>> >>>>>> On Jul 30, 2013, at 1:16 PM, Nick Williams wrote: >>>>>> >>>>>>> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote: >>>>>>> >>>>>>>> On 30/07/2013 11:02, Nick Williams wrote: >>>>>>>>> I'm running the core libs tests locally (for the first time), and >>>>>>>>> every java.io test is failing. They're all failing for the same >>>>>>>>> reason (output below), and I suspect it's something local and not >>>>>>>>> an actual problem. But the test output is not very helpful. Note >>>>>>>>> that all of the java.beans tests passed with flying colors. Once >>>>>>>>> it got to java.io, everything started failing. Worse, each test is >>>>>>>>> taking 60 seconds to fail. I could be here a while... >>>>>>>>> >>>>>>>>> Thoughts? >>>>>>>> What command are you using? From the output it suggests that the >>>>>>>> connection between jtreg and the agent VM cannot be established. >>>>>>>> >>>>>>>> -Alan. >>>>>>> Command, just like README-builds.html#testing says: >>>>>>> >>>>>>> cd test&& make >>>>>>> PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ >>>>>>> all >>>>>>> >>>>>>> I assume this is specifically an java.io-related problem because all >>>>>>> the java.beans tests passed without exception and so far every >>>>>>> java.io test through java.io.Externalizable (that's as far as it has >>>>>>> gotten) has failed without exception. Wouldn't a problem with jtreg >>>>>>> communicating with the agent VM have shown up in java.beans as well? >>>>>>> I could be wrong of course. >>>>>> I see now that java.beans tests run in "othervm mode" while java.io >>>>>> tests run in "agentvm mode." Didn't realize they were being run >>>>>> differently. Your explanation makes much more sense now, but I still >>>>>> don't know what's wrong... >>>>>> >>>>>>>> >>>>>>>>> Here's the output from one of the tests. It looks like all the >>>>>>>>> other test outputs: >>>>>>>>> >>>>>>>>> #Test Results (version 2) >>>>>>>>> #Tue Jul 30 12:38:15 CDT 2013 >>>>>>>>> #-----testdescription----- >>>>>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java >>>>>>>>> >>>>>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test >>>>>>>>> keywords=bug4143651 >>>>>>>>> run=ASSUMED_ACTION main ReadAfterClose\n >>>>>>>>> source=ReadAfterClose.java >>>>>>>>> title=Test if I/O methods will check if the stream has been closed. >>>>>>>>> >>>>>>>>> #-----environment----- >>>>>>>>> >>>>>>>>> #-----testresult----- >>>>>>>>> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java >>>>>>>>> >>>>>>>>> elapsed=60007 0\:01\:00.007 >>>>>>>>> end=Tue Jul 30 12\:38\:15 CDT 2013 >>>>>>>>> environment=regtest >>>>>>>>> execStatus=Error. Cannot get VM for test\: >>>>>>>>> java.net.SocketTimeoutException\: Accept timed out >>>>>>>>> hostname=unknown >>>>>>>>> javatestOS=Mac OS X 10.7.5 (x86_64) >>>>>>>>> javatestVersion=4.4.1 >>>>>>>>> jtregVersion=jtreg 4.1 dev b00 >>>>>>>>> script=com.sun.javatest.regtest.RegressionScript >>>>>>>>> sections=script_messages build compile >>>>>>>>> start=Tue Jul 30 12\:37\:15 CDT 2013 >>>>>>>>> test=java/io/BufferedInputStream/ReadAfterClose.java >>>>>>>>> user.name=Nicholas >>>>>>>>> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream >>>>>>>>> >>>>>>>>> >>>>>>>>> #section:script_messages >>>>>>>>> ----------messages:(5/308)---------- >>>>>>>>> JDK under test: >>>>>>>>> (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image) >>>>>>>>> >>>>>>>>> openjdk version "1.8.0-internal" >>>>>>>>> OpenJDK Runtime Environment (build >>>>>>>>> 1.8.0-internal-icholas_2013_07_29_21_14-b00) >>>>>>>>> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode) >>>>>>>>> >>>>>>>>> >>>>>>>>> #section:build >>>>>>>>> ----------messages:(3/100)---------- >>>>>>>>> command: build ReadAfterClose >>>>>>>>> reason: Named class compiled on demand >>>>>>>>> elapsed time (seconds): 60.005 >>>>>>>>> result: Error. Cannot get VM for test: >>>>>>>>> java.net.SocketTimeoutException: Accept timed out >>>>>>>>> >>>>>>>>> #section:compile >>>>>>>>> ----------messages:(3/235)---------- >>>>>>>>> command: compile -XDignore.symbol.file=true >>>>>>>>> /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java >>>>>>>>> >>>>>>>>> reason: .class file out of date or does not exist >>>>>>>>> elapsed time (seconds): 60.005 >>>>>>>>> result: Error. Cannot get VM for test: >>>>>>>>> java.net.SocketTimeoutException: Accept timed out >>>>>>>>> >>>>>>>>> >>>>>>>>> test result: Error. Cannot get VM for test: >>>>>>>>> java.net.SocketTimeoutException: Accept timed out >>>>>>>>> >>>> >> From rednaxelafx at gmail.com Thu Aug 1 13:16:14 2013 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 1 Aug 2013 21:16:14 +0800 Subject: Getting ciObject from oop/jobject In-Reply-To: <25D4AFB8-82DE-43E0-92E5-754BFC4DBBAD@nicholaswilliams.net> References: <25D4AFB8-82DE-43E0-92E5-754BFC4DBBAD@nicholaswilliams.net> Message-ID: Hi Nick, This topic is related to HotSpot Server Compiler instead of the Java core library, so I'm cc'ing this email to hotspot-compiler-dev and dropping core-libs-dev. As you already know, HotSpot compilers are shielded from VM runtime implementation details via the Compiler Interface (CI). That's why you shouldn't be getting raw oops in C2 code. Where are you getting the oopInstance from? If it can be found from some known "roots", e.g. "well-known classes", fields of "well-known classes", or the holder class of the method to be compiled, etc., then it's already available through CI. - Kris On Thu, Aug 1, 2013 at 3:17 AM, Nick Williams < nicholas+openjdk at nicholaswilliams.net> wrote: > In native code (library_call.cpp), if I have an oop (which I can convert > to a jobject if need be), how do I get a ciObject? I see that ciEnv has a > ciObject* get_object(oop) method, but it's private. And ciObjectFactory has > a ciObject* get(oop) method, but I can't figure out how to get the > ciObjectFactory instance. > > I know that ciObject keeps a jobject internally, and I know that ciObject > has a ciObject(oop) constructor, but it's protected (for good reason). > > If it helps, I'm trying to inline a method and need to > set_result(makecon(TypeInstPtr::make(oopInstance))). I may be going down > the wrong path. > > Thanks in advance for any help, > > Nick From brent.christian at oracle.com Thu Aug 1 18:22:23 2013 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 01 Aug 2013 11:22:23 -0700 Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X In-Reply-To: <51F84C28.3050209@oracle.com> References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com> <51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com> <8CC8FA32-26C3-47D3-B6A3-33AA4BEC7D12@devrx.org> <4DB36382-0D2A-492F-8472-C198D2AB1568@apple.com> <51F84C28.3050209@oracle.com> Message-ID: <51FAA75F.7040205@oracle.com> On 7/30/13 4:28 PM, Naoto Sato wrote: > On 7/30/13 4:06 PM, David DeHaven wrote: >> >> I was about to chime in that UTF-8 has been the preferred encoding for >> (stored) text on Mac OS X as long as I've been hacking on it (think >> "Rhapsody"), so why is this even an issue? >> >> Judging from the docs, nl_langinfo seems like a Unix portability >> function (something more likely to be happier with ASCII in a >> terminal), not something to be used by a native Cocoa application. >> >> >> >> Set it to UTF-8 and forget about it >> > > +1. Naoto, would you be able to push this for me? Thanks, -Brent From naoto.sato at oracle.com Thu Aug 1 18:26:20 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 01 Aug 2013 11:26:20 -0700 Subject: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X In-Reply-To: <51FAA75F.7040205@oracle.com> References: <51F2B781.1050104@oracle.com> <51F5FA02.9020909@oracle.com> <51F6C860.4020000@oracle.com> <51F72EAD.7040201@oracle.com> <8CC8FA32-26C3-47D3-B6A3-33AA4BEC7D12@devrx.org> <4DB36382-0D2A-492F-8472-C198D2AB1568@apple.com> <51F84C28.3050209@oracle.com> <51FAA75F.7040205@oracle.com> Message-ID: <51FAA84C.4030704@oracle.com> Sure. Send me the final diff to me. Naoto On 8/1/13 11:22 AM, Brent Christian wrote: > On 7/30/13 4:28 PM, Naoto Sato wrote: >> On 7/30/13 4:06 PM, David DeHaven wrote: >>> >>> I was about to chime in that UTF-8 has been the preferred encoding for >>> (stored) text on Mac OS X as long as I've been hacking on it (think >>> "Rhapsody"), so why is this even an issue? >>> >>> Judging from the docs, nl_langinfo seems like a Unix portability >>> function (something more likely to be happier with ASCII in a >>> terminal), not something to be used by a native Cocoa application. >>> >>> >>> >>> Set it to UTF-8 and forget about it >>> >> >> +1. > > Naoto, would you be able to push this for me? > > Thanks, > -Brent From mike.duigou at oracle.com Thu Aug 1 18:51:51 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 1 Aug 2013 11:51:51 -0700 Subject: Try to run core libs tests -- All IO tests failing In-Reply-To: <437338A3-91DE-4ABB-A89A-B9104090410B@nicholaswilliams.net> References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net> <51F80198.4050209@oracle.com> <51F8262A.3060809@oracle.com> <51F922D2.4030305@oracle.com> <51F92947.70402@oracle.com> <437338A3-91DE-4ABB-A89A-B9104090410B@nicholaswilliams.net> Message-ID: <4AAA5CB8-5A6D-4F50-BFC8-6DF3740F87EA@oracle.com> On Aug 1 2013, at 10:38 , Nick Williams wrote: > That was the ticket! All the tests run with this command, despite the fact that some of them fail. Thanks! > > You might want to update the readme with this command, at least as an alternative to the one there now. > > Nick > > On Jul 31, 2013, at 10:12 AM, Chris Hegarty wrote: > >> >> try: >> make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ *jdk_core* An alternative is to use the top level repo make: make test TEST="jdk_core" The jdk/test/Makefile has not been upgraded to understand the location of the built jdk image with the new build infrastructure. I have been doing some work to try to improve the running of tests via make. We haven't yet decided whether running the jdk/test/Makefile directly will remain a supported invocation method. Mike >> >> -Chris. >> >> On 31/07/2013 15:49, Nick Williams wrote: >>> That's how I'm running it. >>> >>> $ pwd >>> /foo/bar/jdk8/jdk8 >>> $ cd test >>> $ make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ all >>> >>> If one test fails in a batch, none of the following batches run. So if one test fails in java.io, java.lang won't run. Makes it difficult to run all of the tests, especial since there are two tests in java.lang (ThreadLocalSupplierTests due to java.lang.VerifyError: Bad local variable type, and DefaultMethodModeling due to java.lang.NullPointerException at java.util.Objects.requireNonNull when checking class B) that fail consistently (on Mac OS X at least) that I haven't been able to solve by identifying issues with the testing environment. >>> >>> Nick >>> >>> On Jul 31, 2013, at 9:44 AM, Chris Hegarty wrote: >>> >>>> I believe if you run the tests from the top-level test/Makefile, not jdk/test/Makefile, all individual test batches ( invocations of jtreg ) get run. >>>> >>>> -Chris. >>>> >>>> On 30/07/2013 21:46, Jonathan Gibbons wrote: >>>>> >>>>> jtreg itself does not "stop on error". If you're driving the tests >>>>> through the makefiles, the makefiles may partition the work into >>>>> separate jtreg runs on separate parts of the test suite. >>>>> >>>>> -- Jon >>>>> >>>>> >>>>> On 07/30/2013 01:13 PM, Nick Williams wrote: >>>>>> Okay, this is indeed very interesting. After two hours it was only >>>>>> about half-way through the java.io tests and all of them had failed so >>>>>> far. On a sheer hunch and nothing more, I unplugged my ethernet cable, >>>>>> thus disconnecting me from any/all networks and the Internet. BOOM. >>>>>> The rest of the java.io tests finished (and passed) in a few seconds, >>>>>> leaving 137 that had failed. I then re-ran the tests while still >>>>>> disconnected from the Internet and 312 of the java.io tests passed >>>>>> this time, leaving only 1 failure (java/io/BufferedReader/Lines.java, >>>>>> output below). >>>>>> >>>>>> I plugged my Ethernet back in and ran the tests again and java.io >>>>>> started failing every test again, timing out after 60 seconds each. >>>>>> Curiously extending my hunch I remained connected over Ethernet and >>>>>> connected to a remote network via OpenVPN. Now all of the java.io test >>>>>> pass again (except that same one, with the same output). >>>>>> >>>>>> What on Earth??? (If it helps, I'm on Mac OS X 10.7.5.) >>>>>> >>>>>> Unfortunately, the one failed java.io test prevents jtreg from >>>>>> continuing on to the next set of tests (java.lang). Anyone know how to >>>>>> tell jtreg to continue running on error? >>>>>> >>>>>> Nick >>>>>> >>>>>> #Test Results (version 2) >>>>>> #Tue Jul 30 14:53:42 CDT 2013 >>>>>> #-----testdescription----- >>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedReader/Lines.java >>>>>> >>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test >>>>>> keywords=bug8003258 >>>>>> run=USER_SPECIFIED testng Lines\n >>>>>> source=Lines.java >>>>>> title=\ >>>>>> >>>>>> #-----environment----- >>>>>> >>>>>> #-----testresult----- >>>>>> end=Tue Jul 30 14\:53\:42 CDT 2013 >>>>>> execStatus=Error. Unexpected exception caught from test >>>>>> java/io/BufferedReader/Lines.java\: java.lang.NullPointerException >>>>>> sections=script_messages Details >>>>>> >>>>>> #section:script_messages >>>>>> ----------messages:(0/0)---------- >>>>>> >>>>>> #section:Details >>>>>> ----------messages:(0/0)---------- >>>>>> ----------Stack trace:(10/672)---------- >>>>>> java.lang.NullPointerException >>>>>> at >>>>>> com.sun.javatest.regtest.TestNGReporter.getMatcher(TestNGReporter.java:97) >>>>>> >>>>>> at com.sun.javatest.regtest.TestNGReporter.add(TestNGReporter.java:80) >>>>>> at com.sun.javatest.regtest.TestNGAction.endAction(TestNGAction.java:131) >>>>>> at com.sun.javatest.regtest.MainAction.run(MainAction.java:260) >>>>>> at >>>>>> com.sun.javatest.regtest.RegressionScript.run(RegressionScript.java:149) >>>>>> at com.sun.javatest.Script.run(Script.java:228) >>>>>> at com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174) >>>>>> at >>>>>> com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43) >>>>>> at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66) >>>>>> result: Not run. Test running... >>>>>> >>>>>> >>>>>> test result: Error. Unexpected exception caught from test >>>>>> java/io/BufferedReader/Lines.java: java.lang.NullPointerException >>>>>> >>>>>> >>>>>> On Jul 30, 2013, at 1:39 PM, Nick Williams wrote: >>>>>> >>>>>>> On Jul 30, 2013, at 1:16 PM, Nick Williams wrote: >>>>>>> >>>>>>>> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote: >>>>>>>> >>>>>>>>> On 30/07/2013 11:02, Nick Williams wrote: >>>>>>>>>> I'm running the core libs tests locally (for the first time), and >>>>>>>>>> every java.io test is failing. They're all failing for the same >>>>>>>>>> reason (output below), and I suspect it's something local and not >>>>>>>>>> an actual problem. But the test output is not very helpful. Note >>>>>>>>>> that all of the java.beans tests passed with flying colors. Once >>>>>>>>>> it got to java.io, everything started failing. Worse, each test is >>>>>>>>>> taking 60 seconds to fail. I could be here a while... >>>>>>>>>> >>>>>>>>>> Thoughts? >>>>>>>>> What command are you using? From the output it suggests that the >>>>>>>>> connection between jtreg and the agent VM cannot be established. >>>>>>>>> >>>>>>>>> -Alan. >>>>>>>> Command, just like README-builds.html#testing says: >>>>>>>> >>>>>>>> cd test&& make >>>>>>>> PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ >>>>>>>> all >>>>>>>> >>>>>>>> I assume this is specifically an java.io-related problem because all >>>>>>>> the java.beans tests passed without exception and so far every >>>>>>>> java.io test through java.io.Externalizable (that's as far as it has >>>>>>>> gotten) has failed without exception. Wouldn't a problem with jtreg >>>>>>>> communicating with the agent VM have shown up in java.beans as well? >>>>>>>> I could be wrong of course. >>>>>>> I see now that java.beans tests run in "othervm mode" while java.io >>>>>>> tests run in "agentvm mode." Didn't realize they were being run >>>>>>> differently. Your explanation makes much more sense now, but I still >>>>>>> don't know what's wrong... >>>>>>> >>>>>>>>> >>>>>>>>>> Here's the output from one of the tests. It looks like all the >>>>>>>>>> other test outputs: >>>>>>>>>> >>>>>>>>>> #Test Results (version 2) >>>>>>>>>> #Tue Jul 30 12:38:15 CDT 2013 >>>>>>>>>> #-----testdescription----- >>>>>>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java >>>>>>>>>> >>>>>>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test >>>>>>>>>> keywords=bug4143651 >>>>>>>>>> run=ASSUMED_ACTION main ReadAfterClose\n >>>>>>>>>> source=ReadAfterClose.java >>>>>>>>>> title=Test if I/O methods will check if the stream has been closed. >>>>>>>>>> >>>>>>>>>> #-----environment----- >>>>>>>>>> >>>>>>>>>> #-----testresult----- >>>>>>>>>> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java >>>>>>>>>> >>>>>>>>>> elapsed=60007 0\:01\:00.007 >>>>>>>>>> end=Tue Jul 30 12\:38\:15 CDT 2013 >>>>>>>>>> environment=regtest >>>>>>>>>> execStatus=Error. Cannot get VM for test\: >>>>>>>>>> java.net.SocketTimeoutException\: Accept timed out >>>>>>>>>> hostname=unknown >>>>>>>>>> javatestOS=Mac OS X 10.7.5 (x86_64) >>>>>>>>>> javatestVersion=4.4.1 >>>>>>>>>> jtregVersion=jtreg 4.1 dev b00 >>>>>>>>>> script=com.sun.javatest.regtest.RegressionScript >>>>>>>>>> sections=script_messages build compile >>>>>>>>>> start=Tue Jul 30 12\:37\:15 CDT 2013 >>>>>>>>>> test=java/io/BufferedInputStream/ReadAfterClose.java >>>>>>>>>> user.name=Nicholas >>>>>>>>>> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> #section:script_messages >>>>>>>>>> ----------messages:(5/308)---------- >>>>>>>>>> JDK under test: >>>>>>>>>> (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image) >>>>>>>>>> >>>>>>>>>> openjdk version "1.8.0-internal" >>>>>>>>>> OpenJDK Runtime Environment (build >>>>>>>>>> 1.8.0-internal-icholas_2013_07_29_21_14-b00) >>>>>>>>>> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> #section:build >>>>>>>>>> ----------messages:(3/100)---------- >>>>>>>>>> command: build ReadAfterClose >>>>>>>>>> reason: Named class compiled on demand >>>>>>>>>> elapsed time (seconds): 60.005 >>>>>>>>>> result: Error. Cannot get VM for test: >>>>>>>>>> java.net.SocketTimeoutException: Accept timed out >>>>>>>>>> >>>>>>>>>> #section:compile >>>>>>>>>> ----------messages:(3/235)---------- >>>>>>>>>> command: compile -XDignore.symbol.file=true >>>>>>>>>> /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java >>>>>>>>>> >>>>>>>>>> reason: .class file out of date or does not exist >>>>>>>>>> elapsed time (seconds): 60.005 >>>>>>>>>> result: Error. Cannot get VM for test: >>>>>>>>>> java.net.SocketTimeoutException: Accept timed out >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> test result: Error. Cannot get VM for test: >>>>>>>>>> java.net.SocketTimeoutException: Accept timed out >>>>>>>>>> >>>>> >>> > From brian.burkhalter at oracle.com Thu Aug 1 19:09:05 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 1 Aug 2013 12:09:05 -0700 Subject: Java 8 RFR 8022094: BigDecimal/CompareToTests and BigInteger/CompareToTests are incorrect Message-ID: Reviewers: This is a test-only issue. Issue http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022094 (not public quite yet) Webrev http://cr.openjdk.java.net/~bpb/8022094/ Summary: 1) BigDecimal * The compareToTest() method was modified to correctly print and report errors. * The set of test cases was changed to eliminate incorrect assumptions. 2) BigInteger * Old version replaced by copying BigDecimal version and changing BigDecimal to BigInteger. * Fractional test cases were replace with others to probe internal mag array having different relative lengths. Thanks, Brian From tbuktu at hotmail.com Thu Aug 1 19:51:27 2013 From: tbuktu at hotmail.com (Tim Buktu) Date: Thu, 1 Aug 2013 21:51:27 +0200 Subject: hg: jdk8/tl/jdk: 8014319: Faster division of large integers In-Reply-To: <20130727154550.747C748417@hg.openjdk.java.net> References: <20130727154550.747C748417@hg.openjdk.java.net> Message-ID: Thanks, Alan. On 27.07.2013 17:45, alan.bateman at oracle.com wrote: > Changeset: d4b2436892c8 > Author: bpb > Date: 2013-07-26 17:03 -0700 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d4b2436892c8 > > 8014319: Faster division of large integers > Summary: Implement Burnickel-Ziegler division algorithm in BigInteger > Reviewed-by: bpb, martin > Contributed-by: Tim Buktu > > ! src/share/classes/java/math/BigInteger.java > ! src/share/classes/java/math/MutableBigInteger.java > ! test/java/math/BigInteger/BigIntegerTest.java > > > From Alan.Bateman at oracle.com Thu Aug 1 20:38:07 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 01 Aug 2013 13:38:07 -0700 Subject: RFR 8020016 Numerous splitereator impls do not throw NPE for null Consumers In-Reply-To: <9AA438B4-70EE-4BF8-8D01-DBF94CE94A4D@oracle.com> References: <7ABB30F0-853F-4762-BE52-E60F2515C696@oracle.com> <51429852-3F0F-429E-B6A8-4EAD1FC361B6@oracle.com> <9AA438B4-70EE-4BF8-8D01-DBF94CE94A4D@oracle.com> Message-ID: <51FAC72F.7010104@oracle.com> On 01/08/2013 08:49, Paul Sandoz wrote: > On Aug 1, 2013, at 4:45 PM, Henry Jen wrote: >> In StremSpliterator:366, I assume the NULL check should be before if. >> > It saves a redundant check if the wrapping spliterator uses buffering, since the tryAdvance will also check: > It looks like the explicit check in DoubleWrappingSpliterator. forEachRemaining is redundant although unlikely to be noticeable. Otherwise looks fine to me. -Alan From paul.sandoz at oracle.com Thu Aug 1 20:53:51 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 1 Aug 2013 21:53:51 +0100 Subject: RFR 8020016 Numerous splitereator impls do not throw NPE for null Consumers In-Reply-To: <51FAC72F.7010104@oracle.com> References: <7ABB30F0-853F-4762-BE52-E60F2515C696@oracle.com> <51429852-3F0F-429E-B6A8-4EAD1FC361B6@oracle.com> <9AA438B4-70EE-4BF8-8D01-DBF94CE94A4D@oracle.com> <51FAC72F.7010104@oracle.com> Message-ID: <4AAEF9CD-B158-4C95-B448-688931954F53@oracle.com> On Aug 1, 2013, at 9:38 PM, Alan Bateman wrote: > On 01/08/2013 08:49, Paul Sandoz wrote: >> >> On Aug 1, 2013, at 4:45 PM, Henry Jen wrote: >>> In StremSpliterator:366, I assume the NULL check should be before if. >>> >> It saves a redundant check if the wrapping spliterator uses buffering, since the tryAdvance will also check: >> > It looks like the explicit check in DoubleWrappingSpliterator. forEachRemaining is redundant although unlikely to be noticeable. Otherwise looks fine to me. > Thanks, well spotted, same for LongWrappingSpliterator too, i fixed those to be consistent with the others. Paul. From paul.sandoz at oracle.com Thu Aug 1 21:07:32 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 01 Aug 2013 21:07:32 +0000 Subject: hg: jdk8/tl/jdk: 8020016: Numerous splitereator impls do not throw NPE for null Consumers Message-ID: <20130801210757.ADA8748544@hg.openjdk.java.net> Changeset: 0be7839d4599 Author: psandoz Date: 2013-08-01 15:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0be7839d4599 8020016: Numerous splitereator impls do not throw NPE for null Consumers Reviewed-by: mduigou, alanb, henryjen ! src/share/classes/java/util/stream/SpinedBuffer.java ! src/share/classes/java/util/stream/StreamSpliterators.java ! src/share/classes/java/util/stream/Streams.java ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java ! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java From stuart.marks at oracle.com Thu Aug 1 21:18:01 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 01 Aug 2013 14:18:01 -0700 Subject: Remaining doclint issues in java.net In-Reply-To: <20130731213957.GA24485@mhcomputing.net> References: <51F67C14.5040804@oracle.com> <51F983D2.3050501@oracle.com> <20130731213957.GA24485@mhcomputing.net> Message-ID: <51FAD089.9000805@oracle.com> On 7/31/13 2:39 PM, Matthew Hall wrote: > On Wed, Jul 31, 2013 at 02:38:26PM -0700, Stuart Marks wrote: >> The alternative is to add "@throws SocketException never" to the >> javadoc, just to get rid of the doclint warning, but this has the >> consequence of requiring people to keep dead code around >> indefinitely, and furthermore it requires them to add new dead code >> every time they create a DatagramPacket. > > I have never understood in many years using Java why the compiler generates > errors about attempting to catch supposedly-impossible exceptions, instead of > warnings. > > For me it only leads to difficulties when I'm trying to write prototypes or > refactor and clean up some old brittle code, and I run into that rather > dubious sort of error. > > This is a good example of where it causes more harm than good. Is there still > a really good reason for this over-paranoid compiler error given that checked > exceptions aren't as popular as they used to be anyways? I don't have the definitive answer, but it was a very early Java design decision to make unreachable code be a compilation error instead of a warning. This is a matter of judgment, of course; reasonable people come down on different sides of this, for different cases. For example, see this Stackoverflow conversation: http://stackoverflow.com/questions/3795585/why-does-java-have-an-unreachable-statement-compiler-error * * * Meanwhile, I did a little bit of studying about DatagramPacket. The doclint warnings occur on two of the six DatagramPacket constructors: DatagramPacket(byte[] buf, int len, SocketAddress sa) DatagramPacket(byte[] buf, int off, int len, SocketAddress sa) There are two other equivalent overloaded constructors that take InetAddress and port arguments: DatagramPacket(byte[] buf, int len, InetAddress ia, int port) DatagramPacket(byte[] buf, int off, int len, InetAddress ia, int port) To my eye the InetAddress/port constructors are used quite a bit more often than the SocketAddress ones. I did a web search for "java DatagramPacket example" and looked at all the examples on the first page of hits. All of them used the InetAddress+port constructor overloads (including the Oracle Java tutorial). I didn't see any uses of the SocketAddress overloads. I also did an ohloh search for "new DatagramPacket(": http://code.ohloh.net/search?s=%22new%20DatagramPacket%28%22&p=2&pp=0&fl=Java&mp=1&ml=1&me=1&md=1&ff=1&filterChecked=true (HT: Dalibor) I looked through around 100 examples, and the vast majority of them use the InetAddress+port overloads. I saw three examples that use the SocketAddress overloads. Two of them were within methods that declared "throws Exception." The third was within a try/catch block that catches IOException. None of the three cases would suffer a source incompatibility. This isn't definitive, of course, but it does seem to supply some evidence that making this change would result in a relatively minor source incompatibility. s'marks From Alan.Bateman at oracle.com Thu Aug 1 22:08:39 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 01 Aug 2013 15:08:39 -0700 Subject: Remaining doclint issues in java.net In-Reply-To: <51FAD089.9000805@oracle.com> References: <51F67C14.5040804@oracle.com> <51F983D2.3050501@oracle.com> <20130731213957.GA24485@mhcomputing.net> <51FAD089.9000805@oracle.com> Message-ID: <51FADC67.9020502@oracle.com> On 01/08/2013 14:18, Stuart Marks wrote: > : > > To my eye the InetAddress/port constructors are used quite a bit more > often than the SocketAddress ones. I did a web search for "java > DatagramPacket example" and looked at all the examples on the first > page of hits. All of them used the InetAddress+port constructor > overloads (including the Oracle Java tutorial). I didn't see any uses > of the SocketAddress overloads. That's what I would expect as DatagramPacket is old and and pre-dates the SocketAddress abstraction. One other thing to check is whether this API bug has ever been reported. If not then it suggests that not too many people have actually run into it. If these constructors are widely used then I would expect that the bug would be reported before now. -Alan From david.holmes at oracle.com Thu Aug 1 23:05:38 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 02 Aug 2013 09:05:38 +1000 Subject: RFR: 8021591 : (s) Additional explicit null checks In-Reply-To: <51FA8584.1000702@oracle.com> References: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com> <51FA8584.1000702@oracle.com> Message-ID: <51FAE9C2.8050101@oracle.com> On 2/08/2013 1:57 AM, Alan Bateman wrote: > On 26/07/2013 16:31, Mike Duigou wrote: >> Hello all; >> >> This patch adds some missing checks for null that, according to >> interface contract, should be throwing NPE. It also improves the >> existing tests to check for these cases. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8021591/0/webrev/ >> >> The changes to >> src/share/classes/java/util/concurrent/ConcurrentHashMap.java will be >> synchronized separately with the jsr166 workspace. They are part of >> this review to avoid test failures. >> >> Mike > As retainAll and removeAll are long standing methods, are there are > cases where we might now throw NPE when we didn't previously? I'm just > wondering if any of these need to be looked at more closely, minimally > to get into release/compatibility notes. I get a sense of deja-vu here. For retainAll/removeAll this fixes the case where you would not get NPE if the target collection is empty. We already dealt with this for some j.u.c collections - see 7123424 and then 8001575. David > -Alan From tbuktu at hotmail.com Thu Aug 1 23:47:45 2013 From: tbuktu at hotmail.com (Tim Buktu) Date: Fri, 2 Aug 2013 01:47:45 +0200 Subject: RFR: two minor changes to BigIntegerTest and MutableBigInteger Message-ID: I propose the patch below to fix a theoretical bug in divideAndRemainderBurnikelZiegler(). That method assumes the quotient parameter to be zero which is the case in all places it is called from. But there is no guarantee this won't change in the future and besides, the assumption is not documented. The right way to do it, in my opinion, is to set quotient to zero when needed instead of relying on a zero being passed in. --- a/MutableBigInteger.java +++ b/MutableBigInteger.java @@ -1243,6 +1243,7 @@ class MutableBigInteger { int s = b.intLen; if (r < s) { + quotient.intLen = quotient.offset = 0; return this; } else { // Unlike Knuth division, we don't check for common powers of two here because The second patch I'd like to submit changes the ORDER_TOOM_COOK value in BigIntegerTest.java which is currently set to 3000. This is too low for BZ division to be triggered in arithmetic() (although it does get triggered in several other tests). The number used to be higher but it must have changed along the way. --- a/BigIntegerTest.java +++ b/BigIntegerTest.java @@ -74,10 +74,10 @@ public class BigIntegerTest { static final int ORDER_SMALL = 60; static final int ORDER_MEDIUM = 100; - // #bits for testing Karatsuba and Burnikel-Ziegler + // #bits for testing Karatsuba static final int ORDER_KARATSUBA = 1800; - // #bits for testing Toom-Cook - static final int ORDER_TOOM_COOK = 3000; + // #bits for testing Toom-Cook and Burnikel-Ziegler + static final int ORDER_TOOM_COOK = 4000; // #bits for testing Karatsuba squaring static final int ORDER_KARATSUBA_SQUARE = 3200; // #bits for testing Toom-Cook squaring @@ -964,12 +964,12 @@ public class BigIntegerTest { nextProbablePrime(); arithmetic(order1); // small numbers - arithmetic(order3); // Karatsuba / Burnikel-Ziegler range - arithmetic(order4); // Toom-Cook range + arithmetic(order3); // Karatsuba range + arithmetic(order4); // Toom-Cook / Burnikel-Ziegler range divideAndRemainder(order1); // small numbers - divideAndRemainder(order3); // Karatsuba / Burnikel-Ziegler range - divideAndRemainder(order4); // Toom-Cook range + divideAndRemainder(order3); // Karatsuba range + divideAndRemainder(order4); // Toom-Cook / Burnikel-Ziegler range pow(order1); pow(order3); @@ -989,8 +989,8 @@ public class BigIntegerTest { byteArrayConv(order1); modInv(order1); // small numbers - modInv(order3); // Karatsuba / Burnikel-Ziegler range - modInv(order4); // Toom-Cook range + modInv(order3); // Karatsuba range + modInv(order4); // Toom-Cook / Burnikel-Ziegler range modExp(order1, order2); modExp2(order1); The patched files are at https://gist.github.com/tbuktu/1576025/raw/7eb495658353779fe579e89fc4d82ae787402a9e/MutableBigInteger.java.phase3 and https://gist.github.com/tbuktu/1576025/raw/279f5546b58523254c6a4d3c393058c6a12c5a71/BigIntegerTest.java.phase3 Tim From brian.burkhalter at oracle.com Thu Aug 1 23:57:58 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 1 Aug 2013 16:57:58 -0700 Subject: RFR: two minor changes to BigIntegerTest and MutableBigInteger In-Reply-To: References: Message-ID: <058F77C2-13A5-4537-A22D-42E6F36C18C9@oracle.com> Hi Tim, Thanks for keeping an eye on this and for the patches. We'll need to have an issue on file to track this. I can take care of that tomorrow. Brian On Aug 1, 2013, at 4:47 PM, Tim Buktu wrote: > I propose the patch below to fix a theoretical bug in > divideAndRemainderBurnikelZiegler(). From tbuktu at hotmail.com Fri Aug 2 00:01:48 2013 From: tbuktu at hotmail.com (Tim Buktu) Date: Fri, 2 Aug 2013 02:01:48 +0200 Subject: RFR: two minor changes to BigIntegerTest and MutableBigInteger In-Reply-To: <058F77C2-13A5-4537-A22D-42E6F36C18C9@oracle.com> References: <058F77C2-13A5-4537-A22D-42E6F36C18C9@oracle.com> Message-ID: Okay, thanks! On 02.08.2013 01:57, Brian Burkhalter wrote: > Hi Tim, > > Thanks for keeping an eye on this and for the patches. We'll need to > have an issue on file to track this. I can take care of that tomorrow. > > Brian > > On Aug 1, 2013, at 4:47 PM, Tim Buktu wrote: > >> I propose the patch below to fix a theoretical bug in >> divideAndRemainderBurnikelZiegler(). > From weijun.wang at oracle.com Fri Aug 2 01:17:36 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 02 Aug 2013 01:17:36 +0000 Subject: hg: jdk8/tl/jdk: 8021789: jarsigner parses alias as command line option (depending on locale) Message-ID: <20130802011827.507EE48551@hg.openjdk.java.net> Changeset: 29f153e11683 Author: weijun Date: 2013-08-02 08:59 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/29f153e11683 8021789: jarsigner parses alias as command line option (depending on locale) Reviewed-by: vinnie ! src/share/classes/sun/security/tools/jarsigner/Main.java + test/sun/security/tools/jarsigner/collator.sh From stuart.marks at oracle.com Fri Aug 2 02:54:11 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 01 Aug 2013 19:54:11 -0700 Subject: Java 8 RFR 8022094: BigDecimal/CompareToTests and BigInteger/CompareToTests are incorrect In-Reply-To: References: Message-ID: <51FB1F53.4080701@oracle.com> Looks good. Always a good idea to make sure that failures are reported properly. :-) It does look like the following cases are repeated, in both tests: {valueOf(Long.MIN_VALUE+1), valueOf(Long.MAX_VALUE), MINUS_ONE}, {valueOf(Long.MIN_VALUE+1).negate(), valueOf(Long.MAX_VALUE), ZERO}, Is this right? The first four cases are (excuse the poor cross product notation): {max, max-1, min, min+1} x {1, -1} compareTo max but then there's simply {min} x {1, -1} compareTo min followed by the duplicate {min+1} x {1, -1} compareTo max Just following the pattern, I'd expect {max, max-1, min, min+1} x {1, -1} compareTo min though I'm not sure that all of these cases are necessary. s'marks On 8/1/13 12:09 PM, Brian Burkhalter wrote: > Reviewers: > > This is a test-only issue. > > Issue http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022094 (not public quite yet) > Webrev http://cr.openjdk.java.net/~bpb/8022094/ > > Summary: > > 1) BigDecimal > * The compareToTest() method was modified to correctly print and report errors. > * The set of test cases was changed to eliminate incorrect assumptions. > 2) BigInteger > * Old version replaced by copying BigDecimal version and changing BigDecimal to BigInteger. > * Fractional test cases were replace with others to probe internal mag array having different relative lengths. > > Thanks, > > Brian > From joe.darcy at oracle.com Fri Aug 2 05:04:06 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 01 Aug 2013 22:04:06 -0700 Subject: Remaining doclint issues in java.net In-Reply-To: <51FADC67.9020502@oracle.com> References: <51F67C14.5040804@oracle.com> <51F983D2.3050501@oracle.com> <20130731213957.GA24485@mhcomputing.net> <51FAD089.9000805@oracle.com> <51FADC67.9020502@oracle.com> Message-ID: <51FB3DC6.80705@oracle.com> On 08/01/2013 03:08 PM, Alan Bateman wrote: > On 01/08/2013 14:18, Stuart Marks wrote: >> : >> >> To my eye the InetAddress/port constructors are used quite a bit more >> often than the SocketAddress ones. I did a web search for "java >> DatagramPacket example" and looked at all the examples on the first >> page of hits. All of them used the InetAddress+port constructor >> overloads (including the Oracle Java tutorial). I didn't see any uses >> of the SocketAddress overloads. > That's what I would expect as DatagramPacket is old and and pre-dates > the SocketAddress abstraction. > > One other thing to check is whether this API bug has ever been > reported. If not then it suggests that not too many people have > actually run into it. If these constructors are widely used then I > would expect that the bug would be reported before now. > > -Alan Given the results of Stuart's initial investigation, I would favor removing the throws clauses and calling out the change in the release notes. Cheers, -Joe From chris.hegarty at oracle.com Fri Aug 2 08:36:06 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 02 Aug 2013 09:36:06 +0100 Subject: Review request: JDK-8020191 System.getProperty( " os.name " ) returns " Windows NT (unknown) " on Windows 8.1 (v.1) In-Reply-To: <51FA8777.3050902@oracle.com> References: <51F908CA.1070502@oracle.com> <51F91BE7.70403@oracle.com> <51FA8777.3050902@oracle.com> Message-ID: <51FB6F76.2000901@oracle.com> Looks good Alexey. -Chris. On 01/08/2013 17:06, Alexey Utkin wrote: > I did the Windows 8.1 Preview installation and faced with the same > problem as described in the article: > http://social.msdn.microsoft.com/forums/windowsazure/zh-tw/c471de52-611f-435d-ab44-56064e5fd7d5/windows-81-preview-getversionex-reports-629200 > > > To fix the problem, java executable modules need to upgrade the manifest. > That is in new fix version > http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8020191/webrev.01/ > > The bug > https://jbs.oracle.com/bugs/browse/JDK-8020191 > contains the attachment with screen shot proof. > > Regards, > -uta > > On 7/31/2013 7:14 PM, Kurchi Subhra Hazra wrote: >> Changes look good to me (once Alan's point is verified). >> >> Thanks, >> >> - Kurchi >> >> >> >> On Wed, Jul 31, 2013 at 7:15 AM, Alan Bateman > > wrote: >> >> >> The changes in the webrev look okay to me but the reference to the >> "app compatibility shim" in the MS article is a bit confusing and >> not clear to me (with checking into it more) whether this might >> consider java.exe as something that isn't targeted to Windows 8.1. >> So can you verify that you have checked it on the latest 8.1 preview? >> >> As regards the helper library then this could be useful in the >> future (for now then it probably complicates things because the >> JDK still has to run on older versions of Windows). >> >> -Alan. >> >> >> >> On 31/07/2013 05:53, Alexey Utkin wrote: >> >> Bug description: >> https://jbs.oracle.com/bugs/browse/JDK-8020191 >> http://bugs.sun.com/view_bug.do?bug_id=8020191 >> >> Here is the suggested fix: >> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8020191/webrev.00/ >> >> >> >> Summary: >> We need to be consistent with the rest of OS, so I extend the >> case for 6.3 internal version number by values "Windows 8.1" >> for workstation OS, and "Windows Server 2012 R2" for server OS. >> (http://msdn.microsoft.com/en-us/library/windows/desktop/dn302074.aspx) >> >> But we get a chance to have a wrong OS name due to MS >> compatibility problems. >> >> Here is the problem description: >> >> http://social.msdn.microsoft.com/forums/windowsazure/zh-tw/c471de52-611f-435d-ab44-56064e5fd7d5/windows-81-preview-getversionex-reports-629200 >> >> >> >> and MS respond: >> http://msdn.microsoft.com/en-us/library/windows/desktop/dn302074.aspx >> >> Quotations: >> "In Windows 8.1 Preview, we have introduced a new API, >> Versionhelpers API, that deprecates the need for using >> GetVersion(Ex) APIs. This addresses difficulties in >> interpreting the numerical value returned by the >> GetVersion(Ex) APIs." >> >> "The internal version number for Windows 8.1 Preview and >> Windows Server 2012 R2 Preview is 6.3. Only apps that are >> targeting Windows 8.1 will receive a return value of 6.3. >> Those apps that are not targeted for Windows 8.1 will receive >> a return value of 6.2 unless previously shimmed as discussed >> below." >> >> >> Regards, >> -uta >> >> >> > From chris.hegarty at oracle.com Fri Aug 2 08:59:38 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 02 Aug 2013 09:59:38 +0100 Subject: Remove superfluous @test tags from SpliteratorTraversingAndSplittingTest Message-ID: <51FB74FA.3080003@oracle.com> SpliteratorTraversingAndSplittingTest contains two @test tags. The second of which does not specify that the test needs to run with testng. This causes the test to fail, or have an error, when run as a batch with other tests. The second @test tag is just not needed, and the @bug should be moved to the original @test tag. diff -r 29f153e11683 test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java --- a/test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java Fri Aug 02 08:59:37 2013 +0800 +++ b/test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java Fri Aug 02 09:53:00 2013 +0100 @@ -25,6 +25,7 @@ * @test * @summary Spliterator traversing and splitting tests * @run testng SpliteratorTraversingAndSplittingTest + * @bug 8020016 */ import org.testng.annotations.DataProvider; @@ -81,10 +82,6 @@ import static org.testng.Assert.*; import static org.testng.Assert.*; import static org.testng.Assert.assertEquals; -/** - * @test - * @bug 8020016 - */ @Test public class SpliteratorTraversingAndSplittingTest { -Chris. From chris.hegarty at oracle.com Fri Aug 2 09:37:13 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 02 Aug 2013 10:37:13 +0100 Subject: Remaining doclint issues in java.net In-Reply-To: <51FAD089.9000805@oracle.com> References: <51F67C14.5040804@oracle.com> <51F983D2.3050501@oracle.com> <20130731213957.GA24485@mhcomputing.net> <51FAD089.9000805@oracle.com> Message-ID: <51FB7DC9.9000605@oracle.com> comments inline... On 01/08/2013 22:18, Stuart Marks wrote: > On 7/31/13 2:39 PM, Matthew Hall wrote: >> On Wed, Jul 31, 2013 at 02:38:26PM -0700, Stuart Marks wrote: >>> The alternative is to add "@throws SocketException never" to the >>> javadoc, just to get rid of the doclint warning, but this has the >>> consequence of requiring people to keep dead code around >>> indefinitely, and furthermore it requires them to add new dead code >>> every time they create a DatagramPacket. >> >> I have never understood in many years using Java why the compiler >> generates >> errors about attempting to catch supposedly-impossible exceptions, >> instead of >> warnings. >> >> For me it only leads to difficulties when I'm trying to write >> prototypes or >> refactor and clean up some old brittle code, and I run into that rather >> dubious sort of error. >> >> This is a good example of where it causes more harm than good. Is >> there still >> a really good reason for this over-paranoid compiler error given that >> checked >> exceptions aren't as popular as they used to be anyways? > > I don't have the definitive answer, but it was a very early Java design > decision to make unreachable code be a compilation error instead of a > warning. This is a matter of judgment, of course; reasonable people come > down on different sides of this, for different cases. For example, see > this Stackoverflow conversation: > > http://stackoverflow.com/questions/3795585/why-does-java-have-an-unreachable-statement-compiler-error > > > * * * > > Meanwhile, I did a little bit of studying about DatagramPacket. The > doclint warnings occur on two of the six DatagramPacket constructors: > > DatagramPacket(byte[] buf, int len, SocketAddress sa) > DatagramPacket(byte[] buf, int off, int len, SocketAddress sa) > > There are two other equivalent overloaded constructors that take > InetAddress and port arguments: > > DatagramPacket(byte[] buf, int len, InetAddress ia, int port) > DatagramPacket(byte[] buf, int off, int len, InetAddress ia, int port) > > To my eye the InetAddress/port constructors are used quite a bit more > often than the SocketAddress ones. I did a web search for "java > DatagramPacket example" and looked at all the examples on the first page > of hits. All of them used the InetAddress+port constructor overloads > (including the Oracle Java tutorial). I didn't see any uses of the > SocketAddress overloads. > > I also did an ohloh search for "new DatagramPacket(": > > http://code.ohloh.net/search?s=%22new%20DatagramPacket%28%22&p=2&pp=0&fl=Java&mp=1&ml=1&me=1&md=1&ff=1&filterChecked=true Thank you Stuart, this is really helpful. > (HT: Dalibor) > > I looked through around 100 examples, and the vast majority of them use > the InetAddress+port overloads. I saw three examples that use the I would tend to agree with this, the InetAddress+port are probably most commonly used. The SocketAddress variants are useful when you have already constructed an InetSocketAddress elsewhere and pass it into the method that creates/sends the packet. I can only find this sort of code in tests. Also worth noting is that typically datagram packets are created in close proximity to the code that sends them, and the sending of a packet requires handling IOE. This, IMO, further reduces the impact of removing 'throw SE'. > SocketAddress overloads. Two of them were within methods that declared > "throws Exception." The third was within a try/catch block that catches > IOException. None of the three cases would suffer a source incompatibility. I cannot comment on the code you are talking about, but removing 'throws SE' from these constructors will affect anyone that is catching IOE ( since SE is a subclass of IOE ). Simple test: : cat ThrowingCtrs.java import java.net.*; import java.io.IOException; public class ThrowingCtrs { public static void main(String[] args) { SocketAddress sa = new InetSocketAddress("127.0.0.1", 45678); // DatagramPacket(byte[], int, SocketAddress) try { DatagramPacket dp = new DatagramPacket(new byte[1], 1, sa); } catch (SocketException x) { } try { DatagramPacket dp = new DatagramPacket(new byte[1], 1, sa); } catch (IOException x) { } try { DatagramPacket dp = new DatagramPacket(new byte[1], 1, sa); } catch (Exception x) { } // DatagramPacket(byte[], int, int, SocketAddress) try { DatagramPacket dp = new DatagramPacket(new byte[1], 0, 1, sa); } catch (SocketException x) { } try { DatagramPacket dp = new DatagramPacket(new byte[1], 0, 1, sa); } catch (IOException x) { } try { DatagramPacket dp = new DatagramPacket(new byte[1], 0, 1, sa); } catch (Exception x) { } } } Output of javac from a build with SE removed. build/solaris-x86_64-normal-server-release/jdk/bin/javac ThrowingCtrs.java ThrowingCtrs.java:11: error: exception SocketException is never thrown in body of corresponding try statement catch (SocketException x) { } ^ ThrowingCtrs.java:14: error: exception IOException is never thrown in body of corresponding try statement catch (IOException x) { } ^ ThrowingCtrs.java:21: error: exception SocketException is never thrown in body of corresponding try statement catch (SocketException x) { } ^ ThrowingCtrs.java:24: error: exception IOException is never thrown in body of corresponding try statement catch (IOException x) { } ^ 4 errors > This isn't definitive, of course, but it does seem to supply some > evidence that making this change would result in a relatively minor > source incompatibility. Given the above, I still agree with the sentiment here. I will file a bug and proceed with the necessary changes to remove SE. Thanks again, -Chris. > > s'marks From chris.hegarty at oracle.com Fri Aug 2 09:38:08 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 02 Aug 2013 10:38:08 +0100 Subject: Remaining doclint issues in java.net In-Reply-To: <51FADC67.9020502@oracle.com> References: <51F67C14.5040804@oracle.com> <51F983D2.3050501@oracle.com> <20130731213957.GA24485@mhcomputing.net> <51FAD089.9000805@oracle.com> <51FADC67.9020502@oracle.com> Message-ID: <51FB7E00.3040106@oracle.com> On 01/08/2013 23:08, Alan Bateman wrote: > On 01/08/2013 14:18, Stuart Marks wrote: >> : >> >> To my eye the InetAddress/port constructors are used quite a bit more >> often than the SocketAddress ones. I did a web search for "java >> DatagramPacket example" and looked at all the examples on the first >> page of hits. All of them used the InetAddress+port constructor >> overloads (including the Oracle Java tutorial). I didn't see any uses >> of the SocketAddress overloads. > That's what I would expect as DatagramPacket is old and and pre-dates > the SocketAddress abstraction. > > One other thing to check is whether this API bug has ever been reported. > If not then it suggests that not too many people have actually run into > it. If these constructors are widely used then I would expect that the > bug would be reported before now. I can find not such bug(s) reporting this issue. But I will file one now ;-) -Chris. > > -Alan > > > From paul.sandoz at oracle.com Fri Aug 2 09:52:54 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 2 Aug 2013 10:52:54 +0100 Subject: Remove superfluous @test tags from SpliteratorTraversingAndSplittingTest In-Reply-To: <51FB74FA.3080003@oracle.com> References: <51FB74FA.3080003@oracle.com> Message-ID: On Aug 2, 2013, at 9:59 AM, Chris Hegarty wrote: > SpliteratorTraversingAndSplittingTest contains two @test tags. The second of which does not specify that the test needs to run with testng. This causes the test to fail, or have an error, when run as a batch with other tests. > > The second @test tag is just not needed, and the @bug should be moved to the original @test tag. > Ooops that is my fault, thanks for sorting this out. When i ran jtreg manually it did not barf, is there anyway for it to validate the meta-data? Paul. > > diff -r 29f153e11683 test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java > --- a/test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java Fri Aug 02 08:59:37 2013 +0800 > +++ b/test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java Fri Aug 02 09:53:00 2013 +0100 > @@ -25,6 +25,7 @@ > * @test > * @summary Spliterator traversing and splitting tests > * @run testng SpliteratorTraversingAndSplittingTest > + * @bug 8020016 > */ > > import org.testng.annotations.DataProvider; > @@ -81,10 +82,6 @@ import static org.testng.Assert.*; > import static org.testng.Assert.*; > import static org.testng.Assert.assertEquals; > > -/** > - * @test > - * @bug 8020016 > - */ > @Test > public class SpliteratorTraversingAndSplittingTest { > > -Chris. From alexey.utkin at oracle.com Fri Aug 2 09:20:40 2013 From: alexey.utkin at oracle.com (alexey.utkin at oracle.com) Date: Fri, 02 Aug 2013 09:20:40 +0000 Subject: hg: jdk8/tl/jdk: 8020191: System.getProperty("os.name") returns "Windows NT (unknown)" on Windows 8.1 Message-ID: <20130802092154.E615B48565@hg.openjdk.java.net> Changeset: 40221b09812f Author: uta Date: 2013-08-02 13:16 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40221b09812f 8020191: System.getProperty("os.name") returns "Windows NT (unknown)" on Windows 8.1 Reviewed-by: alanb, khazra, chegar ! src/windows/native/java/lang/java_props_md.c ! src/windows/resource/java.manifest From chris.hegarty at oracle.com Fri Aug 2 10:18:35 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 02 Aug 2013 11:18:35 +0100 Subject: Remove superfluous @test tags from SpliteratorTraversingAndSplittingTest In-Reply-To: References: <51FB74FA.3080003@oracle.com> Message-ID: <51FB877B.9020907@oracle.com> On 02/08/2013 10:52, Paul Sandoz wrote: > > On Aug 2, 2013, at 9:59 AM, Chris Hegarty wrote: > >> SpliteratorTraversingAndSplittingTest contains two @test tags. The second of which does not specify that the test needs to run with testng. This causes the test to fail, or have an error, when run as a batch with other tests. >> >> The second @test tag is just not needed, and the @bug should be moved to the original @test tag. >> > Ooops that is my fault, thanks for sorting this out. No Problem. > When i ran jtreg manually it did not barf, is there anyway for it to validate the meta-data? I also noticed this. Running the test explicitly seems to locate just the first @test, while running in a batch (sometimes) finds the two! Not sure why. It is also ok to have more than one @test, just in this case it would need to specify testng. -Chris. > Paul. > >> >> diff -r 29f153e11683 test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java >> --- a/test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java Fri Aug 02 08:59:37 2013 +0800 >> +++ b/test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java Fri Aug 02 09:53:00 2013 +0100 >> @@ -25,6 +25,7 @@ >> * @test >> * @summary Spliterator traversing and splitting tests >> * @run testng SpliteratorTraversingAndSplittingTest >> + * @bug 8020016 >> */ >> >> import org.testng.annotations.DataProvider; >> @@ -81,10 +82,6 @@ import static org.testng.Assert.*; >> import static org.testng.Assert.*; >> import static org.testng.Assert.assertEquals; >> >> -/** >> - * @test >> - * @bug 8020016 >> - */ >> @Test >> public class SpliteratorTraversingAndSplittingTest { >> >> -Chris. > From chris.hegarty at oracle.com Fri Aug 2 10:25:17 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 02 Aug 2013 10:25:17 +0000 Subject: hg: jdk8/tl/jdk: 8022121: Remove superfluous @test tag from SpliteratorTraversingAndSplittingTest Message-ID: <20130802102548.A0C5D48569@hg.openjdk.java.net> Changeset: 60c275e56a69 Author: chegar Date: 2013-08-02 11:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60c275e56a69 8022121: Remove superfluous @test tag from SpliteratorTraversingAndSplittingTest Reviewed-by: psandoz ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java From chris.hegarty at oracle.com Fri Aug 2 13:30:49 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 02 Aug 2013 13:30:49 +0000 Subject: hg: jdk8/tl/jdk: 8020291: j.u.c.CompletionStage; ... Message-ID: <20130802133116.5F3184856D@hg.openjdk.java.net> Changeset: 6ec910ff3ea1 Author: chegar Date: 2013-08-02 14:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ec910ff3ea1 8020291: j.u.c.CompletionStage 8020435: CompletableFuture/Basic.java fails on single core machine Reviewed-by: chegar, psandoz Contributed-by: Doug Lea

! src/share/classes/java/util/concurrent/CompletableFuture.java + src/share/classes/java/util/concurrent/CompletionStage.java ! test/ProblemList.txt ! test/java/util/concurrent/CompletableFuture/Basic.java From sean.mullan at oracle.com Fri Aug 2 13:39:43 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Fri, 02 Aug 2013 13:39:43 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20130802134021.928284856E@hg.openjdk.java.net> Changeset: 42b786f2fb99 Author: mullan Date: 2013-08-02 08:30 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/42b786f2fb99 8001319: Add SecurityPermission "insertProvider" target name Reviewed-by: vinnie ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/SecurityPermission.java + test/java/security/Security/AddProvider.java + test/java/security/Security/AddProvider.policy.1 + test/java/security/Security/AddProvider.policy.2 + test/java/security/Security/AddProvider.policy.3 Changeset: 7bbc6c2351d7 Author: mullan Date: 2013-08-02 08:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bbc6c2351d7 Merge - src/share/classes/java/net/package.html - src/share/classes/java/util/stream/StreamBuilder.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html - test/java/util/Collections/EmptySortedSet.java Changeset: 0a778e487a73 Author: mullan Date: 2013-08-02 09:38 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a778e487a73 Merge From alexey.utkin at oracle.com Fri Aug 2 14:45:26 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Fri, 02 Aug 2013 18:45:26 +0400 Subject: Review request: JDK-6518827 (process) zero length Process arguments ignored on win32 Message-ID: <51FBC606.5070603@oracle.com> Bug description: https://jbs.oracle.com/bugs/browse/JDK-6518827 http://bugs.sun.com/view_bug.do?bug_id=6518827 Here is the suggested fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-6518827/webrev.00/ Summary: Here we close the long-standing problem of the lost empty argument. Due to significant impact for legacy applications, the functionality is not active by default and needs the presence of the Security Manager, or defined in "false" the system property "jdk.lang.Process.allowAmbiguousCommands" Currently the property has the "true" value by default. We need to declare, that the property could change the default value in the next major release. Please, read 7u21, 7u25, 7u40 release notes for details. By introducing the dependence from property value we are stimulating developer for more accurate approach for argument transfer and minimizing the regression risk. New feature has the test coverage. Regards, -uta From mhall at mhcomputing.net Thu Aug 1 21:56:16 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Thu, 1 Aug 2013 14:56:16 -0700 Subject: Remaining doclint issues in java.net In-Reply-To: <51FAD089.9000805@oracle.com> References: <51F67C14.5040804@oracle.com> <51F983D2.3050501@oracle.com> <20130731213957.GA24485@mhcomputing.net> <51FAD089.9000805@oracle.com> Message-ID: <20130801215616.GA6859@mhcomputing.net> On Thu, Aug 01, 2013 at 02:18:01PM -0700, Stuart Marks wrote: > This isn't definitive, of course, but it does seem to supply some > evidence that making this change would result in a relatively minor > source incompatibility. Good, maybe it will allow a true fix to be made in this case. Matthew. From mike.duigou at oracle.com Fri Aug 2 17:20:46 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 2 Aug 2013 10:20:46 -0700 Subject: RFR: 8021591 : (s) Additional explicit null checks In-Reply-To: <51FAE9C2.8050101@oracle.com> References: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com> <51FA8584.1000702@oracle.com> <51FAE9C2.8050101@oracle.com> Message-ID: <96EA7548-3889-4D6C-A349-AF067A06B945@oracle.com> On Aug 1 2013, at 16:05 , David Holmes wrote: > On 2/08/2013 1:57 AM, Alan Bateman wrote: >> On 26/07/2013 16:31, Mike Duigou wrote: >>> Hello all; >>> >>> This patch adds some missing checks for null that, according to >>> interface contract, should be throwing NPE. It also improves the >>> existing tests to check for these cases. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8021591/0/webrev/ >>> >>> The changes to >>> src/share/classes/java/util/concurrent/ConcurrentHashMap.java will be >>> synchronized separately with the jsr166 workspace. They are part of >>> this review to avoid test failures. >>> >>> Mike >> As retainAll and removeAll are long standing methods, are there are >> cases where we might now throw NPE when we didn't previously? I'm just >> wondering if any of these need to be looked at more closely, minimally >> to get into release/compatibility notes. Yes, this would definitely be something we want to mention for the release notes. > I get a sense of deja-vu here. For retainAll/removeAll this fixes the case where you would not get NPE if the target collection is empty. We already dealt with this for some j.u.c collections - see 7123424 and then 8001575. I am not sure if this is a vote for or against continuing to add the missing NPE checks. If we decide against adding the checks I would actually push for revising the spec (make the NPE optional) to reflect the relatively common practice and possibly even remove some of the recently added NPE. Mike From brian.burkhalter at oracle.com Fri Aug 2 18:12:35 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 2 Aug 2013 11:12:35 -0700 Subject: Java 8 RFR 8022094: BigDecimal/CompareToTests and BigInteger/CompareToTests are incorrect In-Reply-To: <51FB1F53.4080701@oracle.com> References: <51FB1F53.4080701@oracle.com> Message-ID: <1AD9C51B-CAAB-45F1-93E3-4B5E100F0037@oracle.com> Hi Stuart, On Aug 1, 2013, at 7:54 PM, Stuart Marks wrote: > Looks good. Always a good idea to make sure that failures are reported properly. :-) Indeed. > It does look like the following cases are repeated, in both tests: > > {valueOf(Long.MIN_VALUE+1), valueOf(Long.MAX_VALUE), MINUS_ONE}, > {valueOf(Long.MIN_VALUE+1).negate(), valueOf(Long.MAX_VALUE), ZERO}, > > Is this right? Yes. I actually did not add any tests or test cases to BigDecimal, only fixed the intended use of the ones present. What was happening is this. Each test case was of the form {a, b, expected} where "expected" is the correct result of a.compareTo(b). Each test case was used like this: failures += compareToTest(a, b, expected); failures += compareToTest(a.negate(), b, -1); failures += compareToTest(a, b.negate(), 1); failures += compareToTest(a.negate(), b.negate(), -expected); which could instead be written as one test failures += compareToTest(this, other, expected); with four text cases {a, b, expected}, {-a, b, -1}, {a, -b, 1), {-a, -b, -expected} which is patently incorrect for some of the test cases. What I did to fix this was to remove the two middle tests for each test case and add a new test case defined as {-a, b, expected2} Another way to state this is that the original test case becomes two test cases {a, b, expected} {-a, b, expected2} and the four tests become two failures += compareToTest(a, b, expected); failures += compareToTest(a.negate(), b.negate(), -expected); So the test cases and tests are really the same as before, but the expected value is different in some instances as needed. > The first four cases are (excuse the poor cross product notation): > > {max, max-1, min, min+1} x {1, -1} compareTo max > > but then there's simply > > {min} x {1, -1} compareTo min > > followed by the duplicate > > {min+1} x {1, -1} compareTo max > > Just following the pattern, I'd expect > > {max, max-1, min, min+1} x {1, -1} compareTo min > > though I'm not sure that all of these cases are necessary. You are absolutely correct and I have updated the webrev accordingly: http://cr.openjdk.java.net/~bpb/8022094/ Now only a Reviewer approval is needed. Thanks, Brian From xueming.shen at oracle.com Fri Aug 2 20:20:17 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 02 Aug 2013 13:20:17 -0700 Subject: RFR: 8015666: test/tools/pack200/TimeStamp.java failing In-Reply-To: <51D31BF4.3000900@oracle.com> References: <51C34E6D.4000502@oracle.com> <51CC7099.2050007@oracle.com> <51CC7291.1080602@oracle.com> <51CDA1ED.9040302@oracle.com> <51D31BF4.3000900@oracle.com> Message-ID: <51FC1481.2020203@oracle.com> Kumar, Alan, Here is the latest webrev of the changes based on the latest CCC. http://cr.openjdk.java.net/~sherman/8015666/webrev -Sherman On 07/02/2013 11:29 AM, Xueming Shen wrote: > On 06/28/2013 07:47 AM, Kumar Srinivasan wrote: >> Some nits while reading the changes: >> 1. ZipEntry.java >> a. typo: >> >> + * Sets the laste access time of the entry. >> >> >> b. extra space >> >> + case EXTID_ZIP64 : >> >> 2. ZipOutputStream.java >> I think it would be nice to have the flags 0x1, 0x2 and 0x4 defined >> as constants, this will also help a casual reader as to what this means. >> >> >> Besides my previous concern with finish(), everything else appears to be ok. > > Kumar, > > I have the dostime "cached" in XEntry, so the writeCEN() and writeLOC() will > always write out the same local msdos time. The cache should help the perf > a little, as the javaToDosTime() now only invoked once for the same entry. > > Nothing needs to be updated in unpack side now. (I took a look at the API, > it appears there is no way to do anything on unpack side to workaround > this issue, without the possibility of breaking someone's code) > > http://cr.openjdk.java.net/~sherman/8015666/webrev/ > > -Sherman > >> >> Kumar >> >> >>> On 06/27/2013 10:04 AM, Kumar Srinivasan wrote: >>>> Hi Sherman, >>>> >>>> I started looking at this, my initial comment, the Unpacker.unpack >>>> does not close its output and we allow multiple pack files to be concatenated, >>>> I am assuming out.finish() will allow further jar files to be appended ? >>>> or would this cause a problem ? >>> >>> No, out.finish() will not allow further entry appending. Then, it appears >>> we need to have a different approach to "finish" the Jar/ZipOutputStream. >>> What need to be done here is that either out.close/finish() need to be >>> invoked under the UTC locale as well (to output the time stamps in cen >>> table correctly). This is another "incompatible" change of the previous >>> change, in which the msdosTime<->javaTime conversion no longer >>> occurs during the ZipEntry.set/getTime(), but during the read and write >>> the ZipEntry from/to the zip file. >>> >>> -Sherman >>> >>> >>>> >>>> Kumar >>>> >>>>> Hi, >>>>> >>>>> The zip time related changes[1] I pushed back last month appears >>>>> to have the compatibility risk of breaking existing code. The main >>>>> idea in that changeset is to use the more accurate and timezone >>>>> insensitive utc time stored in the extra field for the ZipEntry.set/getTime() >>>>> if possible. However it turns out the reality is that the code out there >>>>> might have already had some interesting workaround/hack solution >>>>> to workaround the problem that the time stamp stored in the "standard' >>>>> zip entry header is a MS-DOS standard date/time, which is a "local >>>>> date/time" and sensitive to timezone, in which, if the zip is archived >>>>> in time zone A (our implementation converts the "java" time to dos >>>>> time by using the default tz A) and then transferred/un-archived in >>>>> a different zone B (use default tz B to convert back to java time), we >>>>> have a time stamp mess up. The "workaround" from pack200 for this >>>>> issue when pack/unpacking a jar file is to "specify/recommend/suggest" >>>>> in its spec that the "time zone" in a jar file entry is assumed to be "UTC", >>>>> so the pack/unpack200 implementation set the "default time" to utc >>>>> before the pack/unpack and set it back to the original after that. It worked >>>>> "perfectly" for a roundtrip pack/unpacking, until the changeset [2], in >>>>> which ZipEntry.getTime() (packing) returns a real utc time and the following >>>>> ZipEntry.setTime() (unpacking), then mess up the MS-DOS date/time >>>>> entry, this is the root cause of this regression. >>>>> >>>>> Given the facts that >>>>> (1) there are actually two real physical time stamps in a zip file header, >>>>> one is in the date/time fields, which is MS-DOS-local-date/time-with-2- >>>>> seconds-granularity , one is in the extra data field, which is UTC-1-second >>>>> -granularity >>>>> (2) and there are applications over there that have dependency on the >>>>> MS-DOS date/time stamp. >>>>> >>>>> I'm proposing the following approach to add the functionality of supporting >>>>> the "utc-date/time-with-1-second granularity" and keep the old behavior >>>>> of the get/setTime() of the ZipEntry. >>>>> >>>>> (1) keep the time/setTime()/getTime() for the MS-DOS standard date/time. >>>>> To set via the old setTime() will only store the time into zip's standard >>>>> date/time field, which is in MS-DOS date/time. And getTime() only returns >>>>> the date/time from that field, when read from the zip file/stream. >>>>> (2) add mtime/set/getLastModifiedTime() to work on the UTC time fields, >>>>> and the last modified time set via the new method will also set the "time", >>>>> and the getLastModifiedTime() also returns the "time", if the UTC time >>>>> stamp fields are not set in the zip file header. The idea is that for the new >>>>> application, the recommendation is to use ZipEntry.set/getLastModifiedTime() >>>>> for better/correct time stamp, but the existing apps keep the same behavior. >>>>> (3) jar and ZipOutputStream are updated to use the set/getLastModifiedTime(). >>>>> (4) Pack/unpack continues to use the set/getTime(), so the current workaround >>>>> continues work. I will leave this to Kuma to decide how it should be handled >>>>> going forward. (there are two facts need to be considered here, a) the >>>>> existing jar file might not have the utc time instored, and b) all "extra" data >>>>> are wiped out during the pack/unpacking process) >>>>> (5) additionally add another pair of atime/get/setLastAccessTime and >>>>> ctime/get/setCreationTime(). >>>>> (6) The newly added 3 pairs of the m/a/ctime get/set methods use the "new" >>>>> nio FileTime, instead of the "long". This may add some additional cost of >>>>> conversion when working with them, but may also help improve the >>>>> performance if the time stamps are directly from nio file system when >>>>> get/set XYZTime. Good/bad? >>>>> >>>>> http://cr.openjdk.java.net/~sherman/8015666/webrev/ >>>>> >>>>> Comment, option and suggestion are appreciated. >>>>> >>>>> -Sherman >>>>> >>>>> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90df6756406f >>>> >>> >> > From xueming.shen at oracle.com Fri Aug 2 20:53:58 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 02 Aug 2013 13:53:58 -0700 Subject: RFR: 6614237: missing codepage Cp290 at java runtime Message-ID: <51FC1C66.8000108@oracle.com> Masayoshi, Would you please help review this change? The changeset also adds the requested Cp300. webrev: http://cr.openjdk.java.net/~sherman/6614237/webrev/ original mapptables: http://cr.openjdk.java.net/~sherman/6614237/290/ http://cr.openjdk.java.net/~sherman/6614237/300/ regression tests: http://cr.openjdk.java.net/~sherman/6614237/closed Thanks! -Sherman From nicholas+openjdk at nicholaswilliams.net Fri Aug 2 21:15:01 2013 From: nicholas+openjdk at nicholaswilliams.net (Nick Williams) Date: Fri, 2 Aug 2013 16:15:01 -0500 Subject: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass) In-Reply-To: <51F7DCD0.1030306@gmx.org> References: <51F7AEEE.4040305@gmail.com> <51F7BD75.4030708@gmx.org> <51F7CACD.2070703@gmail.com> <51F7DCD0.1030306@gmx.org> Message-ID: <4946C916-1208-488C-8A05-C4E7763D15FC@nicholaswilliams.net> I have patch for a public API for this just about complete. I'm going to re-run unit tests tonight and then submit it. But I need some help. I quickly figured out that I can't just `hg diff` from the root directory, because of the whole "forrest" thing. Ick. So, is there a specific way that I need to generate a diff to work with how y'all are using Mercurial? Or do I just need to `hg diff` in each sub-repository under the main repository and put all of the diff files somewhere? Some guidance on how to "properly" create a diff in this project would be appreciated. :-) Nick On Jul 30, 2013, at 10:33 AM, Jochen Theodorou wrote: > Am 30.07.2013 16:16, schrieb Peter Levart: >> >> On 07/30/2013 03:19 PM, Jochen Theodorou wrote: >>> Am 30.07.2013 14:17, schrieb Peter Levart: >>> [...] >>>> So what would give Groovy or other language runtimes headaches when all >>>> there was was a parameter-less getCallerClass() API? Aren't the >>>> intermediate frames inserted by those runtimes controlled by the >>>> runtimes? Couldn't the "surface" runtime-inserted methods capture the >>>> caller and pass it down? I guess the problem is supporting calling the >>>> caller-sensitive methods like Class.forName(String) and such which don't >>>> have the overloaded variant taking caller Class or ClassLoader as an >>>> argument... >>> Speaking for Groovy... >>> those intermediate frames are runtime controlled, yes, but passing down >>> the caller class is exactly the problem. Imagine I would suggest that >>> each and every method definition in Java automatically gets an >>> additional parameter for the caller class, just to have access to it >>> inside the method. You would not accept that for Java, would you? And so >>> we cannot accept that for Groovy if we want to keep integration with >>> Java... >> >> Are you talking about internal Groovy implementation (the >> runtime-inserted methods) or the publicly visible API? > > that's the problem, it is a mix, some internal, other not. We are going to change that in Groovy 3 > >> One solution for >> internal implementation of Groovy could be (speaking by heart since I >> don't know the internals of Groovy) for the "surface" public API method >> which doesn't have to have the special caller parameter, to capture the >> caller with getCallerClass() parameterless API (possibly enclosed with a >> quick check confirming that it might actually be needed) and bind it to >> a ThreadLocal, then use this ThreadLocal down at the end... > > confirming that it might actually be needed is a problem. In the old fallback path we don't know what we call until after we are deep in runtime code, and there it is too late. In the other paths we could mark those methods in a @CallerSensitive style and do it in that case only. > >>> and the good integration with Java is one of the key points of >>> Groovy. Even if we make something like that @CallerSensitive and add the >>> parameter only in those cases, we break being able to override methods. >> >> I guess I don't know every Groovy need to obtain the caller class. I >> thought the problem was to support calling caller-sensitive methods in >> Java API (like Class.forName(String)) from within Groovy code, where >> there are runtime-inserted frames between the "call-site" and the target >> method. Are there any other needs? > > ok, there is a misunderstanding... > > if we call a Java implemented method from Groovy, which is using getCallerClass() it may or may not work. In general this does not work and our problem is not about that at all. With the change to let getCallerClass() ignore some reflective frames it will work actually better as long as we use our custom callsite caching implementation, it will not work if indy is used or the fallback path. > > To be able to call a method Class#forName(String), we need to "replace" it with an implementation of our own, which we do with an approach similar to extension methods (only that ours can hide existing implementation methods for groovy). And in there we need to get to the caller class > > Our problem though is @Grab which is an annotation to add elements to the classpath while running a script. > >>> Plus, before Groovy3 is not done we have to support several call paths. >>> And the oldest one, which is still a fallback, does not support >>> transporting the caller class through the runtime layers at all. >>> Changing here is a breaking change. >> >> Could you describe those call-paths? Examples of Groovy code and to what >> it gets translated (equivalent Java code at call site) with a brief >> description of what each intermediate layer (between the call-site and >> the target method) does and at which point the caller class is extracted... > > the code generated at the call site depends on several factors actually... The call site code itself is usually not very informative > > I start with Groovy 1.0, since that is basically the fallback path. Here this.foo() translates more or less to > ScriptBytecodeAdapter.invokeMethod0(staticCallerClass, this,"foo") > which basically does this.getMetaClass().invokeMethod(staticCallerClass, this, "foo"). The problem is that the meta class might be user supplied and the code executed in invokeMethod as well. The invocation is then finally done by reflection. That means we have frames from ScriptBytecodeAdapter, from the meta class, as well as maybe frames from a custom meta class and reflection frames. At the level of ScriptBytecodeAdapter there is a means of transporting the caller class, but that is the static one. Once there is a subclass, this information is different from what is needed here and it cannot simply be exchanged. Even if the bytecode adapter is changed, we cannot change the public API for MetaClass#invokeMethod now. And then the information would be lost. > > In later versions of Groovy (since 1.6) we introduced a custom call site caching technique, which uses runtime generated classes to create a helper class per call site and is then used for invocation. At the callsite we basically have something like callsiteArray[i].invoke(..). Here again the staticCallerClass can be found. In this version we are able to "get" the method we want to invoke, before invoking it (bypassing MetaClass#invokeMethod). But to be able to get the method, certain conditions have to be met (like no user supplied meta class). If they are not met, then we do basically the same path as in 1.0, only that we don't use ScriptBytecodeAdapter. Instead We use our CallSite class as entrance point, which then makes the call to the meta class. In the "efficent" case we have now frames from the callsite handling code between the callsite and the target method only. This includes reflection in the first instantiation, later the generated class is used so it reduces to two frames of which one is the Callsite entrance point, the other a frame form the generated method. In the fallback case we have frames from the callsite handling code, plus meta class code, plus reflection of course. Again the fallback case prevents us from transporting the caller information to the target method. If we ignore the fallback case, then we could here maybe use the Threadlocal information. It will require a new callsite interface for the bytecode though, meaning this code will not work for precompiled grovvy of older version, excluding from getting into Groovy 2.1.x, since it would be a breaking change. The earliest version for that would be Groovy 2.2.0, which is almost in RC now. Effectively it would mean we would have to do a 2.3.0 very soon after most probably. > > In Groovy 2 we added an indy implementation, which replaces the callsite caching code. At the callsite we have here basically invokedynamic "foo" with IndyInterface#bootstrap. bootstrap will first introduce a target for IndyInterface#selectMethod, since I need the runtime types instead of the static ones. The static caller class information is here part of the bootstrap method as Lookup object, added by invokedynamic itself. After selectMethod is done we have an initial invocation using invokeExact and later invocations by the handle stored in the callsite. Of course the same conditions as for the callsite caching above have to be met, meaning the fallback path might appear. That makes initially one IndyInterface frame, then invokedynamic and lambda related frames, then optionally the traget method, or in the fallback case the meta class frames plus reflection > > > bye Jochen > > -- > Jochen "blackdrag" Theodorou - Groovy Project Tech Lead > blog: http://blackdragsview.blogspot.com/ > german groovy discussion newsgroup: de.comp.lang.misc > For Groovy programming sources visit http://groovy-lang.org > From joe.darcy at oracle.com Fri Aug 2 21:19:21 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 02 Aug 2013 21:19:21 +0000 Subject: hg: jdk8/tl/jdk: 6476168: (fmt) Inconsistency formatting subnormal doubles with hexadecimal conversion Message-ID: <20130802212009.363134859F@hg.openjdk.java.net> Changeset: 33617583c545 Author: bpb Date: 2013-07-31 10:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33617583c545 6476168: (fmt) Inconsistency formatting subnormal doubles with hexadecimal conversion Summary: Update specification to match implementation. Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/util/Formatter.java ! test/java/util/Formatter/Basic-X.java.template ! test/java/util/Formatter/Basic.java ! test/java/util/Formatter/BasicDouble.java From stuart.marks at oracle.com Fri Aug 2 21:38:33 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 02 Aug 2013 14:38:33 -0700 Subject: Remaining doclint issues in java.net In-Reply-To: <51FB7DC9.9000605@oracle.com> References: <51F67C14.5040804@oracle.com> <51F983D2.3050501@oracle.com> <20130731213957.GA24485@mhcomputing.net> <51FAD089.9000805@oracle.com> <51FB7DC9.9000605@oracle.com> Message-ID: <51FC26D9.1050800@oracle.com> On 8/2/13 2:37 AM, Chris Hegarty wrote: > On 01/08/2013 22:18, Stuart Marks wrote: >> SocketAddress overloads. Two of them were within methods that declared >> "throws Exception." The third was within a try/catch block that catches >> IOException. None of the three cases would suffer a source incompatibility. > > I cannot comment on the code you are talking about, but removing 'throws SE' > from these constructors will affect anyone that is catching IOE ( since SE is a > subclass of IOE ). Simple test: [...] You're correct, of course, that constructing a new DatagramPacket within a try/catch of IOException would suffer the source incompatibility. I had neglected to mention, though, that the try/catch(IOException) code that I looked at also did a bunch of other IOException-throwing stuff within the try block. So in that particular case the code wouldn't have had a compatibility issue. >> This isn't definitive, of course, but it does seem to supply some >> evidence that making this change would result in a relatively minor >> source incompatibility. > > Given the above, I still agree with the sentiment here. I will file a bug and > proceed with the necessary changes to remove SE. Great! Glad to hear it. Thanks. s'marks From stuart.marks at oracle.com Fri Aug 2 21:40:54 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 02 Aug 2013 14:40:54 -0700 Subject: Java 8 RFR 8022094: BigDecimal/CompareToTests and BigInteger/CompareToTests are incorrect In-Reply-To: <1AD9C51B-CAAB-45F1-93E3-4B5E100F0037@oracle.com> References: <51FB1F53.4080701@oracle.com> <1AD9C51B-CAAB-45F1-93E3-4B5E100F0037@oracle.com> Message-ID: <51FC2766.4070201@oracle.com> On 8/2/13 11:12 AM, Brian Burkhalter wrote: > You are absolutely correct and I have updated the webrev accordingly: > > http://cr.openjdk.java.net/~bpb/8022094/ > > Now only a Reviewer approval is needed. > > Thanks, > > Brian Updated webrev looks good. Thanks. s'marks From Alan.Bateman at oracle.com Fri Aug 2 22:52:57 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 02 Aug 2013 15:52:57 -0700 Subject: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass) In-Reply-To: <4946C916-1208-488C-8A05-C4E7763D15FC@nicholaswilliams.net> References: <51F7AEEE.4040305@gmail.com> <51F7BD75.4030708@gmx.org> <51F7CACD.2070703@gmail.com> <51F7DCD0.1030306@gmx.org> <4946C916-1208-488C-8A05-C4E7763D15FC@nicholaswilliams.net> Message-ID: <51FC3849.30105@oracle.com> On 02/08/2013 14:15, Nick Williams wrote: > I have patch for a public API for this just about complete. I'm going to re-run unit tests tonight and then submit it. But I need some help. > > I quickly figured out that I can't just `hg diff` from the root directory, because of the whole "forrest" thing. Ick. > > So, is there a specific way that I need to generate a diff to work with how y'all are using Mercurial? Or do I just need to `hg diff` in each sub-repository under the main repository and put all of the diff files somewhere? > > Some guidance on how to "properly" create a diff in this project would be appreciated. :-) > > Nick If you haven't already, then make sure to read the "How to contribute" page [1]. For the API proposal then I would suggest starting a discussion so that you can get input and a sense for whether you will get a sponsor. As regards publishing patches then attach hg diffs or publishing a webrev (on a http server) for each of the changes repos should be fine. -Alan [1] http://openjdk.java.net/contribute/ From martinrb at google.com Fri Aug 2 22:57:04 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 2 Aug 2013 15:57:04 -0700 Subject: RFR doclint issues in j.u.Deque & Queue In-Reply-To: <51FA39D0.1060309@oracle.com> References: <51FA39D0.1060309@oracle.com> Message-ID: On Thu, Aug 1, 2013 at 3:34 AM, Chris Hegarty wrote: > These changes are already committed in the jsr166 CVS, this is a request > to pull them into jdk8. > > Specdiff has been run, and there is nothing surprising. > The doclint issues are specifically around the addition of a caption to > the tables, the remaining changes are cleanup, -> {@code ..}, etc. > > Note: there are some minor doc updates around throwing an > IllegalStateException if no space is currently available in Deque, which is > already part of the spec. > > Of course, I'm also happy to see the changes from jsr166 making it into jdk8. > Martin, Doug, > The 166 CVS is trivially missing 6546713, > http://cr.openjdk.java.net/~**mduigou/6546713/0/webrev/src/** > share/classes/java/util/Deque.**java.sdiff.html. > Once the changes below are in jdk8, you can easily sync with the 8 version, > or apply the diffs from the webrev link above. > > jsr166 CVS now also has these changes to Deque.java. Although....... I am not entirely happy about them because they create broken links if jsr166 is built independently, i.e. not as part of openjdk, and I don't see an easy way to fix that. But this is one set of broken links we can just live with. > I have already reviewed these changes, but more reviewers are welcome. > From brian.burkhalter at oracle.com Fri Aug 2 23:13:22 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 2 Aug 2013 16:13:22 -0700 Subject: Reviewer+Committer needed (Re: Java 8 RFR 8022094: BigDecimal/CompareToTests and BigInteger/CompareToTests are incorrect) In-Reply-To: <51FC2766.4070201@oracle.com> References: <51FB1F53.4080701@oracle.com> <1AD9C51B-CAAB-45F1-93E3-4B5E100F0037@oracle.com> <51FC2766.4070201@oracle.com> Message-ID: <3A76590A-7A96-40D2-B341-7E9CC4D08884@oracle.com> Thanks, Stuart. I still need _Reviewer_ approval for this and subsequent to that a Committer. Thanks, Brian On Aug 2, 2013, at 2:40 PM, Stuart Marks wrote: > On 8/2/13 11:12 AM, Brian Burkhalter wrote: >> You are absolutely correct and I have updated the webrev accordingly: >> >> http://cr.openjdk.java.net/~bpb/8022094/ >> >> Now only a Reviewer approval is needed. >> >> Thanks, >> >> Brian > > Updated webrev looks good. Thanks. From naoto.sato at oracle.com Fri Aug 2 22:45:52 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 02 Aug 2013 22:45:52 +0000 Subject: hg: jdk8/tl/jdk: 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X Message-ID: <20130802224616.147DA485A2@hg.openjdk.java.net> Changeset: 883cc296ec89 Author: bchristi Date: 2013-08-02 15:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/883cc296ec89 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X Summary: On Mac, default to UTF-8 if no environmental hints are available Reviewed-by: naoto, ddehaven ! src/solaris/native/java/lang/java_props_md.c + test/java/lang/System/MacEncoding/ExpectedEncoding.java + test/java/lang/System/MacEncoding/MacJNUEncoding.sh + test/java/lang/System/MacEncoding/TestFileEncoding.java - test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java - test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh From brian.burkhalter at oracle.com Sat Aug 3 00:02:52 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 2 Aug 2013 17:02:52 -0700 Subject: RFR: two minor changes to BigIntegerTest and MutableBigInteger In-Reply-To: <058F77C2-13A5-4537-A22D-42E6F36C18C9@oracle.com> References: <058F77C2-13A5-4537-A22D-42E6F36C18C9@oracle.com> Message-ID: <6FB1C208-36AA-45DD-8A86-1DD21B79C411@oracle.com> I filed 8022180 to track this. Thanks, Brian On Aug 1, 2013, at 4:57 PM, Brian Burkhalter wrote: > Hi Tim, > > Thanks for keeping an eye on this and for the patches. We'll need to have an issue on file to track this. I can take care of that tomorrow. > > Brian > > On Aug 1, 2013, at 4:47 PM, Tim Buktu wrote: > >> I propose the patch below to fix a theoretical bug in >> divideAndRemainderBurnikelZiegler(). > From brian.burkhalter at oracle.com Sat Aug 3 00:48:38 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 2 Aug 2013 17:48:38 -0700 Subject: RFC 8010430: Math.round has surprising behavior for odd values of ulp 1 Message-ID: This request for comment concerns this issue: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010430. The behavior in question occurs when the value of the unbiased exponent is equal to the signficand precision excluding the implicit leading bit, i.e., 23 in the case of float [1] or 52 in the case of double[2] , and the least significant bit in the significand is unity. As Math.round(a) is defined to be Math.floor(a+0.5) in these cases, the intermediate sum is calculated using the round-to-nearest rule so that the return value does not equal the parameter when the parameter is odd, even though the latter is a mathematical integer. There are in effect two ways to resolve this issue: A) Change the implementation to return (int)a or (long)a if the unbiased exponent of the value's floating point representation is greater than 22 or 51, respectively. B) Change the specification to state, or add an implementation note stating that the behavior is defined to be round(a) = floor(a+0.5F) where round-to-nearest is applied to the intermediate sum. Note that for comparison, GCC-compiled C code on Mac OS X and Ubuntu 12.04 follows the behavior of option A. Thanks, Brian [1] https://en.wikipedia.org/wiki/Single_precision_floating-point_format [2] https://en.wikipedia.org/wiki/Double-precision_floating-point_format From david.holmes at oracle.com Sat Aug 3 11:07:22 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 03 Aug 2013 21:07:22 +1000 Subject: RFR: 8021591 : (s) Additional explicit null checks In-Reply-To: <96EA7548-3889-4D6C-A349-AF067A06B945@oracle.com> References: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com> <51FA8584.1000702@oracle.com> <51FAE9C2.8050101@oracle.com> <96EA7548-3889-4D6C-A349-AF067A06B945@oracle.com> Message-ID: <51FCE46A.2050404@oracle.com> On 3/08/2013 3:20 AM, Mike Duigou wrote: > > On Aug 1 2013, at 16:05 , David Holmes wrote: > >> On 2/08/2013 1:57 AM, Alan Bateman wrote: >>> On 26/07/2013 16:31, Mike Duigou wrote: >>>> Hello all; >>>> >>>> This patch adds some missing checks for null that, according to >>>> interface contract, should be throwing NPE. It also improves the >>>> existing tests to check for these cases. >>>> >>>> http://cr.openjdk.java.net/~mduigou/JDK-8021591/0/webrev/ >>>> >>>> The changes to >>>> src/share/classes/java/util/concurrent/ConcurrentHashMap.java will be >>>> synchronized separately with the jsr166 workspace. They are part of >>>> this review to avoid test failures. >>>> >>>> Mike >>> As retainAll and removeAll are long standing methods, are there are >>> cases where we might now throw NPE when we didn't previously? I'm just >>> wondering if any of these need to be looked at more closely, minimally >>> to get into release/compatibility notes. > > Yes, this would definitely be something we want to mention for the release notes. > >> I get a sense of deja-vu here. For retainAll/removeAll this fixes the case where you would not get NPE if the target collection is empty. We already dealt with this for some j.u.c collections - see 7123424 and then 8001575. > > I am not sure if this is a vote for or against continuing to add the missing NPE checks. If we decide against adding the checks I would actually push for revising the spec (make the NPE optional) to reflect the relatively common practice and possibly even remove some of the recently added NPE. It was merely an observation that we have already trodden this path. But if it were a vote I would vote to throw and add a note to the compatibility docs. A spec that is loosened to say may throw NPE is useless because anyone who relies on an implementation not throwing will be bitten by an implementation that does. Cheers, David ----- > Mike > From Alan.Bateman at oracle.com Sat Aug 3 16:32:03 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 03 Aug 2013 09:32:03 -0700 Subject: Reviewer+Committer needed (Re: Java 8 RFR 8022094: BigDecimal/CompareToTests and BigInteger/CompareToTests are incorrect) In-Reply-To: <3A76590A-7A96-40D2-B341-7E9CC4D08884@oracle.com> References: <51FB1F53.4080701@oracle.com> <1AD9C51B-CAAB-45F1-93E3-4B5E100F0037@oracle.com> <51FC2766.4070201@oracle.com> <3A76590A-7A96-40D2-B341-7E9CC4D08884@oracle.com> Message-ID: <51FD3083.4060704@oracle.com> On 02/08/2013 16:13, Brian Burkhalter wrote: > Thanks, Stuart. > > I still need _Reviewer_ approval for this and subsequent to that a Committer. > > Thanks, > > Brian > The updated version looks good to me too, I can push this for you later today. -Alan From Alan.Bateman at oracle.com Sun Aug 4 02:03:01 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 03 Aug 2013 19:03:01 -0700 Subject: RFR: 8015666: test/tools/pack200/TimeStamp.java failing In-Reply-To: <51FC1481.2020203@oracle.com> References: <51C34E6D.4000502@oracle.com> <51CC7099.2050007@oracle.com> <51CC7291.1080602@oracle.com> <51CDA1ED.9040302@oracle.com> <51D31BF4.3000900@oracle.com> <51FC1481.2020203@oracle.com> Message-ID: <51FDB655.2070706@oracle.com> On 02/08/2013 13:20, Xueming Shen wrote: > Kumar, Alan, > > Here is the latest webrev of the changes based on the latest CCC. > > http://cr.openjdk.java.net/~sherman/8015666/webrev > > -Sherman I went through the latest webrev and the spec and implementation looks good. I still have a lingering concern about the increase in ZipEntry but other API alternative aren't appealing. A minor comment is that FileTime defines toMillis and fromMillis that might be nicer to use. -Alan. From alan.bateman at oracle.com Sun Aug 4 02:14:50 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 04 Aug 2013 02:14:50 +0000 Subject: hg: jdk8/tl/jdk: 8022094: BigDecimal/CompareToTests and BigInteger/CompareToTests are incorrect Message-ID: <20130804021551.9BF2A485B9@hg.openjdk.java.net> Changeset: dd1040690e31 Author: bpb Date: 2013-08-02 11:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd1040690e31 8022094: BigDecimal/CompareToTests and BigInteger/CompareToTests are incorrect Summary: Fail test if errors; fix test values; port BigDecimal version to BigInteger Reviewed-by: smarks, alanb Contributed-by: Brian Burkhalter ! test/java/math/BigDecimal/CompareToTests.java ! test/java/math/BigInteger/CompareToTests.java From joe.darcy at oracle.com Mon Aug 5 01:04:41 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 04 Aug 2013 18:04:41 -0700 Subject: RFR JDK 8: 8022190 Fix varargs lint warnings in the JDK Message-ID: <51FEFA29.9000008@oracle.com> Hello, Please review this fix for 8022190: Fix varargs lint warnings in the JDK http://cr.openjdk.java.net/~darcy/8022190.0/ Full patch below. While the @SafeVarargs annotation generally suppresses compiler warnings about methods, when the varargs lint option is enabled, javac does some checking of the body to see if it is indeed safe. If it cannot be proven safe, javac will issue a warning. The the four cases below, javac is unable to determine that the methods are safe. The @SuppressWarnings("varargs") annotations added below help javac out in this regard. Thanks, -Joe diff -r 33617583c545 src/share/classes/java/util/stream/Stream.java --- a/src/share/classes/java/util/stream/Stream.java Wed Jul 31 10:53:33 2013 -0700 +++ b/src/share/classes/java/util/stream/Stream.java Sun Aug 04 18:02:15 2013 -0700 @@ -827,6 +827,7 @@ * @return the new stream */ @SafeVarargs + @SuppressWarnings("varargs") // Creating a stream for an array is safe public static Stream of(T... values) { return Arrays.stream(values); } diff -r 33617583c545 src/share/classes/javax/swing/SwingWorker.java --- a/src/share/classes/javax/swing/SwingWorker.java Wed Jul 31 10:53:33 2013 -0700 +++ b/src/share/classes/javax/swing/SwingWorker.java Sun Aug 04 18:02:15 2013 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -405,6 +405,7 @@ * */ @SafeVarargs + @SuppressWarnings("varargs") // Passing chunks to add is safe protected final void publish(V... chunks) { synchronized (this) { if (doProcess == null) { diff -r 33617583c545 src/share/classes/sun/reflect/annotation/AnnotationParser.java --- a/src/share/classes/sun/reflect/annotation/AnnotationParser.java Wed Jul 31 10:53:33 2013 -0700 +++ b/src/share/classes/sun/reflect/annotation/AnnotationParser.java Sun Aug 04 18:02:15 2013 -0700 @@ -88,6 +88,7 @@ * @param selectAnnotationClasses an array of annotation types to select when parsing */ @SafeVarargs + @SuppressWarnings("varargs") // selectAnnotationClasses is used safely static Map, Annotation> parseSelectAnnotations( byte[] rawAnnotations, ConstantPool constPool, diff -r 33617583c545 src/share/classes/sun/swing/AccumulativeRunnable.java --- a/src/share/classes/sun/swing/AccumulativeRunnable.java Wed Jul 31 10:53:33 2013 -0700 +++ b/src/share/classes/sun/swing/AccumulativeRunnable.java Sun Aug 04 18:02:15 2013 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -121,6 +121,7 @@ * @param args the arguments to accumulate */ @SafeVarargs + @SuppressWarnings("varargs") // Copying args is safe public final synchronized void add(T... args) { boolean isSubmitted = true; if (arguments == null) { From weijun.wang at oracle.com Mon Aug 5 01:28:17 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 05 Aug 2013 09:28:17 +0800 Subject: Code review request: 8021788: JarInputStream doesn't provide certificates for some file under META-INF Message-ID: <51FEFFB1.2040506@oracle.com> Please take a look at http://cr.openjdk.java.net/~weijun/8021788/webrev.00/ The problem is that the method treats no META-INF entry as normal. If we can be sure that MANIFEST.MF and signature-related files are always at the beginning, we can safely treat an entry normal when we have done with those. Thanks Max From Alan.Bateman at oracle.com Mon Aug 5 02:53:22 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 04 Aug 2013 19:53:22 -0700 Subject: RFR JDK 8: 8022190 Fix varargs lint warnings in the JDK In-Reply-To: <51FEFA29.9000008@oracle.com> References: <51FEFA29.9000008@oracle.com> Message-ID: <51FF13A2.7080509@oracle.com> On 04/08/2013 18:04, Joe Darcy wrote: > Hello, > > Please review this fix for > > 8022190: Fix varargs lint warnings in the JDK > http://cr.openjdk.java.net/~darcy/8022190.0/ > > Full patch below. > > While the @SafeVarargs annotation generally suppresses compiler > warnings about methods, when the varargs lint option is enabled, javac > does some checking of the body to see if it is indeed safe. If it > cannot be proven safe, javac will issue a warning. > > The the four cases below, javac is unable to determine that the > methods are safe. The @SuppressWarnings("varargs") annotations added > below help javac out in this regard. > > Thanks, > > -Joe This looks okay to me (although I have to admit that I initially scratched my head as to why the @SafeVarargs wasn't enough). -Alan. From masayoshi.okutsu at oracle.com Mon Aug 5 05:17:19 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Mon, 05 Aug 2013 14:17:19 +0900 Subject: RFR: 6614237: missing codepage Cp290 at java runtime In-Reply-To: <51FC1C66.8000108@oracle.com> References: <51FC1C66.8000108@oracle.com> Message-ID: <51FF355F.6050005@oracle.com> Hi Sherman, IANA seems to define the following aliases for IBM290. cp290 EBCDIC-JP-kana csIBM290 The alias table should include EBCDIC-JP-kana and csIBM290 as well? Otherwise, the changes look good to me. Thanks, Masayoshi On 8/3/2013 5:53 AM, Xueming Shen wrote: > Masayoshi, > > Would you please help review this change? The changeset also adds the > requested Cp300. > > webrev: > http://cr.openjdk.java.net/~sherman/6614237/webrev/ > > original mapptables: > http://cr.openjdk.java.net/~sherman/6614237/290/ > http://cr.openjdk.java.net/~sherman/6614237/300/ > > regression tests: > http://cr.openjdk.java.net/~sherman/6614237/closed > > Thanks! > -Sherman > From stevenschlansker at gmail.com Mon Aug 5 05:21:10 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Sun, 4 Aug 2013 22:21:10 -0700 Subject: Dismal performance of String.intern() In-Reply-To: <51B6EDAE.3080300@oracle.com> References: <51B6EDAE.3080300@oracle.com> Message-ID: <20130804222110.3b032f4e@luminol> On Tue, 11 Jun 2013 10:28:14 +0100 Alan Bateman wrote: > On 10/06/2013 19:06, Steven Schlansker wrote: > > Hi core-libs-dev, > > > > While doing performance profiling of my application, I discovered > > that nearly 50% of the time deserializing JSON was spent within > > String.intern(). I understand that in general interning Strings is > > not the best approach for things, but I think I have a decent use > > case -- the value of a certain field is one of a very limited > > number of valid values (that are not known at compile time, so I > > cannot use an Enum), and is repeated many millions of times in the > > JSON stream. > > > Have you run with -XX:+PrintStringTableStatistics? Might be > interesting if you can share the output (it is printed just before > the VM terminates). > > There are also tuning knobs such as StringTableSize and would be > interesting to know if you've experimented with. > > -Alan. Hi everyone, Thanks again for your useful advice. I definitely misjudged the difficulty and complexity of working with methods that directly bridge the Java <-> C++ "gap"! As such, it took me way longer to get to this than I expected... That said, I think I have very good results to report. OpenJDK8 is already *significantly* better than OpenJDK 7 was, but still can be better. Here is the patch I have at the moment: https://gist.github.com/stevenschlansker/6153643 I used oprofile with oprofile-jit to identify the hot spots in the benchmark code as being java_lang_String::equals() and java_lang_String::as_unicode_string. Both of these methods have hand-written loops that copy or compare jchar arrays. The problem is that in -fastdebug or -slowdebug releases, this is one method call per character (the function is not inlined). Even in -release builds, it seems that this is significantly slower than the libc memcpy() or memcmp() functions which can use SSE4 (or other related technologies). My patch adds new methods, char_cmp and char_cpy, which delegate to the mem* functions instead of using hand-written loops. The micro-benchmark results are very good for such a small change. On fastdebug, before: Benchmark Mode Thr Cnt Sec Mean Mean error Units o.s.b.InternBenchmark.testLongStringChmIntern sample 1 2819 5 1.780 0.184 msec/op o.s.b.InternBenchmark.testLongStringJdkIntern sample 1 343 5 14.571 0.310 msec/op o.s.b.InternBenchmark.testLongStringNoIntern sample 1 8712 5 0.526 0.138 msec/op o.s.b.InternBenchmark.testShortStringChmIntern sample 1 4427 5 1.133 0.121 msec/op o.s.b.InternBenchmark.testShortStringJdkIntern sample 1 603 5 8.319 0.161 msec/op o.s.b.InternBenchmark.testShortStringNoIntern sample 1 17185 5 0.274 0.048 msec/op After: Benchmark Mode Thr Cnt Sec Mean Mean error Units o.s.b.InternBenchmark.testLongStringChmIntern sample 1 2898 5 1.812 0.208 msec/op o.s.b.InternBenchmark.testLongStringJdkIntern sample 1 1138 5 4.397 0.136 msec/op o.s.b.InternBenchmark.testLongStringNoIntern sample 1 9035 5 0.519 0.146 msec/op o.s.b.InternBenchmark.testShortStringChmIntern sample 1 4538 5 1.094 0.107 msec/op o.s.b.InternBenchmark.testShortStringJdkIntern sample 1 1363 5 3.686 0.100 msec/op o.s.b.InternBenchmark.testShortStringNoIntern sample 1 16686 5 0.316 0.081 msec/op On release, before: Benchmark Mode Thr Cnt Sec Mean Mean error Units o.s.b.InternBenchmark.testLongStringChmIntern sample 1 4030 5 1.240 0.002 msec/op o.s.b.InternBenchmark.testLongStringJdkIntern sample 1 1024 5 4.894 0.042 msec/op o.s.b.InternBenchmark.testLongStringNoIntern sample 1 20000 5 0.185 0.002 msec/op o.s.b.InternBenchmark.testShortStringChmIntern sample 1 6143 5 0.814 0.005 msec/op o.s.b.InternBenchmark.testShortStringJdkIntern sample 1 1852 5 2.702 0.016 msec/op o.s.b.InternBenchmark.testShortStringNoIntern sample 1 20000 5 0.102 0.001 msec/op After: Benchmark Mode Thr Cnt Sec Mean Mean error Units o.s.b.InternBenchmark.testLongStringChmIntern sample 1 4040 5 1.236 0.002 msec/op o.s.b.InternBenchmark.testLongStringJdkIntern sample 1 2733 5 1.832 0.010 msec/op o.s.b.InternBenchmark.testLongStringNoIntern sample 1 20000 5 0.181 0.002 msec/op o.s.b.InternBenchmark.testShortStringChmIntern sample 1 6170 5 0.809 0.001 msec/op o.s.b.InternBenchmark.testShortStringJdkIntern sample 1 3577 5 1.396 0.007 msec/op o.s.b.InternBenchmark.testShortStringNoIntern sample 1 20000 5 0.102 0.000 msec/op This is almost a 3.5x improvement on fastdebug builds, and more than a 2.5x improvement on release builds. It is now only ~50% slower than ConcurrentHashMap, at least for the low-contention case! (I did not benchmark higher numbers of threads thoroughly, but I do not think that my changes could make that worse...) Finally, the benchmark code: https://github.com/stevenschlansker/jvm-intern-benchmark/blob/master/src/main/java/org/sugis/benchmark/InternBenchmark.java It is not the best ever benchmark, but I'm hopeful that it's "good enough" to demonstrate the wins I have. Please let me know if you believe the benchmark invalidates my conclusions. It is run with JMH, as that seems to be the standard way of doing things around here. Thank you again for your time and input; I am hopeful that I have not erred terribly :-) Best, Steven From Lance.Andersen at oracle.com Mon Aug 5 10:36:53 2013 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Mon, 5 Aug 2013 06:36:53 -0400 Subject: RFR JDK 8: 8022190 Fix varargs lint warnings in the JDK In-Reply-To: <51FEFA29.9000008@oracle.com> References: <51FEFA29.9000008@oracle.com> Message-ID: Joe Looks ok as well Best Lance -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com On Aug 4, 2013, at 9:04 PM, Joe Darcy wrote: > Hello, > > Please review this fix for > > 8022190: Fix varargs lint warnings in the JDK > http://cr.openjdk.java.net/~darcy/8022190.0/ > > Full patch below. > > While the @SafeVarargs annotation generally suppresses compiler warnings about methods, when the varargs lint option is enabled, javac does some checking of the body to see if it is indeed safe. If it cannot be proven safe, javac will issue a warning. > > The the four cases below, javac is unable to determine that the methods are safe. The @SuppressWarnings("varargs") annotations added below help javac out in this regard. > > Thanks, > > -Joe > > diff -r 33617583c545 src/share/classes/java/util/stream/Stream.java > --- a/src/share/classes/java/util/stream/Stream.java Wed Jul 31 10:53:33 2013 -0700 > +++ b/src/share/classes/java/util/stream/Stream.java Sun Aug 04 18:02:15 2013 -0700 > @@ -827,6 +827,7 @@ > * @return the new stream > */ > @SafeVarargs > + @SuppressWarnings("varargs") // Creating a stream for an array is safe > public static Stream of(T... values) { > return Arrays.stream(values); > } > diff -r 33617583c545 src/share/classes/javax/swing/SwingWorker.java > --- a/src/share/classes/javax/swing/SwingWorker.java Wed Jul 31 10:53:33 2013 -0700 > +++ b/src/share/classes/javax/swing/SwingWorker.java Sun Aug 04 18:02:15 2013 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2011, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -405,6 +405,7 @@ > * > */ > @SafeVarargs > + @SuppressWarnings("varargs") // Passing chunks to add is safe > protected final void publish(V... chunks) { > synchronized (this) { > if (doProcess == null) { > diff -r 33617583c545 src/share/classes/sun/reflect/annotation/AnnotationParser.java > --- a/src/share/classes/sun/reflect/annotation/AnnotationParser.java Wed Jul 31 10:53:33 2013 -0700 > +++ b/src/share/classes/sun/reflect/annotation/AnnotationParser.java Sun Aug 04 18:02:15 2013 -0700 > @@ -88,6 +88,7 @@ > * @param selectAnnotationClasses an array of annotation types to select when parsing > */ > @SafeVarargs > + @SuppressWarnings("varargs") // selectAnnotationClasses is used safely > static Map, Annotation> parseSelectAnnotations( > byte[] rawAnnotations, > ConstantPool constPool, > diff -r 33617583c545 src/share/classes/sun/swing/AccumulativeRunnable.java > --- a/src/share/classes/sun/swing/AccumulativeRunnable.java Wed Jul 31 10:53:33 2013 -0700 > +++ b/src/share/classes/sun/swing/AccumulativeRunnable.java Sun Aug 04 18:02:15 2013 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2011, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -121,6 +121,7 @@ > * @param args the arguments to accumulate > */ > @SafeVarargs > + @SuppressWarnings("varargs") // Copying args is safe > public final synchronized void add(T... args) { > boolean isSubmitted = true; > if (arguments == null) { > From aleksej.efimov at oracle.com Mon Aug 5 11:47:09 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Mon, 05 Aug 2013 15:47:09 +0400 Subject: RFR 8021820: Number of opened files used in select() is limited to 1024 [macosx] In-Reply-To: <51F920A7.3000600@oracle.com> References: <51F9007D.8090801@oracle.com> <51F9150B.4000008@oracle.com> <51F920A7.3000600@oracle.com> Message-ID: <51FF90BD.6070600@oracle.com> Alan, Tim, I have addressed your comments and as a result - new webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.01 The list of changes: 1. The connection to Oracle site is removed (it's not internal, but anyway it's better not to rely on availability of external resource in test). In current version a server socket is created and accept() method is used for bug disclosure. 2. The cleanup method is added for closing file streams. The JTREG successfully cleaned-up on windows after this modification. 3. common/autoconf/toolchain.m4 untouched, but 'bash common/autoconf/autogen.sh' was executed to update generated-configure.sh. Aleksej On 07/31/2013 06:35 PM, Tim Bell wrote: > Aleksej, Alan > > The change in common/autoconf/toolchain.m4 looks correct to me, and I > think that is a good place to have it. Remember to run 'bash > common/autoconf/autogen.sh' and check in the generated-configure.sh > files as part of the changeset. > > I didn't look at the test case, but I think Alan has some good points. > > Tim > > On 07/31/13 06:45 AM, Alan Bateman wrote: >> On 31/07/2013 05:18, Aleksej Efimov wrote: >>> Hi, >>> Can I have a review for the following problem: >>> The MACOSX JDK (more precisely - the java.net classes) uses the >>> select() system call to wait for different events on sockets fds. >>> And the default behaviour for select() on Darwin is to fail when >>> fdset contains the fd with id greater than FDSET_SIZE(=1024). Test >>> case in webrev illustrates this behavior. >>> There is at least one solution for it: use >>> -D_DARWIN_UNLIMITED_SELECT compilation flag for all macosx sources: >>> this won't affect other parts of JDK because they are not using >>> select(). >>> Currently, I have added this compilation flag to >>> common/autoconf/generated-configure.sh and >>> common/autoconf/generated-configure.sh. I wonder, if there is a >>> better place where I can put this flag? >>> >>> The webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.00/ >>> BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021820 >> >> Thanks for looking into this one. The build changes look okay to me >> but it's probably best that someone on build-dev agree to those. >> Michael McMahon can probably explain why the net code is using select >> for timed read/accept (I have a vague recollection of there being an >> issue with poll due to the way that it is implemented on kqueue with >> the result that it had to be changed to use select). >> >> I think the test needs re-work. It looks to me that the it attempts >> to connect to an Oracle internal site so that's not going to work >> everywhere. In general we don't want the tests to be dependent on >> hosts that may or may not exist (we had tests that used to this in >> the past but they caused a lot of grief). It also looks like the test >> doesn't close the 1023 files that it opens at the start and so I >> assume this test will always fail on Windows when jtreg tries to >> clean-up. >> >> -Alan. > From joe.darcy at oracle.com Mon Aug 5 14:50:31 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 05 Aug 2013 14:50:31 +0000 Subject: hg: jdk8/tl/jdk: 8022190: Fix varargs lint warnings in the JDK Message-ID: <20130805145121.77CAF485DA@hg.openjdk.java.net> Changeset: 80da091343af Author: darcy Date: 2013-08-05 07:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80da091343af 8022190: Fix varargs lint warnings in the JDK Reviewed-by: alanb, lancea, alexsch ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/javax/swing/SwingWorker.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java ! src/share/classes/sun/swing/AccumulativeRunnable.java From alexandr.scherbatiy at oracle.com Mon Aug 5 12:07:36 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 05 Aug 2013 16:07:36 +0400 Subject: RFR JDK 8: 8022190 Fix varargs lint warnings in the JDK In-Reply-To: <51FEFA29.9000008@oracle.com> References: <51FEFA29.9000008@oracle.com> Message-ID: <51FF9588.4050700@oracle.com> The fix looks good for me. Thanks, Alexandr. On 8/5/2013 5:04 AM, Joe Darcy wrote: > Hello, > > Please review this fix for > > 8022190: Fix varargs lint warnings in the JDK > http://cr.openjdk.java.net/~darcy/8022190.0/ > > Full patch below. > > While the @SafeVarargs annotation generally suppresses compiler > warnings about methods, when the varargs lint option is enabled, javac > does some checking of the body to see if it is indeed safe. If it > cannot be proven safe, javac will issue a warning. > > The the four cases below, javac is unable to determine that the > methods are safe. The @SuppressWarnings("varargs") annotations added > below help javac out in this regard. > > Thanks, > > -Joe > > diff -r 33617583c545 src/share/classes/java/util/stream/Stream.java > --- a/src/share/classes/java/util/stream/Stream.java Wed Jul 31 > 10:53:33 2013 -0700 > +++ b/src/share/classes/java/util/stream/Stream.java Sun Aug 04 > 18:02:15 2013 -0700 > @@ -827,6 +827,7 @@ > * @return the new stream > */ > @SafeVarargs > + @SuppressWarnings("varargs") // Creating a stream for an array is > safe > public static Stream of(T... values) { > return Arrays.stream(values); > } > diff -r 33617583c545 src/share/classes/javax/swing/SwingWorker.java > --- a/src/share/classes/javax/swing/SwingWorker.java Wed Jul 31 > 10:53:33 2013 -0700 > +++ b/src/share/classes/javax/swing/SwingWorker.java Sun Aug 04 > 18:02:15 2013 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2011, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -405,6 +405,7 @@ > * > */ > @SafeVarargs > + @SuppressWarnings("varargs") // Passing chunks to add is safe > protected final void publish(V... chunks) { > synchronized (this) { > if (doProcess == null) { > diff -r 33617583c545 > src/share/classes/sun/reflect/annotation/AnnotationParser.java > --- a/src/share/classes/sun/reflect/annotation/AnnotationParser.java > Wed Jul 31 10:53:33 2013 -0700 > +++ b/src/share/classes/sun/reflect/annotation/AnnotationParser.java > Sun Aug 04 18:02:15 2013 -0700 > @@ -88,6 +88,7 @@ > * @param selectAnnotationClasses an array of annotation types to > select when parsing > */ > @SafeVarargs > + @SuppressWarnings("varargs") // selectAnnotationClasses is used > safely > static Map, Annotation> > parseSelectAnnotations( > byte[] rawAnnotations, > ConstantPool constPool, > diff -r 33617583c545 > src/share/classes/sun/swing/AccumulativeRunnable.java > --- a/src/share/classes/sun/swing/AccumulativeRunnable.java Wed Jul > 31 10:53:33 2013 -0700 > +++ b/src/share/classes/sun/swing/AccumulativeRunnable.java Sun Aug > 04 18:02:15 2013 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2011, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -121,6 +121,7 @@ > * @param args the arguments to accumulate > */ > @SafeVarargs > + @SuppressWarnings("varargs") // Copying args is safe > public final synchronized void add(T... args) { > boolean isSubmitted = true; > if (arguments == null) { > From sundararajan.athijegannathan at oracle.com Mon Aug 5 16:02:20 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 05 Aug 2013 16:02:20 +0000 Subject: hg: jdk8/tl/jdk: 8016531: jconsole-plugin script demo does not work with nashorn Message-ID: <20130805160233.DF480485DE@hg.openjdk.java.net> Changeset: 87367a1c7f76 Author: sundar Date: 2013-08-05 21:31 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/87367a1c7f76 8016531: jconsole-plugin script demo does not work with nashorn Reviewed-by: lagergren, hannesw Contributed-by: rieberandreas at gmail.com ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptShellPanel.java ! src/share/demo/scripting/jconsole-plugin/src/resources/jconsole.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/invoke.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/jstack.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/jtop.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/sysprops.js ! src/share/sample/scripting/scriptpad/README.txt ! src/share/sample/scripting/scriptpad/src/resources/conc.js ! src/share/sample/scripting/scriptpad/src/resources/mm.js From alexey.utkin at oracle.com Mon Aug 5 16:05:09 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Mon, 05 Aug 2013 20:05:09 +0400 Subject: Review request: JDK-7147084 (process) appA hangs when read output stream of appB which starts appC that runs forever (v.2) In-Reply-To: <51F59C1A.4070602@oracle.com> References: <518A88B1.3060105@oracle.com> <5190FC54.8050808@oracle.com> <5194B0D8.2040607@oracle.com> <51D685E1.1080606@oracle.com> <51D6D139.40508@oracle.com> <51DE74D1.70607@oracle.com> <51F59C1A.4070602@oracle.com> Message-ID: <51FFCD35.9050308@oracle.com> Here is new version of the fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7147084/webrev.02/ Changes (in accordance with Alan's recommendations): -- Magic constant -1 was changed to JAVA_INVALID_HANDLE_VALUE with explanation why the macro INVALID_HANDLE_VALUE is not in use. -- The comments were added for each usage of the JAVA_INVALID_HANDLE_VALUE macro. -- 10 seconds time limit was rewritten to file signals. Regards, -uta On 7/29/2013 2:32 AM, Alan Bateman wrote: > On 11/07/2013 02:03, Alexey Utkin wrote: >> : >> >> Bug description: >> https://jbs.oracle.com/bugs/browse/JDK-7147084 >> http://bugs.sun.com/view_bug.do?bug_id=7147084 >> >> Here is the suggested fix: >> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7147084/webrev.01/ >> >> Summary for v1 changes: >> >> -- The set of handles that need to restore the inherit flag was extended >> by child process IOE handles. That was done to avoid "greedy sibling" >> problem for the file handles. The file handles are closed outside the >> synchronized block. >> -- "Greedy sibling" problem is covered by the >> [test/java/lang/ProcessBuilder/SiblingIOEHandle.java] test. >> -- The fact that the set of current process standard IOE handles and the >> set of child process IOE handles can intersect was taken into account. >> -- The [test/java/lang/ProcessBuilder/InheritIOEHandle.java] was changed >> in accordance with Martin's concern. >> > I've done a first pass over this. This is a long standing issue so a > big thank you for taking this on. It's unfortunate that this requires > serializing the exec but based on the various Microsoft articles that > you cited when researching this one then it seems that this is what we > have to do. > > Overall I don't see any issues. It's nice to have the create function > broken up into smaller functions. I do think the new code needs > several comments, particularly initHolder and the constants. > > One concern with the tests is that 10 seconds might not be sufficient > on a slow/busy machine or a Windows machine that is being choked by AV > software. Could this be changed so that it just getting timed by the > test harness if the child does not terminate? I'm also wondering about > waitAbit and whether this is useful. > > -Alan. > From iris.clark at oracle.com Mon Aug 5 17:16:01 2013 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 5 Aug 2013 10:16:01 -0700 (PDT) Subject: Remove superfluous @test tags from SpliteratorTraversingAndSplittingTest In-Reply-To: <51FB877B.9020907@oracle.com> References: <51FB74FA.3080003@oracle.com> <51FB877B.9020907@oracle.com> Message-ID: <82202e6b-829a-4316-9cfb-947f99121906@default> Hi, Chris. > I also noticed this. Running the test explicitly seems to locate just the first @test, while running in a batch (sometimes) finds the two! Not sure why. If you execute jtreg with explicit file name(s), only those files will be search for "@test" tags. If you use anything else, e.g. directory names, then jtreg will search all *.java, *.sh, and *.html files searching for "@test" tags. For the "sometimes" is it possible that one of the tests has been somehow excluded (e.g. on a problem list) but the other one wasn't? Thanks, iris -----Original Message----- From: Chris Hegarty Sent: Friday, August 02, 2013 3:19 AM To: Paul Sandoz Cc: Core-Libs-Dev Core-Libs-Dev Subject: Re: Remove superfluous @test tags from SpliteratorTraversingAndSplittingTest On 02/08/2013 10:52, Paul Sandoz wrote: > > On Aug 2, 2013, at 9:59 AM, Chris Hegarty wrote: > >> SpliteratorTraversingAndSplittingTest contains two @test tags. The second of which does not specify that the test needs to run with testng. This causes the test to fail, or have an error, when run as a batch with other tests. >> >> The second @test tag is just not needed, and the @bug should be moved to the original @test tag. >> > Ooops that is my fault, thanks for sorting this out. No Problem. > When i ran jtreg manually it did not barf, is there anyway for it to validate the meta-data? I also noticed this. Running the test explicitly seems to locate just the first @test, while running in a batch (sometimes) finds the two! Not sure why. It is also ok to have more than one @test, just in this case it would need to specify testng. -Chris. From ioi.lam at oracle.com Mon Aug 5 18:15:43 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 05 Aug 2013 11:15:43 -0700 Subject: Dismal performance of String.intern() In-Reply-To: <20130804222110.3b032f4e@luminol> References: <51B6EDAE.3080300@oracle.com> <20130804222110.3b032f4e@luminol> Message-ID: <51FFEBCF.7090408@oracle.com> Hi Steven, This looks like a promising patch. If all goes well I can sponsor this patch into hotspot-rt. I have problems building your test. Could you send a stand-alone test that can be build with plain JDK (i.e., exclude things like com.google.common. and org.openjdk.jmh)? Also, I saw that you tested with strings that are the same length as UUID, which are 36 chars long: 2544f85f-1845-42c4-aba1-7a431e6edb99 eff61458-32f8-45cd-a77d-fddb14951cab d685f1a2-0b95-4021-b9b3-b0fb3c02a17f We do need to handle strings with shorter length, and making calls to memcmp() may cause degradation with lots of short strings. Can you add a sub-test that tests for strings length <= 4? I would also recommend running a few non-trivial apps (such as eclipse) and dump the interned string table to see the distribution of lengths. I know this is a hassle, but it would be a good last step to wrap up your work. Meanwhile, I will try to run our benchmarks (aka "refworkload") to check for any performance impact. Thanks - Ioi On 08/04/2013 10:21 PM, Steven Schlansker wrote: > On Tue, 11 Jun 2013 10:28:14 +0100 > Alan Bateman wrote: > >> On 10/06/2013 19:06, Steven Schlansker wrote: >>> Hi core-libs-dev, >>> >>> While doing performance profiling of my application, I discovered >>> that nearly 50% of the time deserializing JSON was spent within >>> String.intern(). I understand that in general interning Strings is >>> not the best approach for things, but I think I have a decent use >>> case -- the value of a certain field is one of a very limited >>> number of valid values (that are not known at compile time, so I >>> cannot use an Enum), and is repeated many millions of times in the >>> JSON stream. >>> >> Have you run with -XX:+PrintStringTableStatistics? Might be >> interesting if you can share the output (it is printed just before >> the VM terminates). >> >> There are also tuning knobs such as StringTableSize and would be >> interesting to know if you've experimented with. >> >> -Alan. > Hi everyone, > > Thanks again for your useful advice. I definitely misjudged the > difficulty and complexity of working with methods that directly bridge > the Java <-> C++ "gap"! As such, it took me way longer to get to this > than I expected... > > That said, I think I have very good results to report. OpenJDK8 is > already *significantly* better than OpenJDK 7 was, but still can be > better. > > Here is the patch I have at the moment: > https://gist.github.com/stevenschlansker/6153643 > > I used oprofile with oprofile-jit to identify the hot spots in the > benchmark code as being java_lang_String::equals() and > java_lang_String::as_unicode_string. > > Both of these methods have hand-written loops that copy or compare > jchar arrays. > > The problem is that in -fastdebug or -slowdebug releases, this is > one method call per character (the function is not inlined). Even in > -release builds, it seems that this is significantly slower than the > libc memcpy() or memcmp() functions which can use SSE4 (or other > related technologies). > > My patch adds new methods, char_cmp and char_cpy, which delegate to the > mem* functions instead of using hand-written loops. > > The micro-benchmark results are very good for such a small change. > > On fastdebug, before: > > Benchmark Mode Thr Cnt > Sec Mean Mean error Units > o.s.b.InternBenchmark.testLongStringChmIntern sample 1 2819 > 5 1.780 0.184 msec/op > o.s.b.InternBenchmark.testLongStringJdkIntern sample 1 343 > 5 14.571 0.310 msec/op > o.s.b.InternBenchmark.testLongStringNoIntern sample 1 8712 > 5 0.526 0.138 msec/op > o.s.b.InternBenchmark.testShortStringChmIntern sample 1 4427 > 5 1.133 0.121 msec/op > o.s.b.InternBenchmark.testShortStringJdkIntern sample 1 603 > 5 8.319 0.161 msec/op > o.s.b.InternBenchmark.testShortStringNoIntern sample 1 17185 > 5 0.274 0.048 msec/op > > After: > > Benchmark Mode Thr Cnt > Sec Mean Mean error Units > o.s.b.InternBenchmark.testLongStringChmIntern sample 1 2898 > 5 1.812 0.208 msec/op > o.s.b.InternBenchmark.testLongStringJdkIntern sample 1 1138 > 5 4.397 0.136 msec/op > o.s.b.InternBenchmark.testLongStringNoIntern sample 1 9035 > 5 0.519 0.146 msec/op > o.s.b.InternBenchmark.testShortStringChmIntern sample 1 4538 > 5 1.094 0.107 msec/op > o.s.b.InternBenchmark.testShortStringJdkIntern sample 1 1363 > 5 3.686 0.100 msec/op > o.s.b.InternBenchmark.testShortStringNoIntern sample 1 16686 > 5 0.316 0.081 msec/op > > On release, before: > > Benchmark Mode Thr Cnt > Sec Mean Mean error Units > o.s.b.InternBenchmark.testLongStringChmIntern sample 1 4030 > 5 1.240 0.002 msec/op > o.s.b.InternBenchmark.testLongStringJdkIntern sample 1 1024 > 5 4.894 0.042 msec/op > o.s.b.InternBenchmark.testLongStringNoIntern sample 1 20000 > 5 0.185 0.002 msec/op > o.s.b.InternBenchmark.testShortStringChmIntern sample 1 6143 > 5 0.814 0.005 msec/op > o.s.b.InternBenchmark.testShortStringJdkIntern sample 1 1852 > 5 2.702 0.016 msec/op > o.s.b.InternBenchmark.testShortStringNoIntern sample 1 20000 > 5 0.102 0.001 msec/op > > After: > > Benchmark Mode Thr Cnt > Sec Mean Mean error Units > o.s.b.InternBenchmark.testLongStringChmIntern sample 1 4040 > 5 1.236 0.002 msec/op > o.s.b.InternBenchmark.testLongStringJdkIntern sample 1 2733 > 5 1.832 0.010 msec/op > o.s.b.InternBenchmark.testLongStringNoIntern sample 1 20000 > 5 0.181 0.002 msec/op > o.s.b.InternBenchmark.testShortStringChmIntern sample 1 6170 > 5 0.809 0.001 msec/op > o.s.b.InternBenchmark.testShortStringJdkIntern sample 1 3577 > 5 1.396 0.007 msec/op > o.s.b.InternBenchmark.testShortStringNoIntern sample 1 20000 > 5 0.102 0.000 msec/op > > > This is almost a 3.5x improvement on fastdebug builds, and more than a > 2.5x improvement on release builds. It is now only ~50% slower than > ConcurrentHashMap, at least for the low-contention case! (I did not > benchmark higher numbers of threads thoroughly, but I do not think that > my changes could make that worse...) > > Finally, the benchmark code: > https://github.com/stevenschlansker/jvm-intern-benchmark/blob/master/src/main/java/org/sugis/benchmark/InternBenchmark.java > > It is not the best ever benchmark, but I'm hopeful that it's "good > enough" to demonstrate the wins I have. Please let me know if you > believe the benchmark invalidates my conclusions. It is run with JMH, > as that seems to be the standard way of doing things around here. > > Thank you again for your time and input; I am hopeful that I have not > erred terribly :-) > > Best, > Steven From aleksey.shipilev at oracle.com Mon Aug 5 18:29:54 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 05 Aug 2013 22:29:54 +0400 Subject: Dismal performance of String.intern() In-Reply-To: <51FFEBCF.7090408@oracle.com> References: <51B6EDAE.3080300@oracle.com> <20130804222110.3b032f4e@luminol> <51FFEBCF.7090408@oracle.com> Message-ID: <51FFEF22.7010409@oracle.com> On 08/05/2013 10:15 PM, Ioi Lam wrote: > I have problems building your test. Could you send a stand-alone test > that can be build with plain JDK (i.e., exclude things like > com.google.common. and org.openjdk.jmh)? I would strongly advise against dropping JMH. Maintaining the benchmark with JMH is the way to overcome many of the benchmarking pitfalls we would introduce with custom tests. Depending on Guava is the blocker though, since we can not have this dependency in OpenJDK before prior legal review. -Aleksey. From aleksey.shipilev at oracle.com Mon Aug 5 18:43:50 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 05 Aug 2013 22:43:50 +0400 Subject: Dismal performance of String.intern() In-Reply-To: <20130804222110.3b032f4e@luminol> References: <51B6EDAE.3080300@oracle.com> <20130804222110.3b032f4e@luminol> Message-ID: <51FFF266.5030806@oracle.com> Hi Steven, On 08/05/2013 09:21 AM, Steven Schlansker wrote: > Here is the patch I have at the moment: > https://gist.github.com/stevenschlansker/6153643 Would you like to make char_cmp() and char_cpy() "inline"? In release, they can then be compiled straight to memcmp/memcpy. > This is almost a 3.5x improvement on fastdebug builds, and more than a > 2.5x improvement on release builds. It is now only ~50% slower than > ConcurrentHashMap, at least for the low-contention case! (I did not > benchmark higher numbers of threads thoroughly, but I do not think that > my changes could make that worse...) The results look good. In fact, I think multi-threaded tests will show how the StringTable works under contention, and whether the changes you made are making it worse or better is the open question. (I bet for "better"). > Finally, the benchmark code: > https://github.com/stevenschlansker/jvm-intern-benchmark/blob/master/src/main/java/org/sugis/benchmark/InternBenchmark.java > > It is not the best ever benchmark, but I'm hopeful that it's "good > enough" to demonstrate the wins I have. Please let me know if you > believe the benchmark invalidates my conclusions. It is run with JMH, > as that seems to be the standard way of doing things around here. The benchmark is good, actually. You pay for the cost of constructing the interner, though, but it seems to be the lesser of two evils (i.e. cleaning the interner is more of the hassle). A few minor nits: a) It seems better to design this benchmark this way: prepare the list of random Strings (Ioi's suggestion to juggle the string lenghts fits nicely there), feed them to interner, return the interner from the @GMB method. You will save a lot of blatant allocations like "new String(buf)" in the hot loop, as well as make loop more unpredictable (e.g. not relying on successful hoisting). b) @BenchmarkMode can float up to class level. Less scaffolding. -Aleksey. From stuart.marks at oracle.com Mon Aug 5 20:44:48 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 05 Aug 2013 13:44:48 -0700 Subject: RFR: 8020854 change RMI javadocs to specify that remote objects are exported to the wildcard address Message-ID: <52000EC0.5010406@oracle.com> Hi all, Please review the following RMI javadoc change that clarifies the exporting behavior and that provides an example of how to modify it. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020854 Webrev: http://cr.openjdk.java.net/~smarks/reviews/8020854/webrev.0/ Specdiff: http://cr.openjdk.java.net/~smarks/reviews/8020854/specdiff.0/ Thanks! s'marks From brian.burkhalter at oracle.com Mon Aug 5 22:21:24 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 5 Aug 2013 15:21:24 -0700 Subject: Java 8 RFR 6378503: In java.math.BigDecimal, division by one returns zero In-Reply-To: <56486B03-4047-408D-AE25-937A28DDB5F8@oracle.com> References: <46EBFCD4-D336-4336-9D28-C8F2CAB9CB21@oracle.com> <51F0A329.9010802@oracle.com> <56486B03-4047-408D-AE25-937A28DDB5F8@oracle.com> Message-ID: <3869E218-7D95-4314-AC22-A7AFE088C488@oracle.com> Hi Joe, On Jul 25, 2013, at 2:28 PM, Brian Burkhalter wrote: >> I took a look through the code and I don't see how sdiff == Integer.MIN_VALUE is handled. > > This case, if compareMagnitude() does not return at lines 2668 or 2670, intentionally falls through to line 2690. Otherwise, if hypothetically sdiff were equal to Integer.MIN_VALUE, then evaluating line 2677 would overflow. It is not actually apparent to me however whether line 2671 would ever be reached were sdiff == Integer.MIN_VALUE. I have updated the comments at lines 2673 and 2682 of BigDecimal: http://cr.openjdk.java.net/~bpb/6378503/ >> In any case, as long as the runtimes and memory usage are tractable, the set of test cases should be augmented to include sdiff == Integer.MIN_VALUE and (long)Integer.MIN_VALUE + 1, etc. > > From what I can tell by inspection, sdiff mirrors the MathContext precision (mcp) and all paths will attempt to calculate 10^e where "e" is approximately or exactly mcp. This computation would run for days. I don't yet see a way to test these cases. Thanks, Brian From joe.darcy at oracle.com Mon Aug 5 23:44:49 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Mon, 05 Aug 2013 16:44:49 -0700 Subject: Code Review Request: More tests for 7184826: (reflect) Add support for Project Lambda concepts in core reflection In-Reply-To: <20130722132703.GO18147@jfranck-desktop.jrpg.bea.com> References: <519E2C52.20203@oracle.com> <51B91AA5.6090807@oracle.com> <20130710141722.GA23047@jfranck-desktop.jrpg.bea.com> <51ED2FC9.5040200@oracle.com> <20130722132703.GO18147@jfranck-desktop.jrpg.bea.com> Message-ID: <520038F1.3020908@oracle.com> Hello, Sorry for the repeated review delays. This looks fine to go back. Thanks, -Joe On 7/22/2013 6:27 AM, Joel Borggren-Franck wrote: > Hi Amy, > > I'm happy with the current iteration. I'll help you find an official > reviewer. > > cheers > /Joel > > On 2013-07-22, Amy Lu wrote: >> Thank you Joel for all the valuable feedback. >> >> Test have been refactored and here comes the updated version: >> https://dl.dropboxusercontent.com/u/5812451/yl153753/7184826/webrev.01/index.html >> >> Thanks, >> Amy >> >> >> On 7/10/13 10:17 PM, Joel Borggren-Franck wrote: >>> Hi Amy, Tristan, >>> >>> I'm not a Reviewer kind of reviewer, but I've started to look at the >>> code and can sponsor this. >>> >>> Some comments on test/java/lang/reflect/Method/invoke/DefaultStaticTest.java: >>> >>> As there are a lot of non-public top-level classes perhaps this test >>> should be in it own directory. >>> >>> It is very hard to read the data table: >>> >>> 292 {interface1.class, 1, 1, new Object1(), new Object[]{}, >>> 293 new Object[]{}, "interface1", null}, >>> >>> I believe you should move the methodsNum constant and the declMethods >>> num constant to an annotation on the interface/class in question. For >>> example: >>> >>> @MyTestData(numMethods=1, declMethods=1) >>> 41 interface interface1 { >>> 42 @DefaultMethod(isDefault = true) >>> 43 @StaticMethod(isStatic = false) >>> 44 @ReturnValue(value = "interface1.defaultMethod") >>> 45 default String defaultMethod(){ return "interface1.defaultMethod"; }; >>> 46 } >>> >>> That way it is much easier to inspect that the constants are right. >>> >>> The same can probably be done with the return values encoded. >>> >>> Instead of all these "new Objects[] {}" can't you create a field, >>> >>> Object [] EMPTY_PARAMETERS = new Object() {} >>> >>> and reuse it? >>> >>> That way it will be much easier to verify that the encoded test data is >>> correct. >>> >>> I'll comment on the other tests shortly. >>> >>> cheers >>> /Joel >>> >>> On 2013-06-13, Amy Lu wrote: >>>> This has been pending on review for long ... Please help to review. >>>> I also need a sponsor for this. >>>> >>>> Thank you very much. >>>> >>>> /Amy >>>> >>>> On 5/23/13 10:48 PM, Amy Lu wrote: >>>>> Please help to review: >>>>> >>>>> More tests for 7184826: (reflect) Add support for Project Lambda >>>>> concepts in core reflection >>>>> >>>>> This includes: >>>>> 1. improvement for existing tests with more situations >>>>> 2. Test for invoking interface default/static method by j.l.r.Method >>>>> 3. Test for invoking interface default/static method by MethodHandle >>>>> >>>>> https://dl.dropboxusercontent.com/u/5812451/yl153753/7184826/webrev.00/index.html >>>>> >>>>> >>>>> Thanks, >>>>> Amy From stuart.marks at oracle.com Tue Aug 6 01:14:01 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 05 Aug 2013 18:14:01 -0700 Subject: RFR 8021820: Number of opened files used in select() is limited to 1024 [macosx] In-Reply-To: <51FF90BD.6070600@oracle.com> References: <51F9007D.8090801@oracle.com> <51F9150B.4000008@oracle.com> <51F920A7.3000600@oracle.com> <51FF90BD.6070600@oracle.com> Message-ID: <52004DD9.4040202@oracle.com> Hi Aleksej, Thanks for the update. I took a look at the revised test, and there are still some issues. (I didn't look at the build changes.) 1) System-specific resource limits. I think the biggest issue is resource limits on the number of open files per process that might vary from system to system. On my Ubuntu system, the hard limit on the number of open files is 1,024. The test opens 1,023 files and then one more for the socket. Unfortunately the JVM and jtreg have several files open already, and the test crashes before the openFiles() method completes. (Oddly it crashes with a NoClassDefFoundError from the main thread's uncaught exception handler, and then the test reports that it passed! Placing a try/catch of Throwable in main() or openFiles() doesn't catch this error. I have no explanation for this. When run standalone -- i.e., not from jtreg -- the test throws FileNotFoundException (too many open files) from openFiles(), which is expected.) On my Mac (10.7.5) the soft limit is 256 files, but the hard limit is unlimited. The test succeeds in opening all its files but fails because of the select() bug you're fixing. (This is expected; I didn't rebuild my JDK with your patch.) I guess the soft limit doesn't do anything on Mac. Amazingly, the test passed fine on both Windows XP and Windows 8. I'm not entirely sure what to do about resource limits. Since the test is able to open >1024 files on Mac, Windows, and possibly other Linuxes, it seems reasonable to continue with this approach. If it's possible to catch the error that occurs if the test cannot open its initial 1,024 files, perhaps it should do this, log a message indicating what happened, and consider the test to have passed. I'm mystified by the uncaught/uncatchable NoClassDefFoundError though. 2) Closing files. If an exception is thrown while opening the initial set of files, or sometime during the closing process, the test can still leak files. One approach would be to keep a data structure representing the current set of open files, and close them all in a finally-block around all the test logic, and making sure that exceptions from the close() call are caught and do not prevent the rest of the files from being closed. This seems like a lot of work. Perhaps a more effective approach would be to run the test in "othervm" mode, as follows: @run main/othervm SelectFdsLimit This will cause the test to run in a dedicated JVM, so all files will be closed automatically when it exits. (It would be good to add a comment explaining the need for othervm, if you do this.) 3) Port number for sockets. It's fairly common for tests to fail occasionally because they use some constant port number that sometimes happens to be in use at the same time by another process on the system. I have to say, 8080 is a pretty common port number. :-) For purposes of this test, you can let the system assign a port. Just use: new ServerSocket(0) 4) Style. It's probably possible to use the same File object for the test file, instead of creating new File objects repeatedly. It might be nice to add a comment explaining the logic of the test, that SocketTimeoutException is expected, and that failure will be indicated if the accept() throws SocketException caused by the underlying mishandling of large fds by select(). Thanks, s'marks On 8/5/13 4:47 AM, Aleksej Efimov wrote: > Alan, Tim, > > I have addressed your comments and as a result - new webrev: > http://cr.openjdk.java.net/~aefimov/8021820/webrev.01 > > The list of changes: > 1. The connection to Oracle site is removed (it's not internal, but anyway it's > better not to rely on availability of external resource in test). In current > version a server socket is created and accept() method is used for bug disclosure. > 2. The cleanup method is added for closing file streams. The JTREG successfully > cleaned-up on windows after this modification. > 3. common/autoconf/toolchain.m4 untouched, but 'bash > common/autoconf/autogen.sh' was executed to update generated-configure.sh. > > Aleksej > > > On 07/31/2013 06:35 PM, Tim Bell wrote: >> Aleksej, Alan >> >> The change in common/autoconf/toolchain.m4 looks correct to me, and I think >> that is a good place to have it. Remember to run 'bash >> common/autoconf/autogen.sh' and check in the generated-configure.sh files as >> part of the changeset. >> >> I didn't look at the test case, but I think Alan has some good points. >> >> Tim >> >> On 07/31/13 06:45 AM, Alan Bateman wrote: >>> On 31/07/2013 05:18, Aleksej Efimov wrote: >>>> Hi, >>>> Can I have a review for the following problem: >>>> The MACOSX JDK (more precisely - the java.net classes) uses the select() >>>> system call to wait for different events on sockets fds. And the default >>>> behaviour for select() on Darwin is to fail when fdset contains the fd with >>>> id greater than FDSET_SIZE(=1024). Test case in webrev illustrates this >>>> behavior. >>>> There is at least one solution for it: use -D_DARWIN_UNLIMITED_SELECT >>>> compilation flag for all macosx sources: this won't affect other parts of >>>> JDK because they are not using select(). >>>> Currently, I have added this compilation flag to >>>> common/autoconf/generated-configure.sh and >>>> common/autoconf/generated-configure.sh. I wonder, if there is a better >>>> place where I can put this flag? >>>> >>>> The webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.00/ >>>> BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021820 >>> >>> Thanks for looking into this one. The build changes look okay to me but it's >>> probably best that someone on build-dev agree to those. >>> Michael McMahon can probably explain why the net code is using select for >>> timed read/accept (I have a vague recollection of there being an issue with >>> poll due to the way that it is implemented on kqueue with the result that it >>> had to be changed to use select). >>> >>> I think the test needs re-work. It looks to me that the it attempts to >>> connect to an Oracle internal site so that's not going to work everywhere. >>> In general we don't want the tests to be dependent on hosts that may or may >>> not exist (we had tests that used to this in the past but they caused a lot >>> of grief). It also looks like the test doesn't close the 1023 files that it >>> opens at the start and so I assume this test will always fail on Windows >>> when jtreg tries to clean-up. >>> >>> -Alan. >> > From Alan.Bateman at oracle.com Tue Aug 6 01:16:47 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 05 Aug 2013 18:16:47 -0700 Subject: RFR: 8020854 change RMI javadocs to specify that remote objects are exported to the wildcard address In-Reply-To: <52000EC0.5010406@oracle.com> References: <52000EC0.5010406@oracle.com> Message-ID: <52004E7F.9090302@oracle.com> On 05/08/2013 13:44, Stuart Marks wrote: > Hi all, > > Please review the following RMI javadoc change that clarifies the > exporting behavior and that provides an example of how to modify it. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020854 > > Webrev: http://cr.openjdk.java.net/~smarks/reviews/8020854/webrev.0/ > > Specdiff: http://cr.openjdk.java.net/~smarks/reviews/8020854/specdiff.0/ > > Thanks! > > s'marks This mostly looks good to me. The only thing is that I would suggest is "on all network interfaces" rather than "from any internet host" in RMISocketFactory. The wording in UnicastRemoteObject uses "network interfaces" so I think it's fine. -Alan From stuart.marks at oracle.com Tue Aug 6 02:08:25 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Tue, 06 Aug 2013 02:08:25 +0000 Subject: hg: jdk8/tl/jdk: 8020854: change RMI javadocs to specify that remote objects are exported to the wildcard address Message-ID: <20130806020849.73652485F5@hg.openjdk.java.net> Changeset: 31759750ff63 Author: smarks Date: 2013-08-05 19:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31759750ff63 8020854: change RMI javadocs to specify that remote objects are exported to the wildcard address Reviewed-by: rgallard, alanb ! src/share/classes/java/rmi/server/RMISocketFactory.java ! src/share/classes/java/rmi/server/UnicastRemoteObject.java From stuart.marks at oracle.com Tue Aug 6 02:20:17 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 05 Aug 2013 19:20:17 -0700 Subject: RFR: 8020854 change RMI javadocs to specify that remote objects are exported to the wildcard address In-Reply-To: <52004E7F.9090302@oracle.com> References: <52000EC0.5010406@oracle.com> <52004E7F.9090302@oracle.com> Message-ID: <52005D61.1090600@oracle.com> On 8/5/13 6:16 PM, Alan Bateman wrote: > On 05/08/2013 13:44, Stuart Marks wrote: >> Hi all, >> >> Please review the following RMI javadoc change that clarifies the exporting >> behavior and that provides an example of how to modify it. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020854 >> >> Webrev: http://cr.openjdk.java.net/~smarks/reviews/8020854/webrev.0/ >> >> Specdiff: http://cr.openjdk.java.net/~smarks/reviews/8020854/specdiff.0/ >> >> Thanks! >> >> s'marks > This mostly looks good to me. The only thing is that I would suggest is "on all > network interfaces" rather than "from any internet host" in RMISocketFactory. > The wording in UnicastRemoteObject uses "network interfaces" so I think it's fine. Good wording suggestion. I've pushed the fix with this change in place. Thanks. s'marks From Alan.Bateman at oracle.com Tue Aug 6 04:48:50 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 05 Aug 2013 21:48:50 -0700 Subject: Review request: JDK-7147084 (process) appA hangs when read output stream of appB which starts appC that runs forever (v.2) In-Reply-To: <51FFCD35.9050308@oracle.com> References: <518A88B1.3060105@oracle.com> <5190FC54.8050808@oracle.com> <5194B0D8.2040607@oracle.com> <51D685E1.1080606@oracle.com> <51D6D139.40508@oracle.com> <51DE74D1.70607@oracle.com> <51F59C1A.4070602@oracle.com> <51FFCD35.9050308@oracle.com> Message-ID: <52008032.9010705@oracle.com> On 05/08/2013 09:05, Alexey Utkin wrote: > Here is new version of the fix: > http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7147084/webrev.02/ > > Changes (in accordance with Alan's recommendations): > -- Magic constant -1 was changed to JAVA_INVALID_HANDLE_VALUE with > explanation why the macro > INVALID_HANDLE_VALUE is not in use. > -- The comments were added for each usage of the > JAVA_INVALID_HANDLE_VALUE macro. > -- 10 seconds time limit was rewritten to file signals. > > Regards, > -uta Thanks for adding comments. I still think initHolder will be confusing to future maintainers and could benefit from a clear comment (above the static BOOL ...) to explain the parameters. One typo in the comment in " [thisProcessEnd] has no the inherit flag.". The other functions are mostly clear now (thanks). There are a few formatting oddities in Java_java_lang_ProcessImpl_create. Looks like a newline has crept into the if statement at L337. Then L358-364 is mis-aligned which makes it hard to tie the JNI ReleaseStringChars back to the JNI GetStringChars. Thanks for replacing the fragile 10s in the tests. If I read performC (in both tests) correctly then the test will still pass after 5 minutes even if the JDK is broken - is that right? Just wonder if it would be better to just replace the for loop with while (true) and let the test harness timeout the test. Otherwise I think this is good work and we are finally close to the finish line. -Alan. From henry.jen at oracle.com Tue Aug 6 05:40:57 2013 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 05 Aug 2013 22:40:57 -0700 Subject: RFR (2nd): 8015318: Extend Collector with 'finish' operation In-Reply-To: <51DC82CB.2080007@oracle.com> References: <51DC82CB.2080007@oracle.com> Message-ID: <52008C69.1040203@oracle.com> Ping on this, the 8012238 fix is already in, thus this webrev is ready to go, only if we can have a reviewer review it. Cheers, Henry On 07/09/2013 02:38 PM, Henry Jen wrote: > Hi, > > An update from earlier request based on some feedbacks. > > The webrev is at > > http://cr.openjdk.java.net/~henryjen/ccc/8015318.1/webrev > > This webrev depends on fix of bug 8012238[1]. Before that bug is fixed, > applies this patch[2] to add needed type information. > > See the summary of API changes, specdiff is at > > http://cr.openjdk.java.net/~henryjen/ccc/8015318.1/specdiff/overview-summary.html > > > [1] http://bugs.sun.com/view_bug.do?bug_id=8012238 > [2] http://cr.openjdk.java.net/~henryjen/ccc/8015318.1/collector-hacks.patch > > Cheers, > Henry > From sundararajan.athijegannathan at oracle.com Tue Aug 6 09:03:35 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 06 Aug 2013 09:03:35 +0000 Subject: hg: jdk8/tl/nashorn: 2 new changesets Message-ID: <20130806090338.AC2B7485FB@hg.openjdk.java.net> Changeset: 0ad00ae4fec6 Author: hannesw Date: 2013-08-01 12:23 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0ad00ae4fec6 8020132: Big object literal with numerical keys exceeds method size Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NoTypeArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java + test/script/basic/JDK-8020132.js + test/script/basic/JDK-8020132.js.EXPECTED Changeset: bb0f3c896cb7 Author: sundar Date: 2013-08-06 13:10 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/bb0f3c896cb7 Merge From chris.hegarty at oracle.com Tue Aug 6 09:29:27 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 06 Aug 2013 10:29:27 +0100 Subject: Remove superfluous @test tags from SpliteratorTraversingAndSplittingTest In-Reply-To: <82202e6b-829a-4316-9cfb-947f99121906@default> References: <51FB74FA.3080003@oracle.com> <51FB877B.9020907@oracle.com> <82202e6b-829a-4316-9cfb-947f99121906@default> Message-ID: <5200C1F7.3080808@oracle.com> Hi Iris, I'm not saying it is right, but this is the situation we found ourselves in. It might point to a bug in jtreg, or just "bad" jtreg meta-data. >: ls one . .. HelloWorld.java >: cat one/HelloWorld.java /* * @test * @bug 8765432 */ /* * @test */ public class HelloWorld { public static void main(String[] args) { System.out.println("Hello World."); } } >: jtreg -v1 one/HelloWorld.java Passed: one/HelloWorld.java Test results: passed: 1 Report written to .../jdk/test/JTreport/html/report.html Results written to .../jdk/test/JTwork >: jtreg -v1 one Passed: one/HelloWorld.java Passed: one/HelloWorld.java#id1 Test results: passed: 2 Report written to .../jdk/test/JTreport/html/report.html Results written to .../jdk/test/JTwork -Chris. P.S. Note, the offending test has been fixed, and there is no issue in the jdk regression tests affected by this. On 05/08/2013 18:16, Iris Clark wrote: > Hi, Chris. > >> I also noticed this. Running the test explicitly seems to locate just the first @test, while running in a batch (sometimes) finds the two! Not sure why. > > If you execute jtreg with explicit file name(s), only those files will be search for "@test" tags. If you use anything else, e.g. directory names, then jtreg will search all *.java, *.sh, and *.html files searching for "@test" tags. For the "sometimes" is it possible that one of the tests has been somehow excluded (e.g. on a problem list) but the other one wasn't? > > Thanks, > iris > > -----Original Message----- > From: Chris Hegarty > Sent: Friday, August 02, 2013 3:19 AM > To: Paul Sandoz > Cc: Core-Libs-Dev Core-Libs-Dev > Subject: Re: Remove superfluous @test tags from SpliteratorTraversingAndSplittingTest > > On 02/08/2013 10:52, Paul Sandoz wrote: >> >> On Aug 2, 2013, at 9:59 AM, Chris Hegarty wrote: >> >>> SpliteratorTraversingAndSplittingTest contains two @test tags. The second of which does not specify that the test needs to run with testng. This causes the test to fail, or have an error, when run as a batch with other tests. >>> >>> The second @test tag is just not needed, and the @bug should be moved to the original @test tag. >>> >> Ooops that is my fault, thanks for sorting this out. > > No Problem. > >> When i ran jtreg manually it did not barf, is there anyway for it to validate the meta-data? > > I also noticed this. Running the test explicitly seems to locate just the first @test, while running in a batch (sometimes) finds the two! Not sure why. It is also ok to have more than one @test, just in this case it would need to specify testng. > > -Chris. From dmitry.samersoff at oracle.com Tue Aug 6 10:05:31 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Tue, 06 Aug 2013 10:05:31 +0000 Subject: hg: jdk8/tl/jdk: 8011038: sourceObj validation during desereliazation of RelationNotification should be relaxed Message-ID: <20130806100558.D1A33485FD@hg.openjdk.java.net> Changeset: fce446b29577 Author: dsamersoff Date: 2013-08-06 14:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fce446b29577 8011038: sourceObj validation during desereliazation of RelationNotification should be relaxed Summary: sourceObj could be set to null by setSource() relax a validation of deserialized object. Reviewed-by: sjiang, skoivu, dfuchs ! src/share/classes/javax/management/relation/RelationNotification.java From chris.hegarty at oracle.com Tue Aug 6 10:20:26 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 06 Aug 2013 11:20:26 +0100 Subject: Code review request: 8021788: JarInputStream doesn't provide certificates for some file under META-INF In-Reply-To: <51FEFFB1.2040506@oracle.com> References: <51FEFFB1.2040506@oracle.com> Message-ID: <5200CDEA.2010200@oracle.com> This looks ok to me Max, but I think it would be good to get a second review on this too. -Chris. On 05/08/2013 02:28, Weijun Wang wrote: > Please take a look at > > http://cr.openjdk.java.net/~weijun/8021788/webrev.00/ > > The problem is that the method treats no META-INF entry as normal. If we > can be sure that MANIFEST.MF and signature-related files are always at > the beginning, we can safely treat an entry normal when we have done > with those. > > Thanks > Max From alexey.utkin at oracle.com Tue Aug 6 10:27:31 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Tue, 06 Aug 2013 14:27:31 +0400 Subject: Review request: JDK-7147084 (process) appA hangs when read output stream of appB which starts appC that runs forever (v.3) In-Reply-To: <52008032.9010705@oracle.com> References: <518A88B1.3060105@oracle.com> <5190FC54.8050808@oracle.com> <5194B0D8.2040607@oracle.com> <51D685E1.1080606@oracle.com> <51D6D139.40508@oracle.com> <51DE74D1.70607@oracle.com> <51F59C1A.4070602@oracle.com> <51FFCD35.9050308@oracle.com> <52008032.9010705@oracle.com> Message-ID: <5200CF93.9030608@oracle.com> Here is new version of the fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7147084/webrev.03/ On 8/6/2013 8:48 AM, Alan Bateman wrote: > On 05/08/2013 09:05, Alexey Utkin wrote: >> Here is new version of the fix: >> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7147084/webrev.02/ >> >> Changes (in accordance with Alan's recommendations): >> -- Magic constant -1 was changed to JAVA_INVALID_HANDLE_VALUE with >> explanation why the macro >> INVALID_HANDLE_VALUE is not in use. >> -- The comments were added for each usage of the >> JAVA_INVALID_HANDLE_VALUE macro. >> -- 10 seconds time limit was rewritten to file signals. >> >> Regards, >> -uta > Thanks for adding comments. I still think initHolder will be confusing > to future maintainers and could benefit from a clear comment (above > the static BOOL ...) to explain the parameters. One typo in the > comment in " [thisProcessEnd] has no the inherit flag.". The other > functions are mostly clear now (thanks). The sentence was changed, more comments were written. > There are a few formatting oddities in > Java_java_lang_ProcessImpl_create. Looks like a newline has crept into > the if statement at L337. Then L358-364 is mis-aligned which makes it > hard to tie the JNI ReleaseStringChars back to the JNI GetStringChars. Thanks, that was [hg diff]/[patch] artifacts. Fixed. > Thanks for replacing the fragile 10s in the tests. If I read performC > (in both tests) correctly then the test will still pass after 5 > minutes even if the JDK is broken - is that right? Just wonder if it > would be better to just replace the for loop with while (true) and let > the test harness timeout the test. That is not so easy. The same program body is used 3 times in 3 different process: "A", "B", and "C". The process "A" life cycle in managed by JPRT machinery. "B" is a short-living intermediate process. "C" is a long-living "greedy" process. "C" process is unknown for JPRT and is living till the signal from process "A", or 5 min if the test failed. Hope that is long enough for slow machines. > I'm also wondering about waitAbit and whether this is useful. [waitAbit] is used to force the thread context switching. > > Otherwise I think this is good work and we are finally close to the > finish line. > > -Alan. From chris.hegarty at oracle.com Tue Aug 6 11:12:58 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 06 Aug 2013 12:12:58 +0100 Subject: RFR Additional debug info for test/java/net/NetworkInterface/IndexTest.java Message-ID: <5200DA3A.2010105@oracle.com> This test has been seen to fail intermittently on a number of systems. This change proposes to add some additional debug information to help diagnose the failure when it appears again. The test remains silent until it encounters an issue. I need a reviewer before I can push this simple change. diff -r 0a778e487a73 test/java/net/NetworkInterface/IndexTest.java --- a/test/java/net/NetworkInterface/IndexTest.java Fri Aug 02 09:38:13 2013 -0400 +++ b/test/java/net/NetworkInterface/IndexTest.java Tue Aug 06 12:06:09 2013 +0100 @@ -27,7 +27,10 @@ */ import java.net.*; +import java.util.Arrays; +import java.util.Collections; import java.util.Enumeration; +import static java.lang.System.out; public class IndexTest { public static void main(String[] args) throws Exception { @@ -39,12 +42,17 @@ public class IndexTest { if (index >= 0) { NetworkInterface nif2 = NetworkInterface.getByIndex(index); if (! nif.equals(nif2)) { + out.printf("\nExpected interfaces to be the same, but got:\n"); + displayInterfaceInformation(nif); + displayInterfaceInformation(nif2); throw new RuntimeException("both interfaces should be equal"); } } } try { nif = NetworkInterface.getByIndex(-1); + out.printf("\ngetByIndex(-1) should have thrown, but instead returned:\n"); + displayInterfaceInformation(nif); throw new RuntimeException("Should have thrown IllegalArgumentException"); } catch (IllegalArgumentException e) { // OK @@ -52,7 +60,29 @@ public class IndexTest { // In all likelyhood, this interface should not exist. nif = NetworkInterface.getByIndex(Integer.MAX_VALUE - 1); if (nif != null) { + out.printf("\ngetByIndex(MAX_VALUE - 1), expected null, got:\n"); + displayInterfaceInformation(nif); throw new RuntimeException("getByIndex() should have returned null"); } } + + static void displayInterfaceInformation(NetworkInterface netint) throws SocketException { + out.printf("Display name: %s\n", netint.getDisplayName()); + out.printf("Name: %s\n", netint.getName()); + Enumeration inetAddresses = netint.getInetAddresses(); + + for (InetAddress inetAddress : Collections.list(inetAddresses)) + out.printf("InetAddress: %s\n", inetAddress); + + out.printf("Up? %s\n", netint.isUp()); + out.printf("Loopback? %s\n", netint.isLoopback()); + out.printf("PointToPoint? %s\n", netint.isPointToPoint()); + out.printf("Supports multicast? %s\n", netint.supportsMulticast()); + out.printf("Virtual? %s\n", netint.isVirtual()); + out.printf("Hardware address: %s\n", + Arrays.toString(netint.getHardwareAddress())); + out.printf("MTU: %s\n", netint.getMTU()); + out.printf("Index: %s\n", netint.getIndex()); + out.printf("\n"); + } } -Chris. From vicente.romero at oracle.com Tue Aug 6 13:59:40 2013 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Tue, 06 Aug 2013 14:59:40 +0100 Subject: code review request: JDK-8015780: java/lang/reflect/Method/GenericStringTest.java failing Message-ID: <5201014C.90903@oracle.com> Hello, Please review this patch, which updates test jdk/test/java/lang/reflect/Method/GenericStringTest.java for it to pass after changes introduced to generation of bridge methods. Now if a bridge method is generated, all annotations present in the related "standard" method are copied to the bridge method. Part of the job of this test is to compare the method generic string against the one provided in the ExpectedGenericString annotation. The fix is to add another element to the same annotation in case a bridge method is generated. Later it's needed to determine which element's value we need to compare with. The webrev is here: http://cr.openjdk.java.net/~vromero/8015780/webrev.00/ The bug report is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015780 Thanks, Vicente. From Alan.Bateman at oracle.com Tue Aug 6 14:09:55 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 06 Aug 2013 07:09:55 -0700 Subject: RFR Additional debug info for test/java/net/NetworkInterface/IndexTest.java In-Reply-To: <5200DA3A.2010105@oracle.com> References: <5200DA3A.2010105@oracle.com> Message-ID: <520103B3.3050601@oracle.com> On 06/08/2013 04:12, Chris Hegarty wrote: > This test has been seen to fail intermittently on a number of systems. > This change proposes to add some additional debug information to help > diagnose the failure when it appears again. The test remains silent > until it encounters an issue. > > I need a reviewer before I can push this simple change. Looks okay to me (although I guess I might have used %n to be more portable). -Alan From chris.hegarty at oracle.com Tue Aug 6 14:15:41 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 06 Aug 2013 15:15:41 +0100 Subject: RFR Additional debug info for test/java/net/NetworkInterface/IndexTest.java In-Reply-To: <520103B3.3050601@oracle.com> References: <5200DA3A.2010105@oracle.com> <520103B3.3050601@oracle.com> Message-ID: <5201050D.3000604@oracle.com> On 06/08/2013 15:09, Alan Bateman wrote: > On 06/08/2013 04:12, Chris Hegarty wrote: >> This test has been seen to fail intermittently on a number of systems. >> This change proposes to add some additional debug information to help >> diagnose the failure when it appears again. The test remains silent >> until it encounters an issue. >> >> I need a reviewer before I can push this simple change. > Looks okay to me (although I guess I might have used %n to be more > portable). Will update before the push. -Chris. > > -Alan From Alan.Bateman at oracle.com Tue Aug 6 14:15:04 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 06 Aug 2013 07:15:04 -0700 Subject: FileVisitor / Are we feature frozen yet? In-Reply-To: References: Message-ID: <520104E8.1080000@oracle.com> On 06/08/2013 06:39, Ben Evans wrote: > Hi, > > I have a suggestion for a point lambdafication change which I don't think > anyone's proposed yet. (As usual, if my Google-fu has failed me, please > point me at the relevant discussion). > > In java.nio.file we have the FileVisitor interface, which defines 4 methods. > > We also have the SimpleFileVisitor class which defines sane (basically > no-op) implementations of all the methods. > > In using FileVisitor, I've noticed that visitFile() tends to be overridden > / used far more often than the others. It would be nifty if it we could > lambdify in such a way that a lambda expression could be fed to > Files.walkFileTree(). > > Could we add default implementations to FileVisitor (those from > SimpleFileVisitor seem reasonable) for all methods except visitFile() ? > > This would then make code like this possible: > > Path homeDir = Paths.get("/Users/kittylyst"); > Files.walkFileTree(homeDir, (p, attrs) -> { > System.out.println(p.getFileName()); return FileVisitResult.CONTINUE; }); > > I have a patch which demonstrates this - let me know if there's potential > here, and if anyone would be interested in sponsoring the patch. > Have you looked at the walk and find methods? (They currently return a CloseableStream but there is discussion on just returning a Stream). -Alan. From vicente.romero at oracle.com Tue Aug 6 14:18:15 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 06 Aug 2013 14:18:15 +0000 Subject: hg: jdk8/tl/langtools: 8022186: javac generates dead code if a try with an empty body has a finalizer Message-ID: <20130806141821.C84924860B@hg.openjdk.java.net> Changeset: 99b60bcf3862 Author: vromero Date: 2013-08-06 15:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/99b60bcf3862 8022186: javac generates dead code if a try with an empty body has a finalizer Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/T8022186/DeadCodeGeneratedForEmptyTryTest.java From chris.hegarty at oracle.com Tue Aug 6 14:35:49 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 06 Aug 2013 14:35:49 +0000 Subject: hg: jdk8/tl/jdk: 8022344: Additional debug info for test/java/net/NetworkInterface/IndexTest.java Message-ID: <20130806143616.38D8B4860E@hg.openjdk.java.net> Changeset: 6773af0dda02 Author: chegar Date: 2013-08-06 15:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6773af0dda02 8022344: Additional debug info for test/java/net/NetworkInterface/IndexTest.java Reviewed-by: michaelm, alanb ! test/java/net/NetworkInterface/IndexTest.java From chris.hegarty at oracle.com Tue Aug 6 15:32:43 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 06 Aug 2013 16:32:43 +0100 Subject: RFR 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress Message-ID: <5201171B.3030907@oracle.com> This is a followup to the recent discussion on: http://mail.openjdk.java.net/pipermail/net-dev/2013-July/006889.html (cont'd) http://mail.openjdk.java.net/pipermail/net-dev/2013-August/006914.html Two DatagramPacket constructors declare that they throw SocketException. DatagramPacket(byte[] buf, int len, SocketAddress sa) throws SocketException DatagramPacket(byte[] buf, int off, int len, SocketAddress sa) throws SocketException As it happens 'throws SE' was incorrectly added to these constructors when introduced in 1.4. The original API specified that SE was thrown when the given SocketAddress was not supported. That was later changed to throw IAE, in 1.4.2. These constructor now can never throw SE. Removing 'throws SE' from the method declaration is a binary compatible change, but not source compatible ( XXX is never thrown in body of corresponding try statement ). The conclusion of the discussion is that since these constructors are not that widely used (the InetAddress+port variants are more popular). Where they are, the affected code typically sends the packet, which requires handling of IOException anyway. A note will be added to the jdk8 release notes documenting this incompatibility. diff -r 6773af0dda02 src/share/classes/java/net/DatagramPacket.java --- a/src/share/classes/java/net/DatagramPacket.java Tue Aug 06 15:35:20 2013 +0100 +++ b/src/share/classes/java/net/DatagramPacket.java Tue Aug 06 16:26:38 2013 +0100 @@ -140,7 +140,7 @@ class DatagramPacket { * @since 1.4 */ public DatagramPacket(byte buf[], int offset, int length, - SocketAddress address) throws SocketException { + SocketAddress address) { setData(buf, offset, length); setSocketAddress(address); } @@ -176,7 +176,7 @@ class DatagramPacket { * @see java.net.InetAddress */ public DatagramPacket(byte buf[], int length, - SocketAddress address) throws SocketException { + SocketAddress address) { this(buf, 0, length, address); } -Chris. From Alan.Bateman at oracle.com Tue Aug 6 15:57:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 06 Aug 2013 08:57:17 -0700 Subject: RFR 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress In-Reply-To: <5201171B.3030907@oracle.com> References: <5201171B.3030907@oracle.com> Message-ID: <52011CDD.2000001@oracle.com> On 06/08/2013 08:32, Chris Hegarty wrote: > This is a followup to the recent discussion on: > http://mail.openjdk.java.net/pipermail/net-dev/2013-July/006889.html > (cont'd) > http://mail.openjdk.java.net/pipermail/net-dev/2013-August/006914.html > > Two DatagramPacket constructors declare that they throw SocketException. > > DatagramPacket(byte[] buf, int len, SocketAddress sa) throws > SocketException > DatagramPacket(byte[] buf, int off, int len, SocketAddress sa) > throws SocketException > > As it happens 'throws SE' was incorrectly added to these constructors > when introduced in 1.4. The original API specified that SE was thrown > when the given SocketAddress was not supported. That was later changed > to throw IAE, in 1.4.2. These constructor now can never throw SE. > > Removing 'throws SE' from the method declaration is a binary > compatible change, but not source compatible ( XXX is never thrown in > body of corresponding try statement ). > > The conclusion of the discussion is that since these constructors are > not that widely used (the InetAddress+port variants are more popular). > Where they are, the affected code typically sends the packet, which > requires handling of IOException anyway. > > A note will be added to the jdk8 release notes documenting this > incompatibility. While it a source incompatible change, I think it's the right thing to do. The patch looks fine to me (if you want then the declaration will probably fit on one line now). -Alan. From sean.mullan at oracle.com Tue Aug 6 15:56:29 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 06 Aug 2013 15:56:29 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130806155652.F28CB48610@hg.openjdk.java.net> Changeset: 1f4af3e0447e Author: mullan Date: 2013-08-06 08:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1f4af3e0447e 8022120: JCK test api/javax_xml/crypto/dsig/TransformService/index_ParamMethods fails Summary: TransformService.init and marshalParams must throw NullPointerException when parent parameter is null Reviewed-by: xuelei ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java + test/javax/xml/crypto/dsig/TransformService/NullParent.java Changeset: ba634b53f53a Author: mullan Date: 2013-08-06 08:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ba634b53f53a Merge From Alan.Bateman at oracle.com Tue Aug 6 16:14:54 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 06 Aug 2013 09:14:54 -0700 Subject: Review request: JDK-7147084 (process) appA hangs when read output stream of appB which starts appC that runs forever (v.3) In-Reply-To: <5200CF93.9030608@oracle.com> References: <518A88B1.3060105@oracle.com> <5190FC54.8050808@oracle.com> <5194B0D8.2040607@oracle.com> <51D685E1.1080606@oracle.com> <51D6D139.40508@oracle.com> <51DE74D1.70607@oracle.com> <51F59C1A.4070602@oracle.com> <51FFCD35.9050308@oracle.com> <52008032.9010705@oracle.com> <5200CF93.9030608@oracle.com> Message-ID: <520120FE.4050208@oracle.com> On 06/08/2013 03:27, Alexey Utkin wrote: > Here is new version of the fix: > http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7147084/webrev.03/ > Thanks for the updates, it looks good now. I think someday we might need to re-examine performC in the tests but what you have is fine for now. -Alan. From Alan.Bateman at oracle.com Tue Aug 6 16:18:51 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 06 Aug 2013 09:18:51 -0700 Subject: FileVisitor / Are we feature frozen yet? In-Reply-To: References: <520104E8.1080000@oracle.com> Message-ID: <520121EB.9040001@oracle.com> On 06/08/2013 08:00, Ben Evans wrote: > On Files? > > Yes, that does indeed look suspiciously like it'll cover the current use > cases I have. Let me check& come back if not. > > Ben > The BiPredicate that find takes is useful to filter the source so this can be used to get a stream of the non-directories in the file tree (so equivalent to what visitFile would be called with when using walkFileTree). -Alan From ivan.gerasimov at oracle.com Tue Aug 6 16:38:48 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 06 Aug 2013 20:38:48 +0400 Subject: RFR [6961766]: PrintStream.write() should flush at most once Message-ID: <52012698.4090005@oracle.com> Hello everybody! Would you please review a simple fix, suggested by someone on bugs.sun.com? j.i.PrintStream#write(char[]) calls out.flush() on each '\n' character found in the array. It's sufficient to do it only once. BUGURL: http://bugs.sun.com/view_bug.do?bug_id=6961766 WEBREV: http://cr.openjdk.java.net/~igerasim/6961766/0/webrev/ Sincerely yours, Ivan From joel.franck at oracle.com Tue Aug 6 17:03:13 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Tue, 06 Aug 2013 17:03:13 +0000 Subject: hg: jdk8/tl/jdk: 7184826: (reflect) Add support for Project Lambda concepts in core reflection Message-ID: <20130806170335.9D79848615@hg.openjdk.java.net> Changeset: cd0ea5563523 Author: jfranck Date: 2013-08-06 18:54 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd0ea5563523 7184826: (reflect) Add support for Project Lambda concepts in core reflection Reviewed-by: darcy, jfranck Contributed-by: Amy Lu + test/java/lang/reflect/DefaultStaticTest/DefaultStaticInvokeTest.java + test/java/lang/reflect/DefaultStaticTest/DefaultStaticTestData.java + test/java/lang/reflect/DefaultStaticTest/helper/Declared.java + test/java/lang/reflect/DefaultStaticTest/helper/Mod.java ! test/java/lang/reflect/Method/DefaultMethodModeling.java ! test/java/lang/reflect/Method/IsDefaultTest.java From mike.duigou at oracle.com Tue Aug 6 17:06:06 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 6 Aug 2013 10:06:06 -0700 Subject: RFR (2nd): 8015318: Extend Collector with 'finish' operation In-Reply-To: <52008C69.1040203@oracle.com> References: <51DC82CB.2080007@oracle.com> <52008C69.1040203@oracle.com> Message-ID: <10C5E931-00BA-487B-9239-D82A235B2086@oracle.com> Looks OK. A few minor non-blocking comments: DelegatingStream:: - I wonder if an extends wildcard might also be included on R ReduceOps:: - It is not clear in makeRef why collector.accumulator() wouldn't also benefit from a Objects.requireNonNull General:: - Is there a constant immutable EnumSet for the Collector.Characteristics.IDENTITY_FINISH ? It would be nice to avoid creating lots of EnumSet instances. On Aug 5 2013, at 22:40 , Henry Jen wrote: > Ping on this, the 8012238 fix is already in, thus this webrev is ready > to go, only if we can have a reviewer review it. > > Cheers, > Henry > > > On 07/09/2013 02:38 PM, Henry Jen wrote: >> Hi, >> >> An update from earlier request based on some feedbacks. >> >> The webrev is at >> >> http://cr.openjdk.java.net/~henryjen/ccc/8015318.1/webrev >> >> This webrev depends on fix of bug 8012238[1]. Before that bug is fixed, >> applies this patch[2] to add needed type information. >> >> See the summary of API changes, specdiff is at >> >> http://cr.openjdk.java.net/~henryjen/ccc/8015318.1/specdiff/overview-summary.html >> >> >> [1] http://bugs.sun.com/view_bug.do?bug_id=8012238 >> [2] http://cr.openjdk.java.net/~henryjen/ccc/8015318.1/collector-hacks.patch >> >> Cheers, >> Henry >> > From paul.sandoz at oracle.com Tue Aug 6 17:15:53 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 6 Aug 2013 18:15:53 +0100 Subject: RFR (2nd): 8015318: Extend Collector with 'finish' operation In-Reply-To: <10C5E931-00BA-487B-9239-D82A235B2086@oracle.com> References: <51DC82CB.2080007@oracle.com> <52008C69.1040203@oracle.com> <10C5E931-00BA-487B-9239-D82A235B2086@oracle.com> Message-ID: On Aug 6, 2013, at 6:06 PM, Mike Duigou wrote: > General:: > > - Is there a constant immutable EnumSet for the Collector.Characteristics.IDENTITY_FINISH ? It would be nice to avoid creating lots of EnumSet instances. > There is a package private unmodifiable Set: Collectors .CH_ID Are you suggesting that should be made public? Paul. From michael.x.mcmahon at oracle.com Tue Aug 6 17:18:39 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 06 Aug 2013 18:18:39 +0100 Subject: RFR 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress In-Reply-To: <52011CDD.2000001@oracle.com> References: <5201171B.3030907@oracle.com> <52011CDD.2000001@oracle.com> Message-ID: <52012FEF.9030307@oracle.com> On 06/08/13 16:57, Alan Bateman wrote: > On 06/08/2013 08:32, Chris Hegarty wrote: >> This is a followup to the recent discussion on: >> http://mail.openjdk.java.net/pipermail/net-dev/2013-July/006889.html >> (cont'd) >> http://mail.openjdk.java.net/pipermail/net-dev/2013-August/006914.html >> >> Two DatagramPacket constructors declare that they throw SocketException. >> >> DatagramPacket(byte[] buf, int len, SocketAddress sa) throws >> SocketException >> DatagramPacket(byte[] buf, int off, int len, SocketAddress sa) >> throws SocketException >> >> As it happens 'throws SE' was incorrectly added to these constructors >> when introduced in 1.4. The original API specified that SE was thrown >> when the given SocketAddress was not supported. That was later >> changed to throw IAE, in 1.4.2. These constructor now can never throw >> SE. >> >> Removing 'throws SE' from the method declaration is a binary >> compatible change, but not source compatible ( XXX is never thrown in >> body of corresponding try statement ). >> >> The conclusion of the discussion is that since these constructors are >> not that widely used (the InetAddress+port variants are more >> popular). Where they are, the affected code typically sends the >> packet, which requires handling of IOException anyway. >> >> A note will be added to the jdk8 release notes documenting this >> incompatibility. > While it a source incompatible change, I think it's the right thing to > do. > > The patch looks fine to me (if you want then the declaration will > probably fit on one line now). > > -Alan. Late to this discussion ... So, the extent of the source compatibility is that a possible user of this class may have to edit their calling code, when recompiling in JDK 8 to possibly remove a catch(SocketException) block, which was dead code that was never being called? I guess that is okay especially since it's not so likely to happen. But, if it does, it will probably cause some confusion, as developers won't be expecting it. Documenting in release notes is okay too, but I suspect developers are not likely to look there at first anyway. Thinking aloud, it would be nice if some kind of annotation could be associated with the affected constructors such that a more meaningful/customized error message could be emitted by javac. But, perhaps there aren't sufficient other use cases to justify that. Michael. From joe.darcy at oracle.com Tue Aug 6 17:23:55 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 06 Aug 2013 10:23:55 -0700 Subject: RFR JDK 8 JDK-8022404 Fix doclint issues in java.applet Message-ID: <5201312B.2010005@oracle.com> Hello, Please review this fix below for the doclint issues in java.applet. Thanks, -Joe diff -r ba634b53f53a src/share/classes/java/applet/AppletContext.java --- a/src/share/classes/java/applet/AppletContext.java Tue Aug 06 08:34:28 2013 -0700 +++ b/src/share/classes/java/applet/AppletContext.java Tue Aug 06 10:21:19 2013 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1995, 2006, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -56,7 +56,7 @@ /** * Returns an Image object that can then be painted on - * the screen. The url argument that is + * the screen. The url argument that is * passed as an argument must specify an absolute URL. *

* This method always returns immediately, whether or not the image @@ -157,7 +157,7 @@ * @param stream stream to be associated with the specified key. If this * parameter is null, the specified key is removed * in this applet context. - * @throws IOException if the stream size exceeds a certain + * @throws IOException if the stream size exceeds a certain * size limit. Size limit is decided by the implementor of this * interface. * @since 1.4 From philip.race at oracle.com Tue Aug 6 17:36:54 2013 From: philip.race at oracle.com (Phil Race) Date: Tue, 06 Aug 2013 10:36:54 -0700 Subject: RFR JDK 8 JDK-8022404 Fix doclint issues in java.applet In-Reply-To: <5201312B.2010005@oracle.com> References: <5201312B.2010005@oracle.com> Message-ID: <52013436.8030108@oracle.com> Looks OK. Not sure we need to update copyright unless there's something copyrightable -phil. On 8/6/13 10:23 AM, Joe Darcy wrote: > Hello, > > Please review this fix below for the doclint issues in java.applet. > > Thanks, > > -Joe > > diff -r ba634b53f53a src/share/classes/java/applet/AppletContext.java > --- a/src/share/classes/java/applet/AppletContext.java Tue Aug 06 > 08:34:28 2013 -0700 > +++ b/src/share/classes/java/applet/AppletContext.java Tue Aug 06 > 10:21:19 2013 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 2006, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -56,7 +56,7 @@ > > /** > * Returns an Image object that can then be painted on > - * the screen. The url argument that is > + * the screen. The url argument that is > * passed as an argument must specify an absolute URL. > *

> * This method always returns immediately, whether or not the image > @@ -157,7 +157,7 @@ > * @param stream stream to be associated with the specified key. > If this > * parameter is null, the specified > key is removed > * in this applet context. > - * @throws IOException if the stream size exceeds a > certain > + * @throws IOException if the stream size exceeds a certain > * size limit. Size limit is decided by the implementor > of this > * interface. > * @since 1.4 > From joe.darcy at oracle.com Tue Aug 6 20:25:21 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 06 Aug 2013 20:25:21 +0000 Subject: hg: jdk8/tl/jdk: 8022174: Fix doclint warnings in javax.sound; ... Message-ID: <20130806202538.5AED948628@hg.openjdk.java.net> Changeset: 98643f3ddf40 Author: darcy Date: 2013-08-06 13:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98643f3ddf40 8022174: Fix doclint warnings in javax.sound 8022404: Fix doclint issues in java.applet Reviewed-by: prr ! src/share/classes/java/applet/AppletContext.java ! src/share/classes/javax/sound/midi/MetaMessage.java ! src/share/classes/javax/sound/midi/MidiDevice.java ! src/share/classes/javax/sound/midi/MidiDeviceReceiver.java ! src/share/classes/javax/sound/midi/MidiDeviceTransmitter.java ! src/share/classes/javax/sound/midi/MidiFileFormat.java ! src/share/classes/javax/sound/midi/MidiMessage.java ! src/share/classes/javax/sound/midi/MidiSystem.java ! src/share/classes/javax/sound/midi/ShortMessage.java ! src/share/classes/javax/sound/midi/Synthesizer.java ! src/share/classes/javax/sound/midi/SysexMessage.java ! src/share/classes/javax/sound/midi/Track.java ! src/share/classes/javax/sound/sampled/AudioFileFormat.java ! src/share/classes/javax/sound/sampled/AudioFormat.java ! src/share/classes/javax/sound/sampled/AudioSystem.java ! src/share/classes/javax/sound/sampled/BooleanControl.java ! src/share/classes/javax/sound/sampled/Mixer.java ! src/share/classes/javax/sound/sampled/spi/FormatConversionProvider.java From stuart.marks at oracle.com Tue Aug 6 20:40:32 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Tue, 06 Aug 2013 20:40:32 +0000 Subject: hg: jdk8/tl/jdk: 8022412: Fixed warnings in java.util root, except for HashMap Message-ID: <20130806204046.A790D4862B@hg.openjdk.java.net> Changeset: 12c1b78acf9a Author: lagergren Date: 2013-08-06 12:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/12c1b78acf9a 8022412: Fixed warnings in java.util root, except for HashMap Reviewed-by: mduigou, darcy Contributed-by: marcus.lagergren at oracle.com ! src/share/classes/java/util/ArrayPrefixHelpers.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Comparator.java ! src/share/classes/java/util/Comparators.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/WeakHashMap.java From jason.uh at oracle.com Tue Aug 6 20:46:52 2013 From: jason.uh at oracle.com (jason.uh at oracle.com) Date: Tue, 06 Aug 2013 20:46:52 +0000 Subject: hg: jdk8/tl/jdk: 8022439: Fix lint warnings in sun.security.ec Message-ID: <20130806204704.1C4B04862C@hg.openjdk.java.net> Changeset: 8112076ae424 Author: juh Date: 2013-08-06 13:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8112076ae424 8022439: Fix lint warnings in sun.security.ec Reviewed-by: darcy ! src/share/classes/sun/security/ec/ECDSASignature.java From stuart.marks at oracle.com Tue Aug 6 21:08:12 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 06 Aug 2013 14:08:12 -0700 Subject: RFR: 8022440: suppress deprecation warnings in sun.rmi Message-ID: <520165BC.5050503@oracle.com> Please review the following change to suppress a bunch of deprecation warnings from the sun.rmi package. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022440 (not yet publicly visible, but it will be eventually) Webrev: http://cr.openjdk.java.net/~smarks/reviews/8022440/webrev.0/ Thanks! s'marks From mike.duigou at oracle.com Tue Aug 6 21:07:43 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 6 Aug 2013 14:07:43 -0700 Subject: RFR: 8022440: suppress deprecation warnings in sun.rmi In-Reply-To: <520165BC.5050503@oracle.com> References: <520165BC.5050503@oracle.com> Message-ID: <524AE25D-0589-4D95-93B4-64785E2A07FC@oracle.com> Looks fine (reviewed patch file rather than webrev) Mike On Aug 6 2013, at 14:08 , Stuart Marks wrote: > Please review the following change to suppress a bunch of deprecation warnings from the sun.rmi package. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022440 > (not yet publicly visible, but it will be eventually) > > Webrev: http://cr.openjdk.java.net/~smarks/reviews/8022440/webrev.0/ > > Thanks! > > s'marks > From daniel.smith at oracle.com Tue Aug 6 21:11:19 2013 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 6 Aug 2013 14:11:19 -0700 Subject: RFR JDK-8022442: Fix unchecked warnings in HashMap Message-ID: Please review this warnings cleanup. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022442 (not yet visible) Webrev: http://cr.openjdk.java.net/~dlsmith/8022442/webrev.00/ ?Dan From jason.uh at oracle.com Tue Aug 6 21:10:36 2013 From: jason.uh at oracle.com (jason.uh at oracle.com) Date: Tue, 06 Aug 2013 21:10:36 +0000 Subject: hg: jdk8/tl/jdk: 8022443: Fix lint warnings in sun.security.pkcs12 Message-ID: <20130806211049.52D984862E@hg.openjdk.java.net> Changeset: 69cfd941aec2 Author: juh Date: 2013-08-06 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/69cfd941aec2 8022443: Fix lint warnings in sun.security.pkcs12 Reviewed-by: darcy ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java From henry.jen at oracle.com Tue Aug 6 21:28:11 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 06 Aug 2013 14:28:11 -0700 Subject: RFR: 8022446: Fix serial warnings in java.util.stream Message-ID: <52016A6B.3090000@oracle.com> Hi, Please review a webrev[1] clean up on serial warning, as we don't intend to serialize those tasks, we simply suppress those warnings. It would be nice if there is a way to undo serializable. [1] http://cr.openjdk.java.net/~henryjen/tl/8022446/0/webrev/ Cheers, Henry From joe.darcy at oracle.com Tue Aug 6 21:34:58 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 06 Aug 2013 14:34:58 -0700 Subject: RFR JDK-8022442: Fix unchecked warnings in HashMap In-Reply-To: References: Message-ID: <52016C02.3040601@oracle.com> Hi Dan, Looks good; nice cleanup :-) Thanks, -Joe On 08/06/2013 02:11 PM, Dan Smith wrote: > Please review this warnings cleanup. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022442 (not yet visible) > Webrev: http://cr.openjdk.java.net/~dlsmith/8022442/webrev.00/ > > ?Dan From dan.xu at oracle.com Tue Aug 6 21:34:13 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Tue, 06 Aug 2013 21:34:13 +0000 Subject: hg: jdk8/tl/jdk: 8022410: Fix Javac Warnings in com.sun.security.auth Package Message-ID: <20130806213427.3FD5948632@hg.openjdk.java.net> Changeset: 4b8b811059db Author: dxu Date: 2013-08-06 14:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b8b811059db 8022410: Fix Javac Warnings in com.sun.security.auth Package Reviewed-by: darcy ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/SubjectCodeSource.java From stuart.marks at oracle.com Tue Aug 6 21:19:57 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Tue, 06 Aug 2013 21:19:57 +0000 Subject: hg: jdk8/tl/jdk: 8022440: suppress deprecation warnings in sun.rmi Message-ID: <20130806212010.B4F394862F@hg.openjdk.java.net> Changeset: 31e923842d49 Author: smarks Date: 2013-08-06 14:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31e923842d49 8022440: suppress deprecation warnings in sun.rmi Reviewed-by: mduigou ! src/share/classes/sun/rmi/runtime/Log.java ! src/share/classes/sun/rmi/server/ActivatableRef.java ! src/share/classes/sun/rmi/server/Dispatcher.java ! src/share/classes/sun/rmi/server/LoaderHandler.java ! src/share/classes/sun/rmi/server/UnicastRef.java ! src/share/classes/sun/rmi/server/UnicastServerRef.java ! src/share/classes/sun/rmi/server/Util.java ! src/share/classes/sun/rmi/transport/DGCImpl.java ! src/share/classes/sun/rmi/transport/StreamRemoteCall.java ! src/share/classes/sun/rmi/transport/Transport.java ! src/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java ! src/share/classes/sun/rmi/transport/tcp/ConnectionMultiplexer.java ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java From forax at univ-mlv.fr Tue Aug 6 21:43:41 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 06 Aug 2013 23:43:41 +0200 Subject: RFR JDK-8022442: Fix unchecked warnings in HashMap In-Reply-To: References: Message-ID: <52016E0D.8070008@univ-mlv.fr> On 08/06/2013 11:11 PM, Dan Smith wrote: > Please review this warnings cleanup. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022442 (not yet visible) > Webrev: http://cr.openjdk.java.net/~dlsmith/8022442/webrev.00/ > > ?Dan Hi Dan, I've seen that you have introduce a common super interface for entry and tree node, I suppose that you check that there is no performance regression. I wonder if an abstract class is not better than an interface because as far as I know CHA implemented in hotspot doesn't work on interface (but I may be wrong, there is perhaps a special optimization for arrays). cheers, R?mi From kumar.x.srinivasan at oracle.com Tue Aug 6 21:57:06 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 06 Aug 2013 14:57:06 -0700 Subject: RFR: 8015666: test/tools/pack200/TimeStamp.java failing In-Reply-To: <51FC1481.2020203@oracle.com> References: <51C34E6D.4000502@oracle.com> <51CC7099.2050007@oracle.com> <51CC7291.1080602@oracle.com> <51CDA1ED.9040302@oracle.com> <51D31BF4.3000900@oracle.com> <51FC1481.2020203@oracle.com> Message-ID: <52017132.1060303@oracle.com> Hi Sherman, The code changes look good to me, I was thinking about the test and here are some observations: test/java/util/zip/TestExtraTime.java a. you have TZ of Asia/Shanghai, I am wondering if it would help to add a TZ which has DST for any DST computation issues that we might encounter. Also perhaps a tests which zips a file in one TimeZone and test in another TimeZone ? If these are being addressed by SQE that is fine. b. this test sets the default TimeZone, this could cause weird issues for other downstream tests, specifically when jtreg runs in the samevm or agentvm mode, so either we run this test in a discrete VM or reset the TimeZone using a finally. Thanks Kumar > Kumar, Alan, > > Here is the latest webrev of the changes based on the latest CCC. > > http://cr.openjdk.java.net/~sherman/8015666/webrev > > -Sherman > > > On 07/02/2013 11:29 AM, Xueming Shen wrote: >> On 06/28/2013 07:47 AM, Kumar Srinivasan wrote: >>> Some nits while reading the changes: >>> 1. ZipEntry.java >>> a. typo: >>> >>> + * Sets the laste access time of the entry. >>> >>> >>> b. extra space >>> >>> + case EXTID_ZIP64 : >>> >>> 2. ZipOutputStream.java >>> I think it would be nice to have the flags 0x1, 0x2 and 0x4 defined >>> as constants, this will also help a casual reader as to what this >>> means. >>> >>> >>> Besides my previous concern with finish(), everything else appears >>> to be ok. >> >> Kumar, >> >> I have the dostime "cached" in XEntry, so the writeCEN() and >> writeLOC() will >> always write out the same local msdos time. The cache should help the >> perf >> a little, as the javaToDosTime() now only invoked once for the same >> entry. >> >> Nothing needs to be updated in unpack side now. (I took a look at the >> API, >> it appears there is no way to do anything on unpack side to workaround >> this issue, without the possibility of breaking someone's code) >> >> http://cr.openjdk.java.net/~sherman/8015666/webrev/ >> >> -Sherman >> >>> >>> Kumar >>> >>> >>>> On 06/27/2013 10:04 AM, Kumar Srinivasan wrote: >>>>> Hi Sherman, >>>>> >>>>> I started looking at this, my initial comment, the Unpacker.unpack >>>>> does not close its output and we allow multiple pack files to be >>>>> concatenated, >>>>> I am assuming out.finish() will allow further jar files to be >>>>> appended ? >>>>> or would this cause a problem ? >>>> >>>> No, out.finish() will not allow further entry appending. Then, it >>>> appears >>>> we need to have a different approach to "finish" the >>>> Jar/ZipOutputStream. >>>> What need to be done here is that either out.close/finish() need to be >>>> invoked under the UTC locale as well (to output the time stamps in cen >>>> table correctly). This is another "incompatible" change of the >>>> previous >>>> change, in which the msdosTime<->javaTime conversion no longer >>>> occurs during the ZipEntry.set/getTime(), but during the read and >>>> write >>>> the ZipEntry from/to the zip file. >>>> >>>> -Sherman >>>> >>>> >>>>> >>>>> Kumar >>>>> >>>>>> Hi, >>>>>> >>>>>> The zip time related changes[1] I pushed back last month appears >>>>>> to have the compatibility risk of breaking existing code. The main >>>>>> idea in that changeset is to use the more accurate and timezone >>>>>> insensitive utc time stored in the extra field for the >>>>>> ZipEntry.set/getTime() >>>>>> if possible. However it turns out the reality is that the code >>>>>> out there >>>>>> might have already had some interesting workaround/hack solution >>>>>> to workaround the problem that the time stamp stored in the >>>>>> "standard' >>>>>> zip entry header is a MS-DOS standard date/time, which is a "local >>>>>> date/time" and sensitive to timezone, in which, if the zip is >>>>>> archived >>>>>> in time zone A (our implementation converts the "java" time to dos >>>>>> time by using the default tz A) and then transferred/un-archived in >>>>>> a different zone B (use default tz B to convert back to java >>>>>> time), we >>>>>> have a time stamp mess up. The "workaround" from pack200 for this >>>>>> issue when pack/unpacking a jar file is to >>>>>> "specify/recommend/suggest" >>>>>> in its spec that the "time zone" in a jar file entry is assumed >>>>>> to be "UTC", >>>>>> so the pack/unpack200 implementation set the "default time" to utc >>>>>> before the pack/unpack and set it back to the original after >>>>>> that. It worked >>>>>> "perfectly" for a roundtrip pack/unpacking, until the changeset >>>>>> [2], in >>>>>> which ZipEntry.getTime() (packing) returns a real utc time and >>>>>> the following >>>>>> ZipEntry.setTime() (unpacking), then mess up the MS-DOS date/time >>>>>> entry, this is the root cause of this regression. >>>>>> >>>>>> Given the facts that >>>>>> (1) there are actually two real physical time stamps in a zip >>>>>> file header, >>>>>> one is in the date/time fields, which is >>>>>> MS-DOS-local-date/time-with-2- >>>>>> seconds-granularity , one is in the extra data field, which is >>>>>> UTC-1-second >>>>>> -granularity >>>>>> (2) and there are applications over there that have dependency on >>>>>> the >>>>>> MS-DOS date/time stamp. >>>>>> >>>>>> I'm proposing the following approach to add the functionality of >>>>>> supporting >>>>>> the "utc-date/time-with-1-second granularity" and keep the old >>>>>> behavior >>>>>> of the get/setTime() of the ZipEntry. >>>>>> >>>>>> (1) keep the time/setTime()/getTime() for the MS-DOS standard >>>>>> date/time. >>>>>> To set via the old setTime() will only store the time into >>>>>> zip's standard >>>>>> date/time field, which is in MS-DOS date/time. And getTime() >>>>>> only returns >>>>>> the date/time from that field, when read from the zip >>>>>> file/stream. >>>>>> (2) add mtime/set/getLastModifiedTime() to work on the UTC time >>>>>> fields, >>>>>> and the last modified time set via the new method will also >>>>>> set the "time", >>>>>> and the getLastModifiedTime() also returns the "time", if >>>>>> the UTC time >>>>>> stamp fields are not set in the zip file header. The idea is >>>>>> that for the new >>>>>> application, the recommendation is to use >>>>>> ZipEntry.set/getLastModifiedTime() >>>>>> for better/correct time stamp, but the existing apps keep >>>>>> the same behavior. >>>>>> (3) jar and ZipOutputStream are updated to use the >>>>>> set/getLastModifiedTime(). >>>>>> (4) Pack/unpack continues to use the set/getTime(), so the >>>>>> current workaround >>>>>> continues work. I will leave this to Kuma to decide how it >>>>>> should be handled >>>>>> going forward. (there are two facts need to be considered >>>>>> here, a) the >>>>>> existing jar file might not have the utc time instored, and >>>>>> b) all "extra" data >>>>>> are wiped out during the pack/unpacking process) >>>>>> (5) additionally add another pair of atime/get/setLastAccessTime and >>>>>> ctime/get/setCreationTime(). >>>>>> (6) The newly added 3 pairs of the m/a/ctime get/set methods use >>>>>> the "new" >>>>>> nio FileTime, instead of the "long". This may add some >>>>>> additional cost of >>>>>> conversion when working with them, but may also help improve >>>>>> the >>>>>> performance if the time stamps are directly from nio file >>>>>> system when >>>>>> get/set XYZTime. Good/bad? >>>>>> >>>>>> http://cr.openjdk.java.net/~sherman/8015666/webrev/ >>>>>> >>>>>> Comment, option and suggestion are appreciated. >>>>>> >>>>>> -Sherman >>>>>> >>>>>> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90df6756406f >>>>> >>>> >>> >> > From tom.hawtin at oracle.com Tue Aug 6 22:01:20 2013 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Tue, 06 Aug 2013 15:01:20 -0700 Subject: RFR: 8022446: Fix serial warnings in java.util.stream In-Reply-To: <52016A6B.3090000@oracle.com> References: <52016A6B.3090000@oracle.com> Message-ID: <52017230.5040404@oracle.com> Are you happy with the API docs in docs/api/serialized-form.html? Tom On 06/08/2013 14:28, Henry Jen wrote: > Hi, > > Please review a webrev[1] clean up on serial warning, as we don't intend > to serialize those tasks, we simply suppress those warnings. > > It would be nice if there is a way to undo serializable. > > [1] http://cr.openjdk.java.net/~henryjen/tl/8022446/0/webrev/ > > Cheers, > Henry > From daniel.smith at oracle.com Tue Aug 6 22:00:26 2013 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 6 Aug 2013 15:00:26 -0700 Subject: RFR JDK-8022442: Fix unchecked warnings in HashMap In-Reply-To: References: Message-ID: <9370E94C-04C1-45F3-808F-A7A3A60EEEC5@oracle.com> Update: some minor changes are necessary to LinkedHashMap to be compatible with the HashMap changes (HashMap is unchanged). Webrev: http://cr.openjdk.java.net/~dlsmith/8022442/webrev.01/ I confirmed that the jdk_util tests pass. ?Dan On Aug 6, 2013, at 2:11 PM, Dan Smith wrote: > Please review this warnings cleanup. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022442 (not yet visible) > Webrev: http://cr.openjdk.java.net/~dlsmith/8022442/webrev.00/ > > ?Dan From brent.christian at oracle.com Tue Aug 6 22:10:26 2013 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 06 Aug 2013 15:10:26 -0700 Subject: RFR JDK-8022442: Fix unchecked warnings in HashMap In-Reply-To: References: Message-ID: <52017452.4000204@oracle.com> Looks fine to me, though I'm not a Reviewer (but I think I "contributed" a fair number of those warnings O:). One question: why was enext added?: 1249 Entry enext = (Entry) newTable[i]; 1250 e.next = enext; Thanks, -Brent On 8/6/13 2:11 PM, Dan Smith wrote: > Please review this warnings cleanup. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022442 (not yet visible) > Webrev: http://cr.openjdk.java.net/~dlsmith/8022442/webrev.00/ > > ?Dan > From daniel.smith at oracle.com Tue Aug 6 22:13:26 2013 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 6 Aug 2013 15:13:26 -0700 Subject: RFR JDK-8022442: Fix unchecked warnings in HashMap In-Reply-To: <52017452.4000204@oracle.com> References: <52017452.4000204@oracle.com> Message-ID: <886305C3-BF8E-4061-BA77-9FD6B698080F@oracle.com> An intermediate result from an unnecessary refactoring. Thanks for catching. ?Dan On Aug 6, 2013, at 3:10 PM, Brent Christian wrote: > Looks fine to me, though I'm not a Reviewer (but I think I "contributed" a fair number of those warnings O:). > > One question: why was enext added?: > > 1249 Entry enext = (Entry) newTable[i]; > 1250 e.next = enext; > > Thanks, > -Brent > > On 8/6/13 2:11 PM, Dan Smith wrote: >> Please review this warnings cleanup. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022442 (not yet visible) >> Webrev: http://cr.openjdk.java.net/~dlsmith/8022442/webrev.00/ >> >> ?Dan >> From jeremymanson at google.com Tue Aug 6 22:21:55 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 6 Aug 2013 15:21:55 -0700 Subject: Deadlock in clinit for sun.nio.ch.Util/IOUtil Message-ID: FAO alanb, I suppose. There's a deadlock in these classes. Thread 1 owns the class lock on Util, and is suspended waiting for IOUtil to finish its class init. Thread 2 owns the class lock on IOUtil, and is suspended waiting for Util to finish its class init. Thread 1 (Suspended) owns: Class (sun.nio.ch.Util) (id=19) Util.load() line: 491 EPollSelectorImpl.() line: 201 EPollSelectorProvider.openSelector() line: 36 Selector.open() line: 227 Thread 2 (Suspended) waiting for: Class (sun.nio.ch.Util) (id=19) owned by: Thread [main] (Suspended) Util.load() line: 482 IOUtil.() line: 340 PipeImpl.(SelectorProvider) line: 42 EPollSelectorProvider(SelectorProviderImpl).openPipe() line: 50 Pipe.open() line: 150 We can eagerly do class init as a workaround, but that seems less than ideal. It looks easy enough to fix - just move the stuff in Util.load() into IOUtil somewhere, and don't call back to Util from IOUtil.. But I'll defer to the experts. Thanks! Jeremy From daniel.smith at oracle.com Tue Aug 6 22:23:14 2013 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 6 Aug 2013 15:23:14 -0700 Subject: RFR JDK-8022442: Fix unchecked warnings in HashMap In-Reply-To: <52016E0D.8070008@univ-mlv.fr> References: <52016E0D.8070008@univ-mlv.fr> Message-ID: <201C24F5-3499-48E1-8BBA-E8A0A757015E@oracle.com> On Aug 6, 2013, at 2:43 PM, Remi Forax wrote: > On 08/06/2013 11:11 PM, Dan Smith wrote: >> Please review this warnings cleanup. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022442 (not yet visible) >> Webrev: http://cr.openjdk.java.net/~dlsmith/8022442/webrev.00/ >> >> ?Dan > > Hi Dan, > I've seen that you have introduce a common super interface for entry and tree node, > I suppose that you check that there is no performance regression. > I wonder if an abstract class is not better than an interface because as far as I know > CHA implemented in hotspot doesn't work on interface > (but I may be wrong, there is perhaps a special optimization for arrays). To make sure I understand: your concern is that an aastore will be more expensive when assigning to a KeyValueData[] than to an Object[] (or even to SomeOtherClass[])? For what it's worth, all assignments to table[i] are statically known to be safe. E.g.: Entry next = (Entry) e.next; ... table[i] = next; So surely a smart VM only does the check once? Here are some other things that might be concerns, but don't apply here: - interface method invocations: there are no methods in the interface to invoke - checkcast to an interface: all the casts are to concrete classes (Entry, TreeBin, TreeNode) (There are some unchecked casts from KeyValueData to KeyValueData with different type parameters, but I assume these don't cause any checkcasts.) ?Dan From henry.jen at oracle.com Tue Aug 6 22:35:18 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 06 Aug 2013 15:35:18 -0700 Subject: RFR (2nd): 8015318: Extend Collector with 'finish' operation In-Reply-To: <10C5E931-00BA-487B-9239-D82A235B2086@oracle.com> References: <51DC82CB.2080007@oracle.com> <52008C69.1040203@oracle.com> <10C5E931-00BA-487B-9239-D82A235B2086@oracle.com> Message-ID: <52017A26.2010103@oracle.com> On 08/06/2013 10:06 AM, Mike Duigou wrote: > Looks OK. A few minor non-blocking comments: > > DelegatingStream:: > > - I wonder if an extends wildcard might also be included on R > I will include this change in the push if passes all tests. diff --git a/src/share/classes/java/util/stream/DelegatingStream.java b/src/share/classes/java/util/stream/DelegatingStream.java --- a/src/share/classes/java/util/stream/DelegatingStream.java +++ b/src/share/classes/java/util/stream/DelegatingStream.java @@ -209,7 +209,7 @@ } @Override - public R collect(Collector collector) { + public R collect(Collector collector) { return delegate.collect(collector); } diff --git a/src/share/classes/java/util/stream/ReferencePipeline.java b/src/share/classes/java/util/stream/ReferencePipeline.java --- a/src/share/classes/java/util/stream/ReferencePipeline.java +++ b/src/share/classes/java/util/stream/ReferencePipeline.java @@ -490,7 +490,7 @@ } @Override - public final R collect(Collector collector) { + public final R collect(Collector collector) { A container; if (isParallel() && (collector.characteristics().contains(Collector.Characteristics.CONCURRENT)) diff --git a/src/share/classes/java/util/stream/Stream.java b/src/share/classes/java/util/stream/Stream.java --- a/src/share/classes/java/util/stream/Stream.java +++ b/src/share/classes/java/util/stream/Stream.java @@ -657,7 +657,7 @@ * @see #collect(Supplier, BiConsumer, BiConsumer) * @see Collectors */ - R collect(Collector collector); + R collect(Collector collector); /** * Returns the minimum element of this stream according to the provided > ReduceOps:: > > - It is not clear in makeRef why collector.accumulator() wouldn't also benefit from a Objects.requireNonNull > The check is only against collector. We probably should have those checked in collector already. > General:: > > - Is there a constant immutable EnumSet for the Collector.Characteristics.IDENTITY_FINISH ? It would be nice to avoid creating lots of EnumSet instances. > We create new EnumSet when needed to combine with incoming characteristics; otherwise, the same set is returned. Cheers, Henry From forax at univ-mlv.fr Tue Aug 6 22:42:42 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 07 Aug 2013 00:42:42 +0200 Subject: RFR JDK-8022442: Fix unchecked warnings in HashMap In-Reply-To: <201C24F5-3499-48E1-8BBA-E8A0A757015E@oracle.com> References: <52016E0D.8070008@univ-mlv.fr> <201C24F5-3499-48E1-8BBA-E8A0A757015E@oracle.com> Message-ID: <52017BE2.7020706@univ-mlv.fr> On 08/07/2013 12:23 AM, Dan Smith wrote: > On Aug 6, 2013, at 2:43 PM, Remi Forax wrote: > >> On 08/06/2013 11:11 PM, Dan Smith wrote: >>> Please review this warnings cleanup. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022442 (not yet visible) >>> Webrev: http://cr.openjdk.java.net/~dlsmith/8022442/webrev.00/ >>> >>> ?Dan >> Hi Dan, >> I've seen that you have introduce a common super interface for entry and tree node, >> I suppose that you check that there is no performance regression. >> I wonder if an abstract class is not better than an interface because as far as I know >> CHA implemented in hotspot doesn't work on interface >> (but I may be wrong, there is perhaps a special optimization for arrays). > To make sure I understand: your concern is that an aastore will be more expensive when assigning to a KeyValueData[] than to an Object[] (or even to SomeOtherClass[])? > > For what it's worth, all assignments to table[i] are statically known to be safe. E.g.: > > Entry next = (Entry) e.next; > ... > table[i] = next; > > So surely a smart VM only does the check once? I was thinking (dreaming) that the VM can do no check at all because most of the time, TreeNode is not loaded. > > Here are some other things that might be concerns, but don't apply here: > - interface method invocations: there are no methods in the interface to invoke > - checkcast to an interface: all the casts are to concrete classes (Entry, TreeBin, TreeNode) > > (There are some unchecked casts from KeyValueData to KeyValueData with different type parameters, but I assume these don't cause any checkcasts.) > > ?Dan R?mi From henry.jen at oracle.com Tue Aug 6 22:54:34 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 06 Aug 2013 15:54:34 -0700 Subject: RFR: 8022446: Fix serial warnings in java.util.stream In-Reply-To: <52017230.5040404@oracle.com> References: <52016A6B.3090000@oracle.com> <52017230.5040404@oracle.com> Message-ID: <52017EAA.1000305@oracle.com> On 08/06/2013 03:01 PM, Tom Hawtin wrote: > Are you happy with the API docs in docs/api/serialized-form.html? > Those are all internal classes, thus is not showing up on that page at all. I assume this is the concern? Cheers, Henry From joe.darcy at oracle.com Tue Aug 6 23:01:58 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 06 Aug 2013 23:01:58 +0000 Subject: hg: jdk8/tl/jdk: 8022406: Fix doclint issues in java.beans Message-ID: <20130806230214.28DEC48634@hg.openjdk.java.net> Changeset: d5694d78ebc6 Author: darcy Date: 2013-08-06 16:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5694d78ebc6 8022406: Fix doclint issues in java.beans Reviewed-by: prr ! src/share/classes/java/beans/AppletInitializer.java ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/ConstructorProperties.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/EventHandler.java ! src/share/classes/java/beans/Expression.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PersistenceDelegate.java ! src/share/classes/java/beans/PropertyChangeSupport.java ! src/share/classes/java/beans/PropertyDescriptor.java ! src/share/classes/java/beans/Transient.java ! src/share/classes/java/beans/VetoableChangeSupport.java ! src/share/classes/java/beans/beancontext/BeanContext.java ! src/share/classes/java/beans/beancontext/BeanContextChild.java ! src/share/classes/java/beans/beancontext/BeanContextChildSupport.java ! src/share/classes/java/beans/beancontext/BeanContextMembershipEvent.java ! src/share/classes/java/beans/beancontext/BeanContextServices.java ! src/share/classes/java/beans/beancontext/BeanContextServicesSupport.java ! src/share/classes/java/beans/beancontext/BeanContextSupport.java From henry.jen at oracle.com Tue Aug 6 23:21:11 2013 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Tue, 06 Aug 2013 23:21:11 +0000 Subject: hg: jdk8/tl/jdk: 8015318: Extend Collector with 'finish' operation Message-ID: <20130806232124.D773C48636@hg.openjdk.java.net> Changeset: 939c3be6cc86 Author: briangoetz Date: 2013-06-28 16:26 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/939c3be6cc86 8015318: Extend Collector with 'finish' operation Reviewed-by: mduigou Contributed-by: brian.goetz at oracle.com ! src/share/classes/java/util/DoubleSummaryStatistics.java ! src/share/classes/java/util/IntSummaryStatistics.java ! src/share/classes/java/util/LongSummaryStatistics.java ! src/share/classes/java/util/StringJoiner.java ! src/share/classes/java/util/stream/Collector.java ! src/share/classes/java/util/stream/Collectors.java ! src/share/classes/java/util/stream/DelegatingStream.java ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/ReduceOps.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/package-info.java ! test/java/util/stream/test/org/openjdk/tests/java/util/FillableStringTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/GroupByOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SummaryStatisticsTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java ! test/jdk/lambda/MethodReferenceTestInstanceMethod.java ! test/jdk/lambda/separate/TestHarness.java From joel.franck at oracle.com Tue Aug 6 23:40:45 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Tue, 06 Aug 2013 23:40:45 +0000 Subject: hg: jdk8/tl/langtools: 8009367: Wrong kind of name used in comparison in javax.lang.model code for repeatable annotations Message-ID: <20130806234048.1AF1848637@hg.openjdk.java.net> Changeset: 051e64d0816e Author: jfranck Date: 2013-08-07 01:32 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/051e64d0816e 8009367: Wrong kind of name used in comparison in javax.lang.model code for repeatable annotations Reviewed-by: jjg, darcy ! src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java + test/tools/javac/processing/model/element/8009367/TestQualifiedNameUsed.java + test/tools/javac/processing/model/element/8009367/p/Q.java + test/tools/javac/processing/model/element/8009367/p/QQ.java + test/tools/javac/processing/model/element/8009367/p/R.java + test/tools/javac/processing/model/element/8009367/p/RR.java From joe.darcy at oracle.com Tue Aug 6 23:45:51 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 06 Aug 2013 23:45:51 +0000 Subject: hg: jdk8/tl/jdk: 8022453: Fix doclint issues in javax.accessibility Message-ID: <20130806234603.A3A9048638@hg.openjdk.java.net> Changeset: 6cc8c2ad9804 Author: darcy Date: 2013-08-06 16:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6cc8c2ad9804 8022453: Fix doclint issues in javax.accessibility Reviewed-by: prr ! src/share/classes/javax/accessibility/Accessible.java ! src/share/classes/javax/accessibility/AccessibleBundle.java ! src/share/classes/javax/accessibility/AccessibleExtendedTable.java ! src/share/classes/javax/accessibility/AccessibleRelationSet.java ! src/share/classes/javax/accessibility/AccessibleTable.java ! src/share/classes/javax/accessibility/AccessibleTableModelChange.java ! src/share/classes/javax/accessibility/AccessibleTextSequence.java ! src/share/classes/javax/accessibility/AccessibleValue.java From joe.darcy at oracle.com Tue Aug 6 23:56:12 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 06 Aug 2013 16:56:12 -0700 Subject: RFR: 8022446: Fix serial warnings in java.util.stream In-Reply-To: <52016A6B.3090000@oracle.com> References: <52016A6B.3090000@oracle.com> Message-ID: <52018D1C.6090904@oracle.com> Hello, In ReduceOps.java, I recommend replacing 46 * Factory for the creating instances of {@code TerminalOp} that implement with something like Factory for creating instances of {@code TerminalOp} that implement... Otherwise, the changes look good. Thanks, -Joe On 08/06/2013 02:28 PM, Henry Jen wrote: > Hi, > > Please review a webrev[1] clean up on serial warning, as we don't intend > to serialize those tasks, we simply suppress those warnings. > > It would be nice if there is a way to undo serializable. > > [1] http://cr.openjdk.java.net/~henryjen/tl/8022446/0/webrev/ > > Cheers, > Henry From lana.steuck at oracle.com Wed Aug 7 00:16:51 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Aug 2013 00:16:51 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20130807001653.ECB1B4863C@hg.openjdk.java.net> Changeset: 528c7e76eaee Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/528c7e76eaee Added tag jdk8-b101 for changeset a013024b0747 ! .hgtags Changeset: 342a954b68f3 Author: lana Date: 2013-08-06 16:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/342a954b68f3 Merge From lana.steuck at oracle.com Wed Aug 7 00:16:56 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Aug 2013 00:16:56 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b101 for changeset 60b623a36164 Message-ID: <20130807001701.D5BDD4863E@hg.openjdk.java.net> Changeset: 988a5f2ac559 Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/988a5f2ac559 Added tag jdk8-b101 for changeset 60b623a36164 ! .hgtags From lana.steuck at oracle.com Wed Aug 7 00:16:59 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Aug 2013 00:16:59 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20130807001704.8F0EE4863F@hg.openjdk.java.net> Changeset: 573ccf92d646 Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/573ccf92d646 Added tag jdk8-b101 for changeset a302b05d0ee4 ! .hgtags Changeset: e966ff0a3ffe Author: lana Date: 2013-08-06 10:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e966ff0a3ffe Merge Changeset: ab90c566272d Author: lana Date: 2013-08-06 17:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ab90c566272d Merge From lana.steuck at oracle.com Wed Aug 7 00:16:56 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Aug 2013 00:16:56 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20130807001706.D504A48640@hg.openjdk.java.net> Changeset: b8cd8b101ecb Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b8cd8b101ecb Added tag jdk8-b101 for changeset 0a7432f898e5 ! .hgtags Changeset: 7cffafa606e9 Author: lana Date: 2013-08-06 10:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/7cffafa606e9 Merge From lana.steuck at oracle.com Wed Aug 7 00:17:23 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Aug 2013 00:17:23 +0000 Subject: hg: jdk8/tl/hotspot: 61 new changesets Message-ID: <20130807001932.4D8C048642@hg.openjdk.java.net> Changeset: 2285b4a0a4e6 Author: amurillo Date: 2013-07-18 09:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2285b4a0a4e6 8020797: new hotspot build - hs25-b43 Reviewed-by: jcoomes ! make/hotspot_version Changeset: dbc0b5dc08f5 Author: fparain Date: 2013-07-10 15:49 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dbc0b5dc08f5 7143807: ResourceMark nesting problem in stringStream Reviewed-by: kvn, dcubed ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp Changeset: c9a5fab39234 Author: zgu Date: 2013-07-11 13:15 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c9a5fab39234 8012241: NMT huge memory footprint, it usually leads to OOME Summary: Enforce memory limitation on NMT to prevent JVM OOM Reviewed-by: acorn, dcubed, minqi ! src/share/vm/services/memTracker.cpp Changeset: 5f056abe17c6 Author: zgu Date: 2013-07-12 04:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5f056abe17c6 Merge Changeset: 2e8f19c2feef Author: allwin Date: 2013-07-12 18:43 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2e8f19c2feef 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Summary: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Reviewed-by: dcubed, dholmes, sspitsyn, mgerdin, ctornqvi, dsamersoff ! src/os/bsd/vm/attachListener_bsd.cpp ! src/os/linux/vm/attachListener_linux.cpp ! src/os/solaris/vm/attachListener_solaris.cpp ! src/os/windows/vm/attachListener_windows.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/attachListener.hpp + test/serviceability/attach/AttachWithStalePidFile.java + test/serviceability/attach/AttachWithStalePidFileTarget.java Changeset: c0cb474be37e Author: ctornqvi Date: 2013-07-12 20:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c0cb474be37e Merge Changeset: 862625d214fa Author: fparain Date: 2013-07-15 00:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/862625d214fa Merge Changeset: 23123fc6968a Author: rbackman Date: 2013-07-15 11:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/23123fc6968a 8019324: assert(_f2 == 0 || _f2 == f2) failed: illegal field change Reviewed-by: dholmes, rbackman Contributed-by: David Simms ! src/share/vm/oops/cpCache.hpp Changeset: ee9e76adced3 Author: rbackman Date: 2013-07-15 12:06 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ee9e76adced3 Merge Changeset: 33c52908bcdb Author: dholmes Date: 2013-07-15 23:23 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/33c52908bcdb 8015759: hotspot changes needed to compile with Visual Studio 2012 Reviewed-by: anthony, dholmes, dcubed Contributed-by: Tim Bell ! make/windows/makefiles/compile.make ! make/windows/makefiles/sanity.make ! make/windows/makefiles/vm.make ! src/os_cpu/windows_x86/vm/unwind_windows_x86.hpp Changeset: 39deebbc90b3 Author: mgerdin Date: 2013-07-16 07:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/39deebbc90b3 6671508: JNI GetPrimitiveArrayCritical should not be callable on object arrays Summary: Checked JNI now reports error for Get/ReleasePrimitiveArrayCritical on object arrays Reviewed-by: dholmes, acorn Contributed-by: david.simms at oracle.com ! src/share/vm/prims/jniCheck.cpp Changeset: e619a2766bcc Author: rbackman Date: 2013-06-12 11:17 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e619a2766bcc 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' Reviewed-by: jrose, kvn, mgronlun ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 732af649bc3a Author: ccheung Date: 2013-07-17 12:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/732af649bc3a 8017498: JVM crashes when native code calls sigaction(sig) where sig>=0x20 Summary: Added (sig < MAXSIGNUM) check in jsig.c Reviewed-by: dholmes, acorn ! src/os/linux/vm/jsig.c + test/runtime/jsig/Test8017498.sh + test/runtime/jsig/TestJNI.c + test/runtime/jsig/TestJNI.java Changeset: 825e6cb66923 Author: jiangli Date: 2013-07-17 18:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/825e6cb66923 8020309: Eliminate InstanceKlass::_cached_class_file_len. Summary: Use JvmtiCachedClassFileData. Reviewed-by: iklam, sspitsyn, dcubed ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp Changeset: 6388dbc4b7ca Author: jiangli Date: 2013-07-17 17:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6388dbc4b7ca Merge Changeset: c29568b733d2 Author: dholmes Date: 2013-07-18 06:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c29568b733d2 8020697: jniCheck.cpp:check_is_obj_array asserts on TypeArrayKlass::cast(aOop->klass()) Reviewed-by: dcubed, fparain, dholmes Contributed-by: David Simms ! src/share/vm/prims/jniCheck.cpp Changeset: 5e3b6f79d280 Author: rbackman Date: 2013-07-17 13:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5e3b6f79d280 8020701: Avoid crashes in WatcherThread Reviewed-by: acorn, dcubed, dsimms ! src/os/posix/vm/os_posix.cpp ! src/os/posix/vm/os_posix.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 248c459b2b75 Author: dcubed Date: 2013-07-18 12:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/248c459b2b75 Merge ! src/share/vm/services/memTracker.cpp Changeset: af21010d1062 Author: dcubed Date: 2013-07-18 12:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/af21010d1062 Merge ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/runtime/os.hpp Changeset: 02d7aa1456c9 Author: ccheung Date: 2013-07-18 14:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/02d7aa1456c9 8004872: Early loading of HashMap and StringValue under -XX:+AggressiveOpts can be removed Summary: this fix also removes the -XX:+UseStringCache option Reviewed-by: dholmes, acorn, iklam ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: 383a5e21cc2d Author: minqi Date: 2013-07-18 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/383a5e21cc2d Merge Changeset: 060ae9b7ffea Author: mgronlun Date: 2013-07-19 17:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/060ae9b7ffea 8020547: Event based tracing needs a UNICODE string type Reviewed-by: egahlin, rbackman, dcubed, brutisso, acorn ! src/share/vm/trace/traceDataTypes.hpp ! src/share/vm/trace/tracetypes.xml ! src/share/vm/trace/xinclude.mod Changeset: 4614a598dae1 Author: minqi Date: 2013-07-19 08:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4614a598dae1 8016538: volatile double access via Unsafe.cpp is not atomic Summary: volatile jdouble load/store is not atomic, fix by using of existing volatile jlong operations which are atomic for jdouble. Reviewed-by: kvn, vladidan, jrose Contributed-by: david.holmes at oracle.com ! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp Changeset: 55a61ceb2fe7 Author: minqi Date: 2013-07-19 11:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/55a61ceb2fe7 Merge Changeset: 16511b7e3d35 Author: emc Date: 2013-07-22 17:57 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/16511b7e3d35 8019632: Method parameters are not copied in clone_with_new_data Summary: Add code to copy method parameters data in clone_with_new_data Reviewed-by: coleenp, sspitsyn ! src/share/vm/oops/method.cpp Changeset: 72727c4b6dec Author: ccheung Date: 2013-07-19 14:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/72727c4b6dec 8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code Summary: Added -DLINUX to the gcc command and improved the .sh script Reviewed-by: dcubed, dholmes, minqi ! test/runtime/jsig/Test8017498.sh ! test/runtime/jsig/TestJNI.c Changeset: 5165d659cebd Author: minqi Date: 2013-07-22 22:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5165d659cebd Merge Changeset: c0f353803b47 Author: minqi Date: 2013-07-23 12:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c0f353803b47 Merge Changeset: c90c698831d7 Author: kvn Date: 2013-07-12 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c90c698831d7 8020215: Different execution plan when using JIT vs interpreter Summary: fix bytecode analyzer Reviewed-by: twisti ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp + test/compiler/EscapeAnalysis/Test8020215.java Changeset: fcf521c3fbc6 Author: kvn Date: 2013-07-12 14:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fcf521c3fbc6 8007898: Incorrect optimization of Memory Barriers in Matcher::post_store_load_barrier() Summary: generate one "fat" membar instead of set of barriers for volitile store Reviewed-by: roland ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/parse3.cpp + test/compiler/membars/DekkerTest.java Changeset: 34ce0b5acb81 Author: morris Date: 2013-07-15 06:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/34ce0b5acb81 Merge Changeset: 0f57ccdb9084 Author: kvn Date: 2013-07-15 10:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0f57ccdb9084 8020433: Crash when using -XX:+RestoreMXCSROnJNICalls Summary: remove StubRoutines::x86::_mxcsr_std and use StubRoutines::_mxcsr_std Reviewed-by: jrose ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp + test/compiler/cpuflags/RestoreMXCSR.java Changeset: 46a90f83df31 Author: morris Date: 2013-07-19 13:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/46a90f83df31 Merge ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 6efedc114807 Author: morris Date: 2013-07-24 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6efedc114807 Merge Changeset: 01aa164323fa Author: dholmes Date: 2013-07-24 19:23 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/01aa164323fa 8020799: Allow customization of hotspot source directories and files Reviewed-by: kvn, dlong ! make/linux/makefiles/vm.make Changeset: a4b9a8ec8f4a Author: jiangli Date: 2013-07-25 18:12 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a4b9a8ec8f4a Merge Changeset: 46487ba40ff2 Author: amurillo Date: 2013-07-26 03:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/46487ba40ff2 Merge Changeset: f6921c876db1 Author: amurillo Date: 2013-07-26 03:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f6921c876db1 Added tag hs25-b43 for changeset 46487ba40ff2 ! .hgtags Changeset: 7c9885d23744 Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7c9885d23744 Added tag jdk8-b101 for changeset f6921c876db1 ! .hgtags Changeset: e84845884c85 Author: amurillo Date: 2013-07-26 04:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e84845884c85 8021566: new hotspot build - hs25-b44 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d90d1b96b65b Author: kvn Date: 2013-07-26 12:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d90d1b96b65b 8008938: TieredCompilation should be default Summary: switch on TieredCompilation by default Reviewed-by: twisti ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp Changeset: 1b6395189726 Author: minqi Date: 2013-07-19 14:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1b6395189726 8012263: ciReplay: gracefully exit & report meaningful error when replay data parsing fails Summary: find_method could return NULL so need explicitly check if there is error after parse_method, exit on error to avoid crash. Reviewed-by: kvn, twisti Contributed-by: yumin.qi at oracle.com ! src/share/vm/ci/ciReplay.cpp Changeset: 5ad7f8179bf7 Author: minqi Date: 2013-07-24 08:04 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ad7f8179bf7 Merge Changeset: b6baf306e698 Author: fparain Date: 2013-07-26 05:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b6baf306e698 Merge Changeset: 83ca9dc4564d Author: fparain Date: 2013-07-26 15:24 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/83ca9dc4564d 8019845: Memory leak during class redefinition Reviewed-by: acorn, jmasa, coleenp, dcubed, mgerdin ! src/share/vm/memory/metaspace.cpp Changeset: f9ee986a9fea Author: ccheung Date: 2013-07-30 14:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f9ee986a9fea 8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases Summary: Added checking for gcc and simplified the sig_handler() in the test case Reviewed-by: dcubed, coleenp, minqi, dlong ! test/runtime/6929067/Test6929067.sh ! test/runtime/7107135/Test7107135.sh ! test/runtime/jsig/Test8017498.sh ! test/runtime/jsig/TestJNI.c Changeset: 0f98cc013b21 Author: fparain Date: 2013-07-31 08:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0f98cc013b21 Merge Changeset: c65045599519 Author: dholmes Date: 2013-07-25 21:05 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c65045599519 8021314: minimal1.make needs to force off components not supported by the minimal VM Reviewed-by: coleenp, bpittore ! make/bsd/makefiles/minimal1.make ! make/linux/makefiles/minimal1.make Changeset: 078e5eb2e52e Author: clucasius Date: 2013-07-27 17:23 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/078e5eb2e52e Merge Changeset: da839a3c5735 Author: dholmes Date: 2013-07-31 19:05 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/da839a3c5735 Merge Changeset: e3c8767c5cf8 Author: tschatzl Date: 2013-07-24 10:07 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e3c8767c5cf8 8020123: Test gc/g1/TestPrintRegionRememberedSetInfo.java fails with "test result: Error. No action after @build" Summary: Remove the @build tag and replace it by a @run tag so that the test gets executed Reviewed-by: brutisso, mgerdin ! test/gc/g1/TestPrintRegionRememberedSetInfo.java Changeset: 7b06ae405d7b Author: jmasa Date: 2013-07-23 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7b06ae405d7b 6990419: CMS Remaining work for 6572569: consistently skewed work distribution in (long) re-mark pauses Reviewed-by: rasbold, tschatzl, jmasa Contributed-by: yamauchi at google.com ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/runtime/globals.hpp Changeset: fb7010c7c011 Author: jmasa Date: 2013-07-25 07:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fb7010c7c011 Merge Changeset: ca9dedeebdec Author: jmasa Date: 2013-07-25 11:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca9dedeebdec 6412968: CMS Long initial mark pauses Reviewed-by: rasbold, tschatzl, jmasa Contributed-by: yamauchi at google.com ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/runtime/globals.hpp Changeset: 8796fd3ac898 Author: tamao Date: 2013-07-26 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8796fd3ac898 Merge ! src/share/vm/runtime/globals.hpp Changeset: 313227279a05 Author: brutisso Date: 2013-08-01 07:03 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/313227279a05 8021967: Deprecate -XX:DefaultMaxRAMFraction Reviewed-by: tschatzl, jmasa, kvn, tamao ! src/share/vm/runtime/arguments.cpp + test/gc/startup_warnings/TestDefaultMaxRAMFraction.java Changeset: dae8324fc7d1 Author: brutisso Date: 2013-08-01 09:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dae8324fc7d1 8021879: G1: G1HeapRegionSize flag value not updated correctly Reviewed-by: tschatzl, jmasa ! src/share/vm/gc_implementation/g1/heapRegion.cpp + test/gc/arguments/TestG1HeapRegionSize.java Changeset: 8d4ff57af591 Author: brutisso Date: 2013-08-01 17:29 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8d4ff57af591 8022051: G1: Remove some unused G1 flags Reviewed-by: tschatzl, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 69d0dbb53c78 Author: tamao Date: 2013-08-01 17:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/69d0dbb53c78 Merge Changeset: 530fe88b3b2c Author: amurillo Date: 2013-08-02 02:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/530fe88b3b2c Merge Changeset: c4697c1c4484 Author: amurillo Date: 2013-08-02 02:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c4697c1c4484 Added tag hs25-b44 for changeset 530fe88b3b2c ! .hgtags From lana.steuck at oracle.com Wed Aug 7 00:17:01 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Aug 2013 00:17:01 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20130807001717.0D2A148641@hg.openjdk.java.net> Changeset: 4c42fba7b0e7 Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4c42fba7b0e7 Added tag jdk8-b101 for changeset 0324dbf07b0f ! .hgtags Changeset: 453a305e1165 Author: lana Date: 2013-08-06 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/453a305e1165 Merge Changeset: f3ea20a6e958 Author: lana Date: 2013-08-06 17:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f3ea20a6e958 Merge Changeset: b926dc251be8 Author: lana Date: 2013-08-06 17:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b926dc251be8 Merge From lana.steuck at oracle.com Wed Aug 7 00:19:12 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Aug 2013 00:19:12 +0000 Subject: hg: jdk8/tl/jdk: 28 new changesets Message-ID: <20130807002511.5A6A848643@hg.openjdk.java.net> Changeset: b52a2ecdb803 Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b52a2ecdb803 Added tag jdk8-b101 for changeset 690161232823 ! .hgtags Changeset: 2978c0a543ed Author: prr Date: 2013-07-22 12:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2978c0a543ed 7196866: CTW fails on all Solaris platforms Reviewed-by: prr, jrose, twisti, kvn ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 784589c7bc55 Author: vadim Date: 2013-07-24 13:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/784589c7bc55 8008782: NPE in TrueTypeGlyphMapper Reviewed-by: bae, prr ! src/share/classes/sun/font/TrueTypeFont.java Changeset: db2e3a686cf3 Author: jchen Date: 2013-07-24 12:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db2e3a686cf3 8011709: [parfait] False positive: memory leak in jdk/src/share/native/sun/font/layout/CanonShaping.cpp Reviewed-by: jgodinez, prr ! src/share/native/sun/font/layout/CanonShaping.cpp Changeset: c2e27e7a42ae Author: jchen Date: 2013-07-24 13:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e27e7a42ae 8005126: [parfait] #418 - #428 XRBackendNative.c Integer overflow Reviewed-by: prr, vadim ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 833f05116f7b Author: bae Date: 2013-07-25 17:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/833f05116f7b 8019201: Regression: java.awt.image.ConvolveOp throws java.awt.image.ImagingOpException Reviewed-by: prr ! src/share/native/sun/awt/medialib/awt_ImagingLib.c + test/sun/awt/image/ImagingLib/SamePackingTypeTest.java Changeset: a8b9df782017 Author: serb Date: 2013-07-26 21:18 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8b9df782017 7190349: [macosx] Text (Label) is incorrectly drawn with a rotated g2d 8013569: [macosx] JLabel preferred size incorrect on retina displays with non-default font size Reviewed-by: prr ! src/macosx/classes/sun/font/CStrike.java ! src/macosx/native/sun/font/AWTStrike.h ! src/macosx/native/sun/font/AWTStrike.m ! src/macosx/native/sun/font/CGGlyphImages.m + test/java/awt/Graphics2D/DrawString/DrawRotatedString.java + test/java/awt/Graphics2D/IncorrectTextSize/IncorrectTextSize.java Changeset: 467a0c21790b Author: jgodinez Date: 2013-07-26 15:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/467a0c21790b 8020208: NullPointerException at sun.print.Win32PrintService.getMediaPrintables Reviewed-by: jchen, prr ! src/windows/classes/sun/print/Win32PrintService.java Changeset: 56c6f9a9653d Author: jgodinez Date: 2013-07-26 15:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56c6f9a9653d 8016343: [macosx] Print job goes to default printer regardless of chosen printer Reviewed-by: jchen, prr ! src/share/classes/sun/print/PSPrinterJob.java ! src/solaris/classes/sun/print/IPPPrintService.java ! src/solaris/classes/sun/print/UnixPrintJob.java ! test/javax/print/DialogMargins.java Changeset: 1c48544c3da9 Author: lana Date: 2013-07-26 15:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c48544c3da9 Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java - src/share/classes/java/util/stream/StreamBuilder.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html - test/java/util/Collections/EmptySortedSet.java Changeset: 921338e44ba7 Author: lana Date: 2013-07-26 17:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/921338e44ba7 Merge Changeset: 046025f78ea8 Author: jgodinez Date: 2013-07-30 13:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/046025f78ea8 8021835: Fix for 8016343 will not compile on Windows. Reviewed-by: jchen, prr ! src/share/classes/sun/print/PSPrinterJob.java Changeset: 7f0e569c5a66 Author: bae Date: 2013-07-31 13:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7f0e569c5a66 8020983: OutOfMemoryError caused by non garbage collected JPEGImageWriter Instances Reviewed-by: prr, flar ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c + test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java Changeset: 607ad960fe24 Author: malenkov Date: 2013-07-22 15:36 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/607ad960fe24 8019975: closed/javax/swing/JFileChooser/4966171/bug4966171.java throws java.io.NotSerializableException: javax.swing.plaf.basic.BasicFileChooserUI$AcceptAllFileFilter Reviewed-by: alexsch ! src/share/classes/javax/swing/JFileChooser.java Changeset: 3cbe376233a9 Author: malenkov Date: 2013-07-22 20:33 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3cbe376233a9 8015926: NPE when using SynthTreeUI's expandPath() Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java + test/javax/swing/plaf/synth/Test8015926.java Changeset: bdad697c03aa Author: pchelko Date: 2013-07-23 13:09 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bdad697c03aa 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session) Reviewed-by: art, anthony ! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java Changeset: 99ee6ddab113 Author: serb Date: 2013-07-24 17:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/99ee6ddab113 8017189: [macosx] AWT program menu disabled on Mac Reviewed-by: leonidr, anthony ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m ! src/macosx/native/sun/awt/CMenuBar.m Changeset: 7bd6eda2d217 Author: leonidr Date: 2013-07-26 16:22 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bd6eda2d217 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working Reviewed-by: anthony, serb ! src/macosx/classes/com/apple/eawt/_AppMenuBarHandler.java ! src/macosx/classes/sun/lwawt/macosx/CMenuComponent.java ! src/macosx/native/sun/awt/AWTWindow.m ! src/macosx/native/sun/awt/CMenuItem.m Changeset: 65c90209edbb Author: lana Date: 2013-07-26 15:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/65c90209edbb Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java - src/share/classes/java/util/stream/StreamBuilder.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html - test/java/util/Collections/EmptySortedSet.java Changeset: 37016eaea5d2 Author: serb Date: 2013-07-29 16:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/37016eaea5d2 6230360: Spelling mistake in documentation for AWT: 1.4, 1.5, 1.6, 1.7 Reviewed-by: malenkov, art ! src/share/classes/java/awt/AWTException.java Changeset: bf80c2965a84 Author: malenkov Date: 2013-07-29 18:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf80c2965a84 8010782: clean up source files containing carriage return characters Reviewed-by: alexsch, art ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth.properties Changeset: 1e482f58c747 Author: ant Date: 2013-07-30 16:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1e482f58c747 8020927: JLightweightFrame API should export layout properties change notifications Reviewed-by: anthony ! src/share/classes/sun/swing/JLightweightFrame.java ! src/share/classes/sun/swing/LightweightContent.java Changeset: 336a94dbecb5 Author: malenkov Date: 2013-07-30 17:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/336a94dbecb5 8015300: JComboBox text sometimes become selected, sometimes not (Windows LAF) Reviewed-by: alexsch, serb ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java + test/javax/swing/JComboBox/8015300/Test8015300.java Changeset: 726ac8f75b54 Author: lana Date: 2013-07-31 12:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/726ac8f75b54 Merge Changeset: 0741b19835b0 Author: lana Date: 2013-07-31 13:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0741b19835b0 Merge - src/share/classes/java/net/package.html Changeset: 8ed8e2b4b90e Author: lana Date: 2013-08-06 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8ed8e2b4b90e Merge Changeset: 2bc9ce1aade5 Author: lana Date: 2013-08-06 17:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2bc9ce1aade5 Merge Changeset: 7ab5f19a9a31 Author: lana Date: 2013-08-06 17:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ab5f19a9a31 Merge From tom.hawtin at oracle.com Wed Aug 7 00:39:20 2013 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Tue, 06 Aug 2013 17:39:20 -0700 Subject: RFR: 8022446: Fix serial warnings in java.util.stream In-Reply-To: <52017EAA.1000305@oracle.com> References: <52016A6B.3090000@oracle.com> <52017230.5040404@oracle.com> <52017EAA.1000305@oracle.com> Message-ID: <52019738.3070104@oracle.com> I'm not sure what the criteria for inclusion is. javax.security.auth.PrivateCredentialPermission.CredOwner, for example, appears but isn't in the normal API docs. It's also worth noting that the classes are still serialisable and deserialisable. Tom On 06/08/2013 15:54, Henry Jen wrote: > On 08/06/2013 03:01 PM, Tom Hawtin wrote: >> Are you happy with the API docs in docs/api/serialized-form.html? >> > > Those are all internal classes, thus is not showing up on that page at > all. I assume this is the concern? > > Cheers, > Henry > From henry.jen at oracle.com Wed Aug 7 00:43:18 2013 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Wed, 07 Aug 2013 00:43:18 +0000 Subject: hg: jdk8/tl/jdk: 8022446: Fix serial warnings in java.util.stream Message-ID: <20130807004332.2400448644@hg.openjdk.java.net> Changeset: e303c228bf31 Author: henryjen Date: 2013-08-06 17:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e303c228bf31 8022446: Fix serial warnings in java.util.stream Reviewed-by: darcy ! src/share/classes/java/util/stream/AbstractShortCircuitTask.java ! src/share/classes/java/util/stream/AbstractTask.java ! src/share/classes/java/util/stream/FindOps.java ! src/share/classes/java/util/stream/ForEachOps.java ! src/share/classes/java/util/stream/MatchOps.java ! src/share/classes/java/util/stream/Nodes.java ! src/share/classes/java/util/stream/ReduceOps.java ! src/share/classes/java/util/stream/SliceOps.java From lana.steuck at oracle.com Wed Aug 7 00:16:51 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Aug 2013 00:16:51 +0000 Subject: hg: jdk8/tl: Added tag jdk8-b101 for changeset 9f74a220677d Message-ID: <20130807001651.B35284863B@hg.openjdk.java.net> Changeset: 5eb3c1dc348f Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/5eb3c1dc348f Added tag jdk8-b101 for changeset 9f74a220677d ! .hgtags From mike.duigou at oracle.com Wed Aug 7 01:06:39 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 6 Aug 2013 18:06:39 -0700 Subject: RFR: 8022476: cleanup some raw types and unchecked warnings in java.util.stream Message-ID: <08D80F74-ED2F-4449-A1E1-98A5B3AABB34@oracle.com> Hello all; A changeset of primarily warning suppression in java.util.stream that reduces the warnings on some of the stream pipeline and ops classes. http://cr.openjdk.java.net/~mduigou/JDK-8022476/0/webrev/ Mike From joe.darcy at oracle.com Wed Aug 7 01:16:41 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 06 Aug 2013 18:16:41 -0700 Subject: RFR: 8022476: cleanup some raw types and unchecked warnings in java.util.stream In-Reply-To: <08D80F74-ED2F-4449-A1E1-98A5B3AABB34@oracle.com> References: <08D80F74-ED2F-4449-A1E1-98A5B3AABB34@oracle.com> Message-ID: <52019FF9.8040706@oracle.com> Hi Mike, Looks good; approved to go back. Thanks, -Joe On 08/06/2013 06:06 PM, Mike Duigou wrote: > Hello all; > > A changeset of primarily warning suppression in java.util.stream that reduces the warnings on some of the stream pipeline and ops classes. > > http://cr.openjdk.java.net/~mduigou/JDK-8022476/0/webrev/ > > Mike From dan.xu at oracle.com Wed Aug 7 01:16:57 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Wed, 07 Aug 2013 01:16:57 +0000 Subject: hg: jdk8/tl/jdk: 8022478: Fix Warnings In sun.net.www.protocol.http Package Message-ID: <20130807011708.86F7148645@hg.openjdk.java.net> Changeset: 1d21ff5c2b3f Author: dxu Date: 2013-08-06 18:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d21ff5c2b3f 8022478: Fix Warnings In sun.net.www.protocol.http Package Reviewed-by: darcy ! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java From mike.duigou at oracle.com Wed Aug 7 01:21:43 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 07 Aug 2013 01:21:43 +0000 Subject: hg: jdk8/tl/jdk: 8022476: cleanup some raw types and unchecked warnings in java.util.stream Message-ID: <20130807012155.28BBF48646@hg.openjdk.java.net> Changeset: e117fcdd2176 Author: mduigou Date: 2013-08-06 18:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e117fcdd2176 8022476: cleanup some raw types and unchecked warnings in java.util.stream Reviewed-by: darcy Contributed-by: mike.duigou at oracle.com, henry.jen at oracle.com ! src/share/classes/java/util/Optional.java ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/AbstractShortCircuitTask.java ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/LongPipeline.java ! src/share/classes/java/util/stream/Nodes.java ! src/share/classes/java/util/stream/ReduceOps.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Sink.java ! src/share/classes/java/util/stream/SortedOps.java ! src/share/classes/java/util/stream/StreamSpliterators.java From Alan.Bateman at oracle.com Wed Aug 7 05:08:46 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 06 Aug 2013 22:08:46 -0700 Subject: RFR [6961766]: PrintStream.write() should flush at most once In-Reply-To: <52012698.4090005@oracle.com> References: <52012698.4090005@oracle.com> Message-ID: <5201D65E.3090504@oracle.com> On 06/08/2013 09:38, Ivan Gerasimov wrote: > Hello everybody! > > Would you please review a simple fix, suggested by someone on > bugs.sun.com? > > j.i.PrintStream#write(char[]) calls out.flush() on each '\n' character > found in the array. > It's sufficient to do it only once. One thing to check is whether this will require any changes to the spec (as it is currently specified to call flush when a newline is written). I don't have time just at the moment to check this but that would be my only concern with a change like this. -Alan From Alan.Bateman at oracle.com Wed Aug 7 05:21:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 06 Aug 2013 22:21:17 -0700 Subject: Deadlock in clinit for sun.nio.ch.Util/IOUtil In-Reply-To: References: Message-ID: <5201D94D.3000407@oracle.com> On 06/08/2013 15:21, Jeremy Manson wrote: > : > > We can eagerly do class init as a workaround, but that seems less than > ideal. It looks easy enough to fix - just move the stuff in Util.load() > into IOUtil somewhere, and don't call back to Util from IOUtil.. > But I'll defer to the experts. > Thanks for the mail, I'll create a bug for this. From an initial look then moving it to IOUtil should resolve this as Util doesn't define any native methods and so doesn't care if the native library has been loaded. -Alan. From stuart.marks at oracle.com Wed Aug 7 06:28:55 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 06 Aug 2013 23:28:55 -0700 Subject: RFR: 8022479: clean up warnings from sun.tools.asm Message-ID: <5201E927.3030508@oracle.com> Hi, Please review the fix for this warnings cleanup bug. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022479 (not yet available publicly, but should be shortly) Webrev: http://cr.openjdk.java.net/~smarks/reviews/8022479/webrev.0/ There are a few items of note. This is *very* old code. You can see some of the authors' names in the code. It's replete with uses of Vector, Hashtable, and Enumeration. It also has a kind of musty style, which might have been reasonable from the standpoint of C programmers (which we all were at the time!). For example, there are a bunch of cases of direct field access to another class. There are also cases where a class contains a Vector that's returned by a getter method. I guess we just have to trust the caller not to modify it at the wrong time. I've confined most of my cleanups to the addition of generics (which gets rid of the rawtypes and unchecked warnings). There were a smattering of other warnings I've cleaned up as well. I've also replaced few cases of calls to "new" on boxed types like Integer and Long with calls to the respective valueOf() methods. I didn't check all the code for this, though, just instances I happened to run across. There is much more cleanup that could be done that I've elected not to do, such as replacing Vector, Hashtable, and Enumeration with ArrayList, HashMap, and Iterator, and using the enhanced-for loop. These changes would *probably* be safe, but they would require more analysis and testing than I'm willing to do at the moment. Two locations deserve a bit of scrutiny. 1) There are four occurrences in Assembler.java of calls to MemberDefinition.getArguments(). Unfortunately MemberDefinition resides in the sun.tools.java package and getArguments() returns a raw Vector. This is also overridden in a couple places spread across a couple sun.tools packages, and there are hints that it being a LocalMember or MemberDefinition. It seems out of scope to try to fix up the return value of getArguments() and its various overrides. Locally in the Assembler.java file, though, the contents of the returned vector are always cast to MemberDefinition, so it seems sensible to make an unchecked cast of the getArguments() return value to Vector and to suppress warnings at that point. Usage beyond those points within Assembler.java is filled with sweet and juicy generic goodness. 2) SwitchData.java contains a field whereCaseTab which is a Hashtable ... most of the time. In the addTableDefault() method, a value is put into the Hashtable under the key "default" -- a String. Ick. To deal with this I declared it as Hashtable since that's the typical case, and for the put(String, Long) case I cast through raw and suppressed the warning. The get() method already takes an Object so we're OK there. Note that "default" as a key for this Hashtable is used in a couple other places in Assembler.java. It's not intractable to change these to some other sentinel value, but, you know, where does one stop? (I said "Ick" when encountering a mix-type collection, and in a generified world we very rarely see this style anymore. Upon further reflection, though, from the standpoint of a pre-generics world, this is pretty sensible. Using a string as a sentinel key is guaranteed not to collide with any Integer keys. Sometimes it's possible to use -1 or Integer.MAX_VALUE as a sentinel, but if any integer value is permitted as a key, what does one do then?) With this changeset, sun.tools.asm is reduced from about 76 to zero warnings. Thanks, s'marks From paul.sandoz at oracle.com Wed Aug 7 07:28:59 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 7 Aug 2013 08:28:59 +0100 Subject: RFR: 8022446: Fix serial warnings in java.util.stream In-Reply-To: <52016A6B.3090000@oracle.com> References: <52016A6B.3090000@oracle.com> Message-ID: <52ADBB5B-DED1-4867-9652-541681B56F17@oracle.com> On Aug 6, 2013, at 10:28 PM, Henry Jen wrote: > Hi, > > Please review a webrev[1] clean up on serial warning, as we don't intend > to serialize those tasks, we simply suppress those warnings. > > It would be nice if there is a way to undo serializable. > > [1] http://cr.openjdk.java.net/~henryjen/tl/8022446/0/webrev/ > Looks good to me. Paul. From peter.levart at gmail.com Wed Aug 7 08:57:30 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 07 Aug 2013 10:57:30 +0200 Subject: RFR JDK-8022442: Fix unchecked warnings in HashMap In-Reply-To: <201C24F5-3499-48E1-8BBA-E8A0A757015E@oracle.com> References: <52016E0D.8070008@univ-mlv.fr> <201C24F5-3499-48E1-8BBA-E8A0A757015E@oracle.com> Message-ID: <52020BFA.20503@gmail.com> On 08/07/2013 12:23 AM, Dan Smith wrote: > On Aug 6, 2013, at 2:43 PM, Remi Forax wrote: > >> On 08/06/2013 11:11 PM, Dan Smith wrote: >>> Please review this warnings cleanup. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022442 (not yet visible) >>> Webrev: http://cr.openjdk.java.net/~dlsmith/8022442/webrev.00/ >>> >>> ?Dan >> Hi Dan, >> I've seen that you have introduce a common super interface for entry and tree node, >> I suppose that you check that there is no performance regression. >> I wonder if an abstract class is not better than an interface because as far as I know >> CHA implemented in hotspot doesn't work on interface >> (but I may be wrong, there is perhaps a special optimization for arrays). > To make sure I understand: your concern is that an aastore will be more expensive when assigning to a KeyValueData[] than to an Object[] (or even to SomeOtherClass[])? > > For what it's worth, all assignments to table[i] are statically known to be safe. E.g.: > > Entry next = (Entry) e.next; > ... > table[i] = next; > > So surely a smart VM only does the check once? > > Here are some other things that might be concerns, but don't apply here: > - interface method invocations: there are no methods in the interface to invoke > - checkcast to an interface: all the casts are to concrete classes (Entry, TreeBin, TreeNode) > > (There are some unchecked casts from KeyValueData to KeyValueData with different type parameters, but I assume these don't cause any checkcasts.) > > ?Dan Hi, FWIW, I compiled old and new HashMap.java and did a javap on the classes. javap outputs: http://cr.openjdk.java.net/~plevart/misc/hm-8022442/ differences: http://cr.openjdk.java.net/~plevart/misc/hm-8022442/hm.javap.stripped.diff Besides unneeded introduction of local variable discussed already, there seem to be 4 new checkcasts in the following locations (new HashMap.java): public java.util.HashMap(int, float); Code: 0: aload_0 1: invokespecial #10 // Method java/util/AbstractMap."":()V 4: aload_0 5: getstatic #11 // Field EMPTY_TABLE:[Ljava/util/HashMap$KeyValueData; * 8: checkcast #12 // class "[Ljava/util/HashMap$KeyValueData;"* 11: putfield #13 // Field table:[Ljava/util/HashMap$KeyValueData; 14: aload_0 15: aconst_null ... private void inflateTable(int); Code: ... 22: aload_0 23: iload_2 24: anewarray #44 // class java/util/HashMap$KeyValueData * 27: checkcast #12 // class "[Ljava/util/HashMap$KeyValueData;"* 30: putfield #13 // Field table:[Ljava/util/HashMap$KeyValueData; 33: return ... void resize(int); Code: ... 20: return 21: iload_1 22: anewarray #44 // class java/util/HashMap$KeyValueData * 25: checkcast #12 // class "[Ljava/util/HashMap$KeyValueData;"* 28: astore 4 30: aload_0 31: aload 4 ... private void readObject(java.io.ObjectInputStream) throws java.io.IOException, java.lang.ClassNotFoundException; Code: ... 82: invokevirtual #141 // Method sun/misc/Unsafe.putIntVolatile:(Ljava/lang/Object;JI)V 85: aload_0 86: getstatic #11 // Field EMPTY_TABLE:[Ljava/util/HashMap$KeyValueData; * 89: checkcast #12 // class "[Ljava/util/HashMap$KeyValueData;"* 92: putfield #13 // Field table:[Ljava/util/HashMap$KeyValueData; 95: aload_1 96: invokevirtual #142 // Method java/io/ObjectInputStream.readInt:()I ... ...but they are all in the infrequently called methods/constructor. Regards, Peter From vicente.romero at oracle.com Wed Aug 7 09:41:49 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 07 Aug 2013 09:41:49 +0000 Subject: hg: jdk8/tl/langtools: 8020997: TreeMaker.AnnotationBuilder creates broken element literals with repeating annotations Message-ID: <20130807094204.96FBC48665@hg.openjdk.java.net> Changeset: f3deeccbf4cf Author: vromero Date: 2013-08-07 10:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f3deeccbf4cf 8020997: TreeMaker.AnnotationBuilder creates broken element literals with repeating annotations Reviewed-by: jjg, jfranck ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java + test/tools/javac/T8020997/CannotCompileRepeatedAnnoTest.java From vicente.romero at oracle.com Wed Aug 7 10:11:08 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 07 Aug 2013 10:11:08 +0000 Subject: hg: jdk8/tl/langtools: 8008274: javac should not reference/use sample code Message-ID: <20130807101110.F276C48668@hg.openjdk.java.net> Changeset: c7dcf899ffff Author: vromero Date: 2013-08-07 11:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c7dcf899ffff 8008274: javac should not reference/use sample code Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/Main.java From weijun.wang at oracle.com Wed Aug 7 11:07:15 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 07 Aug 2013 11:07:15 +0000 Subject: hg: jdk8/tl/jdk: 7151062: [macosx] SCDynamicStore prints error messages to stderr Message-ID: <20130807110825.4E6F348669@hg.openjdk.java.net> Changeset: 906dd23334c1 Author: weijun Date: 2013-08-07 19:06 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/906dd23334c1 7151062: [macosx] SCDynamicStore prints error messages to stderr Reviewed-by: xuelei ! src/macosx/native/java/util/SCDynamicStoreConfig.m From bourges.laurent at gmail.com Wed Aug 7 12:08:58 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Wed, 7 Aug 2013 14:08:58 +0200 Subject: JVM application shutdown hooks In-Reply-To: References: Message-ID: Dear core-libs members, I finally succeed in diagnosing my shutdown hook issue in Java Web Start environment: see Bug ID: 9005822. Could you please give ma feedback to my questions related to LogManager and StreamCloser shutdown hooks ? This library uses java.util.logging to log warnings and exceptions but none > is logged (console or java trace files). > > The 'lost' log messages is related to the LogManager's shutdown hook: > // This private class is used as a shutdown hook. > // It does a "reset" to close all open handlers. > private class Cleaner extends Thread { > > private Cleaner() { > /* Set context class loader to null in order to avoid > * keeping a strong reference to an application classloader. > */ > this.setContextClassLoader(null); > } > > public void run() { > // This is to ensure the LogManager. is completed > // before synchronized block. Otherwise deadlocks are possible. > LogManager mgr = manager; > > // If the global handlers haven't been initialized yet, we > // don't want to initialize them just so we can close them! > synchronized (LogManager.this) { > // Note that death is imminent. > deathImminent = true; > initializedGlobalHandlers = true; > } > > // Do a reset to close all active handlers. > reset(); > } > } > > I think it is annoying as it avoids me getting log and exceptions ... > Exactly what happened to me in JavaWS env !! I had to patch JSamp library to add System.out and printStackTrace statements whereas there are plenty of j.u.l. log statements !! Please postpone that f*** hook after 'true' application hooks !!! Moreover, as a RFE, it could be useful for applications to be able to > define hook priorities within an application: > I did that several times registering only 1 shutdown hook and handling > correct ordering on my own ... but could be supported by the JDK itself. > Do you want me to submit a patch ? I think that the JVM specs should be modified to change the addShutdownHook() signature => RFE ? > Finally, here are (below) the Open JDK8 usages of Runtime.addShutdownHook > [19 occurrences] which are more system hooks than application hooks: > com.sun.imageio.stream > StreamCloser.java > StreamCloser > addToQueue > > run > 101: Runtime.getRuntime().addShutdownHook(streamCloser); > java.util.logging > LogManager.java > LogManager > LogManager > 255: Runtime.getRuntime().addShutdownHook(new Cleaner()); > sun.font > SunFontManager.java > SunFontManager > createFont2D > > run > 2538: Runtime.getRuntime().addShutdownHook(fileCloser); > sun.rmi.server > Activation.java > Activation > init > 240: Runtime.getRuntime().addShutdownHook(shutdownHook); > sun.tools.jstat > > sun.awt.shell > Win32ShellFolderManager2.java > Win32ShellFolderManager2 > ComInvoker > ComInvoker > > > run > 493: Runtime.getRuntime().addShutdownHook( > sun.awt.windows > WToolkit.java > WToolkit > registerShutdownHook > > > run > 285: Runtime.getRuntime().addShutdownHook(shutdown); > sun.java2d.d3d > D3DScreenUpdateManager.java > D3DScreenUpdateManager > D3DScreenUpdateManager > > run > 112: Runtime.getRuntime().addShutdownHook(shutdown); > java.util.prefs > FileSystemPreferences.java > FileSystemPreferences > > > run > 439: Runtime.getRuntime().addShutdownHook(new Thread() { > sun.awt.X11 > XToolkit.java > XToolkit > init > > > run > 350: Runtime.getRuntime().addShutdownHook(shutdownThread); > sun.awt > X11GraphicsDevice.java > X11GraphicsDevice > setDisplayMode > > > run > 445: Runtime.getRuntime().addShutdownHook(t); > java.util.prefs > MacOSXPreferencesFile.java > MacOSXPreferencesFile > timer > 356: Runtime.getRuntime().addShutdownHook(flushThread); > sun.font > CFontManager.java > CFontManager > createFont2D > > > run > 232: Runtime.getRuntime().addShutdownHook(fileCloser); > sun.lwawt > LWToolkit.java > LWToolkit > init > 83: Runtime.getRuntime().addShutdownHook( > > I hope that these hooks are already supporting concurrency execution (awt > ?) but someone should check if there is no dependencies between them (like > systemd or rc scripts does). > Could someone check if there is no dependencies between all these shutdown hooks when they are executed in parallel with random order ? Best regards, Laurent From david.holmes at oracle.com Wed Aug 7 12:19:25 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 07 Aug 2013 22:19:25 +1000 Subject: RFR [6961766]: PrintStream.write() should flush at most once In-Reply-To: <5201D65E.3090504@oracle.com> References: <52012698.4090005@oracle.com> <5201D65E.3090504@oracle.com> Message-ID: <52023B4D.3090001@oracle.com> Ivan, On 7/08/2013 3:08 PM, Alan Bateman wrote: > On 06/08/2013 09:38, Ivan Gerasimov wrote: >> Hello everybody! >> >> Would you please review a simple fix, suggested by someone on >> bugs.sun.com? >> >> j.i.PrintStream#write(char[]) calls out.flush() on each '\n' character >> found in the array. >> It's sufficient to do it only once. > One thing to check is whether this will require any changes to the spec > (as it is currently specified to call flush when a newline is written). > I don't have time just at the moment to check this but that would be my > only concern with a change like this. Yes - this is NOT A BUG this is the spec for this class: "Optionally, a PrintStream can be created so as to flush automatically; this means that the flush method is automatically invoked after a byte array is written, one of the println methods is invoked, or a newline character or byte ('\n') is written. " This bug report should be closed as "not an issue". David ----- > -Alan From sundararajan.athijegannathan at oracle.com Wed Aug 7 12:47:00 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 07 Aug 2013 12:47:00 +0000 Subject: hg: jdk8/tl/jdk: 8022483: Nashorn compatibility issues in jhat's OQL feature Message-ID: <20130807124753.CE61248677@hg.openjdk.java.net> Changeset: 99f4319763a9 Author: sundar Date: 2013-08-07 18:16 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/99f4319763a9 8022483: Nashorn compatibility issues in jhat's OQL feature Reviewed-by: lagergren, attila, hannesw ! src/share/classes/com/sun/tools/hat/resources/hat.js ! src/share/classes/com/sun/tools/hat/resources/oqlhelp.html From aleksej.efimov at oracle.com Wed Aug 7 13:01:51 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 07 Aug 2013 17:01:51 +0400 Subject: RFR 8021820: Number of opened files used in select() is limited to 1024 [macosx] In-Reply-To: <52004DD9.4040202@oracle.com> References: <51F9007D.8090801@oracle.com> <51F9150B.4000008@oracle.com> <51F920A7.3000600@oracle.com> <51FF90BD.6070600@oracle.com> <52004DD9.4040202@oracle.com> Message-ID: <5202453F.2080409@oracle.com> Stuart, thank you for you comments, responses are below. New webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.02/ -Aleksej On 08/06/2013 05:14 AM, Stuart Marks wrote: > Hi Aleksej, > > Thanks for the update. I took a look at the revised test, and there > are still some issues. (I didn't look at the build changes.) > > 1) System-specific resource limits. > > I think the biggest issue is resource limits on the number of open > files per process that might vary from system to system. On my Ubuntu > system, the hard limit on the number of open files is 1,024. The test > opens 1,023 files and then one more for the socket. Unfortunately the > JVM and jtreg have several files open already, and the test crashes > before the openFiles() method completes. > > (Oddly it crashes with a NoClassDefFoundError from the main thread's > uncaught exception handler, and then the test reports that it passed! > Placing a try/catch of Throwable in main() or openFiles() doesn't > catch this error. I have no explanation for this. When run standalone > -- i.e., not from jtreg -- the test throws FileNotFoundException (too > many open files) from openFiles(), which is expected.) > > On my Mac (10.7.5) the soft limit is 256 files, but the hard limit is > unlimited. The test succeeds in opening all its files but fails > because of the select() bug you're fixing. (This is expected; I didn't > rebuild my JDK with your patch.) I guess the soft limit doesn't do > anything on Mac. > > Amazingly, the test passed fine on both Windows XP and Windows 8. > > I'm not entirely sure what to do about resource limits. Since the test > is able to open >1024 files on Mac, Windows, and possibly other > Linuxes, it seems reasonable to continue with this approach. If it's > possible to catch the error that occurs if the test cannot open its > initial 1,024 files, perhaps it should do this, log a message > indicating what happened, and consider the test to have passed. I'm > mystified by the uncaught/uncatchable NoClassDefFoundError though. I wonder if this is a question of test environment required for JTREG tests: if we'll execute JTREG tests with low value assigned to fd hard limit (for example 10) we'll see a lot of unrelated test failures. So, I suggest that we can assume that there is no hard limits set (or at least default ones, i.e. default fd limit on Ubuntu is 4096) on test machine. But we should consider test as Failed if test failed to prepare it's environment because of some external limitations. The JTREG doesn't meet this criteria (log test as PASS and prints incorrect Exception). To illustrate it I have repeated your experiments on ubuntu linux: set fd hard limit to 1024 (ulimit -Hn 1024) and got this error by manual run of test: Exception in thread "main" java.io.FileNotFoundException: testfile (Too many open files) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:128) at SelectFdsLimit.openFiles(SelectFdsLimit.java:63) at SelectFdsLimit.main(SelectFdsLimit.java:81) Seems correct to me. An by JTREG (also with hard limit set to 1024): ----------messages:(3/123)---------- command: main SelectFdsLimit reason: User specified action: run main/othervm SelectFdsLimit elapsed time (seconds): 0.168 ----------System.out:(0/0)---------- ----------System.err:(5/250)---------- Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "MainThread" STATUS:Passed. Exception in thread "main" Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "main" result: Passed. Execution successful test result: Passed. Execution successful The results are identical to results mentioned by you. It seems to me that jtreg doesn't correctly processes such test error (at least it shouldn't be considered as Pass). And I suggest two ways of resolving it: 1. If we don't have official limitations (or default) on what resources test can use then we shouldn't do any modifications to test. 2. If there is some limitations that we should honor then we'll need to figure out what to do with NoClassDefFoundError exception in JTREG. > > 2) Closing files. > > If an exception is thrown while opening the initial set of files, or > sometime during the closing process, the test can still leak files. > > One approach would be to keep a data structure representing the > current set of open files, and close them all in a finally-block > around all the test logic, and making sure that exceptions from the > close() call are caught and do not prevent the rest of the files from > being closed. > > This seems like a lot of work. Perhaps a more effective approach would > be to run the test in "othervm" mode, as follows: > > @run main/othervm SelectFdsLimit > > This will cause the test to run in a dedicated JVM, so all files will > be closed automatically when it exits. (It would be good to add a > comment explaining the need for othervm, if you do this.) > main/othervm and comments were added. > 3) Port number for sockets. > > It's fairly common for tests to fail occasionally because they use > some constant port number that sometimes happens to be in use at the > same time by another process on the system. I have to say, 8080 is a > pretty common port number. :-) > > For purposes of this test, you can let the system assign a port. Just > use: > > new ServerSocket(0) > Completely agree that 8080 port - bad port for testing =). Changed to 0. > 4) Style. > > It's probably possible to use the same File object for the test file, > instead of creating new File objects repeatedly. Agree and corrected. > > It might be nice to add a comment explaining the logic of the test, > that SocketTimeoutException is expected, and that failure will be > indicated if the accept() throws SocketException caused by the > underlying mishandling of large fds by select(). Comments were added. > > Thanks, > > s'marks > > > > On 8/5/13 4:47 AM, Aleksej Efimov wrote: >> Alan, Tim, >> >> I have addressed your comments and as a result - new webrev: >> http://cr.openjdk.java.net/~aefimov/8021820/webrev.01 >> >> The list of changes: >> 1. The connection to Oracle site is removed (it's not internal, but >> anyway it's >> better not to rely on availability of external resource in test). In >> current >> version a server socket is created and accept() method is used for >> bug disclosure. >> 2. The cleanup method is added for closing file streams. The JTREG >> successfully >> cleaned-up on windows after this modification. >> 3. common/autoconf/toolchain.m4 untouched, but 'bash >> common/autoconf/autogen.sh' was executed to update >> generated-configure.sh. >> >> Aleksej >> >> >> On 07/31/2013 06:35 PM, Tim Bell wrote: >>> Aleksej, Alan >>> >>> The change in common/autoconf/toolchain.m4 looks correct to me, and >>> I think >>> that is a good place to have it. Remember to run 'bash >>> common/autoconf/autogen.sh' and check in the generated-configure.sh >>> files as >>> part of the changeset. >>> >>> I didn't look at the test case, but I think Alan has some good points. >>> >>> Tim >>> >>> On 07/31/13 06:45 AM, Alan Bateman wrote: >>>> On 31/07/2013 05:18, Aleksej Efimov wrote: >>>>> Hi, >>>>> Can I have a review for the following problem: >>>>> The MACOSX JDK (more precisely - the java.net classes) uses the >>>>> select() >>>>> system call to wait for different events on sockets fds. And the >>>>> default >>>>> behaviour for select() on Darwin is to fail when fdset contains >>>>> the fd with >>>>> id greater than FDSET_SIZE(=1024). Test case in webrev illustrates >>>>> this >>>>> behavior. >>>>> There is at least one solution for it: use -D_DARWIN_UNLIMITED_SELECT >>>>> compilation flag for all macosx sources: this won't affect other >>>>> parts of >>>>> JDK because they are not using select(). >>>>> Currently, I have added this compilation flag to >>>>> common/autoconf/generated-configure.sh and >>>>> common/autoconf/generated-configure.sh. I wonder, if there is a >>>>> better >>>>> place where I can put this flag? >>>>> >>>>> The webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.00/ >>>>> BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021820 >>>> >>>> Thanks for looking into this one. The build changes look okay to me >>>> but it's >>>> probably best that someone on build-dev agree to those. >>>> Michael McMahon can probably explain why the net code is using >>>> select for >>>> timed read/accept (I have a vague recollection of there being an >>>> issue with >>>> poll due to the way that it is implemented on kqueue with the >>>> result that it >>>> had to be changed to use select). >>>> >>>> I think the test needs re-work. It looks to me that the it attempts to >>>> connect to an Oracle internal site so that's not going to work >>>> everywhere. >>>> In general we don't want the tests to be dependent on hosts that >>>> may or may >>>> not exist (we had tests that used to this in the past but they >>>> caused a lot >>>> of grief). It also looks like the test doesn't close the 1023 files >>>> that it >>>> opens at the start and so I assume this test will always fail on >>>> Windows >>>> when jtreg tries to clean-up. >>>> >>>> -Alan. >>> >> From xuelei.fan at oracle.com Wed Aug 7 13:43:10 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 07 Aug 2013 13:43:10 +0000 Subject: hg: jdk8/tl/jdk: 8013809: deadlock in SSLSocketImpl between between write and close Message-ID: <20130807134325.C4A2E48679@hg.openjdk.java.net> Changeset: 8c7cf4926157 Author: xuelei Date: 2013-08-07 06:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8c7cf4926157 8013809: deadlock in SSLSocketImpl between between write and close Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/SSLSocketImpl.java From dl at cs.oswego.edu Wed Aug 7 14:22:00 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 07 Aug 2013 10:22:00 -0400 Subject: RFR : 6799426 : (xs) Add constructor PriorityQueue(Comparator) In-Reply-To: <51F13300.2080709@cs.oswego.edu> References: <51F13300.2080709@cs.oswego.edu> Message-ID: <52025808.3040404@cs.oswego.edu> On 07/25/13 10:15, Doug Lea wrote: > On 07/24/13 19:30, Martin Buchholz wrote: >> PriorityQueue is unusual in that Doug maintains a copy in jsr166 CVS even though >> it is a non-thread-safe collection. I think it makes sense, >> because PriorityQueue and PriorityBlockingQueue have parallel APIs and parallel >> implementations. Many changes to one file require a matching change to the >> other. >> > > The history is that we introduced java.util.concurrent.PriorityBlockingQueue, > for JDK1.5 which of course led to people wanting plain java.util.PriorityQueue, > which Josh started working on while at Sun. But for sake of JCP approval, > we pulled into jsr166 and have adopted ever since, because the two > classes share code. The capacity constructor was added in JDK1.6, > but I have no recollection why there is not one with comparator > but no capacity. It seems reasonable to add one. Now I remember. Or rather javac forces me to remember. Adding this constructor breaks source compatibility: [javac] /home/dl/concurrent/src/test/tck/PriorityBlockingQueueTest.java:97: error: reference to PriorityBlockingQueue is ambiguous [javac] new PriorityBlockingQueue(null); [javac] ^ [javac] both constructor PriorityBlockingQueue(Comparator) in PriorityBlockingQueue and constructor PriorityBlockingQueue(Collection) in PriorityBlockingQueue match [javac] where E is a type-variable: [javac] E extends Object declared in class PriorityBlockingQueue I'm thinking to not include this at least in PriorityBlockingQueue. -Doug > > >> Regarding this particular change, if PriorityQueue gets a new constructor taking >> a Comparator, then PriorityBlockingQueue probably should too > > Yes. > > *** PriorityBlockingQueue.java.~1.99.~ Wed Jul 24 11:23:05 2013 > --- PriorityBlockingQueue.java Thu Jul 25 10:13:47 2013 > *************** > *** 200,205 **** > --- 200,219 ---- > } > > /** > + * Creates a {@code PriorityBlockingQueue} with the default > + * initial capacity that orders its elements according to the > + * specified comparator. > + * > + * @param comparator the comparator that will be used to order this > + * priority queue. If {@code null}, the {@linkplain Comparable > + * natural ordering} of the elements will be used. > + * @since 1.8 > + */ > + public PriorityBlockingQueue(Comparator comparator) { > + this(DEFAULT_INITIAL_CAPACITY, comparator); > + } > + > + /** > * Creates a {@code PriorityBlockingQueue} containing the elements > * in the specified collection. If the specified collection is a > * {@link SortedSet} or a {@link PriorityQueue}, this > > From martinrb at google.com Wed Aug 7 14:56:58 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 7 Aug 2013 07:56:58 -0700 Subject: RFR JDK-8022442: Fix unchecked warnings in HashMap In-Reply-To: References: Message-ID: Doug is also working on HashMap, with experimental version in jsr166 CVS. I think here: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/dl/java/util/HashMap.java?view=co On Tue, Aug 6, 2013 at 2:11 PM, Dan Smith wrote: > Please review this warnings cleanup. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022442 (not yet > visible) > Webrev: http://cr.openjdk.java.net/~dlsmith/8022442/webrev.00/ > > ?Dan From peter.levart at gmail.com Wed Aug 7 16:18:05 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 07 Aug 2013 18:18:05 +0200 Subject: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters synchronized method Message-ID: <5202733D.60205@gmail.com> Hi, I propose a patch for the following and related bugs: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011940 Here's the 1st webrev: http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.01/ The patch eliminates classic synchronization by using optimistic concurrent construction. At the end of construction, the "winning" result is installed using CAS. The solution is modelled upon the similar solution used to cache reflection data. Both annotations Maps and a redefinedCount int are grouped in a container AnnotationData object which is referenced with a single volatile field. Not using any locks also solves potential deadlock situations described in a related bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7122142 That bug has already been closed with a fix for AnnotationType construction and caching: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4ce6502eac0 So the alternative solution for scalability problem is using double-checked locking instead of CAS should concurrent initial requests for annotations be a problem (CPU usage). Micro benchmark shows about 5x improvement in raw single-threaded speed of retrieving an annotation by type and linear scalability: http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/test_results1.txt The space consumption is different with the patch. Initially j.l.Class objects are smaller, since one int and one reference field are eliminated from the j.l.Class. If annotations are requested the overhead is the AnnotationData container object and the field to reference it. But I tried to be smarter than the original code and when there's no inherited annotations (common situation), the annotations and declaredAnnotations share the same Map instance (originally new HashMap instance was constructed and entries copied). When there's no annotations declared on the class and no inherited annotations, this shared Map instance is an Collections.emptyMap() singleton. Regards, Peter From stuart.marks at oracle.com Wed Aug 7 16:40:01 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 07 Aug 2013 09:40:01 -0700 Subject: Remove superfluous @test tags from SpliteratorTraversingAndSplittingTest In-Reply-To: <5200C1F7.3080808@oracle.com> References: <51FB74FA.3080003@oracle.com> <51FB877B.9020907@oracle.com> <82202e6b-829a-4316-9cfb-947f99121906@default> <5200C1F7.3080808@oracle.com> Message-ID: <52027861.6070604@oracle.com> Yes, this is quite easy to reproduce with jtreg-4.1-b06. I haven't tried the latest sources but I don't think there's been so much change that this would be different using the tip of the jtreg source tree. It's not clear to me what the behavior ought to be if a single test file has more than one @test tag. The jtreg tag spec [1] requires that @test be the first token in the leading comment of the test file. This implies that @test occurring later in the file has no significance. That the test is executed twice under certain circumstances seems like a bug to me. Either the second @test should be ignored, or perhaps it should be an error, not sure. I can file a bug on this, if someone hasn't already. s'marks [1] http://openjdk.java.net/jtreg/tag-spec.txt On 8/6/13 2:29 AM, Chris Hegarty wrote: > Hi Iris, > > I'm not saying it is right, but this is the situation we found ourselves in. > > It might point to a bug in jtreg, or just "bad" jtreg meta-data. > > >: ls one > . .. HelloWorld.java > >: cat one/HelloWorld.java > /* > * @test > * @bug 8765432 > */ > > /* > * @test > */ > > public class HelloWorld { > public static void main(String[] args) { > System.out.println("Hello World."); > } > } > > >: jtreg -v1 one/HelloWorld.java > Passed: one/HelloWorld.java > Test results: passed: 1 > Report written to .../jdk/test/JTreport/html/report.html > Results written to .../jdk/test/JTwork > >: jtreg -v1 one > Passed: one/HelloWorld.java > Passed: one/HelloWorld.java#id1 > Test results: passed: 2 > Report written to .../jdk/test/JTreport/html/report.html > Results written to .../jdk/test/JTwork > > -Chris. > > P.S. Note, the offending test has been fixed, and there is no issue in the jdk > regression tests affected by this. > > On 05/08/2013 18:16, Iris Clark wrote: >> Hi, Chris. >> >>> I also noticed this. Running the test explicitly seems to locate just the >>> first @test, while running in a batch (sometimes) finds the two! Not sure why. >> >> If you execute jtreg with explicit file name(s), only those files will be >> search for "@test" tags. If you use anything else, e.g. directory names, >> then jtreg will search all *.java, *.sh, and *.html files searching for >> "@test" tags. For the "sometimes" is it possible that one of the tests has >> been somehow excluded (e.g. on a problem list) but the other one wasn't? >> >> Thanks, >> iris >> >> -----Original Message----- >> From: Chris Hegarty >> Sent: Friday, August 02, 2013 3:19 AM >> To: Paul Sandoz >> Cc: Core-Libs-Dev Core-Libs-Dev >> Subject: Re: Remove superfluous @test tags from >> SpliteratorTraversingAndSplittingTest >> >> On 02/08/2013 10:52, Paul Sandoz wrote: >>> >>> On Aug 2, 2013, at 9:59 AM, Chris Hegarty wrote: >>> >>>> SpliteratorTraversingAndSplittingTest contains two @test tags. The second >>>> of which does not specify that the test needs to run with testng. This >>>> causes the test to fail, or have an error, when run as a batch with other >>>> tests. >>>> >>>> The second @test tag is just not needed, and the @bug should be moved to >>>> the original @test tag. >>>> >>> Ooops that is my fault, thanks for sorting this out. >> >> No Problem. >> >>> When i ran jtreg manually it did not barf, is there anyway for it to >>> validate the meta-data? >> >> I also noticed this. Running the test explicitly seems to locate just the >> first @test, while running in a batch (sometimes) finds the two! Not sure >> why. It is also ok to have more than one @test, just in this case it would >> need to specify testng. >> >> -Chris. From joe.darcy at oracle.com Wed Aug 7 16:39:59 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 07 Aug 2013 16:39:59 +0000 Subject: hg: jdk8/tl/jdk: 8022454: Fixed various serializations and deprecation warnings in java.util, java.net and sun.tools Message-ID: <20130807164058.5468948686@hg.openjdk.java.net> Changeset: c1f129f62f36 Author: lagergren Date: 2013-08-07 08:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1f129f62f36 8022454: Fixed various serializations and deprecation warnings in java.util, java.net and sun.tools Reviewed-by: darcy Contributed-by: marcus.lagergren at oracle.com ! src/share/classes/java/net/SocketAddress.java ! src/share/classes/java/util/logging/XMLFormatter.java ! src/share/classes/sun/tools/jar/JarException.java From aleksey.shipilev at oracle.com Wed Aug 7 16:42:07 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 07 Aug 2013 20:42:07 +0400 Subject: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters synchronized method In-Reply-To: <5202733D.60205@gmail.com> References: <5202733D.60205@gmail.com> Message-ID: <520278DF.2060102@oracle.com> Hi Peter, On 08/07/2013 08:18 PM, Peter Levart wrote: > http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.01/ Yeah, looks familiar. The install loop is very complicated though, can we simplify it? It seems profitable to move the retry loop up into annotationData(): you then don't have to pass the $annotationData, you can merge the exit paths for $classRedefinedCount, etc. -Aleksey. From jeremymanson at google.com Wed Aug 7 16:56:15 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 7 Aug 2013 09:56:15 -0700 Subject: Deadlock in clinit for sun.nio.ch.Util/IOUtil In-Reply-To: <5201D94D.3000407@oracle.com> References: <5201D94D.3000407@oracle.com> Message-ID: Thanks, Alan. Do please ping back when you've created the bug (I'm not on nio-dev), because I'd like to track it (so we can remove our workaround when the time comes). Jeremy On Tue, Aug 6, 2013 at 10:21 PM, Alan Bateman wrote: > On 06/08/2013 15:21, Jeremy Manson wrote: > >> : >> >> >> We can eagerly do class init as a workaround, but that seems less than >> ideal. It looks easy enough to fix - just move the stuff in Util.load() >> into IOUtil somewhere, and don't call back to Util from IOUtil.. >> But I'll defer to the experts. >> >> Thanks for the mail, I'll create a bug for this. From an initial look > then moving it to IOUtil should resolve this as Util doesn't define any > native methods and so doesn't care if the native library has been loaded. > > -Alan. > From Lance.Andersen at oracle.com Wed Aug 7 17:01:15 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 7 Aug 2013 13:01:15 -0400 Subject: RFR: 8022479: clean up warnings from sun.tools.asm In-Reply-To: <5201E927.3030508@oracle.com> References: <5201E927.3030508@oracle.com> Message-ID: Hi Stuart, On the surface the changes look fine, including what you did for SwitchData. Certainly another pair of eyes would be good also on this. Best Lance On Aug 7, 2013, at 2:28 AM, Stuart Marks wrote: > Hi, > > Please review the fix for this warnings cleanup bug. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022479 > (not yet available publicly, but should be shortly) > > Webrev: http://cr.openjdk.java.net/~smarks/reviews/8022479/webrev.0/ > > There are a few items of note. > > This is *very* old code. You can see some of the authors' names in the code. It's replete with uses of Vector, Hashtable, and Enumeration. It also has a kind of musty style, which might have been reasonable from the standpoint of C programmers (which we all were at the time!). For example, there are a bunch of cases of direct field access to another class. There are also cases where a class contains a Vector that's returned by a getter method. I guess we just have to trust the caller not to modify it at the wrong time. > > I've confined most of my cleanups to the addition of generics (which gets rid of the rawtypes and unchecked warnings). There were a smattering of other warnings I've cleaned up as well. I've also replaced few cases of calls to "new" on boxed types like Integer and Long with calls to the respective valueOf() methods. I didn't check all the code for this, though, just instances I happened to run across. > > There is much more cleanup that could be done that I've elected not to do, such as replacing Vector, Hashtable, and Enumeration with ArrayList, HashMap, and Iterator, and using the enhanced-for loop. These changes would *probably* be safe, but they would require more analysis and testing than I'm willing to do at the moment. > > Two locations deserve a bit of scrutiny. > > 1) There are four occurrences in Assembler.java of calls to MemberDefinition.getArguments(). Unfortunately MemberDefinition resides in the sun.tools.java package and getArguments() returns a raw Vector. This is also overridden in a couple places spread across a couple sun.tools packages, and there are hints that it being a LocalMember or MemberDefinition. It seems out of scope to try to fix up the return value of getArguments() and its various overrides. > > Locally in the Assembler.java file, though, the contents of the returned vector are always cast to MemberDefinition, so it seems sensible to make an unchecked cast of the getArguments() return value to Vector and to suppress warnings at that point. Usage beyond those points within Assembler.java is filled with sweet and juicy generic goodness. > > 2) SwitchData.java contains a field whereCaseTab which is a Hashtable ... most of the time. In the addTableDefault() method, a value is put into the Hashtable under the key "default" -- a String. Ick. > > To deal with this I declared it as Hashtable since that's the typical case, and for the put(String, Long) case I cast through raw and suppressed the warning. The get() method already takes an Object so we're OK there. Note that "default" as a key for this Hashtable is used in a couple other places in Assembler.java. It's not intractable to change these to some other sentinel value, but, you know, where does one stop? > > (I said "Ick" when encountering a mix-type collection, and in a generified world we very rarely see this style anymore. Upon further reflection, though, from the standpoint of a pre-generics world, this is pretty sensible. Using a string as a sentinel key is guaranteed not to collide with any Integer keys. Sometimes it's possible to use -1 or Integer.MAX_VALUE as a sentinel, but if any integer value is permitted as a key, what does one do then?) > > With this changeset, sun.tools.asm is reduced from about 76 to zero warnings. > > Thanks, > > s'marks -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From forax at univ-mlv.fr Wed Aug 7 17:31:17 2013 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 7 Aug 2013 19:31:17 +0200 Subject: RFR JDK-8022442: Fix unchecked warnings in HashMap Message-ID: On 08/07/2013 10:57 AM, Peter Levart wrote: On 08/07/2013 12:23 AM, Dan Smith wrote: On Aug 6, 2013, at 2:43 PM, Remi Forax wrote: On 08/06/2013 11:11 PM, Dan Smith wrote: Please review this warnings cleanup. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022442 (not yet visible) Webrev: http://cr.openjdk.java.net/~dlsmith/8022442/webrev.00/ ?Dan Hi Dan, I've seen that you have introduce a common super interface for entry and tree node, I suppose that you check that there is no performance regression. I wonder if an abstract class is not better than an interface because as far as I know CHA implemented in hotspot doesn't work on interface (but I may be wrong, there is perhaps a special optimization for arrays). To make sure I understand: your concern is that an aastore will be more expensive when assigning to a KeyValueData[] than to an Object[] (or even to SomeOtherClass[])? For what it's worth, all assignments to table[i] are statically known to be safe. E.g.: Entry next = (Entry) e.next; ... table[i] = next; So surely a smart VM only does the check once? Here are some other things that might be concerns, but don't apply here: - interface method invocations: there are no methods in the interface to invoke - checkcast to an interface: all the casts are to concrete classes (Entry, TreeBin, TreeNode) (There are some unchecked casts from KeyValueData to KeyValueData with different type parameters, but I assume these don't cause any checkcasts.) ?Dan Hi, Hi Peter, FWIW, I compiled old and new HashMap.java and did a javap on the classes. javap outputs: http://cr.openjdk.java.net/~plevart/misc/hm-8022442/ differences: http://cr.openjdk.java.net/~plevart/misc/hm-8022442/hm.javap.stripped.diff Besides unneeded introduction of local variable discussed already, there seem to be 4 new checkcasts in the following locations (new HashMap.java): public java.util.HashMap(int, float); Code: 0: aload_0 1: invokespecial #10 // Method java/util/AbstractMap."":()V 4: aload_0 5: getstatic #11 // Field EMPTY_TABLE:[Ljava/util/HashMap$KeyValueData; * 8: checkcast #12 // class "[Ljava/util/HashMap$KeyValueData;"* 11: putfield #13 // Field table:[Ljava/util/HashMap$KeyValueData; 14: aload_0 15: aconst_null ... private void inflateTable(int); Code: ... 22: aload_0 23: iload_2 24: anewarray #44 // class java/util/HashMap$KeyValueData * 27: checkcast #12 // class "[Ljava/util/HashMap$KeyValueData;"* 30: putfield #13 // Field table:[Ljava/util/HashMap$KeyValueData; 33: return ... void resize(int); Code: ... 20: return 21: iload_1 22: anewarray #44 // class java/util/HashMap$KeyValueData * 25: checkcast #12 // class "[Ljava/util/HashMap$KeyValueData;"* 28: astore 4 30: aload_0 31: aload 4 ... private void readObject(java.io.ObjectInputStream) throws java.io.IOException, java.lang.ClassNotFoundException; Code: ... 82: invokevirtual #141 // Method sun/misc/Unsafe.putIntVolatile:(Ljava/lang/Object;JI)V 85: aload_0 86: getstatic #11 // Field EMPTY_TABLE:[Ljava/util/HashMap$KeyValueData; * 89: checkcast #12 // class "[Ljava/util/HashMap$KeyValueData;"* 92: putfield #13 // Field table:[Ljava/util/HashMap$KeyValueData; 95: aload_1 96: invokevirtual #142 // Method java/io/ObjectInputStream.readInt:()I ... ...but they are all in the infrequently called methods/constructor. Regards, Peter and all these 'checkcast' should be removed at runtime. I've no problem with the current patch but I think it can be improved by declaring KeyValueData as an abstract class (static!) instead as an interface because the VM will be able to remove all the instanceof/checkcast that were introduced to deal with the red/black tree implementation. By example, when a user calls get, it calls in fact getEntry which is starts with this code: final Entry getEntry(Object key) { if (size == 0) { return null; } if (key == null) { return nullKeyEntry; } int hash = hash(key); int bin = indexFor(hash, table.length); if (table[bin] instanceof Entry) { Entry e = (Entry) table[bin]; for (; e != null; e = (Entry)e.next) { Object k; if (e.hash == hash && ((k = e.key) == key || key.equals(k))) { return e; } } } ... The interesting part is: ... if (table[bin] instanceof Entry) { Entry e = (Entry) table[bin]; ... (and e = (Entry)e.next but it works in a similar way) The idea is that most of the time, TreeBin and TreeNode are not loaded, at least until someone tries to DDOS your HashMap, so in that case the VM knows that the only implementation of KeyValueData is Entry, so no check are needed. here is the generated code for the snippet above if KeyValueData is an interface: 0x00007f9a710646c1: test %r8d,%r8d 0x00007f9a710646c4: je 0x00007f9a7106471d 0x00007f9a710646c6: mov 0x8(%r8),%r9d 0x00007f9a710646ca: cmp $0xc6861040,%r9d ; {metadata('HashMap2$Entry')} 0x00007f9a710646d1: jne 0x00007f9a71064791 ;*instanceof ; - HashMap2::getEntry at 40(line 1047) ; - HashMap2::get at 2 (line 1008) here is the one if KeyValueData is an abstract class: 0x00007f2d6d06311d: test %r11d,%r11d 0x00007f2d6d063120: je 0x00007f2d6d063165 ;*instanceof ; - HashMap2::getEntry at 40(line 1047) ; - HashMap2::get at 2 (line 1008) as you can see the former code do a nullcheck and then a a quick class check, the later only do a nullcheck. BTW, in getTreeNode(), the local variable 'pl' is assigned but never read and initHashSeed should be static. cheers, R?mi From dan.xu at oracle.com Wed Aug 7 17:49:10 2013 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 07 Aug 2013 10:49:10 -0700 Subject: RFR: JDK-8022554 -- Fix Warnings in sun.invoke.anon Package Message-ID: <52028896.3070304@oracle.com> Hi All, Please review the simple warning fix in src/share/classes/sun/invoke/anon/ConstantPoolPatch.java. webrev: http://cr.openjdk.java.net/~dxu/8022554/webrev/ Thanks, -Dan From Lance.Andersen at oracle.com Wed Aug 7 17:51:25 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 7 Aug 2013 13:51:25 -0400 Subject: RFR: JDK-8022554 -- Fix Warnings in sun.invoke.anon Package In-Reply-To: <52028896.3070304@oracle.com> References: <52028896.3070304@oracle.com> Message-ID: <54BD6A7D-E6F9-4331-82B5-16BFCAE17702@oracle.com> looks fine Dan On Aug 7, 2013, at 1:49 PM, Dan Xu wrote: > Hi All, > > Please review the simple warning fix in src/share/classes/sun/invoke/anon/ConstantPoolPatch.java. > > webrev: http://cr.openjdk.java.net/~dxu/8022554/webrev/ > > Thanks, > > -Dan -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mike.duigou at oracle.com Wed Aug 7 17:53:05 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 7 Aug 2013 10:53:05 -0700 Subject: RFR: JDK-8022554 -- Fix Warnings in sun.invoke.anon Package In-Reply-To: <52028896.3070304@oracle.com> References: <52028896.3070304@oracle.com> Message-ID: <5394BDD2-DDD2-413C-B1ED-0FBB8328641E@oracle.com> Why not have Class[] on the left side as well? Mike On Aug 7 2013, at 10:49 , Dan Xu wrote: > Hi All, > > Please review the simple warning fix in src/share/classes/sun/invoke/anon/ConstantPoolPatch.java. > > webrev: http://cr.openjdk.java.net/~dxu/8022554/webrev/ > > Thanks, > > -Dan From ivan.gerasimov at oracle.com Wed Aug 7 17:53:57 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 07 Aug 2013 21:53:57 +0400 Subject: RFR [6961766]: PrintStream.write() should flush at most once In-Reply-To: <52023B4D.3090001@oracle.com> References: <52012698.4090005@oracle.com> <5201D65E.3090504@oracle.com> <52023B4D.3090001@oracle.com> Message-ID: <520289B5.9080903@oracle.com> Hello David! Thanks for review. > Yes - this is NOT A BUG this is the spec for this class: > > "Optionally, a PrintStream can be created so as to flush > automatically; this means that the flush method is automatically > invoked after a byte array is written, one of the println methods is > invoked, or a newline character or byte ('\n') is written. " > Sorry, I don't see how the proposed change would contradict the spec . The code first writes a char[] buffer to an OutputStream, and then invokes flush() if the written array contained at least one '\n' char. In addition to that, the documentation for OutputStream#flush() says: "Flushes this output stream and forces any buffered output bytes to be written out." Thus, there should be no point to have several subsequent calls to flush() with no data writes between them. I don't insist on pushing this change, but I think it's harmless and may be useful. Sincerely yours, Ivan > This bug report should be closed as "not an issue". > > David > ----- > > >> -Alan > > From benjamin.john.evans at gmail.com Tue Aug 6 13:39:53 2013 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Tue, 6 Aug 2013 14:39:53 +0100 Subject: FileVisitor / Are we feature frozen yet? Message-ID: Hi, I have a suggestion for a point lambdafication change which I don't think anyone's proposed yet. (As usual, if my Google-fu has failed me, please point me at the relevant discussion). In java.nio.file we have the FileVisitor interface, which defines 4 methods. We also have the SimpleFileVisitor class which defines sane (basically no-op) implementations of all the methods. In using FileVisitor, I've noticed that visitFile() tends to be overridden / used far more often than the others. It would be nifty if it we could lambdify in such a way that a lambda expression could be fed to Files.walkFileTree(). Could we add default implementations to FileVisitor (those from SimpleFileVisitor seem reasonable) for all methods except visitFile() ? This would then make code like this possible: Path homeDir = Paths.get("/Users/kittylyst"); Files.walkFileTree(homeDir, (p, attrs) -> { System.out.println(p.getFileName()); return FileVisitResult.CONTINUE; }); I have a patch which demonstrates this - let me know if there's potential here, and if anyone would be interested in sponsoring the patch. Thanks, Ben From benjamin.john.evans at gmail.com Tue Aug 6 15:00:55 2013 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Tue, 6 Aug 2013 16:00:55 +0100 Subject: FileVisitor / Are we feature frozen yet? In-Reply-To: <520104E8.1080000@oracle.com> References: <520104E8.1080000@oracle.com> Message-ID: On Files? Yes, that does indeed look suspiciously like it'll cover the current use cases I have. Let me check & come back if not. Ben On Tue, Aug 6, 2013 at 3:15 PM, Alan Bateman wrote: > On 06/08/2013 06:39, Ben Evans wrote: > >> Hi, >> >> I have a suggestion for a point lambdafication change which I don't think >> anyone's proposed yet. (As usual, if my Google-fu has failed me, please >> point me at the relevant discussion). >> >> In java.nio.file we have the FileVisitor interface, which defines 4 >> methods. >> >> We also have the SimpleFileVisitor class which defines sane (basically >> no-op) implementations of all the methods. >> >> In using FileVisitor, I've noticed that visitFile() tends to be overridden >> / used far more often than the others. It would be nifty if it we could >> lambdify in such a way that a lambda expression could be fed to >> Files.walkFileTree(). >> >> Could we add default implementations to FileVisitor (those from >> SimpleFileVisitor seem reasonable) for all methods except visitFile() ? >> >> This would then make code like this possible: >> >> Path homeDir = Paths.get("/Users/kittylyst"); >> Files.walkFileTree(homeDir, (p, attrs) -> { >> System.out.println(p.**getFileName()); return FileVisitResult.CONTINUE; >> }); >> >> I have a patch which demonstrates this - let me know if there's potential >> here, and if anyone would be interested in sponsoring the patch. >> >> Have you looked at the walk and find methods? (They currently return a > CloseableStream but there is discussion on just returning a Stream). > > -Alan. > From mhall at mhcomputing.net Tue Aug 6 19:25:20 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Tue, 6 Aug 2013 12:25:20 -0700 Subject: RFR 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress In-Reply-To: <52012FEF.9030307@oracle.com> References: <5201171B.3030907@oracle.com> <52011CDD.2000001@oracle.com> <52012FEF.9030307@oracle.com> Message-ID: <20130806192520.GB5157@mhcomputing.net> On Tue, Aug 06, 2013 at 06:18:39PM +0100, Michael McMahon wrote: > Documenting in release notes is okay too, but I suspect developers are not > likely to look there at first anyway. Thinking aloud, it would be nice if > some kind of annotation could be associated with the affected constructors > such that a more meaningful/customized error message could be emitted by > javac. But, perhaps there aren't sufficient other use cases to justify that. Many of us use Eclipse, NetBeans, and JavaDoc. So if we just had a comment in the JavaDoc, saying this was fixed, and what to do, that ought to be more than adequate, and would prevent missing it if you didn't see the relnotes. Matthew. From joe.darcy at oracle.com Wed Aug 7 18:11:49 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 07 Aug 2013 11:11:49 -0700 Subject: RFR: JDK-8022554 -- Fix Warnings in sun.invoke.anon Package In-Reply-To: <5394BDD2-DDD2-413C-B1ED-0FBB8328641E@oracle.com> References: <52028896.3070304@oracle.com> <5394BDD2-DDD2-413C-B1ED-0FBB8328641E@oracle.com> Message-ID: <52028DE5.7070501@oracle.com> I agree with Mike; Class[] should be used on both sides. Cheers, -Joe On 08/07/2013 10:53 AM, Mike Duigou wrote: > Why not have Class[] on the left side as well? > > Mike > > On Aug 7 2013, at 10:49 , Dan Xu wrote: > >> Hi All, >> >> Please review the simple warning fix in src/share/classes/sun/invoke/anon/ConstantPoolPatch.java. >> >> webrev: http://cr.openjdk.java.net/~dxu/8022554/webrev/ >> >> Thanks, >> >> -Dan From dan.xu at oracle.com Wed Aug 7 18:36:38 2013 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 07 Aug 2013 11:36:38 -0700 Subject: RFR: JDK-8022554 -- Fix Warnings in sun.invoke.anon Package In-Reply-To: <52028DE5.7070501@oracle.com> References: <52028896.3070304@oracle.com> <5394BDD2-DDD2-413C-B1ED-0FBB8328641E@oracle.com> <52028DE5.7070501@oracle.com> Message-ID: <520293B6.9090906@oracle.com> Thanks for your review! I was thinking of that. But without Class[] on the left, the compiler just worked fine. Here is a simple example, //Main.java import java.util.*; public class Main { public static final Class[] TEST_CLASS = new Class[16]; public static final List[] TEST_MAP = new ArrayList[16]; } After compiling with javac Xlint:all Main.java, no warnings are printed out. Is it a compiler issue? Thanks! -Dan On 08/07/2013 11:11 AM, Joe Darcy wrote: > I agree with Mike; Class[] should be used on both sides. > > Cheers, > > -Joe > > On 08/07/2013 10:53 AM, Mike Duigou wrote: >> Why not have Class[] on the left side as well? >> >> Mike >> >> On Aug 7 2013, at 10:49 , Dan Xu wrote: >> >>> Hi All, >>> >>> Please review the simple warning fix in >>> src/share/classes/sun/invoke/anon/ConstantPoolPatch.java. >>> >>> webrev: http://cr.openjdk.java.net/~dxu/8022554/webrev/ >>> >>> Thanks, >>> >>> -Dan > From brent.christian at oracle.com Wed Aug 7 18:38:05 2013 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 07 Aug 2013 11:38:05 -0700 Subject: RFR JDK-8022442: Fix unchecked warnings in HashMap In-Reply-To: <201C24F5-3499-48E1-8BBA-E8A0A757015E@oracle.com> References: <52016E0D.8070008@univ-mlv.fr> <201C24F5-3499-48E1-8BBA-E8A0A757015E@oracle.com> Message-ID: <5202940D.6050700@oracle.com> Hi, I did a before/after run with the changes using Doug Lea's MapCheck microbenchmark [1]. I tested java.util.HashMap with Object, String, and Integer types. It should be mentioned this was a quick check for any major performance changes: 2 iterations, run by hand on my own (relatively quiet) Mac. The changes are small. (A more serious run would be needed to accurately measure such a small performance difference, ideally using jmh, and a benchmark with more precise scoring.) A brief summary of the scoring differences is below, by type of access and data type. The benchmark scores are based on the length of time to perform the operation, so a lower score is better, and a positive percent change means the operation took longer with the warnings cleanup changes. --- MapCheck, java.util.HashMap, trials: 1000, size: 36864 %Change No Changes vs HashMap Warnings Cleanup Object String Integer Access Present 0.00% 0.00% 6.67% Add Absent 0.00% 0.76% -1.27% Modify Present 0.00% -1.16% 0.00% Remove Present 0.00% 0.00% 0.00% Search Absent 0.00% 2.00% 3.03% Traverse entry 0.00% 0.00% 0.00% Traverse key/val 0.00% 2.86% 0.00% --- One might think the 6.6% increase for Access Present/Integer is cause for concern, but I think this is more a reflection of the scores being fairly coarse. Specifically, the two scores before the changes were 15 & 15, and with the changes were 15 & 17 (a mean of 16, 6.67% change from 15). I think the change is fine to go back. For reference, my spreadsheet of results is at [2]. Thanks, -Brent [1] http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/loops/MapCheck.java [2] http://cr.openjdk.java.net/~bchristi/8022442/ On 8/6/13 3:23 PM, Dan Smith wrote: > On Aug 6, 2013, at 2:43 PM, Remi Forax wrote: > >> On 08/06/2013 11:11 PM, Dan Smith wrote: >>> Please review this warnings cleanup. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022442 (not yet visible) >>> Webrev: http://cr.openjdk.java.net/~dlsmith/8022442/webrev.00/ >>> >>> ?Dan >> >> Hi Dan, >> I've seen that you have introduce a common super interface for entry and tree node, >> I suppose that you check that there is no performance regression. >> I wonder if an abstract class is not better than an interface because as far as I know >> CHA implemented in hotspot doesn't work on interface >> (but I may be wrong, there is perhaps a special optimization for arrays). > > To make sure I understand: your concern is that an aastore will be more expensive when assigning to a KeyValueData[] than to an Object[] (or even to SomeOtherClass[])? > > For what it's worth, all assignments to table[i] are statically known to be safe. E.g.: > > Entry next = (Entry) e.next; > ... > table[i] = next; > > So surely a smart VM only does the check once? > > Here are some other things that might be concerns, but don't apply here: > - interface method invocations: there are no methods in the interface to invoke > - checkcast to an interface: all the casts are to concrete classes (Entry, TreeBin, TreeNode) > > (There are some unchecked casts from KeyValueData to KeyValueData with different type parameters, but I assume these don't cause any checkcasts.) > > ?Dan > From joe.darcy at oracle.com Wed Aug 7 18:46:49 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 07 Aug 2013 11:46:49 -0700 Subject: RFR: JDK-8022554 -- Fix Warnings in sun.invoke.anon Package In-Reply-To: <520293B6.9090906@oracle.com> References: <52028896.3070304@oracle.com> <5394BDD2-DDD2-413C-B1ED-0FBB8328641E@oracle.com> <52028DE5.7070501@oracle.com> <520293B6.9090906@oracle.com> Message-ID: <52029619.9040709@oracle.com> Hi Dan, Even if the compiler does not complain, using "Class" or "Class[]" is using a raw type and raw types should generally be viewed as unacceptable in modern code. Cheers, -Joe On 08/07/2013 11:36 AM, Dan Xu wrote: > Thanks for your review! > > I was thinking of that. But without Class[] on the left, the > compiler just worked fine. > > Here is a simple example, > > //Main.java > > import java.util.*; > > public class Main { > public static final Class[] TEST_CLASS = new Class[16]; > public static final List[] TEST_MAP = new ArrayList[16]; > } > > After compiling with javac Xlint:all Main.java, no warnings are > printed out. Is it a compiler issue? Thanks! > > -Dan > > > > On 08/07/2013 11:11 AM, Joe Darcy wrote: >> I agree with Mike; Class[] should be used on both sides. >> >> Cheers, >> >> -Joe >> >> On 08/07/2013 10:53 AM, Mike Duigou wrote: >>> Why not have Class[] on the left side as well? >>> >>> Mike >>> >>> On Aug 7 2013, at 10:49 , Dan Xu wrote: >>> >>>> Hi All, >>>> >>>> Please review the simple warning fix in >>>> src/share/classes/sun/invoke/anon/ConstantPoolPatch.java. >>>> >>>> webrev: http://cr.openjdk.java.net/~dxu/8022554/webrev/ >>>> >>>> Thanks, >>>> >>>> -Dan >> > From dan.xu at oracle.com Wed Aug 7 18:54:09 2013 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 07 Aug 2013 11:54:09 -0700 Subject: RFR: JDK-8022554 -- Fix Warnings in sun.invoke.anon Package In-Reply-To: <52029619.9040709@oracle.com> References: <52028896.3070304@oracle.com> <5394BDD2-DDD2-413C-B1ED-0FBB8328641E@oracle.com> <52028DE5.7070501@oracle.com> <520293B6.9090906@oracle.com> <52029619.9040709@oracle.com> Message-ID: <520297D1.2010806@oracle.com> I see, Thanks! I have updated my changeto http://cr.openjdk.java.net/~dxu/8022554/webrev1/. -Dan On 08/07/2013 11:46 AM, Joe Darcy wrote: > Hi Dan, > > Even if the compiler does not complain, using "Class" or "Class[]" is > using a raw type and raw types should generally be viewed as > unacceptable in modern code. > > Cheers, > > -Joe > > On 08/07/2013 11:36 AM, Dan Xu wrote: >> Thanks for your review! >> >> I was thinking of that. But without Class[] on the left, the >> compiler just worked fine. >> >> Here is a simple example, >> >> //Main.java >> >> import java.util.*; >> >> public class Main { >> public static final Class[] TEST_CLASS = new Class[16]; >> public static final List[] TEST_MAP = new ArrayList[16]; >> } >> >> After compiling with javac Xlint:all Main.java, no warnings are >> printed out. Is it a compiler issue? Thanks! >> >> -Dan >> >> >> >> On 08/07/2013 11:11 AM, Joe Darcy wrote: >>> I agree with Mike; Class[] should be used on both sides. >>> >>> Cheers, >>> >>> -Joe >>> >>> On 08/07/2013 10:53 AM, Mike Duigou wrote: >>>> Why not have Class[] on the left side as well? >>>> >>>> Mike >>>> >>>> On Aug 7 2013, at 10:49 , Dan Xu wrote: >>>> >>>>> Hi All, >>>>> >>>>> Please review the simple warning fix in >>>>> src/share/classes/sun/invoke/anon/ConstantPoolPatch.java. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~dxu/8022554/webrev/ >>>>> >>>>> Thanks, >>>>> >>>>> -Dan >>> >> > From joe.darcy at oracle.com Wed Aug 7 18:56:36 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 07 Aug 2013 11:56:36 -0700 Subject: RFR: 8022479: clean up warnings from sun.tools.asm In-Reply-To: References: <5201E927.3030508@oracle.com> Message-ID: <52029864.10404@oracle.com> Hi Stuart, I believe the code in its current state out in review is a good trade-off of effort needed to address the warnings vs improvement in the quality of the code. Certainly the code would benefit from a larger cleanup, but I agree that is not warranted at this point. Longer term, say for JDK 9, we should probably look to providing this functionality in some other way. Approved to go back. Thanks, -Joe On 08/07/2013 10:01 AM, Lance Andersen - Oracle wrote: > Hi Stuart, > > On the surface the changes look fine, including what you did for SwitchData. > > Certainly another pair of eyes would be good also on this. > > Best > Lance > On Aug 7, 2013, at 2:28 AM, Stuart Marks wrote: > >> Hi, >> >> Please review the fix for this warnings cleanup bug. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022479 >> (not yet available publicly, but should be shortly) >> >> Webrev: http://cr.openjdk.java.net/~smarks/reviews/8022479/webrev.0/ >> >> There are a few items of note. >> >> This is *very* old code. You can see some of the authors' names in the code. It's replete with uses of Vector, Hashtable, and Enumeration. It also has a kind of musty style, which might have been reasonable from the standpoint of C programmers (which we all were at the time!). For example, there are a bunch of cases of direct field access to another class. There are also cases where a class contains a Vector that's returned by a getter method. I guess we just have to trust the caller not to modify it at the wrong time. >> >> I've confined most of my cleanups to the addition of generics (which gets rid of the rawtypes and unchecked warnings). There were a smattering of other warnings I've cleaned up as well. I've also replaced few cases of calls to "new" on boxed types like Integer and Long with calls to the respective valueOf() methods. I didn't check all the code for this, though, just instances I happened to run across. >> >> There is much more cleanup that could be done that I've elected not to do, such as replacing Vector, Hashtable, and Enumeration with ArrayList, HashMap, and Iterator, and using the enhanced-for loop. These changes would *probably* be safe, but they would require more analysis and testing than I'm willing to do at the moment. >> >> Two locations deserve a bit of scrutiny. >> >> 1) There are four occurrences in Assembler.java of calls to MemberDefinition.getArguments(). Unfortunately MemberDefinition resides in the sun.tools.java package and getArguments() returns a raw Vector. This is also overridden in a couple places spread across a couple sun.tools packages, and there are hints that it being a LocalMember or MemberDefinition. It seems out of scope to try to fix up the return value of getArguments() and its various overrides. >> >> Locally in the Assembler.java file, though, the contents of the returned vector are always cast to MemberDefinition, so it seems sensible to make an unchecked cast of the getArguments() return value to Vector and to suppress warnings at that point. Usage beyond those points within Assembler.java is filled with sweet and juicy generic goodness. >> >> 2) SwitchData.java contains a field whereCaseTab which is a Hashtable ... most of the time. In the addTableDefault() method, a value is put into the Hashtable under the key "default" -- a String. Ick. >> >> To deal with this I declared it as Hashtable since that's the typical case, and for the put(String, Long) case I cast through raw and suppressed the warning. The get() method already takes an Object so we're OK there. Note that "default" as a key for this Hashtable is used in a couple other places in Assembler.java. It's not intractable to change these to some other sentinel value, but, you know, where does one stop? >> >> (I said "Ick" when encountering a mix-type collection, and in a generified world we very rarely see this style anymore. Upon further reflection, though, from the standpoint of a pre-generics world, this is pretty sensible. Using a string as a sentinel key is guaranteed not to collide with any Integer keys. Sometimes it's possible to use -1 or Integer.MAX_VALUE as a sentinel, but if any integer value is permitted as a key, what does one do then?) >> >> With this changeset, sun.tools.asm is reduced from about 76 to zero warnings. >> >> Thanks, >> >> s'marks > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From joe.darcy at oracle.com Wed Aug 7 18:59:06 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 07 Aug 2013 11:59:06 -0700 Subject: RFR: JDK-8022554 -- Fix Warnings in sun.invoke.anon Package In-Reply-To: <520297D1.2010806@oracle.com> References: <52028896.3070304@oracle.com> <5394BDD2-DDD2-413C-B1ED-0FBB8328641E@oracle.com> <52028DE5.7070501@oracle.com> <520293B6.9090906@oracle.com> <52029619.9040709@oracle.com> <520297D1.2010806@oracle.com> Message-ID: <520298FA.7010500@oracle.com> Amended version approved to go back. Thanks, -Joe On 08/07/2013 11:54 AM, Dan Xu wrote: > I see, Thanks! I have updated my changeto > http://cr.openjdk.java.net/~dxu/8022554/webrev1/. > > -Dan > > On 08/07/2013 11:46 AM, Joe Darcy wrote: >> Hi Dan, >> >> Even if the compiler does not complain, using "Class" or "Class[]" is >> using a raw type and raw types should generally be viewed as >> unacceptable in modern code. >> >> Cheers, >> >> -Joe >> >> On 08/07/2013 11:36 AM, Dan Xu wrote: >>> Thanks for your review! >>> >>> I was thinking of that. But without Class[] on the left, the >>> compiler just worked fine. >>> >>> Here is a simple example, >>> >>> //Main.java >>> >>> import java.util.*; >>> >>> public class Main { >>> public static final Class[] TEST_CLASS = new Class[16]; >>> public static final List[] TEST_MAP = new ArrayList[16]; >>> } >>> >>> After compiling with javac Xlint:all Main.java, no warnings are >>> printed out. Is it a compiler issue? Thanks! >>> >>> -Dan >>> >>> >>> >>> On 08/07/2013 11:11 AM, Joe Darcy wrote: >>>> I agree with Mike; Class[] should be used on both sides. >>>> >>>> Cheers, >>>> >>>> -Joe >>>> >>>> On 08/07/2013 10:53 AM, Mike Duigou wrote: >>>>> Why not have Class[] on the left side as well? >>>>> >>>>> Mike >>>>> >>>>> On Aug 7 2013, at 10:49 , Dan Xu wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> Please review the simple warning fix in >>>>>> src/share/classes/sun/invoke/anon/ConstantPoolPatch.java. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~dxu/8022554/webrev/ >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Dan >>>> >>> >> > From forax at univ-mlv.fr Wed Aug 7 19:08:42 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 07 Aug 2013 21:08:42 +0200 Subject: RFR: JDK-8022554 -- Fix Warnings in sun.invoke.anon Package In-Reply-To: <520298FA.7010500@oracle.com> References: <52028896.3070304@oracle.com> <5394BDD2-DDD2-413C-B1ED-0FBB8328641E@oracle.com> <52028DE5.7070501@oracle.com> <520293B6.9090906@oracle.com> <52029619.9040709@oracle.com> <520297D1.2010806@oracle.com> <520298FA.7010500@oracle.com> Message-ID: <52029B3A.7080301@univ-mlv.fr> On 08/07/2013 08:59 PM, Joe Darcy wrote: > Amended version approved to go back. > > Thanks, > > -Joe As one of the guys involved in the design of this API :) I'm Ok with this change. R?mi > > On 08/07/2013 11:54 AM, Dan Xu wrote: >> I see, Thanks! I have updated my changeto >> http://cr.openjdk.java.net/~dxu/8022554/webrev1/. >> >> -Dan >> >> On 08/07/2013 11:46 AM, Joe Darcy wrote: >>> Hi Dan, >>> >>> Even if the compiler does not complain, using "Class" or "Class[]" >>> is using a raw type and raw types should generally be viewed as >>> unacceptable in modern code. >>> >>> Cheers, >>> >>> -Joe >>> >>> On 08/07/2013 11:36 AM, Dan Xu wrote: >>>> Thanks for your review! >>>> >>>> I was thinking of that. But without Class[] on the left, the >>>> compiler just worked fine. >>>> >>>> Here is a simple example, >>>> >>>> //Main.java >>>> >>>> import java.util.*; >>>> >>>> public class Main { >>>> public static final Class[] TEST_CLASS = new Class[16]; >>>> public static final List[] TEST_MAP = new ArrayList[16]; >>>> } >>>> >>>> After compiling with javac Xlint:all Main.java, no warnings are >>>> printed out. Is it a compiler issue? Thanks! >>>> >>>> -Dan >>>> >>>> >>>> >>>> On 08/07/2013 11:11 AM, Joe Darcy wrote: >>>>> I agree with Mike; Class[] should be used on both sides. >>>>> >>>>> Cheers, >>>>> >>>>> -Joe >>>>> >>>>> On 08/07/2013 10:53 AM, Mike Duigou wrote: >>>>>> Why not have Class[] on the left side as well? >>>>>> >>>>>> Mike >>>>>> >>>>>> On Aug 7 2013, at 10:49 , Dan Xu wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> Please review the simple warning fix in >>>>>>> src/share/classes/sun/invoke/anon/ConstantPoolPatch.java. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~dxu/8022554/webrev/ >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Dan >>>>> >>>> >>> >> > From dan.xu at oracle.com Wed Aug 7 19:16:04 2013 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 07 Aug 2013 12:16:04 -0700 Subject: RFR: JDK-8022554 -- Fix Warnings in sun.invoke.anon Package In-Reply-To: <52029B3A.7080301@univ-mlv.fr> References: <52028896.3070304@oracle.com> <5394BDD2-DDD2-413C-B1ED-0FBB8328641E@oracle.com> <52028DE5.7070501@oracle.com> <520293B6.9090906@oracle.com> <52029619.9040709@oracle.com> <520297D1.2010806@oracle.com> <520298FA.7010500@oracle.com> <52029B3A.7080301@univ-mlv.fr> Message-ID: <52029CF4.3010003@oracle.com> Thank you for your review! -Dan On 08/07/2013 12:08 PM, Remi Forax wrote: > On 08/07/2013 08:59 PM, Joe Darcy wrote: >> Amended version approved to go back. >> >> Thanks, >> >> -Joe > > As one of the guys involved in the design of this API :) > I'm Ok with this change. > > R?mi > >> >> On 08/07/2013 11:54 AM, Dan Xu wrote: >>> I see, Thanks! I have updated my changeto >>> http://cr.openjdk.java.net/~dxu/8022554/webrev1/. >>> >>> -Dan >>> >>> On 08/07/2013 11:46 AM, Joe Darcy wrote: >>>> Hi Dan, >>>> >>>> Even if the compiler does not complain, using "Class" or "Class[]" >>>> is using a raw type and raw types should generally be viewed as >>>> unacceptable in modern code. >>>> >>>> Cheers, >>>> >>>> -Joe >>>> >>>> On 08/07/2013 11:36 AM, Dan Xu wrote: >>>>> Thanks for your review! >>>>> >>>>> I was thinking of that. But without Class[] on the left, the >>>>> compiler just worked fine. >>>>> >>>>> Here is a simple example, >>>>> >>>>> //Main.java >>>>> >>>>> import java.util.*; >>>>> >>>>> public class Main { >>>>> public static final Class[] TEST_CLASS = new Class[16]; >>>>> public static final List[] TEST_MAP = new ArrayList[16]; >>>>> } >>>>> >>>>> After compiling with javac Xlint:all Main.java, no warnings are >>>>> printed out. Is it a compiler issue? Thanks! >>>>> >>>>> -Dan >>>>> >>>>> >>>>> >>>>> On 08/07/2013 11:11 AM, Joe Darcy wrote: >>>>>> I agree with Mike; Class[] should be used on both sides. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> -Joe >>>>>> >>>>>> On 08/07/2013 10:53 AM, Mike Duigou wrote: >>>>>>> Why not have Class[] on the left side as well? >>>>>>> >>>>>>> Mike >>>>>>> >>>>>>> On Aug 7 2013, at 10:49 , Dan Xu wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Please review the simple warning fix in >>>>>>>> src/share/classes/sun/invoke/anon/ConstantPoolPatch.java. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~dxu/8022554/webrev/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Dan >>>>>> >>>>> >>>> >>> >> > From dan.xu at oracle.com Wed Aug 7 19:13:55 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Wed, 07 Aug 2013 19:13:55 +0000 Subject: hg: jdk8/tl/jdk: 8022554: Fix Warnings in sun.invoke.anon Package Message-ID: <20130807191425.1EC9648690@hg.openjdk.java.net> Changeset: d1c82d5bee3f Author: dxu Date: 2013-08-07 12:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1c82d5bee3f 8022554: Fix Warnings in sun.invoke.anon Package Reviewed-by: darcy, mduigou, lancea ! src/share/classes/sun/invoke/anon/ConstantPoolPatch.java From mike.duigou at oracle.com Wed Aug 7 21:44:11 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 7 Aug 2013 14:44:11 -0700 Subject: RFR: 8015068 : (m) Use jtreg -exclude for problemlist.txt processing Message-ID: <145F648E-CDE7-4C36-8E4B-F56ED39C0C5E@oracle.com> Hello all; This changesest simplifies how the the jdk/test/Makefile processes excluded tests. Previously the test exclusions were pre-processed by scripts in the Makefile before being passed to JTReg. JTReg will now the all the processing. The change depends upon improvements in JTReg since the test exclude mechanism was originally defined. There are some changes in the reporting. Most obvious is that the excludelist.txt output file is no longer produced. The 'excluded' count in the summary report may be removed in a future reporting depending on whether the value can be calculated some other way. Additional to the exclusion list processing changes some other changes are possible as a result of the changes to exclusion processing. In particular the obsolete (and incorrect) logic for determining the build path included in the test/Makefile is now removed. If no output directory is provided via ALT_OUTPUTDIR then a default location in the current directory is used, "testoutput". At some point in the future this could be improved to get the CONF from the build configuration but that is not currently possible. Testing of this patch requires using a source build of JTReg as it requires one fix that is not in the promoted builds. http://cr.openjdk.java.net/~mduigou/JDK-8015068/0/webrev/ Mike From bhavesh.x.patel at oracle.com Wed Aug 7 22:01:33 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Wed, 07 Aug 2013 22:01:33 +0000 Subject: hg: jdk8/tl/langtools: 7198274: RFE : Javadoc Accessibility : Use CSS styles rather than or tags Message-ID: <20130807220139.563DB486A5@hg.openjdk.java.net> Changeset: 8c55df2442c1 Author: bpatel Date: 2013-08-07 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8c55df2442c1 7198274: RFE : Javadoc Accessibility : Use CSS styles rather than or tags Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java ! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java ! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java ! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethods.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java ! test/com/sun/javadoc/testPackageDeprecation/TestPackageDeprecation.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java From bhavesh.x.patel at oracle.com Wed Aug 7 23:09:51 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Wed, 07 Aug 2013 23:09:51 +0000 Subject: hg: jdk8/tl/langtools: 4749567: stddoclet: Add CSS style for setting header/footer to be italic Message-ID: <20130807230956.4B163486AA@hg.openjdk.java.net> Changeset: 33294f02c9a5 Author: bpatel Date: 2013-08-07 16:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/33294f02c9a5 4749567: stddoclet: Add CSS style for setting header/footer to be italic Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css + test/com/sun/javadoc/testOptions/TestOptions.java + test/com/sun/javadoc/testOptions/pkg/Foo.java From stuart.marks at oracle.com Wed Aug 7 23:33:00 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 07 Aug 2013 16:33:00 -0700 Subject: RFR: 8022479: clean up warnings from sun.tools.asm In-Reply-To: <52029864.10404@oracle.com> References: <5201E927.3030508@oracle.com> <52029864.10404@oracle.com> Message-ID: <5202D92C.7090703@oracle.com> Thanks for the reviews, guys. I think you meant, long term we should look to providing this functionality in some other way **and throw all of these packages into the trash!** :-) s'marks On 8/7/13 11:56 AM, Joe Darcy wrote: > Hi Stuart, > > I believe the code in its current state out in review is a good trade-off of > effort needed to address the warnings vs improvement in the quality of the code. > > Certainly the code would benefit from a larger cleanup, but I agree that is not > warranted at this point. Longer term, say for JDK 9, we should probably look to > providing this functionality in some other way. > > Approved to go back. > > Thanks, > > -Joe > > On 08/07/2013 10:01 AM, Lance Andersen - Oracle wrote: >> Hi Stuart, >> >> On the surface the changes look fine, including what you did for SwitchData. >> >> Certainly another pair of eyes would be good also on this. >> >> Best >> Lance >> On Aug 7, 2013, at 2:28 AM, Stuart Marks wrote: >> >>> Hi, >>> >>> Please review the fix for this warnings cleanup bug. >>> >>> Bug:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022479 >>> (not yet available publicly, but should be shortly) >>> >>> Webrev:http://cr.openjdk.java.net/~smarks/reviews/8022479/webrev.0/ >>> >>> There are a few items of note. >>> >>> This is *very* old code. You can see some of the authors' names in the code. It's replete with uses of Vector, Hashtable, and Enumeration. It also has a kind of musty style, which might have been reasonable from the standpoint of C programmers (which we all were at the time!). For example, there are a bunch of cases of direct field access to another class. There are also cases where a class contains a Vector that's returned by a getter method. I guess we just have to trust the caller not to modify it at the wrong time. >>> >>> I've confined most of my cleanups to the addition of generics (which gets rid of the rawtypes and unchecked warnings). There were a smattering of other warnings I've cleaned up as well. I've also replaced few cases of calls to "new" on boxed types like Integer and Long with calls to the respective valueOf() methods. I didn't check all the code for this, though, just instances I happened to run across. >>> >>> There is much more cleanup that could be done that I've elected not to do, such as replacing Vector, Hashtable, and Enumeration with ArrayList, HashMap, and Iterator, and using the enhanced-for loop. These changes would *probably* be safe, but they would require more analysis and testing than I'm willing to do at the moment. >>> >>> Two locations deserve a bit of scrutiny. >>> >>> 1) There are four occurrences in Assembler.java of calls to MemberDefinition.getArguments(). Unfortunately MemberDefinition resides in the sun.tools.java package and getArguments() returns a raw Vector. This is also overridden in a couple places spread across a couple sun.tools packages, and there are hints that it being a LocalMember or MemberDefinition. It seems out of scope to try to fix up the return value of getArguments() and its various overrides. >>> >>> Locally in the Assembler.java file, though, the contents of the returned vector are always cast to MemberDefinition, so it seems sensible to make an unchecked cast of the getArguments() return value to Vector and to suppress warnings at that point. Usage beyond those points within Assembler.java is filled with sweet and juicy generic goodness. >>> >>> 2) SwitchData.java contains a field whereCaseTab which is a Hashtable ... most of the time. In the addTableDefault() method, a value is put into the Hashtable under the key "default" -- a String. Ick. >>> >>> To deal with this I declared it as Hashtable since that's the typical case, and for the put(String, Long) case I cast through raw and suppressed the warning. The get() method already takes an Object so we're OK there. Note that "default" as a key for this Hashtable is used in a couple other places in Assembler.java. It's not intractable to change these to some other sentinel value, but, you know, where does one stop? >>> >>> (I said "Ick" when encountering a mix-type collection, and in a generified world we very rarely see this style anymore. Upon further reflection, though, from the standpoint of a pre-generics world, this is pretty sensible. Using a string as a sentinel key is guaranteed not to collide with any Integer keys. Sometimes it's possible to use -1 or Integer.MAX_VALUE as a sentinel, but if any integer value is permitted as a key, what does one do then?) >>> >>> With this changeset, sun.tools.asm is reduced from about 76 to zero warnings. >>> >>> Thanks, >>> >>> s'marks >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> > From brent.christian at oracle.com Wed Aug 7 23:40:08 2013 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 07 Aug 2013 16:40:08 -0700 Subject: Possible HashMap update In-Reply-To: <51D4ABDA.7010801@cs.oswego.edu> References: <51D4ABDA.7010801@cs.oswego.edu> Message-ID: <5202DAD8.9090303@oracle.com> Hi, Doug I like this approach. The subclassing used for nodes/entries and trees looks good, given the constraints. The before/after references that HashMap.TreeNode inherits from LinkedHashMap.Entry are superfluous when trees are used by a HashMap, but IMO we can live with that as trees in general are the uncommon case. And on the other hand, it's great that we can skip the instanceof check for put()/get() when the key is the first/only entry in a bin. "Untreeify" and MIN_TREEIFY_CAPACITY are nice additions. I patched jdk8/tl, and it tests out OK with the jdk_util jtreg tests. I'm in favor of moving forward with this. Thanks, -Brent On 7/3/13 3:55 PM, Doug Lea wrote: > > A few weeks ago, in the course of doing a (hopefully-last) reworking of > JDK8 ConcurrentHashMap (CHM) internals based on experience with > preview versions, I noticed that the balanced tree scheme now in place > as a fallback in the case of usages with many keys all with the same > hashCode could also be profitably used in other cases: CHM (like > HashMap) previously performed some bit-scrambling of user hashCodes to > make it less likely that user hashCodes that were non-identical but > highly-non-random will collide in the same bins (thus with O(n) vs the > expected O(1) performance). This bit-scrambling is an > anti-optimization in many usages that do not contain the kinds of > systematic hashCode bias that most hurt performance. While it is > reasonably fast, it still places computation where you do not > want it: in front of the likely cache-miss to access an entry. Plus, > bit-scrambling is only statistically likely to help. It is still > possible to encounter hashCodes that systematically collide. It would > be nice to provide O(log N) guarantees for these cases as well. > > So, CHM now omits bit-scrambling (well, almost -- just a single xor to > avoid losing impact of top bits), and instead rolls over into using > trees for bins that contain a statistically unlikely number of keys, > and rolling back into simple bin form if/when they don't due to > deletions or resizings. ("Statistically unlikely" is a surprisingly > low number. More than 8 nodes are expected only about once per ten > million under perfectly random keys; this is also often (depending on > cost of equals() methods, additional dispatch overhead, etc), around > the break-even point for using trees vs lists). The updated tree > mechanics now provide O(log N) worst-case performance in either of two > cases: (colliding non-identical-hashCodes), and (identical hashCodes > but mutually Comparable keys). And does so while also speeding up by a > little those typical usages that do not encounter systematic > collisions. Also, there is no sense at all in using any form of > hashSeed in this scheme. It basically behaves the same whether or not > you use one. > > The overall impact appears to be a net win. Non-heavily-colliding > cases are a bit faster. Some colliding cases are a little slower and > use more memory (tree-based nodes are bigger than plain ones), but > have much better worst (and typical) case bounds unless people use > crazily-bad keys that all have same hashCodes but are never equal or > comparable to others, in which case treeification is wasted effort > (but only by a constant factor of about 2 in both time and space). > > This seemed to be enough of an improvement in terms of both worst-case > and expected performance to try applying it to TreeBin-enabled > HashMap. So I gave it a try. To enable bidirectional tree<->plain node > conversion, I used the subclassing strategy mentioned during > discussion of the initial balanced tree version. This in turn requires > a completely different within-package internal API to allow > LinkedHashMap to continue to subclass HashMap. A couple of internal > constructions exist solely to allow the same source code to be > identical in HashMap and ConcurrenHashMap (but not the same compiled > code, since the types they operate on are and must be unrelated in the > two classes, and because they live in different packages, there's no > nice way to express their commonalities without exposing.) > > This note serves as a pre-proposal request for comment, as well a > request for anyone interested in trying it out, especially in any > weird/unusual use cases, to report experiences before seriously > considering it as a replacement. To simplify logistics, I checked in the > code in a workspace directory in jsr166: > > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/dl/java/util/HashMap.java?view=log > > > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/dl/java/util/LinkedHashMap.java?view=log > From kumar.x.srinivasan at oracle.com Thu Aug 8 00:25:08 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 07 Aug 2013 17:25:08 -0700 Subject: RFR: 8022547: [verifier] move DefaultMethodRegressionTests.java to jdk Message-ID: <5202E564.7020405@oracle.com> Hello, Testing this functionality in langtools does not seem to be the appropriate location, and the teams have decided to move it to jdk/test/vm/verifier, which seems to be the logical place. I have modified the test to remove testng dependencies, also added a variant which involves loading classes via an URLClassLoader which exposed a test bug wrt. the class.version.major not being correct, therefore it is useful to have this variant anyway. The webrev: http://cr.openjdk.java.net/~ksrini/8022547/webrev.0/ The bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022547 Thanks Kumar From ivan.gerasimov at oracle.com Thu Aug 8 00:46:59 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 08 Aug 2013 04:46:59 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods Message-ID: <5202EA83.70207@oracle.com> Hello everybody! Some methods of NetworkInterface class were reported to leak memory. http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet available.) Examples are isUp() and isLoopback(). Affected versions of jdk are 6, 7 and 8 Would you please review a simple fix that removes the unnecessary allocation? http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ Sincerely yours, Ivan From jonathan.gibbons at oracle.com Thu Aug 8 00:58:02 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 07 Aug 2013 17:58:02 -0700 Subject: Remove superfluous @test tags from SpliteratorTraversingAndSplittingTest Message-ID: <5202ED1A.8040104@oracle.com> Chris, > It might point to a bug in jtreg, or just "bad" jtreg meta-data. > > >: ls one > . .. HelloWorld.java > >: cat one/HelloWorld.java > /* > * @test > * @bug 8765432 > */ > > /* > * @test > */ > > public class HelloWorld { > public static void main(String[] args) { > System.out.println("Hello World."); > } > } This is a un-feature in jtreg. Strictly speaking, the jtreg Tag Spec only allows one test description per file, and so if you follow the spec, the situation you describe cannot arise. -- Jon From Alan.Bateman at oracle.com Thu Aug 8 01:05:10 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 07 Aug 2013 18:05:10 -0700 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5202EA83.70207@oracle.com> References: <5202EA83.70207@oracle.com> Message-ID: <5202EEC6.8050106@oracle.com> (cc'ing net-dev). The change looks okay to me. One suggestion (while you are there) is to check the return from GetStringUTFChars so that the name returns when it fails with NULL. -Alan. On 07/08/2013 17:46, Ivan Gerasimov wrote: > Hello everybody! > > Some methods of NetworkInterface class were reported to leak memory. > http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet available.) > > Examples are isUp() and isLoopback(). > > Affected versions of jdk are 6, 7 and 8 > > Would you please review a simple fix that removes the unnecessary > allocation? > http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ > > Sincerely yours, > Ivan From ivan.gerasimov at oracle.com Thu Aug 8 01:20:04 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 08 Aug 2013 05:20:04 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5202EEC6.8050106@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> Message-ID: <5202F244.6070006@oracle.com> Thanks Alan! I've checked that and it turns out that GetStringUTFChars cannot return NULL. For allocation of the result string it calls AllocateHeap() with the default EXIT_OOM fail strategy. Thus, in case of being unable to allocate memory it simply stops VM. Sincerely yours, Ivan On 08.08.2013 5:05, Alan Bateman wrote: > (cc'ing net-dev). > > The change looks okay to me. One suggestion (while you are there) is > to check the return from GetStringUTFChars so that the name returns > when it fails with NULL. > > -Alan. > > On 07/08/2013 17:46, Ivan Gerasimov wrote: >> Hello everybody! >> >> Some methods of NetworkInterface class were reported to leak memory. >> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet available.) >> >> Examples are isUp() and isLoopback(). >> >> Affected versions of jdk are 6, 7 and 8 >> >> Would you please review a simple fix that removes the unnecessary >> allocation? >> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >> >> Sincerely yours, >> Ivan > > > From Alan.Bateman at oracle.com Thu Aug 8 01:22:42 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 07 Aug 2013 18:22:42 -0700 Subject: RFR: 8015068 : (m) Use jtreg -exclude for problemlist.txt processing In-Reply-To: <145F648E-CDE7-4C36-8E4B-F56ED39C0C5E@oracle.com> References: <145F648E-CDE7-4C36-8E4B-F56ED39C0C5E@oracle.com> Message-ID: <5202F2E2.4000206@oracle.com> On 07/08/2013 14:44, Mike Duigou wrote: > Hello all; > > This changesest simplifies how the the jdk/test/Makefile processes excluded tests. Previously the test exclusions were pre-processed by scripts in the Makefile before being passed to JTReg. JTReg will now the all the processing. The change depends upon improvements in JTReg since the test exclude mechanism was originally defined. > > There are some changes in the reporting. Most obvious is that the excludelist.txt output file is no longer produced. The 'excluded' count in the summary report may be removed in a future reporting depending on whether the value can be calculated some other way. > > Additional to the exclusion list processing changes some other changes are possible as a result of the changes to exclusion processing. In particular the obsolete (and incorrect) logic for determining the build path included in the test/Makefile is now removed. If no output directory is provided via ALT_OUTPUTDIR then a default location in the current directory is used, "testoutput". At some point in the future this could be improved to get the CONF from the build configuration but that is not currently possible. > > Testing of this patch requires using a source build of JTReg as it requires one fix that is not in the promoted builds. > > http://cr.openjdk.java.net/~mduigou/JDK-8015068/0/webrev/ > > Mike It's good to see this logic going away. Also defaulting the output directory to TEST_ROOT (= pwd) is an improvement. One thing that isn't completely clear to be is the whether the multiple -exclude options work as advertised (because that hasn't worked for me in the past and I always ended cat'ing them as per the old make file logic). I assume you have tested with the Oracle jdk/test/closed repo present to verify this. -Alan From stuart.marks at oracle.com Wed Aug 7 23:25:51 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Wed, 07 Aug 2013 23:25:51 +0000 Subject: hg: jdk8/tl/jdk: 8022479: clean up warnings from sun.tools.asm Message-ID: <20130807232621.8D617486AD@hg.openjdk.java.net> Changeset: 8c50c27418d3 Author: smarks Date: 2013-08-07 16:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8c50c27418d3 8022479: clean up warnings from sun.tools.asm Reviewed-by: lancea, darcy ! src/share/classes/sun/tools/asm/Assembler.java ! src/share/classes/sun/tools/asm/ConstantPool.java ! src/share/classes/sun/tools/asm/Instruction.java ! src/share/classes/sun/tools/asm/SwitchData.java ! src/share/classes/sun/tools/asm/TryData.java From david.holmes at oracle.com Thu Aug 8 01:35:16 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 08 Aug 2013 11:35:16 +1000 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5202F244.6070006@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> Message-ID: <5202F5D4.7070806@oracle.com> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: > Thanks Alan! > > I've checked that and it turns out that GetStringUTFChars cannot return > NULL. > For allocation of the result string it calls AllocateHeap() with the > default EXIT_OOM fail strategy. > Thus, in case of being unable to allocate memory it simply stops VM. Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw OutOfMemoryError if it has memory issues, not abort the VM! I recommend that you check for NULL and/or a pending exception. David > Sincerely yours, > Ivan > > On 08.08.2013 5:05, Alan Bateman wrote: >> (cc'ing net-dev). >> >> The change looks okay to me. One suggestion (while you are there) is >> to check the return from GetStringUTFChars so that the name returns >> when it fails with NULL. >> >> -Alan. >> >> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>> Hello everybody! >>> >>> Some methods of NetworkInterface class were reported to leak memory. >>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet available.) >>> >>> Examples are isUp() and isLoopback(). >>> >>> Affected versions of jdk are 6, 7 and 8 >>> >>> Would you please review a simple fix that removes the unnecessary >>> allocation? >>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>> >>> Sincerely yours, >>> Ivan >> >> >> > From Alan.Bateman at oracle.com Thu Aug 8 01:38:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 07 Aug 2013 18:38:28 -0700 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5202F244.6070006@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> Message-ID: <5202F694.5080707@oracle.com> On 07/08/2013 18:20, Ivan Gerasimov wrote: > Thanks Alan! > > I've checked that and it turns out that GetStringUTFChars cannot > return NULL. > For allocation of the result string it calls AllocateHeap() with the > default EXIT_OOM fail strategy. > Thus, in case of being unable to allocate memory it simply stops VM. > GetStringUTFChars is supposed to return NULL in OOM situations so this may be a bug (but if you can, it would be good to handle it in the NetworkInterface code). -Alan From Alan.Bateman at oracle.com Thu Aug 8 02:04:18 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 07 Aug 2013 19:04:18 -0700 Subject: Deadlock in clinit for sun.nio.ch.Util/IOUtil In-Reply-To: References: <5201D94D.3000407@oracle.com> Message-ID: <5202FCA2.2060806@oracle.com> On 07/08/2013 09:56, Jeremy Manson wrote: > Thanks, Alan. Do please ping back when you've created the bug (I'm > not on nio-dev), because I'd like to track it (so we can remove our > workaround when the time comes). The bug is: 8022594: Potential deadlock in of sun.nio.ch.Util/IOUtil A webrev coming soon, I just want to ensure that the tests pass on all platforms. -Alan. From stuart.marks at oracle.com Thu Aug 8 02:10:07 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 07 Aug 2013 19:10:07 -0700 Subject: RFR 8021820: Number of opened files used in select() is limited to 1024 [macosx] In-Reply-To: <5202453F.2080409@oracle.com> References: <51F9007D.8090801@oracle.com> <51F9150B.4000008@oracle.com> <51F920A7.3000600@oracle.com> <51FF90BD.6070600@oracle.com> <52004DD9.4040202@oracle.com> <5202453F.2080409@oracle.com> Message-ID: <5202FDFF.1030906@oracle.com> Hi Aleksej, Thanks for the update. The situation is a bit twisted. I picked up a couple clues from David Holmes and Jon Gibbons. The NoClassDefFoundError occurs when the JVM has hit its resource limit for the number of open files, *and* it is being run in a development environment with individual class files in a hierarchy, e.g. within ROOT/build//jdk/classes In this case, since each class is in its own file, it's quite likely that the loading of an individual class will fail because of lack of file descriptors. If the JVM itself encounters this, it will generate a NoClassDefFoundError without a stack trace such as the ones we've seen. If the test is being run against a fully built JDK image, classes are loaded from rt.jar. This is usually already open, so quite often classes can be loaded without having to open additional files. In this case we get the FileNotFoundException as expected. The resource limits seem to vary from system to system, and even from one Ubuntu version to the next (mine has a default hard limit of 1024 open files). Unfortunately, while it might seem reasonable to have minimum specifications for systems on which we run tests, in practice this has proven very difficult. Since the bug being fixed is Mac-only, and the default open file limit for Mac seems to be unlimited, perhaps it makes most sense for this to be a Mac-only test. From the discussion here [1] which refers to an Apple technote [2] it seems like the best way to test for being on a Mac is something like this: if (! System.getProperty("os.name").contains("OS X")) { return; } That is, report success if we're on anything other than a Mac. Once we're sure we're on a Mac, having the test fail if it can't open enough files seems reasonable. I'd suggest putting a comment at the top of the test class saying that this test *must* be run in othervm mode, to ensure that files are closed properly. That way, you can take out the cleanupFiles() method too, as well as avoiding lots of exception handling and related cleanup code. Finally, a style point: try/catch statements are conventionally indented as a single multi-block, not as separate statements. I'd suggest something like this: // The accept() call will throw SocketException if the // select() has failed due to limitation on fds size, // indicating test failure. A SocketTimeoutException // is expected, so it is caught and ignored, and the test // passes. try { socket.accept(); } catch (SocketTimeoutException e) { } s'marks [1] http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-November/005148.html [2] https://developer.apple.com/library/mac/#technotes/tn2002/tn2110.html On 8/7/13 6:01 AM, Aleksej Efimov wrote: > Stuart, thank you for you comments, responses are below. > New webrev: > http://cr.openjdk.java.net/~aefimov/8021820/webrev.02/ > > > > -Aleksej > > On 08/06/2013 05:14 AM, Stuart Marks wrote: >> Hi Aleksej, >> >> Thanks for the update. I took a look at the revised test, and there are still >> some issues. (I didn't look at the build changes.) >> >> 1) System-specific resource limits. >> >> I think the biggest issue is resource limits on the number of open files per >> process that might vary from system to system. On my Ubuntu system, the hard >> limit on the number of open files is 1,024. The test opens 1,023 files and >> then one more for the socket. Unfortunately the JVM and jtreg have several >> files open already, and the test crashes before the openFiles() method >> completes. >> >> (Oddly it crashes with a NoClassDefFoundError from the main thread's uncaught >> exception handler, and then the test reports that it passed! Placing a >> try/catch of Throwable in main() or openFiles() doesn't catch this error. I >> have no explanation for this. When run standalone -- i.e., not from jtreg -- >> the test throws FileNotFoundException (too many open files) from openFiles(), >> which is expected.) >> >> On my Mac (10.7.5) the soft limit is 256 files, but the hard limit is >> unlimited. The test succeeds in opening all its files but fails because of >> the select() bug you're fixing. (This is expected; I didn't rebuild my JDK >> with your patch.) I guess the soft limit doesn't do anything on Mac. >> >> Amazingly, the test passed fine on both Windows XP and Windows 8. >> >> I'm not entirely sure what to do about resource limits. Since the test is >> able to open >1024 files on Mac, Windows, and possibly other Linuxes, it >> seems reasonable to continue with this approach. If it's possible to catch >> the error that occurs if the test cannot open its initial 1,024 files, >> perhaps it should do this, log a message indicating what happened, and >> consider the test to have passed. I'm mystified by the uncaught/uncatchable >> NoClassDefFoundError though. > I wonder if this is a question of test environment required for JTREG tests: if > we'll execute JTREG tests with low value assigned to fd hard limit (for example > 10) we'll see a lot of unrelated test failures. So, I suggest that we can > assume that there is no hard limits set (or at least default ones, i.e. default > fd limit on Ubuntu is 4096) on test machine. But we should consider test as > Failed if test failed to prepare it's environment because of some external > limitations. The JTREG doesn't meet this criteria (log test as PASS and prints > incorrect Exception). To illustrate it I have repeated your experiments on > ubuntu linux: set fd hard limit to 1024 (ulimit -Hn 1024) and got this error by > manual run of test: > Exception in thread "main" java.io.FileNotFoundException: testfile (Too many > open files) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(FileInputStream.java:128) > at SelectFdsLimit.openFiles(SelectFdsLimit.java:63) > at SelectFdsLimit.main(SelectFdsLimit.java:81) > > Seems correct to me. > An by JTREG (also with hard limit set to 1024): > ----------messages:(3/123)---------- > command: main SelectFdsLimit > reason: User specified action: run main/othervm SelectFdsLimit > elapsed time (seconds): 0.168 > ----------System.out:(0/0)---------- > ----------System.err:(5/250)---------- > > Exception: java.lang.NoClassDefFoundError thrown from the > UncaughtExceptionHandler in thread "MainThread" > STATUS:Passed. > Exception in thread "main" > Exception: java.lang.NoClassDefFoundError thrown from the > UncaughtExceptionHandler in thread "main" > result: Passed. Execution successful > > > test result: Passed. Execution successful > > > The results are identical to results mentioned by you. It seems to me that > jtreg doesn't correctly processes such test error (at least it shouldn't be > considered as Pass). And I suggest two ways of resolving it: > 1. If we don't have official limitations (or default) on what resources test > can use then we shouldn't do any modifications to test. > 2. If there is some limitations that we should honor then we'll need to figure > out what to do with NoClassDefFoundError exception in JTREG. > >> >> 2) Closing files. >> >> If an exception is thrown while opening the initial set of files, or sometime >> during the closing process, the test can still leak files. >> >> One approach would be to keep a data structure representing the current set >> of open files, and close them all in a finally-block around all the test >> logic, and making sure that exceptions from the close() call are caught and >> do not prevent the rest of the files from being closed. >> >> This seems like a lot of work. Perhaps a more effective approach would be to >> run the test in "othervm" mode, as follows: >> >> @run main/othervm SelectFdsLimit >> >> This will cause the test to run in a dedicated JVM, so all files will be >> closed automatically when it exits. (It would be good to add a comment >> explaining the need for othervm, if you do this.) >> > main/othervm and comments were added. >> 3) Port number for sockets. >> >> It's fairly common for tests to fail occasionally because they use some >> constant port number that sometimes happens to be in use at the same time by >> another process on the system. I have to say, 8080 is a pretty common port >> number. :-) >> >> For purposes of this test, you can let the system assign a port. Just use: >> >> new ServerSocket(0) >> > Completely agree that 8080 port - bad port for testing =). Changed to 0. >> 4) Style. >> >> It's probably possible to use the same File object for the test file, instead >> of creating new File objects repeatedly. > Agree and corrected. >> >> It might be nice to add a comment explaining the logic of the test, that >> SocketTimeoutException is expected, and that failure will be indicated if the >> accept() throws SocketException caused by the underlying mishandling of large >> fds by select(). > Comments were added. >> >> Thanks, >> >> s'marks >> >> >> >> On 8/5/13 4:47 AM, Aleksej Efimov wrote: >>> Alan, Tim, >>> >>> I have addressed your comments and as a result - new webrev: >>> http://cr.openjdk.java.net/~aefimov/8021820/webrev.01 >>> >>> The list of changes: >>> 1. The connection to Oracle site is removed (it's not internal, but anyway it's >>> better not to rely on availability of external resource in test). In current >>> version a server socket is created and accept() method is used for bug >>> disclosure. >>> 2. The cleanup method is added for closing file streams. The JTREG successfully >>> cleaned-up on windows after this modification. >>> 3. common/autoconf/toolchain.m4 untouched, but 'bash >>> common/autoconf/autogen.sh' was executed to update generated-configure.sh. >>> >>> Aleksej >>> >>> >>> On 07/31/2013 06:35 PM, Tim Bell wrote: >>>> Aleksej, Alan >>>> >>>> The change in common/autoconf/toolchain.m4 looks correct to me, and I think >>>> that is a good place to have it. Remember to run 'bash >>>> common/autoconf/autogen.sh' and check in the generated-configure.sh files as >>>> part of the changeset. >>>> >>>> I didn't look at the test case, but I think Alan has some good points. >>>> >>>> Tim >>>> >>>> On 07/31/13 06:45 AM, Alan Bateman wrote: >>>>> On 31/07/2013 05:18, Aleksej Efimov wrote: >>>>>> Hi, >>>>>> Can I have a review for the following problem: >>>>>> The MACOSX JDK (more precisely - the java.net classes) uses the select() >>>>>> system call to wait for different events on sockets fds. And the default >>>>>> behaviour for select() on Darwin is to fail when fdset contains the fd with >>>>>> id greater than FDSET_SIZE(=1024). Test case in webrev illustrates this >>>>>> behavior. >>>>>> There is at least one solution for it: use -D_DARWIN_UNLIMITED_SELECT >>>>>> compilation flag for all macosx sources: this won't affect other parts of >>>>>> JDK because they are not using select(). >>>>>> Currently, I have added this compilation flag to >>>>>> common/autoconf/generated-configure.sh and >>>>>> common/autoconf/generated-configure.sh. I wonder, if there is a better >>>>>> place where I can put this flag? >>>>>> >>>>>> The webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.00/ >>>>>> BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021820 >>>>> >>>>> Thanks for looking into this one. The build changes look okay to me but it's >>>>> probably best that someone on build-dev agree to those. >>>>> Michael McMahon can probably explain why the net code is using select for >>>>> timed read/accept (I have a vague recollection of there being an issue with >>>>> poll due to the way that it is implemented on kqueue with the result that it >>>>> had to be changed to use select). >>>>> >>>>> I think the test needs re-work. It looks to me that the it attempts to >>>>> connect to an Oracle internal site so that's not going to work everywhere. >>>>> In general we don't want the tests to be dependent on hosts that may or may >>>>> not exist (we had tests that used to this in the past but they caused a lot >>>>> of grief). It also looks like the test doesn't close the 1023 files that it >>>>> opens at the start and so I assume this test will always fail on Windows >>>>> when jtreg tries to clean-up. >>>>> >>>>> -Alan. >>>> >>> > From david.holmes at oracle.com Thu Aug 8 02:18:33 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 08 Aug 2013 12:18:33 +1000 Subject: RFR [6961766]: PrintStream.write() should flush at most once In-Reply-To: <520289B5.9080903@oracle.com> References: <52012698.4090005@oracle.com> <5201D65E.3090504@oracle.com> <52023B4D.3090001@oracle.com> <520289B5.9080903@oracle.com> Message-ID: <5202FFF9.8040203@oracle.com> Hi Ivan, On 8/08/2013 3:53 AM, Ivan Gerasimov wrote: > Hello David! > > Thanks for review. > >> Yes - this is NOT A BUG this is the spec for this class: >> >> "Optionally, a PrintStream can be created so as to flush >> automatically; this means that the flush method is automatically >> invoked after a byte array is written, one of the println methods is >> invoked, or a newline character or byte ('\n') is written. " >> > Sorry, I don't see how the proposed change would contradict the spec . > The code first writes a char[] buffer to an OutputStream, and then > invokes flush() if the written array contained at least one '\n' char. > > In addition to that, the documentation for OutputStream#flush() says: > "Flushes this output stream and forces any buffered output bytes to be > written out." Thus, there should be no point to have several subsequent > calls to flush() with no data writes between them. Sorry I misread the original code - it actually violates the spec as well in my opinion. As I read it there should be a flush as soon as the \n is written, not simply a flush at some later point in time if a \n happened to have been written. As written those additional flushes will be no-ops as you rightly point out. So your change is a more efficient version of the existing "incorrect" implementation. That said the layering of the streams in this class is quite confusing to me and it seems odd that if both textOut and charOut are unconditionally flushed in this method, then why is 'out' only flushed based on autoflush and the presence of the \n ?? But I withdraw my objections as what you propose does not change the behaviour. Thanks, David > I don't insist on pushing this change, but I think it's harmless and may > be useful. > > Sincerely yours, > Ivan > >> This bug report should be closed as "not an issue". >> >> David >> ----- >> >> >>> -Alan >> >> > From ivan.gerasimov at oracle.com Thu Aug 8 04:05:07 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 08 Aug 2013 08:05:07 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5202F5D4.7070806@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> Message-ID: <520318F3.7080609@oracle.com> David, Alan, I added checking for NULL results and throwing OOMException if necessary. I've also added some spaces along the code to improve indentation. Would you please review the updated webrev? http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ Sincerely yours, Ivan On 08.08.2013 5:35, David Holmes wrote: > On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >> Thanks Alan! >> >> I've checked that and it turns out that GetStringUTFChars cannot return >> NULL. >> For allocation of the result string it calls AllocateHeap() with the >> default EXIT_OOM fail strategy. >> Thus, in case of being unable to allocate memory it simply stops VM. > > Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw > OutOfMemoryError if it has memory issues, not abort the VM! > > I recommend that you check for NULL and/or a pending exception. > > David > >> Sincerely yours, >> Ivan >> >> On 08.08.2013 5:05, Alan Bateman wrote: >>> (cc'ing net-dev). >>> >>> The change looks okay to me. One suggestion (while you are there) is >>> to check the return from GetStringUTFChars so that the name returns >>> when it fails with NULL. >>> >>> -Alan. >>> >>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>> Hello everybody! >>>> >>>> Some methods of NetworkInterface class were reported to leak memory. >>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>> available.) >>>> >>>> Examples are isUp() and isLoopback(). >>>> >>>> Affected versions of jdk are 6, 7 and 8 >>>> >>>> Would you please review a simple fix that removes the unnecessary >>>> allocation? >>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>> >>>> Sincerely yours, >>>> Ivan >>> >>> >>> >> > > From mike.duigou at oracle.com Thu Aug 8 04:18:35 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 7 Aug 2013 21:18:35 -0700 Subject: RFR: 8015068 : (m) Use jtreg -exclude for problemlist.txt processing In-Reply-To: <5202F2E2.4000206@oracle.com> References: <145F648E-CDE7-4C36-8E4B-F56ED39C0C5E@oracle.com> <5202F2E2.4000206@oracle.com> Message-ID: <426F8FEE-F31A-43B9-90F9-5A7FDC8A8875@oracle.com> On 2013-08-07, at 18:22, Alan Bateman wrote: > On 07/08/2013 14:44, Mike Duigou wrote: >> Hello all; >> >> This changesest simplifies how the the jdk/test/Makefile processes excluded tests. Previously the test exclusions were pre-processed by scripts in the Makefile before being passed to JTReg. JTReg will now the all the processing. The change depends upon improvements in JTReg since the test exclude mechanism was originally defined. >> >> There are some changes in the reporting. Most obvious is that the excludelist.txt output file is no longer produced. The 'excluded' count in the summary report may be removed in a future reporting depending on whether the value can be calculated some other way. >> >> Additional to the exclusion list processing changes some other changes are possible as a result of the changes to exclusion processing. In particular the obsolete (and incorrect) logic for determining the build path included in the test/Makefile is now removed. If no output directory is provided via ALT_OUTPUTDIR then a default location in the current directory is used, "testoutput". At some point in the future this could be improved to get the CONF from the build configuration but that is not currently possible. >> >> Testing of this patch requires using a source build of JTReg as it requires one fix that is not in the promoted builds. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8015068/0/webrev/ >> >> Mike > It's good to see this logic going away. Also defaulting the output directory to TEST_ROOT (= pwd) is an improvement. > > One thing that isn't completely clear to be is the whether the multiple -exclude options work as advertised (because that hasn't worked for me in the past and I always ended cat'ing them as per the old make file logic). I assume you have tested with the Oracle jdk/test/closed repo present to verify this. > Yes. This is the fix that requires the updated jtreg. I won't push this change until jtreg is next promoted (b07) > -Alan > From masayoshi.okutsu at oracle.com Thu Aug 8 04:52:43 2013 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Thu, 08 Aug 2013 04:52:43 +0000 Subject: hg: jdk8/tl/jdk: 8015986: Incorrect Localization of HijrahChronology Message-ID: <20130808045318.043F3486C2@hg.openjdk.java.net> Changeset: 0beaa65c90c8 Author: okutsu Date: 2013-08-08 13:51 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0beaa65c90c8 8015986: Incorrect Localization of HijrahChronology Reviewed-by: naoto Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com ! make/tools/src/build/tools/cldrconverter/CLDRConverter.java ! make/tools/src/build/tools/cldrconverter/CalendarType.java ! src/share/classes/sun/text/resources/FormatData.java ! src/share/classes/sun/text/resources/ar/FormatData_ar.java ! test/java/time/test/java/time/format/TestNonIsoFormatter.java From david.holmes at oracle.com Thu Aug 8 05:01:25 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 08 Aug 2013 15:01:25 +1000 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <520318F3.7080609@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> Message-ID: <52032625.3000501@oracle.com> Ivan, On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: > David, Alan, > > I added checking for NULL results and throwing OOMException if necessary. You don't need to throw it yourself: JNU_ThrowOutOfMemoryError(env, NULL); Assuming a correct VM implementation if NULL is returned then an OOME should already be pending and will be thrown as soon as your native code returns to Java. Thanks, David > I've also added some spaces along the code to improve indentation. > > Would you please review the updated webrev? > http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ > > Sincerely yours, > Ivan > > > On 08.08.2013 5:35, David Holmes wrote: >> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>> Thanks Alan! >>> >>> I've checked that and it turns out that GetStringUTFChars cannot return >>> NULL. >>> For allocation of the result string it calls AllocateHeap() with the >>> default EXIT_OOM fail strategy. >>> Thus, in case of being unable to allocate memory it simply stops VM. >> >> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw >> OutOfMemoryError if it has memory issues, not abort the VM! >> >> I recommend that you check for NULL and/or a pending exception. >> >> David >> >>> Sincerely yours, >>> Ivan >>> >>> On 08.08.2013 5:05, Alan Bateman wrote: >>>> (cc'ing net-dev). >>>> >>>> The change looks okay to me. One suggestion (while you are there) is >>>> to check the return from GetStringUTFChars so that the name returns >>>> when it fails with NULL. >>>> >>>> -Alan. >>>> >>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>> Hello everybody! >>>>> >>>>> Some methods of NetworkInterface class were reported to leak memory. >>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>> available.) >>>>> >>>>> Examples are isUp() and isLoopback(). >>>>> >>>>> Affected versions of jdk are 6, 7 and 8 >>>>> >>>>> Would you please review a simple fix that removes the unnecessary >>>>> allocation? >>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>> >>>> >>>> >>> >> >> > From alexey.utkin at oracle.com Thu Aug 8 05:19:00 2013 From: alexey.utkin at oracle.com (alexey.utkin at oracle.com) Date: Thu, 08 Aug 2013 05:19:00 +0000 Subject: hg: jdk8/tl/jdk: 7147084: (process) appA hangs when read output stream of appB which starts appC that runs forever Message-ID: <20130808051923.3FFD6486C5@hg.openjdk.java.net> Changeset: 2c4f1081a0fa Author: uta Date: 2013-08-08 09:16 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c4f1081a0fa 7147084: (process) appA hangs when read output stream of appB which starts appC that runs forever Reviewed-by: alanb, robm, martin ! src/windows/classes/java/lang/ProcessImpl.java ! src/windows/native/java/lang/ProcessImpl_md.c + test/java/lang/ProcessBuilder/InheritIOEHandle.java + test/java/lang/ProcessBuilder/SiblingIOEHandle.java From paul.sandoz at oracle.com Thu Aug 8 07:10:01 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 8 Aug 2013 09:10:01 +0200 Subject: RFR JDK-8022442: Fix unchecked warnings in HashMap In-Reply-To: References: Message-ID: <5297CBB0-890F-40B7-ABF6-0E60CE32EDAA@oracle.com> On Aug 7, 2013, at 4:56 PM, Martin Buchholz wrote: > Doug is also working on HashMap, with experimental version in jsr166 CVS. > I think here: > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/dl/java/util/HashMap.java?view=co > Right. IMHO i think we should quickly commit this warnings patch then focus efforts on getting Doug's updates into tl, which will effectively overwrite many things. Paul. From jandam at crcdata.cz Thu Aug 8 07:20:01 2013 From: jandam at crcdata.cz (Janda Martin) Date: Thu, 8 Aug 2013 09:20:01 +0200 (CEST) Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52032625.3000501@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> Message-ID: <1010652992.175455.1375946401654.JavaMail.zimbra@crcdata.cz> Hello, are you planning backport to 7u40? I suppose that final version will have minimal impact to code with low probability of introducing regression. This leak is critical for my application because it is periodically scanning network interfaces and should run 24/7. Thank you Martin ----- Original Message ----- From: "David Holmes" To: "Ivan Gerasimov" Cc: "core-libs-dev" , "OpenJDK Network Dev list" Sent: Thursday, August 8, 2013 7:01:25 AM Subject: Re: RFR [8022584] Memory leak in some NetworkInterface methods Ivan, On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: > David, Alan, > > I added checking for NULL results and throwing OOMException if necessary. You don't need to throw it yourself: JNU_ThrowOutOfMemoryError(env, NULL); Assuming a correct VM implementation if NULL is returned then an OOME should already be pending and will be thrown as soon as your native code returns to Java. Thanks, David > I've also added some spaces along the code to improve indentation. > > Would you please review the updated webrev? > http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ > > Sincerely yours, > Ivan > > > On 08.08.2013 5:35, David Holmes wrote: >> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>> Thanks Alan! >>> >>> I've checked that and it turns out that GetStringUTFChars cannot return >>> NULL. >>> For allocation of the result string it calls AllocateHeap() with the >>> default EXIT_OOM fail strategy. >>> Thus, in case of being unable to allocate memory it simply stops VM. >> >> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw >> OutOfMemoryError if it has memory issues, not abort the VM! >> >> I recommend that you check for NULL and/or a pending exception. >> >> David >> >>> Sincerely yours, >>> Ivan >>> >>> On 08.08.2013 5:05, Alan Bateman wrote: >>>> (cc'ing net-dev). >>>> >>>> The change looks okay to me. One suggestion (while you are there) is >>>> to check the return from GetStringUTFChars so that the name returns >>>> when it fails with NULL. >>>> >>>> -Alan. >>>> >>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>> Hello everybody! >>>>> >>>>> Some methods of NetworkInterface class were reported to leak memory. >>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>> available.) >>>>> >>>>> Examples are isUp() and isLoopback(). >>>>> >>>>> Affected versions of jdk are 6, 7 and 8 >>>>> >>>>> Would you please review a simple fix that removes the unnecessary >>>>> allocation? >>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>> >>>> >>>> >>> >> >> > From chris.hegarty at oracle.com Thu Aug 8 08:43:04 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 08 Aug 2013 09:43:04 +0100 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52032625.3000501@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> Message-ID: <52035A18.8020803@oracle.com> Thanks for taking this Ivan. Can you please make the changes suggested by both David and Alan ( simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars fails ( returns NULL ), then I will sponsor this change into jdk8 for you. Please post an update webrev to cr.openjdk.java.net. -Chris. On 08/08/2013 06:01 AM, David Holmes wrote: > Ivan, > > On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >> David, Alan, >> >> I added checking for NULL results and throwing OOMException if >> necessary. > > You don't need to throw it yourself: > > JNU_ThrowOutOfMemoryError(env, NULL); > > Assuming a correct VM implementation if NULL is returned then an OOME > should already be pending and will be thrown as soon as your native code > returns to Java. > > Thanks, > David > >> I've also added some spaces along the code to improve indentation. >> >> Would you please review the updated webrev? >> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >> >> Sincerely yours, >> Ivan >> >> >> On 08.08.2013 5:35, David Holmes wrote: >>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>> Thanks Alan! >>>> >>>> I've checked that and it turns out that GetStringUTFChars cannot return >>>> NULL. >>>> For allocation of the result string it calls AllocateHeap() with the >>>> default EXIT_OOM fail strategy. >>>> Thus, in case of being unable to allocate memory it simply stops VM. >>> >>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw >>> OutOfMemoryError if it has memory issues, not abort the VM! >>> >>> I recommend that you check for NULL and/or a pending exception. >>> >>> David >>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>> (cc'ing net-dev). >>>>> >>>>> The change looks okay to me. One suggestion (while you are there) is >>>>> to check the return from GetStringUTFChars so that the name returns >>>>> when it fails with NULL. >>>>> >>>>> -Alan. >>>>> >>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>> Hello everybody! >>>>>> >>>>>> Some methods of NetworkInterface class were reported to leak memory. >>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>> available.) >>>>>> >>>>>> Examples are isUp() and isLoopback(). >>>>>> >>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>> >>>>>> Would you please review a simple fix that removes the unnecessary >>>>>> allocation? >>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>> >>>>> >>>>> >>>> >>> >>> >> From chris.hegarty at oracle.com Thu Aug 8 08:54:04 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 08 Aug 2013 09:54:04 +0100 Subject: RFR 8021820: Number of opened files used in select() is limited to 1024 [macosx] In-Reply-To: <5202FE3B.8040909@oracle.com> References: <51F9007D.8090801@oracle.com> <51F9150B.4000008@oracle.com> <51F920A7.3000600@oracle.com> <51FF90BD.6070600@oracle.com> <52004DD9.4040202@oracle.com> <5202453F.2080409@oracle.com> <5202FDFF.1030906@oracle.com> <5202FE3B.8040909@oracle.com> Message-ID: <52035CAC.5090000@oracle.com> On 08/08/2013 03:11 AM, Jonathan Gibbons wrote: > On 08/07/2013 07:10 PM, Stuart Marks wrote: >> I'd suggest putting a comment at the top of the test class saying that >> this test *must* be run in othervm mode, to ensure that files are >> closed properly. That way, you can take out the cleanupFiles() method >> too, as well as avoiding lots of exception handling and related >> cleanup code. > > Huh? What's wrong with > @run main/othervm classname I think what Stuart is suggesting is that '@run main/othervm classname' be added, but also an additional text comment explaining why this test is required to be run in othervm mode. During various test cleanup efforts over the years I've come across many tests that specify '@run main/othervm ...' without any obvious reason why. It is as if it was done (incorrectly) by certain engineers as a matter of style! Adding a small text comment can be helpful for future archaeologists ;-) In this particular case, if a reliable test can be created that runs only on Mac then that is fine. But if the test is not reliable, or hogs too much resources, then I think such a source change is ok without a test. -Chris. > > -- Jon From paul.sandoz at oracle.com Thu Aug 8 09:00:19 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 8 Aug 2013 11:00:19 +0200 Subject: RFR 8014824: Document Spliterator characteristics and binding policy of java util collection impls Message-ID: <1C62EB3E-11FF-484B-BC00-2DED97C33A8F@oracle.com> Hi, The following patch updates documentation for various spliterators: http://cr.openjdk.java.net/~psandoz/tl/JDK-8014824-split-docs/webrev/ Mostly this is just clarifying stuff that was missing, but there are a few cases of a spec change to Collections (CCC will be created): http://cr.openjdk.java.net/~psandoz/tl/JDK-8014824-split-docs/specdiff/overview-summary.html This is for the Collection.empty/singleton/nCopies relaxing the reporting of characteristics for spliterators containing 0 or 1 elements. It's more efficient to share code for empty and singleton spliterator implementations (and instance for the former) rather than attempting to conform the required characteristics of the collection, which will anyway have little or no benefit in terms of the client trying to optimize based on those characteristics. Paul. From paul.sandoz at oracle.com Thu Aug 8 09:03:08 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 8 Aug 2013 11:03:08 +0200 Subject: RFR 8022326: Spliterator for values of j.u.c.ConcurrentSkipListMap does not report ORDERED Message-ID: <169DC803-C67E-405B-92E5-7C92BABBCF03@oracle.com> Hi, The following patch fixes issues with the spliterators of ConcurrentSkipListMap: http://cr.openjdk.java.net/~psandoz/tl/JDK-8022326-CSLM-split/webrev/ Similar changes have already been made to TreeMap, which is also updated here to keep comments in sync. The changes to CSLM were taken directly from the 166 repo. Paul. From chris.hegarty at oracle.com Thu Aug 8 09:41:23 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 08 Aug 2013 10:41:23 +0100 Subject: RFR 8022326: Spliterator for values of j.u.c.ConcurrentSkipListMap does not report ORDERED In-Reply-To: <169DC803-C67E-405B-92E5-7C92BABBCF03@oracle.com> References: <169DC803-C67E-405B-92E5-7C92BABBCF03@oracle.com> Message-ID: <520367C3.3010408@oracle.com> Looks ok to me Paul. -Chris. On 08/08/2013 10:03 AM, Paul Sandoz wrote: > Hi, > > The following patch fixes issues with the spliterators of ConcurrentSkipListMap: > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8022326-CSLM-split/webrev/ > > Similar changes have already been made to TreeMap, which is also updated here to keep comments in sync. The changes to CSLM were taken directly from the 166 repo. > > Paul. > From chris.hegarty at oracle.com Thu Aug 8 09:59:18 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 08 Aug 2013 10:59:18 +0100 Subject: RFR 8014824: Document Spliterator characteristics and binding policy of java util collection impls In-Reply-To: <1C62EB3E-11FF-484B-BC00-2DED97C33A8F@oracle.com> References: <1C62EB3E-11FF-484B-BC00-2DED97C33A8F@oracle.com> Message-ID: <52036BF6.3050807@oracle.com> On 08/08/2013 10:00 AM, Paul Sandoz wrote: > Hi, > > The following patch updates documentation for various spliterators: > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8014824-split-docs/webrev/ > > Mostly this is just clarifying stuff that was missing, but there are a few cases of a spec change to Collections (CCC will be created): > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8014824-split-docs/specdiff/overview-summary.html > > This is for the Collection.empty/singleton/nCopies relaxing the reporting of characteristics for spliterators containing 0 or 1 elements. It's more efficient to share code for empty and singleton spliterator implementations (and instance for the former) rather than attempting to conform the required characteristics of the collection, which will anyway have little or no benefit in terms of the client trying to optimize based on those characteristics. I understand the reason for these spec clarifications, but it just doesn't feel right, to me, that we return Collections that do not obey their own specification, even if we explicitly spell it out. What is to stop others from doing the same? In which case a user can never depend on the specified characteristics being returned. -Chris. P.S. sorry if this has already been discussed, and agreed upon, elsewhere. > > Paul. > From paul.sandoz at oracle.com Thu Aug 8 10:19:09 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 8 Aug 2013 12:19:09 +0200 Subject: RFR 8014824: Document Spliterator characteristics and binding policy of java util collection impls In-Reply-To: <52036BF6.3050807@oracle.com> References: <1C62EB3E-11FF-484B-BC00-2DED97C33A8F@oracle.com> <52036BF6.3050807@oracle.com> Message-ID: <036F6A65-8192-4C70-876B-5F4A65C06DB7@oracle.com> On Aug 8, 2013, at 11:59 AM, Chris Hegarty wrote: > On 08/08/2013 10:00 AM, Paul Sandoz wrote: >> Hi, >> >> The following patch updates documentation for various spliterators: >> >> http://cr.openjdk.java.net/~psandoz/tl/JDK-8014824-split-docs/webrev/ >> >> Mostly this is just clarifying stuff that was missing, but there are a few cases of a spec change to Collections (CCC will be created): >> >> http://cr.openjdk.java.net/~psandoz/tl/JDK-8014824-split-docs/specdiff/overview-summary.html >> >> This is for the Collection.empty/singleton/nCopies relaxing the reporting of characteristics for spliterators containing 0 or 1 elements. It's more efficient to share code for empty and singleton spliterator implementations (and instance for the former) rather than attempting to conform the required characteristics of the collection, which will anyway have little or no benefit in terms of the client trying to optimize based on those characteristics. > > I understand the reason for these spec clarifications, but it just doesn't feel right, to me, that we return Collections that do not obey their own specification, even if we explicitly spell it out. > > What is to stop others from doing the same? In which case a user can never depend on the specified characteristics being returned. > You raise a good point, although we can never stop this, it is setting a poor example. We could state something like the following on Collection: * If the collection contains at most one element then the collections's spliterator is not * required to report characteristics specified * by the {@link java.util.Set#spliterator()}. Since the * spliterator covers at most one element such characteristics do not aid clients * to control, specialize or simplify computation. then perhaps it is not necessary to update the docs on Collections. Note that it is easy to come across empty spliterators in convoluted ways. See Collections.nCopies which defers to using range which returns an empty stream if the range is zero. > -Chris. > > P.S. sorry if this has already been discussed, and agreed upon, elsewhere. > As of now there has not been sufficient discussion on this. Paul. From forax at univ-mlv.fr Thu Aug 8 10:34:53 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 08 Aug 2013 12:34:53 +0200 Subject: RFR JDK-8022442: Fix unchecked warnings in HashMap In-Reply-To: <5297CBB0-890F-40B7-ABF6-0E60CE32EDAA@oracle.com> References: <5297CBB0-890F-40B7-ABF6-0E60CE32EDAA@oracle.com> Message-ID: <5203744D.10806@univ-mlv.fr> On 08/08/2013 09:10 AM, Paul Sandoz wrote: > On Aug 7, 2013, at 4:56 PM, Martin Buchholz wrote: > >> Doug is also working on HashMap, with experimental version in jsr166 CVS. >> I think here: >> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/dl/java/util/HashMap.java?view=co >> > Right. > > IMHO i think we should quickly commit this warnings patch then focus efforts on getting Doug's updates into tl, which will effectively overwrite many things. > > Paul. I've noticed that Doug's version doesn't have the patch from Igor Gerasimov that use Integer.highestOneBit to find the power of two. And that the iterators on entrySet, keySet and values doesn't have their method forEachRemaining overriden (unlike java.util.ArrayList). R?mi From peter.levart at gmail.com Thu Aug 8 10:44:51 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 08 Aug 2013 12:44:51 +0200 Subject: RFR 8014824: Document Spliterator characteristics and binding policy of java util collection impls In-Reply-To: <036F6A65-8192-4C70-876B-5F4A65C06DB7@oracle.com> References: <1C62EB3E-11FF-484B-BC00-2DED97C33A8F@oracle.com> <52036BF6.3050807@oracle.com> <036F6A65-8192-4C70-876B-5F4A65C06DB7@oracle.com> Message-ID: <520376A3.1020300@gmail.com> Hi Paul, Shouldn't Spliterators.EmptySpliterator also be IMMUTABLE, DISTINCT and ORDERED? Like Collections.singletonSpliterator... Although a mutable Collection implementation or immutable with size()>1 can never be Set and List at the same time, A singleton immutable Collection I think could be. Likewise for empty immutable Collection... So why couldn't a spliterator obtained from singleton List be DISTINCT? Likewise why couldn't a spliterator obtained from singleton Set be ORDERED?... These are runtime characteristics, not characteristics of a particular collection type. Regards, Peter On 08/08/2013 12:19 PM, Paul Sandoz wrote: > On Aug 8, 2013, at 11:59 AM, Chris Hegarty wrote: > >> On 08/08/2013 10:00 AM, Paul Sandoz wrote: >>> Hi, >>> >>> The following patch updates documentation for various spliterators: >>> >>> http://cr.openjdk.java.net/~psandoz/tl/JDK-8014824-split-docs/webrev/ >>> >>> Mostly this is just clarifying stuff that was missing, but there are a few cases of a spec change to Collections (CCC will be created): >>> >>> http://cr.openjdk.java.net/~psandoz/tl/JDK-8014824-split-docs/specdiff/overview-summary.html >>> >>> This is for the Collection.empty/singleton/nCopies relaxing the reporting of characteristics for spliterators containing 0 or 1 elements. It's more efficient to share code for empty and singleton spliterator implementations (and instance for the former) rather than attempting to conform the required characteristics of the collection, which will anyway have little or no benefit in terms of the client trying to optimize based on those characteristics. >> I understand the reason for these spec clarifications, but it just doesn't feel right, to me, that we return Collections that do not obey their own specification, even if we explicitly spell it out. >> >> What is to stop others from doing the same? In which case a user can never depend on the specified characteristics being returned. >> > You raise a good point, although we can never stop this, it is setting a poor example. > > We could state something like the following on Collection: > > * If the collection contains at most one element then the collections's spliterator is not > * required to report characteristics specified > * by the {@link java.util.Set#spliterator()}. Since the > * spliterator covers at most one element such characteristics do not aid clients > * to control, specialize or simplify computation. > > then perhaps it is not necessary to update the docs on Collections. > > Note that it is easy to come across empty spliterators in convoluted ways. See Collections.nCopies which defers to using range which returns an empty stream if the range is zero. > > >> -Chris. >> >> P.S. sorry if this has already been discussed, and agreed upon, elsewhere. >> > As of now there has not been sufficient discussion on this. > > Paul. From vicente.romero at oracle.com Thu Aug 8 10:49:52 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Thu, 08 Aug 2013 10:49:52 +0000 Subject: hg: jdk8/tl/langtools: 8019486: javac, generates erroneous LVT for a test case with lambda code Message-ID: <20130808105013.81177486D1@hg.openjdk.java.net> Changeset: b8610a65fbf9 Author: vromero Date: 2013-08-08 11:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b8610a65fbf9 8019486: javac, generates erroneous LVT for a test case with lambda code Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/T8019486/WrongLVTForLambdaTest.java From weijun.wang at oracle.com Thu Aug 8 13:13:28 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 08 Aug 2013 13:13:28 +0000 Subject: hg: jdk8/tl/jdk: 8016594: Native Windows ccache still reads DES tickets Message-ID: <20130808131448.9A66E486D9@hg.openjdk.java.net> Changeset: b7d594716f86 Author: weijun Date: 2013-08-08 21:13 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b7d594716f86 8016594: Native Windows ccache still reads DES tickets Reviewed-by: dsamersoff, xuelei ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/native/sun/security/krb5/nativeccache.c ! src/windows/native/sun/security/krb5/NativeCreds.c From ivan.gerasimov at oracle.com Thu Aug 8 13:33:34 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 08 Aug 2013 17:33:34 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52035A18.8020803@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> Message-ID: <52039E2E.6090504@oracle.com> Hello Chris! Here's the update: http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ Thanks for offering the sponsorship! Here's the hg-export http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch Sincerely yours, Ivan On 08.08.2013 12:43, Chris Hegarty wrote: > Thanks for taking this Ivan. > > Can you please make the changes suggested by both David and Alan ( > simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars > fails ( returns NULL ), then I will sponsor this change into jdk8 for > you. > > Please post an update webrev to cr.openjdk.java.net. > > -Chris. > > On 08/08/2013 06:01 AM, David Holmes wrote: >> Ivan, >> >> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>> David, Alan, >>> >>> I added checking for NULL results and throwing OOMException if >>> necessary. >> >> You don't need to throw it yourself: >> >> JNU_ThrowOutOfMemoryError(env, NULL); >> >> Assuming a correct VM implementation if NULL is returned then an OOME >> should already be pending and will be thrown as soon as your native code >> returns to Java. >> >> Thanks, >> David >> >>> I've also added some spaces along the code to improve indentation. >>> >>> Would you please review the updated webrev? >>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>> >>> Sincerely yours, >>> Ivan >>> >>> >>> On 08.08.2013 5:35, David Holmes wrote: >>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>> Thanks Alan! >>>>> >>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>> return >>>>> NULL. >>>>> For allocation of the result string it calls AllocateHeap() with the >>>>> default EXIT_OOM fail strategy. >>>>> Thus, in case of being unable to allocate memory it simply stops VM. >>>> >>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw >>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>> >>>> I recommend that you check for NULL and/or a pending exception. >>>> >>>> David >>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>> (cc'ing net-dev). >>>>>> >>>>>> The change looks okay to me. One suggestion (while you are there) is >>>>>> to check the return from GetStringUTFChars so that the name returns >>>>>> when it fails with NULL. >>>>>> >>>>>> -Alan. >>>>>> >>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>> Hello everybody! >>>>>>> >>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>> memory. >>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>> available.) >>>>>>> >>>>>>> Examples are isUp() and isLoopback(). >>>>>>> >>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>> >>>>>>> Would you please review a simple fix that removes the unnecessary >>>>>>> allocation? >>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> > > From ivan.gerasimov at oracle.com Thu Aug 8 13:39:55 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 08 Aug 2013 17:39:55 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52032625.3000501@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> Message-ID: <52039FAB.3040206@oracle.com> Thanks, David I've updated the webrev http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/. On 08.08.2013 9:01, David Holmes wrote: > Ivan, > > On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >> David, Alan, >> >> I added checking for NULL results and throwing OOMException if >> necessary. > > You don't need to throw it yourself: > > JNU_ThrowOutOfMemoryError(env, NULL); > > Assuming a correct VM implementation if NULL is returned then an OOME > should already be pending and will be thrown as soon as your native > code returns to Java. It seemed to me that, JNU_ThrowOutOfMemoryError only throws an exception in a case one is not pending. But I don't mind to remove it, relaying on the correct implementation of GetStringUTFChars. Sincerely yours, Ivan > Thanks, > David > >> I've also added some spaces along the code to improve indentation. >> >> Would you please review the updated webrev? >> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >> >> Sincerely yours, >> Ivan >> >> >> On 08.08.2013 5:35, David Holmes wrote: >>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>> Thanks Alan! >>>> >>>> I've checked that and it turns out that GetStringUTFChars cannot >>>> return >>>> NULL. >>>> For allocation of the result string it calls AllocateHeap() with the >>>> default EXIT_OOM fail strategy. >>>> Thus, in case of being unable to allocate memory it simply stops VM. >>> >>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw >>> OutOfMemoryError if it has memory issues, not abort the VM! >>> >>> I recommend that you check for NULL and/or a pending exception. >>> >>> David >>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>> (cc'ing net-dev). >>>>> >>>>> The change looks okay to me. One suggestion (while you are there) is >>>>> to check the return from GetStringUTFChars so that the name returns >>>>> when it fails with NULL. >>>>> >>>>> -Alan. >>>>> >>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>> Hello everybody! >>>>>> >>>>>> Some methods of NetworkInterface class were reported to leak memory. >>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>> available.) >>>>>> >>>>>> Examples are isUp() and isLoopback(). >>>>>> >>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>> >>>>>> Would you please review a simple fix that removes the unnecessary >>>>>> allocation? >>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>> >>>>> >>>>> >>>> >>> >>> >> > > From chris.hegarty at oracle.com Thu Aug 8 13:50:59 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 08 Aug 2013 14:50:59 +0100 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52039E2E.6090504@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> Message-ID: <5203A243.60505@oracle.com> Looks good to me. Thanks Ivan. -Chris. On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: > Hello Chris! > > Here's the update: > http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ > > Thanks for offering the sponsorship! > Here's the hg-export > http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch > > > Sincerely yours, > Ivan > > On 08.08.2013 12:43, Chris Hegarty wrote: >> Thanks for taking this Ivan. >> >> Can you please make the changes suggested by both David and Alan ( >> simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars >> fails ( returns NULL ), then I will sponsor this change into jdk8 for >> you. >> >> Please post an update webrev to cr.openjdk.java.net. >> >> -Chris. >> >> On 08/08/2013 06:01 AM, David Holmes wrote: >>> Ivan, >>> >>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>> David, Alan, >>>> >>>> I added checking for NULL results and throwing OOMException if >>>> necessary. >>> >>> You don't need to throw it yourself: >>> >>> JNU_ThrowOutOfMemoryError(env, NULL); >>> >>> Assuming a correct VM implementation if NULL is returned then an OOME >>> should already be pending and will be thrown as soon as your native code >>> returns to Java. >>> >>> Thanks, >>> David >>> >>>> I've also added some spaces along the code to improve indentation. >>>> >>>> Would you please review the updated webrev? >>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>> On 08.08.2013 5:35, David Holmes wrote: >>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>> Thanks Alan! >>>>>> >>>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>>> return >>>>>> NULL. >>>>>> For allocation of the result string it calls AllocateHeap() with the >>>>>> default EXIT_OOM fail strategy. >>>>>> Thus, in case of being unable to allocate memory it simply stops VM. >>>>> >>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw >>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>> >>>>> I recommend that you check for NULL and/or a pending exception. >>>>> >>>>> David >>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>> (cc'ing net-dev). >>>>>>> >>>>>>> The change looks okay to me. One suggestion (while you are there) is >>>>>>> to check the return from GetStringUTFChars so that the name returns >>>>>>> when it fails with NULL. >>>>>>> >>>>>>> -Alan. >>>>>>> >>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>> Hello everybody! >>>>>>>> >>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>> memory. >>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>> available.) >>>>>>>> >>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>> >>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>> >>>>>>>> Would you please review a simple fix that removes the unnecessary >>>>>>>> allocation? >>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >> >> > From sundararajan.athijegannathan at oracle.com Thu Aug 8 14:01:50 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 08 Aug 2013 14:01:50 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20130808140155.13604486DB@hg.openjdk.java.net> Changeset: 9a3e3bb30db3 Author: attila Date: 2013-08-07 16:38 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9a3e3bb30db3 8022509: Various Dynalink security enhancements Reviewed-by: jlaskey, hannesw ! src/jdk/internal/dynalink/ChainedCallSite.java ! src/jdk/internal/dynalink/DynamicLinkerFactory.java ! src/jdk/internal/dynalink/beans/ClassString.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java - src/jdk/internal/dynalink/support/Backport.java ! src/jdk/internal/dynalink/support/ClassMap.java ! src/jdk/internal/dynalink/support/Guards.java ! src/jdk/internal/dynalink/support/Lookup.java ! src/jdk/internal/dynalink/support/TypeConverterFactory.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java Changeset: dd79c04ef7df Author: sundar Date: 2013-08-08 16:38 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/dd79c04ef7df 8022524: Memory leaks in nashorn sources and tests found by jhat analysis Reviewed-by: attila, hannesw ! make/project.properties ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/ListAdapter.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! test/script/basic/JDK-8020357.js ! test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberBoxingTest.java ! test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java Changeset: 0d7484bf8597 Author: sundar Date: 2013-08-08 18:19 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0d7484bf8597 Merge - src/jdk/internal/dynalink/support/Backport.java From Alan.Bateman at oracle.com Thu Aug 8 15:27:20 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 08 Aug 2013 08:27:20 -0700 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52039FAB.3040206@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52039FAB.3040206@oracle.com> Message-ID: <5203B8D8.3090206@oracle.com> On 08/08/2013 06:39, Ivan Gerasimov wrote: > Thanks, David > > I've updated the webrev > http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/. Thanks for fixing the other GetStringUTFChars usages too. This version looks good to me. -Alan. From jonathan.gibbons at oracle.com Thu Aug 8 16:05:28 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 08 Aug 2013 09:05:28 -0700 Subject: RFR 8021820: Number of opened files used in select() is limited to 1024 [macosx] In-Reply-To: <52035CAC.5090000@oracle.com> References: <51F9007D.8090801@oracle.com> <51F9150B.4000008@oracle.com> <51F920A7.3000600@oracle.com> <51FF90BD.6070600@oracle.com> <52004DD9.4040202@oracle.com> <5202453F.2080409@oracle.com> <5202FDFF.1030906@oracle.com> <5202FE3B.8040909@oracle.com> <52035CAC.5090000@oracle.com> Message-ID: <5203C1C8.5090605@oracle.com> On 08/08/2013 01:54 AM, Chris Hegarty wrote: > On 08/08/2013 03:11 AM, Jonathan Gibbons wrote: >> On 08/07/2013 07:10 PM, Stuart Marks wrote: >>> I'd suggest putting a comment at the top of the test class saying that >>> this test *must* be run in othervm mode, to ensure that files are >>> closed properly. That way, you can take out the cleanupFiles() method >>> too, as well as avoiding lots of exception handling and related >>> cleanup code. >> >> Huh? What's wrong with >> @run main/othervm classname > > I think what Stuart is suggesting is that '@run main/othervm > classname' be added, but also an additional text comment explaining > why this test is required to be run in othervm mode. > > During various test cleanup efforts over the years I've come across > many tests that specify '@run main/othervm ...' without any obvious > reason why. It is as if it was done (incorrectly) by certain engineers > as a matter of style! Adding a small text comment can be helpful for > future archaeologists ;-) > > In this particular case, if a reliable test can be created that runs > only on Mac then that is fine. But if the test is not reliable, or > hogs too much resources, then I think such a source change is ok > without a test. > > -Chris. > >> >> -- Jon Yes, I agree with you and Stuart that comments explaining the use of "@run main/othervm" would be a good idea. Sorry for the confusion. -- jon From jonathan.gibbons at oracle.com Thu Aug 8 16:22:09 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 08 Aug 2013 09:22:09 -0700 Subject: RFR: 8015068 : (m) Use jtreg -exclude for problemlist.txt processing In-Reply-To: <5203C3C7.80503@oracle.com> References: <145F648E-CDE7-4C36-8E4B-F56ED39C0C5E@oracle.com> <5202F2E2.4000206@oracle.com> <5202F803.2050402@oracle.com> <52030383.5010203@oracle.com> <520314EF.2080200@oracle.com> <4E3B1671-55BC-4A76-8980-BE3E30B1FABD@oracle.com> <5203C0EE.3040804@oracle.com> <5203C3C7.80503@oracle.com> Message-ID: <5203C5B1.6080701@oracle.com> On 08/08/2013 09:13 AM, Chris Hegarty wrote: > > So we need a b07 of jtreg before we can proceed with this? > > -Chris. General question to all: How much will fall over if we call it 4.2? -- Jon From mike.duigou at oracle.com Thu Aug 8 16:36:14 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 8 Aug 2013 09:36:14 -0700 Subject: RFR: 8015068 : (m) Use jtreg -exclude for problemlist.txt processing In-Reply-To: <5203C5B1.6080701@oracle.com> References: <145F648E-CDE7-4C36-8E4B-F56ED39C0C5E@oracle.com> <5202F2E2.4000206@oracle.com> <5202F803.2050402@oracle.com> <52030383.5010203@oracle.com> <520314EF.2080200@oracle.com> <4E3B1671-55BC-4A76-8980-BE3E30B1FABD@oracle.com> <5203C0EE.3040804@oracle.com> <5203C3C7.80503@oracle.com> <5203C5B1.6080701@oracle.com> Message-ID: On 2013-08-08, at 9:22, Jonathan Gibbons wrote: > On 08/08/2013 09:13 AM, Chris Hegarty wrote: >> >> So we need a b07 of jtreg before we can proceed with this? >> >> -Chris. > > General question to all: > > How much will fall over if we call it 4.2? Some of the build scripts and makefies use 4.1 in SLASH_JAVA relative paths for default location. If we move to 4.2 it would be nice to add a current -> 4.2 link so that we don't have to fix it again ie scripts would use "current" rather than "4.2" > -- Jon From ivan.gerasimov at oracle.com Thu Aug 8 18:17:57 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 08 Aug 2013 22:17:57 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5203A257.7000803@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52039FAB.3040206@oracle.com> <5203A257.7000803@oracle.com> Message-ID: <5203E0D5.8000308@oracle.com> Thank you Michael! I'm working on the test. Chris, if it's not too late, I would like to include a regtest into the change. It will be ready in a few minutes and I'll send an updated webrev. Thanks, Ivan On 08.08.2013 17:51, Michael McMahon wrote: > The patch looks good to me. I guess a regression test isn't feasible. > So, the bug will be tagged noreg-hard > > Michael > > On 08/08/13 14:39, Ivan Gerasimov wrote: >> Thanks, David >> >> I've updated the webrev >> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/. >> >> On 08.08.2013 9:01, David Holmes wrote: >>> Ivan, >>> >>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>> David, Alan, >>>> >>>> I added checking for NULL results and throwing OOMException if >>>> necessary. >>> >>> You don't need to throw it yourself: >>> >>> JNU_ThrowOutOfMemoryError(env, NULL); >>> >>> Assuming a correct VM implementation if NULL is returned then an >>> OOME should already be pending and will be thrown as soon as your >>> native code returns to Java. >> >> It seemed to me that, JNU_ThrowOutOfMemoryError only throws an >> exception in a case one is not pending. >> But I don't mind to remove it, relaying on the correct implementation >> of GetStringUTFChars. >> >> Sincerely yours, >> Ivan >> >>> Thanks, >>> David >>> >>>> I've also added some spaces along the code to improve indentation. >>>> >>>> Would you please review the updated webrev? >>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>> On 08.08.2013 5:35, David Holmes wrote: >>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>> Thanks Alan! >>>>>> >>>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>>> return >>>>>> NULL. >>>>>> For allocation of the result string it calls AllocateHeap() with the >>>>>> default EXIT_OOM fail strategy. >>>>>> Thus, in case of being unable to allocate memory it simply stops VM. >>>>> >>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw >>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>> >>>>> I recommend that you check for NULL and/or a pending exception. >>>>> >>>>> David >>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>> (cc'ing net-dev). >>>>>>> >>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>> there) is >>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>> returns >>>>>>> when it fails with NULL. >>>>>>> >>>>>>> -Alan. >>>>>>> >>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>> Hello everybody! >>>>>>>> >>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>> memory. >>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>> available.) >>>>>>>> >>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>> >>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>> >>>>>>>> Would you please review a simple fix that removes the unnecessary >>>>>>>> allocation? >>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > > From ivan.gerasimov at oracle.com Thu Aug 8 18:41:06 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 08 Aug 2013 22:41:06 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5203A243.60505@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> Message-ID: <5203E642.40005@oracle.com> Chris, if it's not too late, I'd like to include a regtest in the fix. Here's webrev that includes the test: http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ The test gets past with the fixed jdk8 and fails with jdk8-b101 and jdk7 as expected. Sincerely yours, Ivan On 08.08.2013 17:50, Chris Hegarty wrote: > Looks good to me. Thanks Ivan. > > -Chris. > > On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >> Hello Chris! >> >> Here's the update: >> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >> >> Thanks for offering the sponsorship! >> Here's the hg-export >> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >> >> >> >> Sincerely yours, >> Ivan >> >> On 08.08.2013 12:43, Chris Hegarty wrote: >>> Thanks for taking this Ivan. >>> >>> Can you please make the changes suggested by both David and Alan ( >>> simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars >>> fails ( returns NULL ), then I will sponsor this change into jdk8 for >>> you. >>> >>> Please post an update webrev to cr.openjdk.java.net. >>> >>> -Chris. >>> >>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>> Ivan, >>>> >>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>> David, Alan, >>>>> >>>>> I added checking for NULL results and throwing OOMException if >>>>> necessary. >>>> >>>> You don't need to throw it yourself: >>>> >>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>> >>>> Assuming a correct VM implementation if NULL is returned then an OOME >>>> should already be pending and will be thrown as soon as your native >>>> code >>>> returns to Java. >>>> >>>> Thanks, >>>> David >>>> >>>>> I've also added some spaces along the code to improve indentation. >>>>> >>>>> Would you please review the updated webrev? >>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> >>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>> Thanks Alan! >>>>>>> >>>>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>>>> return >>>>>>> NULL. >>>>>>> For allocation of the result string it calls AllocateHeap() with >>>>>>> the >>>>>>> default EXIT_OOM fail strategy. >>>>>>> Thus, in case of being unable to allocate memory it simply stops >>>>>>> VM. >>>>>> >>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw >>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>> >>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>> >>>>>> David >>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>> (cc'ing net-dev). >>>>>>>> >>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>> there) is >>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>> returns >>>>>>>> when it fails with NULL. >>>>>>>> >>>>>>>> -Alan. >>>>>>>> >>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>> Hello everybody! >>>>>>>>> >>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>> memory. >>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>> available.) >>>>>>>>> >>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>> >>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>> >>>>>>>>> Would you please review a simple fix that removes the unnecessary >>>>>>>>> allocation? >>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>> >>> >> > > From joe.darcy at oracle.com Thu Aug 8 18:55:20 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 08 Aug 2013 11:55:20 -0700 Subject: FunctionalInterface as a rule in the matching interfaces ? In-Reply-To: References: Message-ID: <5203E998.5010002@oracle.com> Hello, On 8/1/2013 5:28 AM, Jean-Baptiste Bugeaud wrote: > Hello, > > As a follow-up from Joe Darcy's proposal (2013-02-06) to add > @FunctionalInterface to some interfaces matching the requirements of > FI. > > I propose that this improvement is applied to all the VM Java libs. > > Doing a quick search, I've found some interfaces are not tagged as > FunctionaInterfaces but clearly look good candidates : > > Here is the list of public API I have found so far : > > java.security.PriviledgeAction > java.awt.event.ActionListener > java.lang.util.concurrent.Callable > java.util.Formattable > javax.management.remote.JMXAddressable > javax.naming.Referenceable > java.awt.print.Printable I found the candidate interfaces by running an annotation processor over the JDK codebase: "Functional Interfaces" https://blogs.oracle.com/darcy/entry/functional_interfaces A bug was filed for analogous API review in the swing area: JDK-8007716 Add FunctionalInterface annotation to swing interfaces and other client teams were contacted as well (2D team on Feb. 8, etc.), but that work has not been done yet. Thanks for the reminder. The general guidance given at the time was: > To a first approximation, if a candidate type today is commonly > created using anonymous inner classes, it is reasonable to add the > functionalInterface annotation. Note that the compiler will allow any > type meeting the structural requirements of a functional interface to > be used in a lambda expression; the annotation just provides > documentation of intent. There are also a few core libs are interfaces where we may want to re-examine if @FI is really needed. Thanks, -Joe From xueming.shen at oracle.com Thu Aug 8 19:00:49 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 08 Aug 2013 19:00:49 +0000 Subject: hg: jdk8/tl/jdk: 8015666: test/tools/pack200/TimeStamp.java failing Message-ID: <20130808190152.9A34248707@hg.openjdk.java.net> Changeset: a388263a7287 Author: sherman Date: 2013-08-08 12:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a388263a7287 8015666: test/tools/pack200/TimeStamp.java failing Summary: to keep the default behavior of ZOS unchanged, if ze extra time not explicitly set Reviewed-by: alanb, ksrini ! src/share/classes/java/util/zip/ZipConstants.java ! src/share/classes/java/util/zip/ZipEntry.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/java/util/zip/ZipInputStream.java ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/classes/java/util/zip/ZipUtils.java ! test/ProblemList.txt ! test/java/util/zip/TestExtraTime.java ! test/tools/pack200/TimeStamp.java From xueming.shen at oracle.com Thu Aug 8 19:19:31 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 08 Aug 2013 12:19:31 -0700 Subject: RFR: 6614237: missing codepage Cp290 at java runtime In-Reply-To: <51FF355F.6050005@oracle.com> References: <51FC1C66.8000108@oracle.com> <51FF355F.6050005@oracle.com> Message-ID: <5203EF43.2030000@oracle.com> Thanks Masayoshi, good catch, yes, those two aliases should be included. Webrev has been updated according. webrev: http://cr.openjdk.java.net/~sherman/6614237/webrev/ -Sherman On 08/04/2013 10:17 PM, Masayoshi Okutsu wrote: > Hi Sherman, > > IANA seems to define the following aliases for IBM290. > > cp290 > EBCDIC-JP-kana > csIBM290 > > The alias table should include EBCDIC-JP-kana and csIBM290 as well? > > Otherwise, the changes look good to me. > > Thanks, > Masayoshi > > On 8/3/2013 5:53 AM, Xueming Shen wrote: >> Masayoshi, >> >> Would you please help review this change? The changeset also adds the requested Cp300. >> >> webrev: >> http://cr.openjdk.java.net/~sherman/6614237/webrev/ >> >> original mapptables: >> http://cr.openjdk.java.net/~sherman/6614237/290/ >> http://cr.openjdk.java.net/~sherman/6614237/300/ >> >> regression tests: >> http://cr.openjdk.java.net/~sherman/6614237/closed >> >> Thanks! >> -Sherman >> > From dan.xu at oracle.com Thu Aug 8 20:44:19 2013 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 08 Aug 2013 13:44:19 -0700 Subject: RFR: JDK-4858457 -- File.getCanonicalPath() throws IOException when invoked with "nul" (win) Message-ID: <52040323.3040505@oracle.com> Hi All, Windows platforms have reserved a few names for device usages, and "nul" is one of them. And Windows API, such as _wfullpath() and GetFullPathNameW, returns its full path with the prefix "\\.\", which represents win32 device namespaces. For example, "nul", whose full path name is "\\.\nul", is a valid device name. But our current Canonicalization logicfails to generate its canonicalpath and throws an IOException. This fix is going to address the problem. Thanks! Webrev: http://cr.openjdk.java.net/~dxu/4858457/webrev.00/ Bug: http://bugs.sun.com/view_bug.do?bug_id=4858457 -Dan From david.holmes at oracle.com Thu Aug 8 21:15:34 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 09 Aug 2013 07:15:34 +1000 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5203E642.40005@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> Message-ID: <52040A76.3060602@oracle.com> Main fix looks good to me. Regression test may need some tweaking eg I think othervm will be needed. Also this: System.out.println("WARNING: Cannot perform memory leak detection on this OS"); should probably just say something like "Test skipped on this OS" - there are other tests that do this so just check if there is common terminology. (In the future we may have keyword tags to flag this as linux only etc.) Thanks, David On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: > Chris, if it's not too late, I'd like to include a regtest in the fix. > > Here's webrev that includes the test: > http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ > > The test gets past with the fixed jdk8 and fails with jdk8-b101 and jdk7 > as expected. > > Sincerely yours, > Ivan > > On 08.08.2013 17:50, Chris Hegarty wrote: >> Looks good to me. Thanks Ivan. >> >> -Chris. >> >> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>> Hello Chris! >>> >>> Here's the update: >>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>> >>> Thanks for offering the sponsorship! >>> Here's the hg-export >>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>> >>> >>> >>> Sincerely yours, >>> Ivan >>> >>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>> Thanks for taking this Ivan. >>>> >>>> Can you please make the changes suggested by both David and Alan ( >>>> simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars >>>> fails ( returns NULL ), then I will sponsor this change into jdk8 for >>>> you. >>>> >>>> Please post an update webrev to cr.openjdk.java.net. >>>> >>>> -Chris. >>>> >>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>> Ivan, >>>>> >>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>> David, Alan, >>>>>> >>>>>> I added checking for NULL results and throwing OOMException if >>>>>> necessary. >>>>> >>>>> You don't need to throw it yourself: >>>>> >>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>> >>>>> Assuming a correct VM implementation if NULL is returned then an OOME >>>>> should already be pending and will be thrown as soon as your native >>>>> code >>>>> returns to Java. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> I've also added some spaces along the code to improve indentation. >>>>>> >>>>>> Would you please review the updated webrev? >>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> >>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>> Thanks Alan! >>>>>>>> >>>>>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>>>>> return >>>>>>>> NULL. >>>>>>>> For allocation of the result string it calls AllocateHeap() with >>>>>>>> the >>>>>>>> default EXIT_OOM fail strategy. >>>>>>>> Thus, in case of being unable to allocate memory it simply stops >>>>>>>> VM. >>>>>>> >>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw >>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>> >>>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>>> >>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>> (cc'ing net-dev). >>>>>>>>> >>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>> there) is >>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>> returns >>>>>>>>> when it fails with NULL. >>>>>>>>> >>>>>>>>> -Alan. >>>>>>>>> >>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>> Hello everybody! >>>>>>>>>> >>>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>>> memory. >>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>> available.) >>>>>>>>>> >>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>> >>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>> >>>>>>>>>> Would you please review a simple fix that removes the unnecessary >>>>>>>>>> allocation? >>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>>> >>> >> >> > From xueming.shen at oracle.com Thu Aug 8 21:53:03 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 08 Aug 2013 14:53:03 -0700 Subject: Code review request: 8021788: JarInputStream doesn't provide certificates for some file under META-INF In-Reply-To: <51FEFFB1.2040506@oracle.com> References: <51FEFFB1.2040506@oracle.com> Message-ID: <5204133F.3040806@oracle.com> Looks fine. -Sherman On 08/04/2013 06:28 PM, Weijun Wang wrote: > Please take a look at > > http://cr.openjdk.java.net/~weijun/8021788/webrev.00/ > > The problem is that the method treats no META-INF entry as normal. If we can be sure that MANIFEST.MF and signature-related files are always at the beginning, we can safely treat an entry normal when we have done with those. > > Thanks > Max From ivan.gerasimov at oracle.com Thu Aug 8 22:15:49 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 09 Aug 2013 02:15:49 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52040FDA.2040600@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52040FDA.2040600@oracle.com> Message-ID: <52041895.9010706@oracle.com> Michael, The test uses /proc/self/stat file to detect changes in virtual memory usage. This approach is specific for Linux. That's why I included the check of OS in the test. Sincerely yours, Ivan On 09.08.2013 1:38, Michael McMahon wrote: > Yes, definitely "othervm" would be required for the test. Also, why > skip other OS'es? > The fix is only for Linux, but it might catch future leaks on Windows. > > The trouble with tests like this, is they sometimes don't age well. > Future changes in OS kernel behavior could cause problems but I guess > 32MB is a fairly large difference. > So, it should be okay > > Michael > > On 08/08/13 22:15, David Holmes wrote: >> Main fix looks good to me. >> >> Regression test may need some tweaking eg I think othervm will be >> needed. >> >> Also this: >> >> System.out.println("WARNING: Cannot perform memory leak detection on >> this OS"); >> >> should probably just say something like "Test skipped on this OS" - >> there are other tests that do this so just check if there is common >> terminology. (In the future we may have keyword tags to flag this as >> linux only etc.) >> >> Thanks, >> David >> >> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>> Chris, if it's not too late, I'd like to include a regtest in the fix. >>> >>> Here's webrev that includes the test: >>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>> >>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and >>> jdk7 >>> as expected. >>> >>> Sincerely yours, >>> Ivan >>> >>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>> Looks good to me. Thanks Ivan. >>>> >>>> -Chris. >>>> >>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>> Hello Chris! >>>>> >>>>> Here's the update: >>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>> >>>>> Thanks for offering the sponsorship! >>>>> Here's the hg-export >>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>> >>>>> >>>>> >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>> Thanks for taking this Ivan. >>>>>> >>>>>> Can you please make the changes suggested by both David and Alan ( >>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>> GetStringUTFChars >>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8 >>>>>> for >>>>>> you. >>>>>> >>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>> >>>>>> -Chris. >>>>>> >>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>> Ivan, >>>>>>> >>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>> David, Alan, >>>>>>>> >>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>> necessary. >>>>>>> >>>>>>> You don't need to throw it yourself: >>>>>>> >>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>> >>>>>>> Assuming a correct VM implementation if NULL is returned then an >>>>>>> OOME >>>>>>> should already be pending and will be thrown as soon as your native >>>>>>> code >>>>>>> returns to Java. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> I've also added some spaces along the code to improve indentation. >>>>>>>> >>>>>>>> Would you please review the updated webrev? >>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>>> >>>>>>>> >>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>> Thanks Alan! >>>>>>>>>> >>>>>>>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>>>>>>> return >>>>>>>>>> NULL. >>>>>>>>>> For allocation of the result string it calls AllocateHeap() with >>>>>>>>>> the >>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>> Thus, in case of being unable to allocate memory it simply stops >>>>>>>>>> VM. >>>>>>>>> >>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to >>>>>>>>> throw >>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>> >>>>>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>> >>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>> there) is >>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>> returns >>>>>>>>>>> when it fails with NULL. >>>>>>>>>>> >>>>>>>>>>> -Alan. >>>>>>>>>>> >>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>> Hello everybody! >>>>>>>>>>>> >>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>>>>> memory. >>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>>> available.) >>>>>>>>>>>> >>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>> >>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>> >>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>> unnecessary >>>>>>>>>>>> allocation? >>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>> Ivan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> > > > From michael.x.mcmahon at oracle.com Thu Aug 8 22:19:17 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 08 Aug 2013 23:19:17 +0100 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52041895.9010706@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52040FDA.2040600@oracle.com> <52041895.9010706@oracle.com> Message-ID: <52041965.3090808@oracle.com> Ivan, Right, it's not worth trying to do the equivalent, whatever it is, for Windows. The test is fine with me. Thanks Michael On 08/08/13 23:15, Ivan Gerasimov wrote: > Michael, > > The test uses /proc/self/stat file to detect changes in virtual memory > usage. > This approach is specific for Linux. > That's why I included the check of OS in the test. > > Sincerely yours, > Ivan > > On 09.08.2013 1:38, Michael McMahon wrote: >> Yes, definitely "othervm" would be required for the test. Also, why >> skip other OS'es? >> The fix is only for Linux, but it might catch future leaks on Windows. >> >> The trouble with tests like this, is they sometimes don't age well. >> Future changes in OS kernel behavior could cause problems but I guess >> 32MB is a fairly large difference. >> So, it should be okay >> >> Michael >> >> On 08/08/13 22:15, David Holmes wrote: >>> Main fix looks good to me. >>> >>> Regression test may need some tweaking eg I think othervm will be >>> needed. >>> >>> Also this: >>> >>> System.out.println("WARNING: Cannot perform memory leak detection >>> on this OS"); >>> >>> should probably just say something like "Test skipped on this OS" - >>> there are other tests that do this so just check if there is common >>> terminology. (In the future we may have keyword tags to flag this as >>> linux only etc.) >>> >>> Thanks, >>> David >>> >>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>> Chris, if it's not too late, I'd like to include a regtest in the fix. >>>> >>>> Here's webrev that includes the test: >>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>> >>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and >>>> jdk7 >>>> as expected. >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>> Looks good to me. Thanks Ivan. >>>>> >>>>> -Chris. >>>>> >>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>> Hello Chris! >>>>>> >>>>>> Here's the update: >>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>> >>>>>> Thanks for offering the sponsorship! >>>>>> Here's the hg-export >>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>> Thanks for taking this Ivan. >>>>>>> >>>>>>> Can you please make the changes suggested by both David and Alan ( >>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>> GetStringUTFChars >>>>>>> fails ( returns NULL ), then I will sponsor this change into >>>>>>> jdk8 for >>>>>>> you. >>>>>>> >>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>> Ivan, >>>>>>>> >>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>> David, Alan, >>>>>>>>> >>>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>>> necessary. >>>>>>>> >>>>>>>> You don't need to throw it yourself: >>>>>>>> >>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>> >>>>>>>> Assuming a correct VM implementation if NULL is returned then >>>>>>>> an OOME >>>>>>>> should already be pending and will be thrown as soon as your >>>>>>>> native >>>>>>>> code >>>>>>>> returns to Java. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>> indentation. >>>>>>>>> >>>>>>>>> Would you please review the updated webrev? >>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>> Thanks Alan! >>>>>>>>>>> >>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars >>>>>>>>>>> cannot >>>>>>>>>>> return >>>>>>>>>>> NULL. >>>>>>>>>>> For allocation of the result string it calls AllocateHeap() >>>>>>>>>>> with >>>>>>>>>>> the >>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>> Thus, in case of being unable to allocate memory it simply >>>>>>>>>>> stops >>>>>>>>>>> VM. >>>>>>>>>> >>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to >>>>>>>>>> throw >>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>> >>>>>>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Sincerely yours, >>>>>>>>>>> Ivan >>>>>>>>>>> >>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>> >>>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>>> there) is >>>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>>> returns >>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>> >>>>>>>>>>>> -Alan. >>>>>>>>>>>> >>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>> >>>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>>>>>> memory. >>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>>>> available.) >>>>>>>>>>>>> >>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>> >>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>> >>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>> unnecessary >>>>>>>>>>>>> allocation? >>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>> >>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>> Ivan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >> >> >> > From ivan.gerasimov at oracle.com Thu Aug 8 22:19:52 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 09 Aug 2013 02:19:52 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52040A76.3060602@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> Message-ID: <52041988.80705@oracle.com> Thanks David! On 09.08.2013 1:15, David Holmes wrote: > Main fix looks good to me. > > Regression test may need some tweaking eg I think othervm will be needed. > Yes, it's a good point. Since there may be a memory leak in the test, it'd better not interfere with other tests in jtreg. > Also this: > > System.out.println("WARNING: Cannot perform memory leak detection on > this OS"); > > should probably just say something like "Test skipped on this OS" - > there are other tests that do this so just check if there is common > terminology. (In the future we may have keyword tags to flag this as > linux only etc.) > OK, I changed the phrase to "Test only runs on Linux". Updated webrev is here: http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ Updated export is at the same place: http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch Sincerely yours, Ivan > Thanks, > David > > On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >> Chris, if it's not too late, I'd like to include a regtest in the fix. >> >> Here's webrev that includes the test: >> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >> >> The test gets past with the fixed jdk8 and fails with jdk8-b101 and jdk7 >> as expected. >> >> Sincerely yours, >> Ivan >> >> On 08.08.2013 17:50, Chris Hegarty wrote: >>> Looks good to me. Thanks Ivan. >>> >>> -Chris. >>> >>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>> Hello Chris! >>>> >>>> Here's the update: >>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>> >>>> Thanks for offering the sponsorship! >>>> Here's the hg-export >>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>> >>>> >>>> >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>> Thanks for taking this Ivan. >>>>> >>>>> Can you please make the changes suggested by both David and Alan ( >>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars >>>>> fails ( returns NULL ), then I will sponsor this change into jdk8 for >>>>> you. >>>>> >>>>> Please post an update webrev to cr.openjdk.java.net. >>>>> >>>>> -Chris. >>>>> >>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>> Ivan, >>>>>> >>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>> David, Alan, >>>>>>> >>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>> necessary. >>>>>> >>>>>> You don't need to throw it yourself: >>>>>> >>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>> >>>>>> Assuming a correct VM implementation if NULL is returned then an >>>>>> OOME >>>>>> should already be pending and will be thrown as soon as your native >>>>>> code >>>>>> returns to Java. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> I've also added some spaces along the code to improve indentation. >>>>>>> >>>>>>> Would you please review the updated webrev? >>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> >>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>> Thanks Alan! >>>>>>>>> >>>>>>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>>>>>> return >>>>>>>>> NULL. >>>>>>>>> For allocation of the result string it calls AllocateHeap() with >>>>>>>>> the >>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>> Thus, in case of being unable to allocate memory it simply stops >>>>>>>>> VM. >>>>>>>> >>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to >>>>>>>> throw >>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>> >>>>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>> (cc'ing net-dev). >>>>>>>>>> >>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>> there) is >>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>> returns >>>>>>>>>> when it fails with NULL. >>>>>>>>>> >>>>>>>>>> -Alan. >>>>>>>>>> >>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>> Hello everybody! >>>>>>>>>>> >>>>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>>>> memory. >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>> available.) >>>>>>>>>>> >>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>> >>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>> >>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>> unnecessary >>>>>>>>>>> allocation? >>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>> >>>>>>>>>>> Sincerely yours, >>>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From ivan.gerasimov at oracle.com Thu Aug 8 22:24:36 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 09 Aug 2013 02:24:36 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52041965.3090808@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52040FDA.2040600@oracle.com> <52041895.9010706@oracle.com> <52041965.3090808@oracle.com> Message-ID: <52041AA4.2000406@oracle.com> Thank you Michael! On 09.08.2013 2:19, Michael McMahon wrote: > Ivan, > > Right, it's not worth trying to do the equivalent, whatever it is, for > Windows. > The test is fine with me. > > Thanks > Michael > > On 08/08/13 23:15, Ivan Gerasimov wrote: >> Michael, >> >> The test uses /proc/self/stat file to detect changes in virtual >> memory usage. >> This approach is specific for Linux. >> That's why I included the check of OS in the test. >> >> Sincerely yours, >> Ivan >> >> On 09.08.2013 1:38, Michael McMahon wrote: >>> Yes, definitely "othervm" would be required for the test. Also, why >>> skip other OS'es? >>> The fix is only for Linux, but it might catch future leaks on Windows. >>> >>> The trouble with tests like this, is they sometimes don't age well. >>> Future changes in OS kernel behavior could cause problems but I >>> guess 32MB is a fairly large difference. >>> So, it should be okay >>> >>> Michael >>> >>> On 08/08/13 22:15, David Holmes wrote: >>>> Main fix looks good to me. >>>> >>>> Regression test may need some tweaking eg I think othervm will be >>>> needed. >>>> >>>> Also this: >>>> >>>> System.out.println("WARNING: Cannot perform memory leak detection >>>> on this OS"); >>>> >>>> should probably just say something like "Test skipped on this OS" - >>>> there are other tests that do this so just check if there is common >>>> terminology. (In the future we may have keyword tags to flag this >>>> as linux only etc.) >>>> >>>> Thanks, >>>> David >>>> >>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>>> Chris, if it's not too late, I'd like to include a regtest in the >>>>> fix. >>>>> >>>>> Here's webrev that includes the test: >>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>>> >>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 >>>>> and jdk7 >>>>> as expected. >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>>> Looks good to me. Thanks Ivan. >>>>>> >>>>>> -Chris. >>>>>> >>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>>> Hello Chris! >>>>>>> >>>>>>> Here's the update: >>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>>> >>>>>>> Thanks for offering the sponsorship! >>>>>>> Here's the hg-export >>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>>> Thanks for taking this Ivan. >>>>>>>> >>>>>>>> Can you please make the changes suggested by both David and Alan ( >>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>>> GetStringUTFChars >>>>>>>> fails ( returns NULL ), then I will sponsor this change into >>>>>>>> jdk8 for >>>>>>>> you. >>>>>>>> >>>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>>> Ivan, >>>>>>>>> >>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>>> David, Alan, >>>>>>>>>> >>>>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>>>> necessary. >>>>>>>>> >>>>>>>>> You don't need to throw it yourself: >>>>>>>>> >>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>>> >>>>>>>>> Assuming a correct VM implementation if NULL is returned then >>>>>>>>> an OOME >>>>>>>>> should already be pending and will be thrown as soon as your >>>>>>>>> native >>>>>>>>> code >>>>>>>>> returns to Java. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>>> indentation. >>>>>>>>>> >>>>>>>>>> Would you please review the updated webrev? >>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>> >>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars >>>>>>>>>>>> cannot >>>>>>>>>>>> return >>>>>>>>>>>> NULL. >>>>>>>>>>>> For allocation of the result string it calls AllocateHeap() >>>>>>>>>>>> with >>>>>>>>>>>> the >>>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply >>>>>>>>>>>> stops >>>>>>>>>>>> VM. >>>>>>>>>>> >>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed >>>>>>>>>>> to throw >>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>>> >>>>>>>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>> Ivan >>>>>>>>>>>> >>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>>> >>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>>>> there) is >>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>>>> returns >>>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>>> >>>>>>>>>>>>> -Alan. >>>>>>>>>>>>> >>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>>>>>>> memory. >>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>>>>> available.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>> allocation? >>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>> Ivan >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>> >>> >>> >> > > > From stuart.marks at oracle.com Thu Aug 8 22:36:45 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 08 Aug 2013 15:36:45 -0700 Subject: RFR 8021820: Number of opened files used in select() is limited to 1024 [macosx] In-Reply-To: <52035CAC.5090000@oracle.com> References: <51F9007D.8090801@oracle.com> <51F9150B.4000008@oracle.com> <51F920A7.3000600@oracle.com> <51FF90BD.6070600@oracle.com> <52004DD9.4040202@oracle.com> <5202453F.2080409@oracle.com> <5202FDFF.1030906@oracle.com> <5202FE3B.8040909@oracle.com> <52035CAC.5090000@oracle.com> Message-ID: <52041D7D.5080400@oracle.com> On 8/8/13 1:54 AM, Chris Hegarty wrote: > On 08/08/2013 03:11 AM, Jonathan Gibbons wrote: >> On 08/07/2013 07:10 PM, Stuart Marks wrote: >>> I'd suggest putting a comment at the top of the test class saying that >>> this test *must* be run in othervm mode, to ensure that files are >>> closed properly. That way, you can take out the cleanupFiles() method >>> too, as well as avoiding lots of exception handling and related >>> cleanup code. >> >> Huh? What's wrong with >> @run main/othervm classname > > I think what Stuart is suggesting is that '@run main/othervm classname' be > added, but also an additional text comment explaining why this test is required > to be run in othervm mode. Yes, thanks, that's exactly what I meant. s'marks From dan.xu at oracle.com Thu Aug 8 23:26:17 2013 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 08 Aug 2013 16:26:17 -0700 Subject: RFR: JDK-8021977 -- Open File Using Java.IO May Throw IOException On Windows Message-ID: <52042919.50301@oracle.com> Hi All, Please review a simple bug fix for JDK8021977. For the backward compatibility, I have to remove the code that might throw out IOExceptionin the native side. The issue has never been reported.But it exists in a possible code path. And it is not easy to write a testcase for this obvious but corner issue. I am relying on the existing IO testcases for testing. Thanks! Webrev: http://cr.openjdk.java.net/~dxu/8021977/webrev.00/ Bug: http://bugs.sun.com/view_bug.do?bug_id=8021977 -Dan From jason.uh at oracle.com Fri Aug 9 00:07:19 2013 From: jason.uh at oracle.com (jason.uh at oracle.com) Date: Fri, 09 Aug 2013 00:07:19 +0000 Subject: hg: jdk8/tl/jdk: 8022461: Fix lint warnings in sun.security.{provider, rsa, x509} Message-ID: <20130809000738.593224872F@hg.openjdk.java.net> Changeset: 67edbf7e6b26 Author: juh Date: 2013-08-08 17:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/67edbf7e6b26 8022461: Fix lint warnings in sun.security.{provider,rsa,x509} Reviewed-by: darcy, weijun, xuelei, mullan ! src/share/classes/sun/security/provider/DSAPublicKey.java ! src/share/classes/sun/security/rsa/RSAPublicKeyImpl.java ! src/share/classes/sun/security/rsa/RSASignature.java ! src/share/classes/sun/security/x509/AlgIdDSA.java ! src/share/classes/sun/security/x509/X509Key.java From joe.darcy at oracle.com Fri Aug 9 01:38:25 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Thu, 08 Aug 2013 18:38:25 -0700 Subject: code review request: JDK-8015780: java/lang/reflect/Method/GenericStringTest.java failing In-Reply-To: <5201014C.90903@oracle.com> References: <5201014C.90903@oracle.com> Message-ID: <52044811.2040104@oracle.com> Hi Vicente, Looks fine; approved to go back. Thanks, -Joe On 8/6/2013 6:59 AM, Vicente-Arturo Romero-Zaldivar wrote: > Hello, > > Please review this patch, which updates test > jdk/test/java/lang/reflect/Method/GenericStringTest.java for it to > pass after changes introduced to generation of bridge methods. > > Now if a bridge method is generated, all annotations present in the > related "standard" method are copied to the bridge method. > > Part of the job of this test is to compare the method generic string > against the one provided in the ExpectedGenericString annotation. The > fix is to add another element to the same annotation in case a bridge > method is generated. Later it's needed to determine which element's > value we need to compare with. > > The webrev is here: > http://cr.openjdk.java.net/~vromero/8015780/webrev.00/ > > The bug report is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015780 > > Thanks, > Vicente. From Alan.Bateman at oracle.com Fri Aug 9 02:01:58 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 08 Aug 2013 19:01:58 -0700 Subject: RFR: JDK-8021977 -- Open File Using Java.IO May Throw IOException On Windows In-Reply-To: <52042919.50301@oracle.com> References: <52042919.50301@oracle.com> Message-ID: <52044D96.1020600@oracle.com> On 08/08/2013 16:26, Dan Xu wrote: > Hi All, > > Please review a simple bug fix for JDK8021977. For the backward > compatibility, I have to remove the code that might throw out > IOExceptionin the native side. The issue has never been reported.But > it exists in a possible code path. And it is not easy to write a > testcase for this obvious but corner issue. I am relying on the > existing IO testcases for testing. Thanks! > > Webrev: http://cr.openjdk.java.net/~dxu/8021977/webrev.00/ > Bug: http://bugs.sun.com/view_bug.do?bug_id=8021977 > > -Dan > This looks good to me. -Alan From weijun.wang at oracle.com Fri Aug 9 03:42:53 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 09 Aug 2013 03:42:53 +0000 Subject: hg: jdk8/tl/jdk: 8021788: JarInputStream doesn't provide certificates for some file under META-INF Message-ID: <20130809034314.C36B848735@hg.openjdk.java.net> Changeset: 758e3117899c Author: weijun Date: 2013-08-09 11:41 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/758e3117899c 8021788: JarInputStream doesn't provide certificates for some file under META-INF Reviewed-by: chegar, sherman ! src/share/classes/java/util/jar/JarVerifier.java + test/java/util/jar/JarInputStream/ExtraFileInMetaInf.java From masayoshi.okutsu at oracle.com Fri Aug 9 04:55:31 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 09 Aug 2013 13:55:31 +0900 Subject: RFR: 6614237: missing codepage Cp290 at java runtime In-Reply-To: <5203EF43.2030000@oracle.com> References: <51FC1C66.8000108@oracle.com> <51FF355F.6050005@oracle.com> <5203EF43.2030000@oracle.com> Message-ID: <52047643.3030601@oracle.com> Looks good. Masayoshi On 8/9/2013 4:19 AM, Xueming Shen wrote: > Thanks Masayoshi, good catch, yes, those two aliases should be included. > Webrev has been updated according. > > webrev: > http://cr.openjdk.java.net/~sherman/6614237/webrev/ > > -Sherman > > On 08/04/2013 10:17 PM, Masayoshi Okutsu wrote: >> Hi Sherman, >> >> IANA seems to define the following aliases for IBM290. >> >> cp290 >> EBCDIC-JP-kana >> csIBM290 >> >> The alias table should include EBCDIC-JP-kana and csIBM290 as well? >> >> Otherwise, the changes look good to me. >> >> Thanks, >> Masayoshi >> >> On 8/3/2013 5:53 AM, Xueming Shen wrote: >>> Masayoshi, >>> >>> Would you please help review this change? The changeset also adds >>> the requested Cp300. >>> >>> webrev: >>> http://cr.openjdk.java.net/~sherman/6614237/webrev/ >>> >>> original mapptables: >>> http://cr.openjdk.java.net/~sherman/6614237/290/ >>> http://cr.openjdk.java.net/~sherman/6614237/300/ >>> >>> regression tests: >>> http://cr.openjdk.java.net/~sherman/6614237/closed >>> >>> Thanks! >>> -Sherman >>> >> > From david.holmes at oracle.com Fri Aug 9 05:21:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 09 Aug 2013 15:21:42 +1000 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52041988.80705@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> Message-ID: <52047C66.2080001@oracle.com> Thumbs up! Thanks, David On 9/08/2013 8:19 AM, Ivan Gerasimov wrote: > Thanks David! > > On 09.08.2013 1:15, David Holmes wrote: >> Main fix looks good to me. >> >> Regression test may need some tweaking eg I think othervm will be needed. >> > Yes, it's a good point. > Since there may be a memory leak in the test, it'd better not interfere > with other tests in jtreg. > >> Also this: >> >> System.out.println("WARNING: Cannot perform memory leak detection on >> this OS"); >> >> should probably just say something like "Test skipped on this OS" - >> there are other tests that do this so just check if there is common >> terminology. (In the future we may have keyword tags to flag this as >> linux only etc.) >> > OK, I changed the phrase to "Test only runs on Linux". > > Updated webrev is here: > http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ > > Updated export is at the same place: > http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch > > > Sincerely yours, > Ivan > > >> Thanks, >> David >> >> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>> Chris, if it's not too late, I'd like to include a regtest in the fix. >>> >>> Here's webrev that includes the test: >>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>> >>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and jdk7 >>> as expected. >>> >>> Sincerely yours, >>> Ivan >>> >>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>> Looks good to me. Thanks Ivan. >>>> >>>> -Chris. >>>> >>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>> Hello Chris! >>>>> >>>>> Here's the update: >>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>> >>>>> Thanks for offering the sponsorship! >>>>> Here's the hg-export >>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>> >>>>> >>>>> >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>> Thanks for taking this Ivan. >>>>>> >>>>>> Can you please make the changes suggested by both David and Alan ( >>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars >>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8 for >>>>>> you. >>>>>> >>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>> >>>>>> -Chris. >>>>>> >>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>> Ivan, >>>>>>> >>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>> David, Alan, >>>>>>>> >>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>> necessary. >>>>>>> >>>>>>> You don't need to throw it yourself: >>>>>>> >>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>> >>>>>>> Assuming a correct VM implementation if NULL is returned then an >>>>>>> OOME >>>>>>> should already be pending and will be thrown as soon as your native >>>>>>> code >>>>>>> returns to Java. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> I've also added some spaces along the code to improve indentation. >>>>>>>> >>>>>>>> Would you please review the updated webrev? >>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>>> >>>>>>>> >>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>> Thanks Alan! >>>>>>>>>> >>>>>>>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>>>>>>> return >>>>>>>>>> NULL. >>>>>>>>>> For allocation of the result string it calls AllocateHeap() with >>>>>>>>>> the >>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>> Thus, in case of being unable to allocate memory it simply stops >>>>>>>>>> VM. >>>>>>>>> >>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to >>>>>>>>> throw >>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>> >>>>>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>> >>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>> there) is >>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>> returns >>>>>>>>>>> when it fails with NULL. >>>>>>>>>>> >>>>>>>>>>> -Alan. >>>>>>>>>>> >>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>> Hello everybody! >>>>>>>>>>>> >>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>>>>> memory. >>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>>> available.) >>>>>>>>>>>> >>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>> >>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>> >>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>> unnecessary >>>>>>>>>>>> allocation? >>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>> Ivan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > From david.holmes at oracle.com Fri Aug 9 05:47:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 09 Aug 2013 15:47:21 +1000 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52047C66.2080001@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> <52047C66.2080001@oracle.com> Message-ID: <52048269.7000501@oracle.com> Sorry I messed this up. The JNI book says GetStringUTFChars will return NULL and post OOME but the JNI spec (latest version 6.0) does not - it only says it will return NULL on failure. So your previous version was the more correct. Given we just failed to allocate C-heap I think we are on thin ice anyway, but better to at least attempt to do the right thing. FYI I filed 8022683 to fix GetStringUTFChars. David ----- On 9/08/2013 3:21 PM, David Holmes wrote: > Thumbs up! > > Thanks, > David > > On 9/08/2013 8:19 AM, Ivan Gerasimov wrote: >> Thanks David! >> >> On 09.08.2013 1:15, David Holmes wrote: >>> Main fix looks good to me. >>> >>> Regression test may need some tweaking eg I think othervm will be >>> needed. >>> >> Yes, it's a good point. >> Since there may be a memory leak in the test, it'd better not interfere >> with other tests in jtreg. >> >>> Also this: >>> >>> System.out.println("WARNING: Cannot perform memory leak detection on >>> this OS"); >>> >>> should probably just say something like "Test skipped on this OS" - >>> there are other tests that do this so just check if there is common >>> terminology. (In the future we may have keyword tags to flag this as >>> linux only etc.) >>> >> OK, I changed the phrase to "Test only runs on Linux". >> >> Updated webrev is here: >> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ >> >> Updated export is at the same place: >> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >> >> >> >> Sincerely yours, >> Ivan >> >> >>> Thanks, >>> David >>> >>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>> Chris, if it's not too late, I'd like to include a regtest in the fix. >>>> >>>> Here's webrev that includes the test: >>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>> >>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and >>>> jdk7 >>>> as expected. >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>> Looks good to me. Thanks Ivan. >>>>> >>>>> -Chris. >>>>> >>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>> Hello Chris! >>>>>> >>>>>> Here's the update: >>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>> >>>>>> Thanks for offering the sponsorship! >>>>>> Here's the hg-export >>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>> Thanks for taking this Ivan. >>>>>>> >>>>>>> Can you please make the changes suggested by both David and Alan ( >>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>> GetStringUTFChars >>>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8 >>>>>>> for >>>>>>> you. >>>>>>> >>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>> Ivan, >>>>>>>> >>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>> David, Alan, >>>>>>>>> >>>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>>> necessary. >>>>>>>> >>>>>>>> You don't need to throw it yourself: >>>>>>>> >>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>> >>>>>>>> Assuming a correct VM implementation if NULL is returned then an >>>>>>>> OOME >>>>>>>> should already be pending and will be thrown as soon as your native >>>>>>>> code >>>>>>>> returns to Java. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> I've also added some spaces along the code to improve indentation. >>>>>>>>> >>>>>>>>> Would you please review the updated webrev? >>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>> Thanks Alan! >>>>>>>>>>> >>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>>>>>>>> return >>>>>>>>>>> NULL. >>>>>>>>>>> For allocation of the result string it calls AllocateHeap() with >>>>>>>>>>> the >>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>> Thus, in case of being unable to allocate memory it simply stops >>>>>>>>>>> VM. >>>>>>>>>> >>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to >>>>>>>>>> throw >>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>> >>>>>>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Sincerely yours, >>>>>>>>>>> Ivan >>>>>>>>>>> >>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>> >>>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>>> there) is >>>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>>> returns >>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>> >>>>>>>>>>>> -Alan. >>>>>>>>>>>> >>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>> >>>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>>>>>> memory. >>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>>>> available.) >>>>>>>>>>>>> >>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>> >>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>> >>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>> unnecessary >>>>>>>>>>>>> allocation? >>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>> >>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>> Ivan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> From xueming.shen at oracle.com Fri Aug 9 05:54:56 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 08 Aug 2013 22:54:56 -0700 Subject: RFR JDK-8020054: (tz) Support tzdata2013d In-Reply-To: <518ACFB3.5030000@oracle.com> References: <518ACFB3.5030000@oracle.com> Message-ID: <52048430.3050300@oracle.com> Hi, Please help review the proposed change to update the tz data in JDK8 from 2013c to 2013d. http://cr.openjdk.java.net/~sherman/8020054/webrev http://cr.openjdk.java.net/~sherman/8020054/closed Tests list below have been run and passed (except java/time/tck/java/time/chrono/TCKChronology.java with error expected [Hijrah-umalqura] but found [Islamic Umm al-Qura Calendar], which I would assume has nothing to do with tz change) java/util/TimeZone java/util/Calendar java/util/Formatter java/time closed/java/util/TimeZone closed/java/util/Calendar Thanks! -Sherman From huizhe.wang at oracle.com Fri Aug 9 05:57:58 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 08 Aug 2013 22:57:58 -0700 Subject: RFR: JAXP in JDK8/7u40 : 8022548 : SPECJVM2008 has errors introduced in 7u40-b34 Message-ID: <520484E6.4020204@oracle.com> Hi, The root cause of this issue is that SPECJVM2008 uses a 3rd party parser XOM 1.1 to convert the output to its canonical form. The XOM parser directly references to the JDK parser implementation "SAXParser" with a different configuration than the default JDK parser, in this case, the DTD-only parser configuration "DTDConfiguration". In JAXP 1.5, we added XMLSecurityPropertyManager that is instantiated in the default configuration "XML11Configuration". Since XMLSecurityPropertyManager is not supported by DTDConfiguration, XOM no longer works. This patch is to add the XMLSecurityPropertyManager to DTDConfiguration so that XOM will continue to work properly with jdk8/7u40. I don't know if there's any library out there that calls into NonValidatingConfiguration directly. Since it's in a similar situation as DTDConfiguration, I added XMLSecurityPropertyManager support as well. webrec: http://cr.openjdk.java.net/~joehw/jdk8/8022548/webrev/ test: I created a new test that runs with xom1.1.jar on the classpath, and passed. all unit tests/SQE regression tests passed Thanks, Joe From xueming.shen at oracle.com Fri Aug 9 06:39:17 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 09 Aug 2013 06:39:17 +0000 Subject: hg: jdk8/tl/jdk: 6614237: missing codepage Cp290 at java runtime Message-ID: <20130809063942.0D9734873B@hg.openjdk.java.net> Changeset: 54f0ccdd9ad7 Author: sherman Date: 2013-08-08 23:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/54f0ccdd9ad7 6614237: missing codepage Cp290 at java runtime Summary: to add charset Cp290 and Cp300 Reviewed-by: okutsu + make/tools/CharsetMapping/IBM290.c2b + make/tools/CharsetMapping/IBM290.map + make/tools/CharsetMapping/IBM300.c2b + make/tools/CharsetMapping/IBM300.map ! make/tools/CharsetMapping/dbcs ! make/tools/CharsetMapping/extsbcs ! make/tools/src/build/tools/charsetmapping/DBCS.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java From yuka.kamiya at oracle.com Fri Aug 9 07:20:51 2013 From: yuka.kamiya at oracle.com (Yuka Kamiya) Date: Fri, 09 Aug 2013 16:20:51 +0900 Subject: RFR JDK-8020054: (tz) Support tzdata2013d In-Reply-To: <52048430.3050300@oracle.com> References: <518ACFB3.5030000@oracle.com> <52048430.3050300@oracle.com> Message-ID: <52049853.3050903@oracle.com> Hi Sherman, The fix looks good to me. Thanks, -- Yuka (2013/08/09 14:54), Xueming Shen wrote: > Hi, > > Please help review the proposed change to update the tz data > in JDK8 from 2013c to 2013d. > > http://cr.openjdk.java.net/~sherman/8020054/webrev > http://cr.openjdk.java.net/~sherman/8020054/closed > > Tests list below have been run and passed > (except java/time/tck/java/time/chrono/TCKChronology.java with error > expected [Hijrah-umalqura] but found [Islamic Umm al-Qura Calendar], which > I would assume has nothing to do with tz change) > > java/util/TimeZone > java/util/Calendar > java/util/Formatter > java/time > closed/java/util/TimeZone > closed/java/util/Calendar > > Thanks! > -Sherman From chris.hegarty at oracle.com Fri Aug 9 07:25:47 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 09 Aug 2013 08:25:47 +0100 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52048269.7000501@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> <52047C66.2080001@oracle.com> <52048269.7000501@oracle.com> Message-ID: <5204997B.3090601@oracle.com> On 09/08/2013 06:47, David Holmes wrote: > Sorry I messed this up. The JNI book says GetStringUTFChars will return > NULL and post OOME but the JNI spec (latest version 6.0) does not - it > only says it will return NULL on failure. This is indeed strange. Most usages of this function in the jdk expect the former. If this is not the case, then we may need to do an audit of all usages. > So your previous version was the more correct. Given we just failed to > allocate C-heap I think we are on thin ice anyway, but better to at > least attempt to do the right thing. I'm not sure what the right thing to do here is? It seems a little unwieldy! if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == NULL) { if ((*env)->ExceptionOccurred(env)) { return NULL/JNI_False/-1; } else { throwException(env, "java/lang/InternalError", "GetStringUTFChars failed"); return NULL/JNI_False/-1; } Given we have no idea why GetStringUTFChars may have failed, what exception do we throw? Also worth noting is that this bug fix has moved away from the original problem (memory leak), and is now focused on code cleanup. If we cannot get agreement on the cleanup, or it looks like more clarification is needed around the cleanup effort, then I would like to suggest that we proceed with the original fix for the memory leak and separate out the cleanup effort. -Chris. > FYI I filed 8022683 to fix GetStringUTFChars. > > David > ----- > > On 9/08/2013 3:21 PM, David Holmes wrote: >> Thumbs up! >> >> Thanks, >> David >> >> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote: >>> Thanks David! >>> >>> On 09.08.2013 1:15, David Holmes wrote: >>>> Main fix looks good to me. >>>> >>>> Regression test may need some tweaking eg I think othervm will be >>>> needed. >>>> >>> Yes, it's a good point. >>> Since there may be a memory leak in the test, it'd better not interfere >>> with other tests in jtreg. >>> >>>> Also this: >>>> >>>> System.out.println("WARNING: Cannot perform memory leak detection on >>>> this OS"); >>>> >>>> should probably just say something like "Test skipped on this OS" - >>>> there are other tests that do this so just check if there is common >>>> terminology. (In the future we may have keyword tags to flag this as >>>> linux only etc.) >>>> >>> OK, I changed the phrase to "Test only runs on Linux". >>> >>> Updated webrev is here: >>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ >>> >>> Updated export is at the same place: >>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>> >>> >>> >>> >>> Sincerely yours, >>> Ivan >>> >>> >>>> Thanks, >>>> David >>>> >>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>>> Chris, if it's not too late, I'd like to include a regtest in the fix. >>>>> >>>>> Here's webrev that includes the test: >>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>>> >>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and >>>>> jdk7 >>>>> as expected. >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>>> Looks good to me. Thanks Ivan. >>>>>> >>>>>> -Chris. >>>>>> >>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>>> Hello Chris! >>>>>>> >>>>>>> Here's the update: >>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>>> >>>>>>> Thanks for offering the sponsorship! >>>>>>> Here's the hg-export >>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>>> Thanks for taking this Ivan. >>>>>>>> >>>>>>>> Can you please make the changes suggested by both David and Alan ( >>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>>> GetStringUTFChars >>>>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8 >>>>>>>> for >>>>>>>> you. >>>>>>>> >>>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>>> Ivan, >>>>>>>>> >>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>>> David, Alan, >>>>>>>>>> >>>>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>>>> necessary. >>>>>>>>> >>>>>>>>> You don't need to throw it yourself: >>>>>>>>> >>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>>> >>>>>>>>> Assuming a correct VM implementation if NULL is returned then an >>>>>>>>> OOME >>>>>>>>> should already be pending and will be thrown as soon as your >>>>>>>>> native >>>>>>>>> code >>>>>>>>> returns to Java. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>>> indentation. >>>>>>>>>> >>>>>>>>>> Would you please review the updated webrev? >>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>> >>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars >>>>>>>>>>>> cannot >>>>>>>>>>>> return >>>>>>>>>>>> NULL. >>>>>>>>>>>> For allocation of the result string it calls AllocateHeap() >>>>>>>>>>>> with >>>>>>>>>>>> the >>>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply >>>>>>>>>>>> stops >>>>>>>>>>>> VM. >>>>>>>>>>> >>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to >>>>>>>>>>> throw >>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>>> >>>>>>>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>> Ivan >>>>>>>>>>>> >>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>>> >>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>>>> there) is >>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>>>> returns >>>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>>> >>>>>>>>>>>>> -Alan. >>>>>>>>>>>>> >>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>>>>>>> memory. >>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>>>>> available.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>> allocation? >>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>> Ivan >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> From sean.coffey at oracle.com Fri Aug 9 08:36:40 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Fri, 09 Aug 2013 09:36:40 +0100 Subject: RFR JDK-8020054: (tz) Support tzdata2013d In-Reply-To: <52049853.3050903@oracle.com> References: <518ACFB3.5030000@oracle.com> <52048430.3050300@oracle.com> <52049853.3050903@oracle.com> Message-ID: <5204AA18.1010008@oracle.com> Looks fine to me also Sherman. On a side note, we should look at migrating some closed TZ tests to open repo. I'm not sure why that wasn't done from first day. regards, Sean. On 09/08/2013 08:20, Yuka Kamiya wrote: > Hi Sherman, > > The fix looks good to me. > > Thanks, > -- > Yuka > > > (2013/08/09 14:54), Xueming Shen wrote: >> Hi, >> >> Please help review the proposed change to update the tz data >> in JDK8 from 2013c to 2013d. >> >> http://cr.openjdk.java.net/~sherman/8020054/webrev >> http://cr.openjdk.java.net/~sherman/8020054/closed >> >> Tests list below have been run and passed >> (except java/time/tck/java/time/chrono/TCKChronology.java with error >> expected [Hijrah-umalqura] but found [Islamic Umm al-Qura Calendar], >> which >> I would assume has nothing to do with tz change) >> >> java/util/TimeZone >> java/util/Calendar >> java/util/Formatter >> java/time >> closed/java/util/TimeZone >> closed/java/util/Calendar >> >> Thanks! >> -Sherman > From ivan.gerasimov at oracle.com Fri Aug 9 09:27:15 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 09 Aug 2013 13:27:15 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5204997B.3090601@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> <52047C66.2080001@oracle.com> <52048269.7000501@oracle.com> <5204997B.3090601@oracle.com> Message-ID: <5204B5F3.6000506@oracle.com> Chris, I would use this if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == NULL) { JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed"); return NULL/JNI_False/-1; } If I understand it correctly, JNU_ThrowOutOfMemoryError throws an exception only if it hasn't been already thrown. Sincerely yours, Ivan On 09.08.2013 11:25, Chris Hegarty wrote: > On 09/08/2013 06:47, David Holmes wrote: >> Sorry I messed this up. The JNI book says GetStringUTFChars will return >> NULL and post OOME but the JNI spec (latest version 6.0) does not - it >> only says it will return NULL on failure. > > This is indeed strange. Most usages of this function in the jdk expect > the former. If this is not the case, then we may need to do an audit > of all usages. > >> So your previous version was the more correct. Given we just failed to >> allocate C-heap I think we are on thin ice anyway, but better to at >> least attempt to do the right thing. > > I'm not sure what the right thing to do here is? It seems a little > unwieldy! > > if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == > NULL) { > if ((*env)->ExceptionOccurred(env)) { > return NULL/JNI_False/-1; > } else { > throwException(env, "java/lang/InternalError", > "GetStringUTFChars failed"); > return NULL/JNI_False/-1; > } > > Given we have no idea why GetStringUTFChars may have failed, what > exception do we throw? > > Also worth noting is that this bug fix has moved away from the > original problem (memory leak), and is now focused on code cleanup. > > If we cannot get agreement on the cleanup, or it looks like more > clarification is needed around the cleanup effort, then I would like > to suggest that we proceed with the original fix for the memory leak > and separate out the cleanup effort. > > -Chris. > >> FYI I filed 8022683 to fix GetStringUTFChars. >> >> David >> ----- >> >> On 9/08/2013 3:21 PM, David Holmes wrote: >>> Thumbs up! >>> >>> Thanks, >>> David >>> >>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote: >>>> Thanks David! >>>> >>>> On 09.08.2013 1:15, David Holmes wrote: >>>>> Main fix looks good to me. >>>>> >>>>> Regression test may need some tweaking eg I think othervm will be >>>>> needed. >>>>> >>>> Yes, it's a good point. >>>> Since there may be a memory leak in the test, it'd better not >>>> interfere >>>> with other tests in jtreg. >>>> >>>>> Also this: >>>>> >>>>> System.out.println("WARNING: Cannot perform memory leak detection on >>>>> this OS"); >>>>> >>>>> should probably just say something like "Test skipped on this OS" - >>>>> there are other tests that do this so just check if there is common >>>>> terminology. (In the future we may have keyword tags to flag this as >>>>> linux only etc.) >>>>> >>>> OK, I changed the phrase to "Test only runs on Linux". >>>> >>>> Updated webrev is here: >>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ >>>> >>>> Updated export is at the same place: >>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>> >>>> >>>> >>>> >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>>>> Chris, if it's not too late, I'd like to include a regtest in the >>>>>> fix. >>>>>> >>>>>> Here's webrev that includes the test: >>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>>>> >>>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and >>>>>> jdk7 >>>>>> as expected. >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>>>> Looks good to me. Thanks Ivan. >>>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>>>> Hello Chris! >>>>>>>> >>>>>>>> Here's the update: >>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>>>> >>>>>>>> Thanks for offering the sponsorship! >>>>>>>> Here's the hg-export >>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>>> >>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>>>> Thanks for taking this Ivan. >>>>>>>>> >>>>>>>>> Can you please make the changes suggested by both David and >>>>>>>>> Alan ( >>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>>>> GetStringUTFChars >>>>>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8 >>>>>>>>> for >>>>>>>>> you. >>>>>>>>> >>>>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>>>> >>>>>>>>> -Chris. >>>>>>>>> >>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>>>> Ivan, >>>>>>>>>> >>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>>>> David, Alan, >>>>>>>>>>> >>>>>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>>>>> necessary. >>>>>>>>>> >>>>>>>>>> You don't need to throw it yourself: >>>>>>>>>> >>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>>>> >>>>>>>>>> Assuming a correct VM implementation if NULL is returned then an >>>>>>>>>> OOME >>>>>>>>>> should already be pending and will be thrown as soon as your >>>>>>>>>> native >>>>>>>>>> code >>>>>>>>>> returns to Java. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>>>> indentation. >>>>>>>>>>> >>>>>>>>>>> Would you please review the updated webrev? >>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>>>> >>>>>>>>>>> Sincerely yours, >>>>>>>>>>> Ivan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>>> >>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars >>>>>>>>>>>>> cannot >>>>>>>>>>>>> return >>>>>>>>>>>>> NULL. >>>>>>>>>>>>> For allocation of the result string it calls AllocateHeap() >>>>>>>>>>>>> with >>>>>>>>>>>>> the >>>>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply >>>>>>>>>>>>> stops >>>>>>>>>>>>> VM. >>>>>>>>>>>> >>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to >>>>>>>>>>>> throw >>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>>>> >>>>>>>>>>>> I recommend that you check for NULL and/or a pending >>>>>>>>>>>> exception. >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>> Ivan >>>>>>>>>>>>> >>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>>>> >>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>>>>> there) is >>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>>>>> returns >>>>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Alan. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to >>>>>>>>>>>>>>> leak >>>>>>>>>>>>>>> memory. >>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>>>>>> available.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>>> allocation? >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> > > From paul.sandoz at oracle.com Fri Aug 9 09:55:25 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 09 Aug 2013 09:55:25 +0000 Subject: hg: jdk8/tl/jdk: 8022326: Spliterator for values of j.u.c.ConcurrentSkipListMap does not report ORDERED Message-ID: <20130809095620.E542848740@hg.openjdk.java.net> Changeset: c29ca19cb816 Author: psandoz Date: 2013-08-09 11:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c29ca19cb816 8022326: Spliterator for values of j.u.c.ConcurrentSkipListMap does not report ORDERED Reviewed-by: martin, chegar ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! test/java/util/Spliterator/SpliteratorCharacteristics.java From chris.hegarty at oracle.com Fri Aug 9 10:36:22 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 09 Aug 2013 11:36:22 +0100 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5204B5F3.6000506@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> <52047C66.2080001@oracle.com> <52048269.7000501@oracle.com> <5204997B.3090601@oracle.com> <5204B5F3.6000506@oracle.com> Message-ID: <5204C626.3000102@oracle.com> Firstly, I think the memory leak issue should be moved forward separately to this cleanup effort. They are unrelated, and I'm starting to get the feeling that this could take some time to reach conclusion. It seems reasonable to separate the issues. On 09/08/2013 10:27, Ivan Gerasimov wrote: > Chris, > > I would use this > > if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == NULL) { > JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed"); > return NULL/JNI_False/-1; > } > > If I understand it correctly, JNU_ThrowOutOfMemoryError throws an > exception only if it hasn't been already thrown. JNU_ThrowOutOfMemoryError is simply a convenience wrapper for JNU_ThrowByName(env, "java/lang/OutOfMemoryError", msg); ...and JNU_ThrowByName [1] is defined as... JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg) { class cls = (*env)->FindClass(env, name); if (cls != 0) /* Otherwise an exception has already been thrown */ (*env)->ThrowNew(env, cls, msg); } } Neither FindClass or ThrowNew is safe to call if there is a pending exception [1]. Now the issue comes down to; could there ever be a pending exception if GetStringUTFChars returns NULL? The latest specs doesn't indicate that there could be, but every copy of "The Java Native Interface Programmer's Guide and Specification" I can find does. There also appears to be an assumption of this if you look at the usages in the JDK. I would really like to get a definitive answer on the JNI specification for GetStringUTFChars before making any changes here. -Chris. [1] http://hg.openjdk.java.net/jdk8/tl/jdk/file/54f0ccdd9ad7/src/share/native/common/jni_util.c [2] http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp17626 > > Sincerely yours, > Ivan > > > On 09.08.2013 11:25, Chris Hegarty wrote: >> On 09/08/2013 06:47, David Holmes wrote: >>> Sorry I messed this up. The JNI book says GetStringUTFChars will return >>> NULL and post OOME but the JNI spec (latest version 6.0) does not - it >>> only says it will return NULL on failure. >> >> This is indeed strange. Most usages of this function in the jdk expect >> the former. If this is not the case, then we may need to do an audit >> of all usages. >> >>> So your previous version was the more correct. Given we just failed to >>> allocate C-heap I think we are on thin ice anyway, but better to at >>> least attempt to do the right thing. >> >> I'm not sure what the right thing to do here is? It seems a little >> unwieldy! >> >> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == NULL) { >> if ((*env)->ExceptionOccurred(env)) { >> return NULL/JNI_False/-1; >> } else { >> throwException(env, "java/lang/InternalError", "GetStringUTFChars >> failed"); >> return NULL/JNI_False/-1; >> } >> >> Given we have no idea why GetStringUTFChars may have failed, what >> exception do we throw? >> >> Also worth noting is that this bug fix has moved away from the >> original problem (memory leak), and is now focused on code cleanup. >> >> If we cannot get agreement on the cleanup, or it looks like more >> clarification is needed around the cleanup effort, then I would like >> to suggest that we proceed with the original fix for the memory leak >> and separate out the cleanup effort. >> >> -Chris. >> >>> FYI I filed 8022683 to fix GetStringUTFChars. >>> >>> David >>> ----- >>> >>> On 9/08/2013 3:21 PM, David Holmes wrote: >>>> Thumbs up! >>>> >>>> Thanks, >>>> David >>>> >>>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote: >>>>> Thanks David! >>>>> >>>>> On 09.08.2013 1:15, David Holmes wrote: >>>>>> Main fix looks good to me. >>>>>> >>>>>> Regression test may need some tweaking eg I think othervm will be >>>>>> needed. >>>>>> >>>>> Yes, it's a good point. >>>>> Since there may be a memory leak in the test, it'd better not >>>>> interfere >>>>> with other tests in jtreg. >>>>> >>>>>> Also this: >>>>>> >>>>>> System.out.println("WARNING: Cannot perform memory leak detection on >>>>>> this OS"); >>>>>> >>>>>> should probably just say something like "Test skipped on this OS" - >>>>>> there are other tests that do this so just check if there is common >>>>>> terminology. (In the future we may have keyword tags to flag this as >>>>>> linux only etc.) >>>>>> >>>>> OK, I changed the phrase to "Test only runs on Linux". >>>>> >>>>> Updated webrev is here: >>>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ >>>>> >>>>> Updated export is at the same place: >>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>>>>> Chris, if it's not too late, I'd like to include a regtest in the >>>>>>> fix. >>>>>>> >>>>>>> Here's webrev that includes the test: >>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>>>>> >>>>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and >>>>>>> jdk7 >>>>>>> as expected. >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>>>>> Looks good to me. Thanks Ivan. >>>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>>>>> Hello Chris! >>>>>>>>> >>>>>>>>> Here's the update: >>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>>>>> >>>>>>>>> Thanks for offering the sponsorship! >>>>>>>>> Here's the hg-export >>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>>>>> Thanks for taking this Ivan. >>>>>>>>>> >>>>>>>>>> Can you please make the changes suggested by both David and >>>>>>>>>> Alan ( >>>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>>>>> GetStringUTFChars >>>>>>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8 >>>>>>>>>> for >>>>>>>>>> you. >>>>>>>>>> >>>>>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>>>>> >>>>>>>>>> -Chris. >>>>>>>>>> >>>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>>>>> Ivan, >>>>>>>>>>> >>>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>>>>> David, Alan, >>>>>>>>>>>> >>>>>>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>>>>>> necessary. >>>>>>>>>>> >>>>>>>>>>> You don't need to throw it yourself: >>>>>>>>>>> >>>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>>>>> >>>>>>>>>>> Assuming a correct VM implementation if NULL is returned then an >>>>>>>>>>> OOME >>>>>>>>>>> should already be pending and will be thrown as soon as your >>>>>>>>>>> native >>>>>>>>>>> code >>>>>>>>>>> returns to Java. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>>>>> indentation. >>>>>>>>>>>> >>>>>>>>>>>> Would you please review the updated webrev? >>>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>> Ivan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars >>>>>>>>>>>>>> cannot >>>>>>>>>>>>>> return >>>>>>>>>>>>>> NULL. >>>>>>>>>>>>>> For allocation of the result string it calls AllocateHeap() >>>>>>>>>>>>>> with >>>>>>>>>>>>>> the >>>>>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply >>>>>>>>>>>>>> stops >>>>>>>>>>>>>> VM. >>>>>>>>>>>>> >>>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to >>>>>>>>>>>>> throw >>>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>>>>> >>>>>>>>>>>>> I recommend that you check for NULL and/or a pending >>>>>>>>>>>>> exception. >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>>>>>> there) is >>>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>>>>>> returns >>>>>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Alan. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to >>>>>>>>>>>>>>>> leak >>>>>>>>>>>>>>>> memory. >>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>>>>>>> available.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>>>> allocation? >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >> >> > From Lance.Andersen at oracle.com Fri Aug 9 10:36:32 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 9 Aug 2013 06:36:32 -0400 Subject: RFR: JAXP in JDK8/7u40 : 8022548 : SPECJVM2008 has errors introduced in 7u40-b34 In-Reply-To: <520484E6.4020204@oracle.com> References: <520484E6.4020204@oracle.com> Message-ID: Hi Joe, The changes look fine Best Lance On Aug 9, 2013, at 1:57 AM, huizhe wang wrote: > Hi, > > The root cause of this issue is that SPECJVM2008 uses a 3rd party parser XOM 1.1 to convert the output to its canonical form. The XOM parser directly references to the JDK parser implementation "SAXParser" with a different configuration than the default JDK parser, in this case, the DTD-only parser configuration "DTDConfiguration". In JAXP 1.5, we added XMLSecurityPropertyManager that is instantiated in the default configuration "XML11Configuration". Since XMLSecurityPropertyManager is not supported by DTDConfiguration, XOM no longer works. > > This patch is to add the XMLSecurityPropertyManager to DTDConfiguration so that XOM will continue to work properly with jdk8/7u40. I don't know if there's any library out there that calls into NonValidatingConfiguration directly. Since it's in a similar situation as DTDConfiguration, I added XMLSecurityPropertyManager support as well. > > webrec: http://cr.openjdk.java.net/~joehw/jdk8/8022548/webrev/ > > test: > I created a new test that runs with xom1.1.jar on the classpath, and passed. > all unit tests/SQE regression tests passed > > Thanks, > Joe -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From david.holmes at oracle.com Fri Aug 9 12:18:48 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 09 Aug 2013 22:18:48 +1000 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5204C626.3000102@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> <52047C66.2080001@oracle.com> <52048269.7000501@oracle.com> <5204997B.3090601@oracle.com> <5204B5F3.6000506@oracle.com> <5204C626.3000102@oracle.com> Message-ID: <5204DE28.5090805@oracle.com> Hi Chris, On 9/08/2013 8:36 PM, Chris Hegarty wrote: > Firstly, I think the memory leak issue should be moved forward > separately to this cleanup effort. They are unrelated, and I'm starting > to get the feeling that this could take some time to reach conclusion. > It seems reasonable to separate the issues. I agree. I'm sure when Alan suggested to check the return he didn't expect it to unravel like this :) As we know hotspot will never actually return NULL there is no urgency to add this in. > On 09/08/2013 10:27, Ivan Gerasimov wrote: >> Chris, >> >> I would use this >> >> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == NULL) { >> JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed"); >> return NULL/JNI_False/-1; >> } >> >> If I understand it correctly, JNU_ThrowOutOfMemoryError throws an >> exception only if it hasn't been already thrown. > > JNU_ThrowOutOfMemoryError is simply a convenience wrapper for > JNU_ThrowByName(env, "java/lang/OutOfMemoryError", msg); > > ...and JNU_ThrowByName [1] is defined as... > > JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg) { > class cls = (*env)->FindClass(env, name); > if (cls != 0) /* Otherwise an exception has already been thrown */ > (*env)->ThrowNew(env, cls, msg); > } > } > > Neither FindClass or ThrowNew is safe to call if there is a pending > exception [1]. Right - we have to check for a pending exception before trying to throw one. > Now the issue comes down to; could there ever be a pending exception if > GetStringUTFChars returns NULL? The latest specs doesn't indicate that > there could be, but every copy of "The Java Native Interface > Programmer's Guide and Specification" I can find does. There also > appears to be an assumption of this if you look at the usages in the JDK. AFAIK there is only one version of the JNI spec book and it never got updated. The official spec says no throw, but when people have the book on their bookshelf that is what they tend to rely on. I looked at some of the usages and they seem exception agnostic - many of them don't even check for NULL :( The implementation as it stands will not throw and will not return NULL. > I would really like to get a definitive answer on the JNI specification > for GetStringUTFChars before making any changes here. The JNI spec (as opposed to the book) is definitive. If we don't like what is there then it requires a spec change. I can't find any reference to this particular issue being raised before. Cheers, David > -Chris. > > [1] > http://hg.openjdk.java.net/jdk8/tl/jdk/file/54f0ccdd9ad7/src/share/native/common/jni_util.c > > [2] > http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp17626 > > >> >> Sincerely yours, >> Ivan >> >> >> On 09.08.2013 11:25, Chris Hegarty wrote: >>> On 09/08/2013 06:47, David Holmes wrote: >>>> Sorry I messed this up. The JNI book says GetStringUTFChars will return >>>> NULL and post OOME but the JNI spec (latest version 6.0) does not - it >>>> only says it will return NULL on failure. >>> >>> This is indeed strange. Most usages of this function in the jdk expect >>> the former. If this is not the case, then we may need to do an audit >>> of all usages. >>> >>>> So your previous version was the more correct. Given we just failed to >>>> allocate C-heap I think we are on thin ice anyway, but better to at >>>> least attempt to do the right thing. >>> >>> I'm not sure what the right thing to do here is? It seems a little >>> unwieldy! >>> >>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == >>> NULL) { >>> if ((*env)->ExceptionOccurred(env)) { >>> return NULL/JNI_False/-1; >>> } else { >>> throwException(env, "java/lang/InternalError", "GetStringUTFChars >>> failed"); >>> return NULL/JNI_False/-1; >>> } >>> >>> Given we have no idea why GetStringUTFChars may have failed, what >>> exception do we throw? >>> >>> Also worth noting is that this bug fix has moved away from the >>> original problem (memory leak), and is now focused on code cleanup. >>> >>> If we cannot get agreement on the cleanup, or it looks like more >>> clarification is needed around the cleanup effort, then I would like >>> to suggest that we proceed with the original fix for the memory leak >>> and separate out the cleanup effort. >>> >>> -Chris. >>> >>>> FYI I filed 8022683 to fix GetStringUTFChars. >>>> >>>> David >>>> ----- >>>> >>>> On 9/08/2013 3:21 PM, David Holmes wrote: >>>>> Thumbs up! >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote: >>>>>> Thanks David! >>>>>> >>>>>> On 09.08.2013 1:15, David Holmes wrote: >>>>>>> Main fix looks good to me. >>>>>>> >>>>>>> Regression test may need some tweaking eg I think othervm will be >>>>>>> needed. >>>>>>> >>>>>> Yes, it's a good point. >>>>>> Since there may be a memory leak in the test, it'd better not >>>>>> interfere >>>>>> with other tests in jtreg. >>>>>> >>>>>>> Also this: >>>>>>> >>>>>>> System.out.println("WARNING: Cannot perform memory leak detection on >>>>>>> this OS"); >>>>>>> >>>>>>> should probably just say something like "Test skipped on this OS" - >>>>>>> there are other tests that do this so just check if there is common >>>>>>> terminology. (In the future we may have keyword tags to flag this as >>>>>>> linux only etc.) >>>>>>> >>>>>> OK, I changed the phrase to "Test only runs on Linux". >>>>>> >>>>>> Updated webrev is here: >>>>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ >>>>>> >>>>>> Updated export is at the same place: >>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>>>>>> Chris, if it's not too late, I'd like to include a regtest in the >>>>>>>> fix. >>>>>>>> >>>>>>>> Here's webrev that includes the test: >>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>>>>>> >>>>>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and >>>>>>>> jdk7 >>>>>>>> as expected. >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>>> >>>>>>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>>>>>> Looks good to me. Thanks Ivan. >>>>>>>>> >>>>>>>>> -Chris. >>>>>>>>> >>>>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>>>>>> Hello Chris! >>>>>>>>>> >>>>>>>>>> Here's the update: >>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>>>>>> >>>>>>>>>> Thanks for offering the sponsorship! >>>>>>>>>> Here's the hg-export >>>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>>>>>> Thanks for taking this Ivan. >>>>>>>>>>> >>>>>>>>>>> Can you please make the changes suggested by both David and >>>>>>>>>>> Alan ( >>>>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>>>>>> GetStringUTFChars >>>>>>>>>>> fails ( returns NULL ), then I will sponsor this change into >>>>>>>>>>> jdk8 >>>>>>>>>>> for >>>>>>>>>>> you. >>>>>>>>>>> >>>>>>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>>>>>> >>>>>>>>>>> -Chris. >>>>>>>>>>> >>>>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>>>>>> Ivan, >>>>>>>>>>>> >>>>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>>>>>> David, Alan, >>>>>>>>>>>>> >>>>>>>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>>>>>>> necessary. >>>>>>>>>>>> >>>>>>>>>>>> You don't need to throw it yourself: >>>>>>>>>>>> >>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>>>>>> >>>>>>>>>>>> Assuming a correct VM implementation if NULL is returned >>>>>>>>>>>> then an >>>>>>>>>>>> OOME >>>>>>>>>>>> should already be pending and will be thrown as soon as your >>>>>>>>>>>> native >>>>>>>>>>>> code >>>>>>>>>>>> returns to Java. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>>>>>> indentation. >>>>>>>>>>>>> >>>>>>>>>>>>> Would you please review the updated webrev? >>>>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>>>>>> >>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>> Ivan >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars >>>>>>>>>>>>>>> cannot >>>>>>>>>>>>>>> return >>>>>>>>>>>>>>> NULL. >>>>>>>>>>>>>>> For allocation of the result string it calls AllocateHeap() >>>>>>>>>>>>>>> with >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply >>>>>>>>>>>>>>> stops >>>>>>>>>>>>>>> VM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to >>>>>>>>>>>>>> throw >>>>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>>>>>> >>>>>>>>>>>>>> I recommend that you check for NULL and/or a pending >>>>>>>>>>>>>> exception. >>>>>>>>>>>>>> >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>>>>>>> there) is >>>>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>>>>>>> returns >>>>>>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Alan. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to >>>>>>>>>>>>>>>>> leak >>>>>>>>>>>>>>>>> memory. >>>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not >>>>>>>>>>>>>>>>> yet >>>>>>>>>>>>>>>>> available.) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>>>>> allocation? >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>> >>> >> From dl at cs.oswego.edu Fri Aug 9 12:29:53 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 09 Aug 2013 08:29:53 -0400 Subject: class SplittableRandom In-Reply-To: <51F7D77B.6010300@cs.oswego.edu> References: <51DDB26D.8050506@cs.oswego.edu> <51DE6069.2060308@gmail.com> <51DEA230.2060504@cs.oswego.edu> <51DEA3D5.5000509@oracle.com> <51E1549D.4060403@cs.oswego.edu> <51E414C6.9070400@cs.oswego.edu> <6099D28A-0B95-42A4-A59B-5E1C465EDCA9@oracle.com> <480BCC80-2A9C-4321-B81B-47487E90C0D7@oracle.com> <51F6B47E.1040102@gmail.com> <51F7D77B.6010300@cs.oswego.edu> Message-ID: <5204E0C1.5060200@cs.oswego.edu> After exploring a bunch of algorithmic variants, we committed to one of the simplest for consideration for inclusion in JDK8. Thanks again to everyone sending comments and suggestions that led us to investigate alternatives. The API is unchanged. While we cannot exhaustively quality-check all possible sequences across all possible splits (parallelism), it passes (both DieHarder and TestU01/Crush) those we have checked. Overall performance with longs and doubles is a little faster, ints a little slower. Currently at: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/SplittableRandom.java?view=log -Doug From peter.levart at gmail.com Fri Aug 9 12:37:48 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 09 Aug 2013 14:37:48 +0200 Subject: Classes on the stack trace In-Reply-To: References: <51F7AEEE.4040305@gmail.com> <51F7BD75.4030708@gmx.org> <51F7CACD.2070703@gmail.com> <51F7DCD0.1030306@gmx.org> <50B05474-BD3F-47C7-8412-F0F305E0F0FF@nicholaswilliams.net> <51F8BE80.1040005@gmail.com> Message-ID: <5204E29C.7060609@gmail.com> On 07/31/2013 03:18 PM, Nick Williams wrote: > Okay, but I don't think @CallerSensitive is necessary to prevent > MethodHandles from spoofing caller classes. I'll admit I don't know > very much about MethodHandle, what it does, or how its invocation > methods are different from Method.invoke(). In the code that I copied > into this email from jvm.cpp last night, the third frame (frame #2) > will always be returned unless it is one ignored by the security stack > walk. @CallerSensitive doesn't come in to play here. Nope. I think @CallerSensitive annotation is currently just a security feature, needed for implementation of MethodHandles. Regards, Peter > > Nick > > On Jul 31, 2013, at 2:36 AM, Peter Levart wrote: > >> Hi Nick, >> >> The @CallerSensitive annotation is an annotation that prevents some >> other infrastructure, namely the MethodHandles, to "spoof" caller >> classes. >> >> Try this: >> >> MethodHandles.Lookup lookup = >> MethodHandles.lookup().in(Object.class); >> MethodHandle mh = lookup.findStatic(Class.class, "forName", >> MethodType.methodType(Class.class, String.class)); >> >> ...you won't be able to pretend that you are the j.l.Object that is >> calling method Class.forName(String)... >> >> The annotation might have (or will have?) other effects like making >> sure some infrastructure-inserted frames are hidden-away just for >> @CallerSensitive methods which might be less optimal and not needed >> for normal methods. >> >> >> Regards, Peter >> >> On 07/31/2013 01:11 AM, Nick Williams wrote: >>> Quick question for those of you that know anything about @CallerSensitive... >>> >>> After looking at the code and experimenting some, I've discovered that getCallerClass() doesn't actually keep going until it finds the first method without @CallerSensitive. It only returns the caller of the caller. So, for example: >>> >>> Stack 1 >>> @CallerSensitive Reflection.getCallerClass() >>> @CallerSensitive MyClass1.method1(); >>> MyClass2.method2(); >>> >>> In this case, getCallerClass() returns MyClass2.class. BUT: >>> >>> Stack 2 >>> @CallerSensitive Reflection.getCallerClass() >>> @CallerSensitive MyClass1.method1(); >>> @CallerSensitive MyClass2.method2(); >>> MyClass3.method3(); >>> >>> In this case, getCallerClass() STILL returns MyClass2.class. Based on the plain-language meaning of @CallerSensitive, I would expect getCallerClass() to return MyClass3.class in the second case. But, indeed, the JavaDoc for Reflection.getCallerClass() says: "Returns the class of the caller of the method calling this method." So, then, what's the point of @CallerSensitive? Looking at the code: >>> >>> vframeStream vfst(thread); >>> // Cf. LibraryCallKit::inline_native_Reflection_getCallerClass >>> for (int n = 0; !vfst.at_end(); vfst.security_next(), n++) { >>> Method* m = vfst.method(); >>> assert(m != NULL, "sanity"); >>> switch (n) { >>> case 0: >>> // This must only be called from Reflection.getCallerClass >>> if (m->intrinsic_id() != vmIntrinsics::_getCallerClass) { >>> THROW_MSG_NULL(vmSymbols::java_lang_InternalError(), "JVM_GetCallerClass must only be called from Reflection.getCallerClass"); >>> } >>> // fall-through >>> case 1: >>> // Frame 0 and 1 must be caller sensitive. >>> if (!m->caller_sensitive()) { >>> THROW_MSG_NULL(vmSymbols::java_lang_InternalError(), err_msg("CallerSensitive annotation expected at frame %d", n)); >>> } >>> break; >>> default: >>> if (!m->is_ignored_by_security_stack_walk()) { >>> // We have reached the desired frame; return the holder class. >>> return (jclass) JNIHandles::make_local(env, m->method_holder()->java_mirror()); >>> } >>> break; >>> } >>> } >>> >>> It seems to me that @CallerSensitive is completely pointless. This is ALWAYS going to return the first non-reflection frame after frame 1, regardless of @CallerSensitive. If @CallerSensitive were really supposed to have an actual purpose, it would seem to me that the last part should be this: >>> >>> if (!m->is_ignored_by_security_stack_walk() && !m->caller_sensitive()) { >>> // We have reached the desired frame; return the holder class. >>> return (jclass) JNIHandles::make_local(env, m->method_holder()->java_mirror()); >>> } >>> >>> Am I completely missing the point here? I just don't see a reason for @CallerSensitive. The code could do the exact same thing it currently is without @CallerSensitive (except for enforcing that frame 1 is @CallerSensitive, which really isn't necessary if you aren't using it in further frames). >>> >>> Thoughts? >>> >>> Nick >>> >>> On Jul 30, 2013, at 10:33 AM, Jochen Theodorou wrote: >>> >>>> Am 30.07.2013 16:16, schrieb Peter Levart: >>>>> On 07/30/2013 03:19 PM, Jochen Theodorou wrote: >>>>>> Am 30.07.2013 14:17, schrieb Peter Levart: >>>>>> [...] >>>>>>> So what would give Groovy or other language runtimes headaches when all >>>>>>> there was was a parameter-less getCallerClass() API? Aren't the >>>>>>> intermediate frames inserted by those runtimes controlled by the >>>>>>> runtimes? Couldn't the "surface" runtime-inserted methods capture the >>>>>>> caller and pass it down? I guess the problem is supporting calling the >>>>>>> caller-sensitive methods like Class.forName(String) and such which don't >>>>>>> have the overloaded variant taking caller Class or ClassLoader as an >>>>>>> argument... >>>>>> Speaking for Groovy... >>>>>> those intermediate frames are runtime controlled, yes, but passing down >>>>>> the caller class is exactly the problem. Imagine I would suggest that >>>>>> each and every method definition in Java automatically gets an >>>>>> additional parameter for the caller class, just to have access to it >>>>>> inside the method. You would not accept that for Java, would you? And so >>>>>> we cannot accept that for Groovy if we want to keep integration with >>>>>> Java... >>>>> Are you talking about internal Groovy implementation (the >>>>> runtime-inserted methods) or the publicly visible API? >>>> that's the problem, it is a mix, some internal, other not. We are going to change that in Groovy 3 >>>> >>>>> One solution for >>>>> internal implementation of Groovy could be (speaking by heart since I >>>>> don't know the internals of Groovy) for the "surface" public API method >>>>> which doesn't have to have the special caller parameter, to capture the >>>>> caller with getCallerClass() parameterless API (possibly enclosed with a >>>>> quick check confirming that it might actually be needed) and bind it to >>>>> a ThreadLocal, then use this ThreadLocal down at the end... >>>> confirming that it might actually be needed is a problem. In the old fallback path we don't know what we call until after we are deep in runtime code, and there it is too late. In the other paths we could mark those methods in a @CallerSensitive style and do it in that case only. >>>> >>>>>> and the good integration with Java is one of the key points of >>>>>> Groovy. Even if we make something like that @CallerSensitive and add the >>>>>> parameter only in those cases, we break being able to override methods. >>>>> I guess I don't know every Groovy need to obtain the caller class. I >>>>> thought the problem was to support calling caller-sensitive methods in >>>>> Java API (like Class.forName(String)) from within Groovy code, where >>>>> there are runtime-inserted frames between the "call-site" and the target >>>>> method. Are there any other needs? >>>> ok, there is a misunderstanding... >>>> >>>> if we call a Java implemented method from Groovy, which is using getCallerClass() it may or may not work. In general this does not work and our problem is not about that at all. With the change to let getCallerClass() ignore some reflective frames it will work actually better as long as we use our custom callsite caching implementation, it will not work if indy is used or the fallback path. >>>> >>>> To be able to call a method Class#forName(String), we need to "replace" it with an implementation of our own, which we do with an approach similar to extension methods (only that ours can hide existing implementation methods for groovy). And in there we need to get to the caller class >>>> >>>> Our problem though is @Grab which is an annotation to add elements to the classpath while running a script. >>>> >>>>>> Plus, before Groovy3 is not done we have to support several call paths. >>>>>> And the oldest one, which is still a fallback, does not support >>>>>> transporting the caller class through the runtime layers at all. >>>>>> Changing here is a breaking change. >>>>> Could you describe those call-paths? Examples of Groovy code and to what >>>>> it gets translated (equivalent Java code at call site) with a brief >>>>> description of what each intermediate layer (between the call-site and >>>>> the target method) does and at which point the caller class is extracted... >>>> the code generated at the call site depends on several factors actually... The call site code itself is usually not very informative >>>> >>>> I start with Groovy 1.0, since that is basically the fallback path. Here this.foo() translates more or less to >>>> ScriptBytecodeAdapter.invokeMethod0(staticCallerClass, this,"foo") >>>> which basically does this.getMetaClass().invokeMethod(staticCallerClass, this, "foo"). The problem is that the meta class might be user supplied and the code executed in invokeMethod as well. The invocation is then finally done by reflection. That means we have frames from ScriptBytecodeAdapter, from the meta class, as well as maybe frames from a custom meta class and reflection frames. At the level of ScriptBytecodeAdapter there is a means of transporting the caller class, but that is the static one. Once there is a subclass, this information is different from what is needed here and it cannot simply be exchanged. Even if the bytecode adapter is changed, we cannot change the public API for MetaClass#invokeMethod now. And then the information would be lost. >>>> >>>> In later versions of Groovy (since 1.6) we introduced a custom call site caching technique, which uses runtime generated classes to create a helper class per call site and is then used for invocation. At the callsite we basically have something like callsiteArray[i].invoke(..). Here again the staticCallerClass can be found. In this version we are able to "get" the method we want to invoke, before invoking it (bypassing MetaClass#invokeMethod). But to be able to get the method, certain conditions have to be met (like no user supplied meta class). If they are not met, then we do basically the same path as in 1.0, only that we don't use ScriptBytecodeAdapter. Instead We use our CallSite class as entrance point, which then makes the call to the meta class. In the "efficent" case we have now frames from the callsite handling code between the callsite and the target method only. This includes reflection in the first instantiation, later the generated class is used so it reduces to two frame >>>> s of which one is the Callsite entrance point, the other a frame form the generated method. In the fallback case we have frames from the callsite handling code, plus meta class code, plus reflection of course. Again the fallback case prevents us from transporting the caller information to the target method. If we ignore the fallback case, then we could here maybe use the Threadlocal information. It will require a new callsite interface for the bytecode though, meaning this code will not work for precompiled grovvy of older version, excluding from getting into Groovy 2.1.x, since it would be a breaking change. The earliest version for that would be Groovy 2.2.0, which is almost in RC now. Effectively it would mean we would have to do a 2.3.0 very soon after most probably. >>>> >>>> In Groovy 2 we added an indy implementation, which replaces the callsite caching code. At the callsite we have here basically invokedynamic "foo" with IndyInterface#bootstrap. bootstrap will first introduce a target for IndyInterface#selectMethod, since I need the runtime types instead of the static ones. The static caller class information is here part of the bootstrap method as Lookup object, added by invokedynamic itself. After selectMethod is done we have an initial invocation using invokeExact and later invocations by the handle stored in the callsite. Of course the same conditions as for the callsite caching above have to be met, meaning the fallback path might appear. That makes initially one IndyInterface frame, then invokedynamic and lambda related frames, then optionally the traget method, or in the fallback case the meta class frames plus reflection >>>> >>>> >>>> bye Jochen >>>> >>>> -- >>>> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead >>>> blog:http://blackdragsview.blogspot.com/ >>>> german groovy discussion newsgroup: de.comp.lang.misc >>>> For Groovy programming sources visithttp://groovy-lang.org >>>> >> > From chris.hegarty at oracle.com Fri Aug 9 12:50:52 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 09 Aug 2013 12:50:52 +0000 Subject: hg: jdk8/tl/jdk: 8022661: InetAddress.writeObject() performs flush() on object output stream Message-ID: <20130809125140.B289D48748@hg.openjdk.java.net> Changeset: 84004d0e3fdd Author: chegar Date: 2013-08-09 13:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/84004d0e3fdd 8022661: InetAddress.writeObject() performs flush() on object output stream Reviewed-by: michaelm, alanb ! src/share/classes/java/net/InetAddress.java From paul.sandoz at oracle.com Fri Aug 9 13:04:49 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 9 Aug 2013 15:04:49 +0200 Subject: RFR 8014824: Document Spliterator characteristics and binding policy of java util collection impls In-Reply-To: <520376A3.1020300@gmail.com> References: <1C62EB3E-11FF-484B-BC00-2DED97C33A8F@oracle.com> <52036BF6.3050807@oracle.com> <036F6A65-8192-4C70-876B-5F4A65C06DB7@oracle.com> <520376A3.1020300@gmail.com> Message-ID: <4B9C62F5-215F-42B4-AFD3-CA22B50B252D@oracle.com> Hi Peter, On Aug 8, 2013, at 12:44 PM, Peter Levart wrote: > Hi Paul, > > Shouldn't Spliterators.EmptySpliterator also be IMMUTABLE, DISTINCT and ORDERED? Like Collections.singletonSpliterator... > Perhaps, for consistency. IIRC at the time it was felt a little odd to declare such characteristics when no elements are present. > Although a mutable Collection implementation or immutable with size()>1 can never be Set and List at the same time, A singleton immutable Collection I think could be. Likewise for empty immutable Collection... So why couldn't a spliterator obtained from singleton List be DISTINCT? Likewise why couldn't a spliterator obtained from singleton Set be ORDERED?... That could be an option, but i was hesitant about explicitly stating such optional constraints on Set/List. For the current Collection implementations i would prefer not to enforce the reporting of characteristics for a size of 0 or 1. > These are runtime characteristics, not characteristics of a particular collection type. > For N > 1 I would argue characteristics of top-level spliterators do map to a particular collection type. Nearly all of the characteristics for at most one element are irrelevant for optimizing computation (SIZED/SUBSIZED/IMMUTABLE/NONULL are probably the most useful of the not very useful). It's almost as if nothing == everything in this case i.e. reporting no/few characteristics is the same as reporting all/most characteristics :-) There is now Collections.emptyNavigableMap/emptySortedMap implying SORTED should also be reported for the empty spliterator, unless we optionally constrain SortedSet. There are currently no type safe ways to obtain a singleton NavigableMap/SortedSet, but perhaps there could be in the future? (there was probably a good reason for not adding them with the empty versions but i dunno what that reason was). Reporting SORTED for all singletons is problematic because the singleton element may not be Comparable. So i thought rather than attempting to be explicit about 0 or 1 element and the type holding that element it was just easier all round to do some hand-waving on Collections or Collection i.e. all bets are off as to what characteristics are reported (beyond that of SIZED/SUBSIZED/IMMUTABLE/NONNULL?) and it does not matter cause you will anyway not be able to to anything useful with them. -- Perhaps i can separate out this webrev, i presume there is little issue with the other doc updates, if so i can commit those for this bug and spin up another for this aspect. Paul. From chris.hegarty at oracle.com Fri Aug 9 13:51:25 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 09 Aug 2013 14:51:25 +0100 Subject: RFR: JAXP in JDK8/7u40 : 8022548 : SPECJVM2008 has errors introduced in 7u40-b34 In-Reply-To: References: <520484E6.4020204@oracle.com> Message-ID: <5204F3DD.1020403@oracle.com> On 09/08/2013 11:36, Lance Andersen - Oracle wrote: > Hi Joe, > > The changes look fine +1 Looks ok to me. Pitty we have to maintain this kind of usage! -Chris. > > Best > Lance > On Aug 9, 2013, at 1:57 AM, huizhe wang wrote: > >> Hi, >> >> The root cause of this issue is that SPECJVM2008 uses a 3rd party parser XOM 1.1 to convert the output to its canonical form. The XOM parser directly references to the JDK parser implementation "SAXParser" with a different configuration than the default JDK parser, in this case, the DTD-only parser configuration "DTDConfiguration". In JAXP 1.5, we added XMLSecurityPropertyManager that is instantiated in the default configuration "XML11Configuration". Since XMLSecurityPropertyManager is not supported by DTDConfiguration, XOM no longer works. >> >> This patch is to add the XMLSecurityPropertyManager to DTDConfiguration so that XOM will continue to work properly with jdk8/7u40. I don't know if there's any library out there that calls into NonValidatingConfiguration directly. Since it's in a similar situation as DTDConfiguration, I added XMLSecurityPropertyManager support as well. >> >> webrec: http://cr.openjdk.java.net/~joehw/jdk8/8022548/webrev/ >> >> test: >> I created a new test that runs with xom1.1.jar on the classpath, and passed. >> all unit tests/SQE regression tests passed >> >> Thanks, >> Joe > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From chris.hegarty at oracle.com Fri Aug 9 15:03:30 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 09 Aug 2013 16:03:30 +0100 Subject: RFR lint warnings in j.u.concurrent.** Message-ID: <520504C2.3000309@oracle.com> These changes address the remaining lint warnings in the j.u.concurrent.** package(s). The changes are already in the JSR166 CVS, this is a request to bring them into jdk8. diff -r 84004d0e3fdd src/share/classes/java/util/concurrent/CompletableFuture.java --- a/src/share/classes/java/util/concurrent/CompletableFuture.java Fri Aug 09 13:50:13 2013 +0100 +++ b/src/share/classes/java/util/concurrent/CompletableFuture.java Fri Aug 09 15:58:41 2013 +0100 @@ -420,6 +420,7 @@ public class CompletableFuture implem } /** Base class can act as either FJ or plain Runnable */ + @SuppressWarnings("serial") abstract static class Async extends ForkJoinTask implements Runnable, AsynchronousCompletionTask { public final Void getRawResult() { return null; } @@ -671,6 +672,7 @@ public class CompletableFuture implem } // Opportunistically subclass AtomicInteger to use compareAndSet to claim. + @SuppressWarnings("serial") abstract static class Completion extends AtomicInteger implements Runnable { } diff -r 84004d0e3fdd src/share/classes/java/util/concurrent/ConcurrentHashMap.java --- a/src/share/classes/java/util/concurrent/ConcurrentHashMap.java Fri Aug 09 13:50:13 2013 +0100 +++ b/src/share/classes/java/util/concurrent/ConcurrentHashMap.java Fri Aug 09 15:58:41 2013 +0100 @@ -4716,6 +4716,7 @@ public class ConcurrentHashMap exte * Base class for bulk tasks. Repeats some fields and code from * class Traverser, because we need to subclass CountedCompleter. */ + @SuppressWarnings("serial") abstract static class BulkTask extends CountedCompleter { Node[] tab; // same as Traverser Node next; diff -r 84004d0e3fdd src/share/classes/java/util/concurrent/atomic/Striped64.java --- a/src/share/classes/java/util/concurrent/atomic/Striped64.java Fri Aug 09 13:50:13 2013 +0100 +++ b/src/share/classes/java/util/concurrent/atomic/Striped64.java Fri Aug 09 15:58:41 2013 +0100 @@ -43,6 +43,7 @@ import java.util.concurrent.ThreadLocalR * for classes supporting dynamic striping on 64bit values. The class * extends Number so that concrete subclasses must publicly do so. */ + at SuppressWarnings("serial") abstract class Striped64 extends Number { /* * This class maintains a lazily-initialized table of atomically -Chris. From ivan.gerasimov at oracle.com Fri Aug 9 15:05:32 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 09 Aug 2013 19:05:32 +0400 Subject: RFR [6961766]: PrintStream.write() should flush at most once In-Reply-To: <5202FFF9.8040203@oracle.com> References: <52012698.4090005@oracle.com> <5201D65E.3090504@oracle.com> <52023B4D.3090001@oracle.com> <520289B5.9080903@oracle.com> <5202FFF9.8040203@oracle.com> Message-ID: <5205053C.7090506@oracle.com> Hello David! On 08.08.2013 6:18, David Holmes wrote: > Hi Ivan, > > On 8/08/2013 3:53 AM, Ivan Gerasimov wrote: >> Hello David! >> >> Thanks for review. >> >>> Yes - this is NOT A BUG this is the spec for this class: >>> >>> "Optionally, a PrintStream can be created so as to flush >>> automatically; this means that the flush method is automatically >>> invoked after a byte array is written, one of the println methods is >>> invoked, or a newline character or byte ('\n') is written. " >>> >> Sorry, I don't see how the proposed change would contradict the spec . >> The code first writes a char[] buffer to an OutputStream, and then >> invokes flush() if the written array contained at least one '\n' char. >> >> In addition to that, the documentation for OutputStream#flush() says: >> "Flushes this output stream and forces any buffered output bytes to be >> written out." Thus, there should be no point to have several subsequent >> calls to flush() with no data writes between them. > > Sorry I misread the original code - it actually violates the spec as > well in my opinion. As I read it there should be a flush as soon as > the \n is written, not simply a flush at some later point in time if a > \n happened to have been written. As written those additional flushes > will be no-ops as you rightly point out. So your change is a more > efficient version of the existing "incorrect" implementation. > It's not hard to rewrite the code, so it would flush after each '\n' occurrence. But would it be a good change? It would likely introduce a performance degradation and change the current behavior of write() function. The fix as it was proposed (reduce number of flushes to at most one) doesn't make any difference in most cases. As Alan said, in most implementations of OutputStream, flush() is no-op. It can slightly improve performance with PipedOutputStream as it synchronizes on the sink in its flush implementation. Sincerely yours, Ivan > That said the layering of the streams in this class is quite confusing > to me and it seems odd that if both textOut and charOut are > unconditionally flushed in this method, then why is 'out' only flushed > based on autoflush and the presence of the \n ?? > > But I withdraw my objections as what you propose does not change the > behaviour. > > Thanks, > David > >> I don't insist on pushing this change, but I think it's harmless and may >> be useful. >> >> Sincerely yours, >> Ivan >> >>> This bug report should be closed as "not an issue". >>> >>> David >>> ----- >>> >>> >>>> -Alan >>> >>> >> > > From Lance.Andersen at oracle.com Fri Aug 9 15:27:21 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 9 Aug 2013 11:27:21 -0400 Subject: RFR lint warnings in j.u.concurrent.** In-Reply-To: <520504C2.3000309@oracle.com> References: <520504C2.3000309@oracle.com> Message-ID: <38328D0F-C4BD-4E20-9164-C3D6EB4DA280@oracle.com> looks fine chris Best Lance On Aug 9, 2013, at 11:03 AM, Chris Hegarty wrote: > These changes address the remaining lint warnings in the j.u.concurrent.** package(s). > > The changes are already in the JSR166 CVS, this is a request to bring them into jdk8. > > diff -r 84004d0e3fdd src/share/classes/java/util/concurrent/CompletableFuture.java > --- a/src/share/classes/java/util/concurrent/CompletableFuture.java Fri Aug 09 13:50:13 2013 +0100 > +++ b/src/share/classes/java/util/concurrent/CompletableFuture.java Fri Aug 09 15:58:41 2013 +0100 > @@ -420,6 +420,7 @@ public class CompletableFuture implem > } > > /** Base class can act as either FJ or plain Runnable */ > + @SuppressWarnings("serial") > abstract static class Async extends ForkJoinTask > implements Runnable, AsynchronousCompletionTask { > public final Void getRawResult() { return null; } > @@ -671,6 +672,7 @@ public class CompletableFuture implem > } > > // Opportunistically subclass AtomicInteger to use compareAndSet to claim. > + @SuppressWarnings("serial") > abstract static class Completion extends AtomicInteger implements Runnable { > } > > diff -r 84004d0e3fdd src/share/classes/java/util/concurrent/ConcurrentHashMap.java > --- a/src/share/classes/java/util/concurrent/ConcurrentHashMap.java Fri Aug 09 13:50:13 2013 +0100 > +++ b/src/share/classes/java/util/concurrent/ConcurrentHashMap.java Fri Aug 09 15:58:41 2013 +0100 > @@ -4716,6 +4716,7 @@ public class ConcurrentHashMap exte > * Base class for bulk tasks. Repeats some fields and code from > * class Traverser, because we need to subclass CountedCompleter. > */ > + @SuppressWarnings("serial") > abstract static class BulkTask extends CountedCompleter { > Node[] tab; // same as Traverser > Node next; > diff -r 84004d0e3fdd src/share/classes/java/util/concurrent/atomic/Striped64.java > --- a/src/share/classes/java/util/concurrent/atomic/Striped64.java Fri Aug 09 13:50:13 2013 +0100 > +++ b/src/share/classes/java/util/concurrent/atomic/Striped64.java Fri Aug 09 15:58:41 2013 +0100 > @@ -43,6 +43,7 @@ import java.util.concurrent.ThreadLocalR > * for classes supporting dynamic striping on 64bit values. The class > * extends Number so that concrete subclasses must publicly do so. > */ > + at SuppressWarnings("serial") > abstract class Striped64 extends Number { > /* > * This class maintains a lazily-initialized table of atomically > > > -Chris. -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Lance.Andersen at oracle.com Fri Aug 9 15:34:58 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 9 Aug 2013 11:34:58 -0400 Subject: RFR: JDK-8021977 -- Open File Using Java.IO May Throw IOException On Windows In-Reply-To: <52042919.50301@oracle.com> References: <52042919.50301@oracle.com> Message-ID: <021C5584-D159-4DA5-9446-B0F91D9ADE96@oracle.com> Looks OK Dan Best Lance On Aug 8, 2013, at 7:26 PM, Dan Xu wrote: > Hi All, > > Please review a simple bug fix for JDK8021977. For the backward compatibility, I have to remove the code that might throw out IOExceptionin the native side. The issue has never been reported.But it exists in a possible code path. And it is not easy to write a testcase for this obvious but corner issue. I am relying on the existing IO testcases for testing. Thanks! > > Webrev: http://cr.openjdk.java.net/~dxu/8021977/webrev.00/ > Bug: http://bugs.sun.com/view_bug.do?bug_id=8021977 > > -Dan > -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Fri Aug 9 15:37:52 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 09 Aug 2013 08:37:52 -0700 Subject: RFR: JAXP in JDK8/7u40 : 8022548 : SPECJVM2008 has errors introduced in 7u40-b34 In-Reply-To: <5204F3DD.1020403@oracle.com> References: <520484E6.4020204@oracle.com> <5204F3DD.1020403@oracle.com> Message-ID: <52050CD0.6000100@oracle.com> Thanks Lance and Chris for the quick review! Joe On 8/9/2013 6:51 AM, Chris Hegarty wrote: > On 09/08/2013 11:36, Lance Andersen - Oracle wrote: >> Hi Joe, >> >> The changes look fine > > +1 Looks ok to me. Pitty we have to maintain this kind of usage! > > -Chris. > >> >> Best >> Lance >> On Aug 9, 2013, at 1:57 AM, huizhe wang wrote: >> >>> Hi, >>> >>> The root cause of this issue is that SPECJVM2008 uses a 3rd party >>> parser XOM 1.1 to convert the output to its canonical form. The XOM >>> parser directly references to the JDK parser implementation >>> "SAXParser" with a different configuration than the default JDK >>> parser, in this case, the DTD-only parser configuration >>> "DTDConfiguration". In JAXP 1.5, we added >>> XMLSecurityPropertyManager that is instantiated in the default >>> configuration "XML11Configuration". Since >>> XMLSecurityPropertyManager is not supported by DTDConfiguration, XOM >>> no longer works. >>> >>> This patch is to add the XMLSecurityPropertyManager to >>> DTDConfiguration so that XOM will continue to work properly with >>> jdk8/7u40. I don't know if there's any library out there that calls >>> into NonValidatingConfiguration directly. Since it's in a similar >>> situation as DTDConfiguration, I added XMLSecurityPropertyManager >>> support as well. >>> >>> webrec: http://cr.openjdk.java.net/~joehw/jdk8/8022548/webrev/ >>> >>> test: >>> I created a new test that runs with xom1.1.jar on the >>> classpath, and passed. >>> all unit tests/SQE regression tests passed >>> >>> Thanks, >>> Joe >> >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> From mark.reinhold at oracle.com Fri Aug 9 15:41:02 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 09 Aug 2013 08:41:02 -0700 Subject: RFR: JDK-8021977 -- Open File Using Java.IO May Throw IOException On Windows In-Reply-To: <52042919.50301@oracle.com> References: <52042919.50301@oracle.com> Message-ID: <20130809084102.425419@eggemoggin.niobe.net> 2013/8/8 9:26 -0700, dan.xu at oracle.com: > Webrev: http://cr.openjdk.java.net/~dxu/8021977/webrev.00/ > Bug: http://bugs.sun.com/view_bug.do?bug_id=8021977 Looks good, but the synopsis is rather horrid ("Java.IO"?). Please use the updated synopsis I just pasted into the bug report: "Opening a file using java.io can throw IOException on Windows". - Mark From aleksey.shipilev at oracle.com Fri Aug 9 15:43:24 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 09 Aug 2013 19:43:24 +0400 Subject: class SplittableRandom In-Reply-To: <5204E0C1.5060200@cs.oswego.edu> References: <51DDB26D.8050506@cs.oswego.edu> <51DE6069.2060308@gmail.com> <51DEA230.2060504@cs.oswego.edu> <51DEA3D5.5000509@oracle.com> <51E1549D.4060403@cs.oswego.edu> <51E414C6.9070400@cs.oswego.edu> <6099D28A-0B95-42A4-A59B-5E1C465EDCA9@oracle.com> <480BCC80-2A9C-4321-B81B-47487E90C0D7@oracle.com> <51F6B47E.1040102@gmail.com> <51F7D77B.6010300@cs.oswego.edu> <5204E0C1.5060200@cs.oswego.edu> Message-ID: <52050E1C.1090407@oracle.com> On 08/09/2013 04:29 PM, Doug Lea wrote: > Currently at: > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/SplittableRandom.java?view=log Looks good. Stupid questions below: * Why use InetAddress.getLocalHost() for the initial seed? I understand you don't want to use SecureRandom to dodge the depleted entropy case, but isn't that the over-optimization to initialize the static seed once per VM/classloader? * Is there something in floating point math forcing us to use the constructions like "if (!(origin < bound))" instead of "if (origin >= bound)"? Thanks, -Aleksey. From dl at cs.oswego.edu Fri Aug 9 15:57:49 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 09 Aug 2013 11:57:49 -0400 Subject: class SplittableRandom In-Reply-To: <52050E1C.1090407@oracle.com> References: <51DDB26D.8050506@cs.oswego.edu> <51DE6069.2060308@gmail.com> <51DEA230.2060504@cs.oswego.edu> <51DEA3D5.5000509@oracle.com> <51E1549D.4060403@cs.oswego.edu> <51E414C6.9070400@cs.oswego.edu> <6099D28A-0B95-42A4-A59B-5E1C465EDCA9@oracle.com> <480BCC80-2A9C-4321-B81B-47487E90C0D7@oracle.com> <51F6B47E.1040102@gmail.com> <51F7D77B.6010300@cs.oswego.edu> <5204E0C1.5060200@cs.oswego.edu> <52050E1C.1090407@oracle.com> Message-ID: <5205117D.4070606@cs.oswego.edu> On 08/09/13 11:43, Aleksey Shipilev wrote: > On 08/09/2013 04:29 PM, Doug Lea wrote: >> Currently at: >> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/SplittableRandom.java?view=log > > Looks good. > > Stupid questions below: > > * Why use InetAddress.getLocalHost() for the initial seed? I understand > you don't want to use SecureRandom to dodge the depleted entropy case, (Yes. SecoreRandom can and does encounter entropy-gathering stalls for users that we don't want to impose without a security rationale.) > but isn't that the over-optimization to initialize the static seed once > per VM/classloader? The hashed seed is just part of a hash forming initial seed. It is a safeguard for the case in which all machines in some big cluster start up with exact same currentTimeMillis and nanoTime so have same seed. Which is extremely unlikely to being with, but using host hash is extremely extremely unlikely :-) > > * Is there something in floating point math forcing us to use the > constructions like "if (!(origin < bound))" instead of "if (origin >= > bound)"? Yes. It traps NaNs and the like. -Doug From sean.coffey at oracle.com Fri Aug 9 16:26:27 2013 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 09 Aug 2013 17:26:27 +0100 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52041965.3090808@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52040FDA.2040600@oracle.com> <52041895.9010706@oracle.com> <52041965.3090808@oracle.com> Message-ID: <52051833.5090204@oracle.com> On the regression testcase theme, it got me thinking as to whether we've any java APIs which can query what the native heap usage of the JVM. Is that available over JMX ? I tried the MBeanServer approach but didn't get the expected results. Queried the "NonHeapMemoryUsage" object. something like. MBeanServer server = ManagementFactory.getPlatformMBeanServer(); ObjectName memory = new ObjectName(MEMORY_MXBEAN_NAME); Object ob = server.getAttribute(memory, "NonHeapMemoryUsage"); MemoryUsage mu = MemoryUsage.from((CompositeData) ob); System.out.println("Nonheap : " + mu.getUsed()); What exactly is JMX measuring in "NonHeapMemoryUsage" mode ? Any pointers ? regards, Sean. On 08/08/13 23:19, Michael McMahon wrote: > Ivan, > > Right, it's not worth trying to do the equivalent, whatever it is, for > Windows. > The test is fine with me. > > Thanks > Michael > > On 08/08/13 23:15, Ivan Gerasimov wrote: >> Michael, >> >> The test uses /proc/self/stat file to detect changes in virtual >> memory usage. >> This approach is specific for Linux. >> That's why I included the check of OS in the test. >> >> Sincerely yours, >> Ivan >> >> On 09.08.2013 1:38, Michael McMahon wrote: >>> Yes, definitely "othervm" would be required for the test. Also, why >>> skip other OS'es? >>> The fix is only for Linux, but it might catch future leaks on Windows. >>> >>> The trouble with tests like this, is they sometimes don't age well. >>> Future changes in OS kernel behavior could cause problems but I >>> guess 32MB is a fairly large difference. >>> So, it should be okay >>> >>> Michael >>> >>> On 08/08/13 22:15, David Holmes wrote: >>>> Main fix looks good to me. >>>> >>>> Regression test may need some tweaking eg I think othervm will be >>>> needed. >>>> >>>> Also this: >>>> >>>> System.out.println("WARNING: Cannot perform memory leak detection >>>> on this OS"); >>>> >>>> should probably just say something like "Test skipped on this OS" - >>>> there are other tests that do this so just check if there is common >>>> terminology. (In the future we may have keyword tags to flag this >>>> as linux only etc.) >>>> >>>> Thanks, >>>> David >>>> >>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>>> Chris, if it's not too late, I'd like to include a regtest in the >>>>> fix. >>>>> >>>>> Here's webrev that includes the test: >>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>>> >>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 >>>>> and jdk7 >>>>> as expected. >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>>> Looks good to me. Thanks Ivan. >>>>>> >>>>>> -Chris. >>>>>> >>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>>> Hello Chris! >>>>>>> >>>>>>> Here's the update: >>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>>> >>>>>>> Thanks for offering the sponsorship! >>>>>>> Here's the hg-export >>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>>> Thanks for taking this Ivan. >>>>>>>> >>>>>>>> Can you please make the changes suggested by both David and Alan ( >>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>>> GetStringUTFChars >>>>>>>> fails ( returns NULL ), then I will sponsor this change into >>>>>>>> jdk8 for >>>>>>>> you. >>>>>>>> >>>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>>> Ivan, >>>>>>>>> >>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>>> David, Alan, >>>>>>>>>> >>>>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>>>> necessary. >>>>>>>>> >>>>>>>>> You don't need to throw it yourself: >>>>>>>>> >>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>>> >>>>>>>>> Assuming a correct VM implementation if NULL is returned then >>>>>>>>> an OOME >>>>>>>>> should already be pending and will be thrown as soon as your >>>>>>>>> native >>>>>>>>> code >>>>>>>>> returns to Java. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>>> indentation. >>>>>>>>>> >>>>>>>>>> Would you please review the updated webrev? >>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>> >>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars >>>>>>>>>>>> cannot >>>>>>>>>>>> return >>>>>>>>>>>> NULL. >>>>>>>>>>>> For allocation of the result string it calls AllocateHeap() >>>>>>>>>>>> with >>>>>>>>>>>> the >>>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply >>>>>>>>>>>> stops >>>>>>>>>>>> VM. >>>>>>>>>>> >>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed >>>>>>>>>>> to throw >>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>>> >>>>>>>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>> Ivan >>>>>>>>>>>> >>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>>> >>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>>>> there) is >>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>>>> returns >>>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>>> >>>>>>>>>>>>> -Alan. >>>>>>>>>>>>> >>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>>>>>>> memory. >>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>>>>> available.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>> allocation? >>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>> Ivan >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>> >>> >>> >> > From joe.darcy at oracle.com Fri Aug 9 16:51:28 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 09 Aug 2013 09:51:28 -0700 Subject: RFR lint warnings in j.u.concurrent.** In-Reply-To: <38328D0F-C4BD-4E20-9164-C3D6EB4DA280@oracle.com> References: <520504C2.3000309@oracle.com> <38328D0F-C4BD-4E20-9164-C3D6EB4DA280@oracle.com> Message-ID: <52051E10.2080204@oracle.com> Agreed; looks good. Thanks, -Joe On 8/9/2013 8:27 AM, Lance Andersen - Oracle wrote: > looks fine chris > > Best > Lance > On Aug 9, 2013, at 11:03 AM, Chris Hegarty wrote: > >> These changes address the remaining lint warnings in the j.u.concurrent.** package(s). >> >> The changes are already in the JSR166 CVS, this is a request to bring them into jdk8. >> >> diff -r 84004d0e3fdd src/share/classes/java/util/concurrent/CompletableFuture.java >> --- a/src/share/classes/java/util/concurrent/CompletableFuture.java Fri Aug 09 13:50:13 2013 +0100 >> +++ b/src/share/classes/java/util/concurrent/CompletableFuture.java Fri Aug 09 15:58:41 2013 +0100 >> @@ -420,6 +420,7 @@ public class CompletableFuture implem >> } >> >> /** Base class can act as either FJ or plain Runnable */ >> + @SuppressWarnings("serial") >> abstract static class Async extends ForkJoinTask >> implements Runnable, AsynchronousCompletionTask { >> public final Void getRawResult() { return null; } >> @@ -671,6 +672,7 @@ public class CompletableFuture implem >> } >> >> // Opportunistically subclass AtomicInteger to use compareAndSet to claim. >> + @SuppressWarnings("serial") >> abstract static class Completion extends AtomicInteger implements Runnable { >> } >> >> diff -r 84004d0e3fdd src/share/classes/java/util/concurrent/ConcurrentHashMap.java >> --- a/src/share/classes/java/util/concurrent/ConcurrentHashMap.java Fri Aug 09 13:50:13 2013 +0100 >> +++ b/src/share/classes/java/util/concurrent/ConcurrentHashMap.java Fri Aug 09 15:58:41 2013 +0100 >> @@ -4716,6 +4716,7 @@ public class ConcurrentHashMap exte >> * Base class for bulk tasks. Repeats some fields and code from >> * class Traverser, because we need to subclass CountedCompleter. >> */ >> + @SuppressWarnings("serial") >> abstract static class BulkTask extends CountedCompleter { >> Node[] tab; // same as Traverser >> Node next; >> diff -r 84004d0e3fdd src/share/classes/java/util/concurrent/atomic/Striped64.java >> --- a/src/share/classes/java/util/concurrent/atomic/Striped64.java Fri Aug 09 13:50:13 2013 +0100 >> +++ b/src/share/classes/java/util/concurrent/atomic/Striped64.java Fri Aug 09 15:58:41 2013 +0100 >> @@ -43,6 +43,7 @@ import java.util.concurrent.ThreadLocalR >> * for classes supporting dynamic striping on 64bit values. The class >> * extends Number so that concrete subclasses must publicly do so. >> */ >> + at SuppressWarnings("serial") >> abstract class Striped64 extends Number { >> /* >> * This class maintains a lazily-initialized table of atomically >> >> >> -Chris. > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From dan.xu at oracle.com Fri Aug 9 17:22:57 2013 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 09 Aug 2013 10:22:57 -0700 Subject: RFR: JDK-8021977 -- Open File Using Java.IO May Throw IOException On Windows In-Reply-To: <20130809084102.425419@eggemoggin.niobe.net> References: <52042919.50301@oracle.com> <20130809084102.425419@eggemoggin.niobe.net> Message-ID: <52052571.5010807@oracle.com> Thank you. I will use the updated synopsis for my pushtoday. -Dan On 08/09/2013 08:41 AM, mark.reinhold at oracle.com wrote: > 2013/8/8 9:26 -0700, dan.xu at oracle.com: >> Webrev: http://cr.openjdk.java.net/~dxu/8021977/webrev.00/ >> Bug: http://bugs.sun.com/view_bug.do?bug_id=8021977 > Looks good, but the synopsis is rather horrid ("Java.IO"?). Please use > the updated synopsis I just pasted into the bug report: "Opening a file > using java.io can throw IOException on Windows". > > - Mark From mike.duigou at oracle.com Fri Aug 9 17:23:49 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 9 Aug 2013 10:23:49 -0700 Subject: RFR lint warnings in j.u.concurrent.** In-Reply-To: <52051E10.2080204@oracle.com> References: <520504C2.3000309@oracle.com> <38328D0F-C4BD-4E20-9164-C3D6EB4DA280@oracle.com> <52051E10.2080204@oracle.com> Message-ID: Fine from me as well. On Aug 9 2013, at 09:51 , Joe Darcy wrote: > Agreed; looks good. > > Thanks, > > -Joe > > On 8/9/2013 8:27 AM, Lance Andersen - Oracle wrote: >> looks fine chris >> >> Best >> Lance >> On Aug 9, 2013, at 11:03 AM, Chris Hegarty wrote: >> >>> These changes address the remaining lint warnings in the j.u.concurrent.** package(s). >>> >>> The changes are already in the JSR166 CVS, this is a request to bring them into jdk8. >>> >>> diff -r 84004d0e3fdd src/share/classes/java/util/concurrent/CompletableFuture.java >>> --- a/src/share/classes/java/util/concurrent/CompletableFuture.java Fri Aug 09 13:50:13 2013 +0100 >>> +++ b/src/share/classes/java/util/concurrent/CompletableFuture.java Fri Aug 09 15:58:41 2013 +0100 >>> @@ -420,6 +420,7 @@ public class CompletableFuture implem >>> } >>> >>> /** Base class can act as either FJ or plain Runnable */ >>> + @SuppressWarnings("serial") >>> abstract static class Async extends ForkJoinTask >>> implements Runnable, AsynchronousCompletionTask { >>> public final Void getRawResult() { return null; } >>> @@ -671,6 +672,7 @@ public class CompletableFuture implem >>> } >>> >>> // Opportunistically subclass AtomicInteger to use compareAndSet to claim. >>> + @SuppressWarnings("serial") >>> abstract static class Completion extends AtomicInteger implements Runnable { >>> } >>> >>> diff -r 84004d0e3fdd src/share/classes/java/util/concurrent/ConcurrentHashMap.java >>> --- a/src/share/classes/java/util/concurrent/ConcurrentHashMap.java Fri Aug 09 13:50:13 2013 +0100 >>> +++ b/src/share/classes/java/util/concurrent/ConcurrentHashMap.java Fri Aug 09 15:58:41 2013 +0100 >>> @@ -4716,6 +4716,7 @@ public class ConcurrentHashMap exte >>> * Base class for bulk tasks. Repeats some fields and code from >>> * class Traverser, because we need to subclass CountedCompleter. >>> */ >>> + @SuppressWarnings("serial") >>> abstract static class BulkTask extends CountedCompleter { >>> Node[] tab; // same as Traverser >>> Node next; >>> diff -r 84004d0e3fdd src/share/classes/java/util/concurrent/atomic/Striped64.java >>> --- a/src/share/classes/java/util/concurrent/atomic/Striped64.java Fri Aug 09 13:50:13 2013 +0100 >>> +++ b/src/share/classes/java/util/concurrent/atomic/Striped64.java Fri Aug 09 15:58:41 2013 +0100 >>> @@ -43,6 +43,7 @@ import java.util.concurrent.ThreadLocalR >>> * for classes supporting dynamic striping on 64bit values. The class >>> * extends Number so that concrete subclasses must publicly do so. >>> */ >>> + at SuppressWarnings("serial") >>> abstract class Striped64 extends Number { >>> /* >>> * This class maintains a lazily-initialized table of atomically >>> >>> >>> -Chris. >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> > From chris.hegarty at oracle.com Fri Aug 9 16:57:08 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 09 Aug 2013 16:57:08 +0000 Subject: hg: jdk8/tl/jdk: 8022724: lint warnings in j.u.concurrent packages Message-ID: <20130809165838.A48BB48759@hg.openjdk.java.net> Changeset: ce1c874903cb Author: dl Date: 2013-08-09 17:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce1c874903cb 8022724: lint warnings in j.u.concurrent packages Reviewed-by: chegar, lancea, darcy ! src/share/classes/java/util/concurrent/CompletableFuture.java ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java ! src/share/classes/java/util/concurrent/atomic/Striped64.java From harold.seigel at oracle.com Wed Aug 7 19:51:04 2013 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 07 Aug 2013 15:51:04 -0400 Subject: RFR 8022259 MakeClasslist tool is buggy and its README is out of date. Message-ID: <5202A528.5060504@oracle.com> Hi, Please review this small fix for bug 8022259. This change fixes a bug in the MakeClasslist tool and updates its README.txt file. webrev: http://cr.openjdk.java.net/~hseigel/bug_8022259/ bug: http://bugs.sun.com/view_bug.do?bug_id=8022259 JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8022259 I tested the change by creating a testlist using the modified MakeClasslist tool and following the information in the changed README.txt file. Thanks! Harold From dan.xu at oracle.com Fri Aug 9 17:55:59 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Fri, 09 Aug 2013 17:55:59 +0000 Subject: hg: jdk8/tl/jdk: 8021977: Opening a file using java.io can throw IOException on Windows Message-ID: <20130809175620.B80534875C@hg.openjdk.java.net> Changeset: 03822f2389bf Author: dxu Date: 2013-08-09 10:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/03822f2389bf 8021977: Opening a file using java.io can throw IOException on Windows Summary: Remove IOException related error-handling code for backward compatibility Reviewed-by: alanb, lancea, mr ! src/windows/native/java/io/io_util_md.c From mike.duigou at oracle.com Fri Aug 9 19:01:39 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 9 Aug 2013 12:01:39 -0700 Subject: RFR 8014824: Document Spliterator characteristics and binding policy of java util collection impls In-Reply-To: <4B9C62F5-215F-42B4-AFD3-CA22B50B252D@oracle.com> References: <1C62EB3E-11FF-484B-BC00-2DED97C33A8F@oracle.com> <52036BF6.3050807@oracle.com> <036F6A65-8192-4C70-876B-5F4A65C06DB7@oracle.com> <520376A3.1020300@gmail.com> <4B9C62F5-215F-42B4-AFD3-CA22B50B252D@oracle.com> Message-ID: On Aug 9 2013, at 06:04 , Paul Sandoz wrote: > Hi Peter, > > On Aug 8, 2013, at 12:44 PM, Peter Levart wrote: > >> Hi Paul, >> >> Shouldn't Spliterators.EmptySpliterator also be IMMUTABLE, DISTINCT and ORDERED? Like Collections.singletonSpliterator... >> > > Perhaps, for consistency. IIRC at the time it was felt a little odd to declare such characteristics when no elements are present. Not commenting on the specific decisions but to express general policy: For the empty/singleton cases it seems like the flags should match as close as possible those which would be found on a "real" collection used in the same context. The "specialness" of singleton/empty should be mostly for source efficiency and not alter the computation. For collections in general a common source of frustration comes from problems arising when there is a difference between the behaviour of the general and the "optimization". Consider: List bar = new ArrayList<>(); bar.add("Hello World"); List foobar = Collections.unmodifiableList(bar); List fubar = Collections.singeltonList("Hello World"); Any cases where the behaviour of foobar and fubar differ are going to be a source of frustration for users. We end up having to work hard to ensure that such cases don't crop up. (Which is in part why exercises like adding Collections.unmodifiableNavigableMap/Set are so painful). >> Although a mutable Collection implementation or immutable with size()>1 can never be Set and List at the same time, A singleton immutable Collection I think could be. Likewise for empty immutable Collection... So why couldn't a spliterator obtained from singleton List be DISTINCT? Likewise why couldn't a spliterator obtained from singleton Set be ORDERED?... > > That could be an option, but i was hesitant about explicitly stating such optional constraints on Set/List. > > For the current Collection implementations i would prefer not to enforce the reporting of characteristics for a size of 0 or 1. > > >> These are runtime characteristics, not characteristics of a particular collection type. >> > > For N > 1 I would argue characteristics of top-level spliterators do map to a particular collection type. Nearly all of the characteristics for at most one element are irrelevant for optimizing computation (SIZED/SUBSIZED/IMMUTABLE/NONULL are probably the most useful of the not very useful). It's almost as if nothing == everything in this case i.e. reporting no/few characteristics is the same as reporting all/most characteristics :-) > > There is now Collections.emptyNavigableMap/emptySortedMap implying SORTED should also be reported for the empty spliterator, unless we optionally constrain SortedSet. > > There are currently no type safe ways to obtain a singleton NavigableMap/SortedSet, but perhaps there could be in the future? (there was probably a good reason for not adding them with the empty versions but i dunno what that reason was). They weren't added mostly to keep the scope of adding the checked/unmodifiable/synchronized issue from being too involved. They could still be added. > Reporting SORTED for all singletons is problematic because the singleton element may not be Comparable. There's also the question of what to do when someone calls sort on it. There's an open question on whether Collections.sort should pre-check for size <= 1 and do nothing rather than throw UOE for Collections.singletonList(). It turns out most people find the UOE merely annoying and not useful. > > So i thought rather than attempting to be explicit about 0 or 1 element and the type holding that element it was just easier all round to do some hand-waving on Collections or Collection i.e. all bets are off as to what characteristics are reported (beyond that of SIZED/SUBSIZED/IMMUTABLE/NONNULL?) and it does not matter cause you will anyway not be able to to anything useful with them. > > -- > > Perhaps i can separate out this webrev, i presume there is little issue with the other doc updates, if so i can commit those for this bug and spin up another for this aspect. > > Paul. From xueming.shen at oracle.com Fri Aug 9 19:38:03 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 09 Aug 2013 19:38:03 +0000 Subject: hg: jdk8/tl/jdk: 8020054: (tz) Support tzdata2013d Message-ID: <20130809193841.0F87148762@hg.openjdk.java.net> Changeset: a7c341f30747 Author: sherman Date: 2013-08-09 12:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7c341f30747 8020054: (tz) Support tzdata2013d Summary: update the jdk8 tz data to version 2013d Reviewed-by: coffeys, peytoia ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/etcetera ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/factory ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/pacificnew ! make/sun/javazic/tzdata/solar87 ! make/sun/javazic/tzdata/solar88 ! make/sun/javazic/tzdata/solar89 ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/systemv ! make/sun/javazic/tzdata/zone.tab ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/antarctica ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/backward ! test/sun/util/calendar/zi/tzdata/etcetera ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/factory ! test/sun/util/calendar/zi/tzdata/iso3166.tab ! test/sun/util/calendar/zi/tzdata/leapseconds ! test/sun/util/calendar/zi/tzdata/northamerica ! test/sun/util/calendar/zi/tzdata/pacificnew ! test/sun/util/calendar/zi/tzdata/solar87 ! test/sun/util/calendar/zi/tzdata/solar88 ! test/sun/util/calendar/zi/tzdata/solar89 ! test/sun/util/calendar/zi/tzdata/southamerica ! test/sun/util/calendar/zi/tzdata/systemv ! test/sun/util/calendar/zi/tzdata/zone.tab From huizhe.wang at oracle.com Fri Aug 9 19:42:39 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Fri, 09 Aug 2013 19:42:39 +0000 Subject: hg: jdk8/tl/jaxp: 8022548: SPECJVM2008 has errors introduced in 7u40-b34 Message-ID: <20130809194247.32C3B48763@hg.openjdk.java.net> Changeset: 4e23bc205d9d Author: joehw Date: 2013-08-09 12:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/4e23bc205d9d 8022548: SPECJVM2008 has errors introduced in 7u40-b34 Reviewed-by: chegar, lancea ! src/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java From huizhe.wang at oracle.com Fri Aug 9 19:54:51 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Fri, 09 Aug 2013 19:54:51 +0000 Subject: hg: jdk8/tl/jdk: 8022548: SPECJVM2008 has errors introduced in 7u40-b34 Message-ID: <20130809195532.B759848766@hg.openjdk.java.net> Changeset: 8f01ccb0c981 Author: joehw Date: 2013-08-09 12:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8f01ccb0c981 8022548: SPECJVM2008 has errors introduced in 7u40-b34 Reviewed-by: chegar, lancea + test/javax/xml/jaxp/parsers/8022548/JDK8022548.xml + test/javax/xml/jaxp/parsers/8022548/JDK8022548.xsl + test/javax/xml/jaxp/parsers/8022548/TestBase.java + test/javax/xml/jaxp/parsers/8022548/XOMParserTest.java From karen.kinnear at oracle.com Fri Aug 9 20:06:28 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 9 Aug 2013 16:06:28 -0400 Subject: RFR: 8022547: [verifier] move DefaultMethodRegressionTests.java to jdk In-Reply-To: <5202E564.7020405@oracle.com> References: <5202E564.7020405@oracle.com> Message-ID: Kumar, Looks good. And thank you - we definitely needed the URLClassLoader so that we actually test the verifier, unless we had a force -Xverify:all flag. Thank you for fixing the major version from 0x33 ->0x34. I presume the push will also delete the file from the current location :-) thanks, Karen On Aug 7, 2013, at 8:25 PM, Kumar Srinivasan wrote: > Hello, > > Testing this functionality in langtools does not seem to be the appropriate location, > and the teams have decided to move it to jdk/test/vm/verifier, which seems to be the > logical place. > > I have modified the test to remove testng dependencies, also added a variant which > involves loading classes via an URLClassLoader which exposed a test bug wrt. the > class.version.major not being correct, therefore it is useful to have this variant anyway. > > The webrev: > http://cr.openjdk.java.net/~ksrini/8022547/webrev.0/ > > The bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022547 > > Thanks > Kumar > > > > From Alan.Bateman at oracle.com Fri Aug 9 20:51:45 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 09 Aug 2013 13:51:45 -0700 Subject: RFR: JAXP in JDK8/7u40 : 8022548 : SPECJVM2008 has errors introduced in 7u40-b34 In-Reply-To: <520484E6.4020204@oracle.com> References: <520484E6.4020204@oracle.com> Message-ID: <52055661.1040301@oracle.com> On 08/08/2013 22:57, huizhe wang wrote: > Hi, > > The root cause of this issue is that SPECJVM2008 uses a 3rd party > parser XOM 1.1 to convert the output to its canonical form. The XOM > parser directly references to the JDK parser implementation > "SAXParser" with a different configuration than the default JDK > parser, in this case, the DTD-only parser configuration > "DTDConfiguration". In JAXP 1.5, we added XMLSecurityPropertyManager > that is instantiated in the default configuration > "XML11Configuration". Since XMLSecurityPropertyManager is not > supported by DTDConfiguration, XOM no longer works. I see this has been pushed but just so I understand, but can you expand on what you mean by "directly references JDK parser implementation"? I'm just wondering whether it's using the standard provider interfaces when on the class path or whether it's tied to an old Xerces interface? -Alan. From kumar.x.srinivasan at oracle.com Fri Aug 9 22:36:04 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 09 Aug 2013 22:36:04 +0000 Subject: hg: jdk8/tl/langtools: 8022161: javac Null Pointer Exception in Enter.visitTopLevel Message-ID: <20130809223615.468C748776@hg.openjdk.java.net> Changeset: d601238641e6 Author: ksrini Date: 2013-08-09 15:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d601238641e6 8022161: javac Null Pointer Exception in Enter.visitTopLevel Reviewed-by: jjg, vromero, jlahoda ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! test/tools/javac/TestPkgInfo.java From huizhe.wang at oracle.com Fri Aug 9 23:55:08 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 09 Aug 2013 16:55:08 -0700 Subject: RFR: JAXP in JDK8/7u40 : 8022548 : SPECJVM2008 has errors introduced in 7u40-b34 In-Reply-To: <52055661.1040301@oracle.com> References: <520484E6.4020204@oracle.com> <52055661.1040301@oracle.com> Message-ID: <5205815C.2000503@oracle.com> On 8/9/2013 1:51 PM, Alan Bateman wrote: > On 08/08/2013 22:57, huizhe wang wrote: >> Hi, >> >> The root cause of this issue is that SPECJVM2008 uses a 3rd party >> parser XOM 1.1 to convert the output to its canonical form. The XOM >> parser directly references to the JDK parser implementation >> "SAXParser" with a different configuration than the default JDK >> parser, in this case, the DTD-only parser configuration >> "DTDConfiguration". In JAXP 1.5, we added XMLSecurityPropertyManager >> that is instantiated in the default configuration >> "XML11Configuration". Since XMLSecurityPropertyManager is not >> supported by DTDConfiguration, XOM no longer works. > I see this has been pushed but just so I understand, but can you > expand on what you mean by "directly references JDK parser > implementation"? I'm just wondering whether it's using the standard > provider interfaces when on the class path or whether it's tied to an > old Xerces interface? It's not using a standard interface. It goes straight to the implementation, here's how it's done: class JDK15XML1_0Parser extends SAXParser { JDK15XML1_0Parser() throws org.xml.sax.SAXException { super(new DTDConfiguration()); // workaround for Java 1.5 beta 2 bugs com.sun.org.apache.xerces.internal.util.SecurityManager manager = new com.sun.org.apache.xerces.internal.util.SecurityManager(); setProperty(Constants.XERCES_PROPERTY_PREFIX + Constants.SECURITY_MANAGER_PROPERTY, manager); } } where: SAXParser is com.sun.org.apache.xerces.internal.parsers.SAXParser DTDConfiguration is com.sun.org.apache.xerces.internal.parsers.DTDConfiguration And of course, if Xerces jars are on the classpath, these would be: org.apache.xerces.parsers.SAXParser and org.apache.xerces.parsers.DTDConfiguration. It looks up Xerces, then JDK, if failed, it actually falls back to the SAX interface, that is XMLReaderFactory. -Joe > > -Alan. From henry.jen at oracle.com Sat Aug 10 00:25:33 2013 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 09 Aug 2013 17:25:33 -0700 Subject: RFR: 8022749: Convert junit tests to testng in test/java/lang/invoke Message-ID: <5205887D.9070204@oracle.com> Hi, Please review a webrev contributed by Mani Sarkar that converts junit tests in test/java/lang/invoke to testng. http://cr.openjdk.java.net/~henryjen/tl/8022749/0/webrev/ Cheers, Henry From brian.burkhalter at oracle.com Sat Aug 10 00:39:08 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 9 Aug 2013 17:39:08 -0700 Subject: Java 8 RFR 8022109: Evaluate adding incrementExact, decrementExact, negateExact to java.lang.Math Message-ID: <89EF1DE7-44AE-4099-A4CF-B7F97FA4A493@oracle.com> Please review at your convenience: Issue http://bugs.sun.com/view_bug.do?bug_id=8022109 Webrev http://cr.openjdk.java.net/~bpb/8022109/ The update is to add the methods incrementExact(), decrementExact(), and negateExact() for int and long parameters to java.lang.Math. Thanks, Brian From brian.burkhalter at oracle.com Sat Aug 10 00:39:21 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 9 Aug 2013 17:39:21 -0700 Subject: Java 8 RFR 8022180: BigInteger Burnikel-Ziegler quotient and remainder calculation assumes quotient parameter is zero Message-ID: <6F5A74F5-C71E-441D-84CB-E71492F31E0B@oracle.com> Please review at your convenience: Issue http://bugs.sun.com/view_bug.do?bug_id=8022180 Webrev http://cr.openjdk.java.net/~bpb/8022180/ The update is to clear the quotient if the divisor is larger than the dividend in divideAndRemainderBurnikelZiegler(). Thanks, Brian From mike.duigou at oracle.com Sat Aug 10 00:43:49 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 9 Aug 2013 17:43:49 -0700 Subject: RFR: 8022749: Convert junit tests to testng in test/java/lang/invoke In-Reply-To: <5205887D.9070204@oracle.com> References: <5205887D.9070204@oracle.com> Message-ID: <82BE9795-0CFA-43D1-9BEE-AFF098457AFD@oracle.com> Looks good to me. Nice cleanup Mani and thank you for sponsoring the change Henry! Mike On Aug 9 2013, at 17:25 , Henry Jen wrote: > Hi, > > Please review a webrev contributed by Mani Sarkar that converts junit > tests in test/java/lang/invoke to testng. > > http://cr.openjdk.java.net/~henryjen/tl/8022749/0/webrev/ > > Cheers, > Henry From mike.duigou at oracle.com Sat Aug 10 01:26:06 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 9 Aug 2013 18:26:06 -0700 Subject: Java 8 RFR 8022109: Evaluate adding incrementExact, decrementExact, negateExact to java.lang.Math In-Reply-To: <89EF1DE7-44AE-4099-A4CF-B7F97FA4A493@oracle.com> References: <89EF1DE7-44AE-4099-A4CF-B7F97FA4A493@oracle.com> Message-ID: <05756DEE-B95F-43DA-BF0A-0EECEF9EFD64@oracle.com> Looks good to me. I am glad we were able to get this back into Java 8. Mike On Aug 9 2013, at 17:39 , Brian Burkhalter wrote: > Please review at your convenience: > > Issue http://bugs.sun.com/view_bug.do?bug_id=8022109 > Webrev http://cr.openjdk.java.net/~bpb/8022109/ > > The update is to add the methods incrementExact(), decrementExact(), and negateExact() for int and long parameters to java.lang.Math. > > Thanks, > > Brian From vicente.romero at oracle.com Sat Aug 10 12:28:55 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sat, 10 Aug 2013 12:28:55 +0000 Subject: hg: jdk8/tl/langtools: 8009640: -profile does not work when -bootclasspath specified Message-ID: <20130810122858.15F1748789@hg.openjdk.java.net> Changeset: 0d9bc764cac7 Author: vromero Date: 2013-08-10 13:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d9bc764cac7 8009640: -profile does not work when -bootclasspath specified Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/resources/javac.properties + test/tools/javac/T8009640/CheckRejectProfileBCPOptionsIfUsedTogetherTest.java From vicente.romero at oracle.com Sat Aug 10 15:27:28 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sat, 10 Aug 2013 15:27:28 +0000 Subject: hg: jdk8/tl/langtools: 8022622: javac, two tests are failing with compile time error after class Collector was modified Message-ID: <20130810152735.353B74878B@hg.openjdk.java.net> Changeset: 8f282dc58dfc Author: vromero Date: 2013-08-10 16:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8f282dc58dfc 8022622: javac, two tests are failing with compile time error after class Collector was modified Reviewed-by: mcimadamore ! test/tools/javac/lambda/TargetType59.java ! test/tools/javac/lambda/TargetType62.java From vicente.romero at oracle.com Sat Aug 10 15:30:27 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sat, 10 Aug 2013 15:30:27 +0000 Subject: hg: jdk8/tl/langtools: 6983297: methods missing from NewArrayTree Message-ID: <20130810153030.01FCA4878C@hg.openjdk.java.net> Changeset: aa6c6f8b5622 Author: vromero Date: 2013-08-10 16:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/aa6c6f8b5622 6983297: methods missing from NewArrayTree Reviewed-by: jjg ! src/share/classes/com/sun/source/tree/NewArrayTree.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! test/tools/javac/tree/SourceTreeScannerTest.java From rob.mckenna at oracle.com Sat Aug 10 16:16:13 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Sat, 10 Aug 2013 17:16:13 +0100 Subject: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion In-Reply-To: <51F58A99.8050402@oracle.com> References: <50AE98B1.2040200@oracle.com> <50B81A8D.2040403@oracle.com> <50B82C94.90109@oracle.com> <50D277BE.8060705@oracle.com> <50D65C3F.2040004@oracle.com> <51D2F496.6050400@oracle.com> <51D57B88.3050707@oracle.com> <51D674B5.7020100@oracle.com> <51F14F85.1010601@oracle.com> <51F58A99.8050402@oracle.com> Message-ID: <5206674D.4090207@oracle.com> Thanks for the build review Erik, Hi Alan, Thanks for the review. I'm hoping this webrev has dealt with your comments. http://cr.openjdk.java.net/~robm/5049299/webrev.06/ A couple of notes: - The jexec comments in CompileLauncher referenced the old build too. I figured it was a handy way to find the corresponding makefile in the old build. Removed though. - I've added a return -1 default case to startChild to avoid a "control reaches end of non-void function" warning on mac & linux. forkAndExec looks for a negative integer specifically, but this should never actually be reached. - Added the ifdef's around spawnChild and its use to avoid an implicit declaration warning on Linux. (posix_spawn) I've tested with the attached (quick and very dirty) test. Forgive the System.gc & the sleep, but as you can see from the output below, it looks like we're correctly closing our fd's. (a much longer running version followed the same pattern) Clearly the test is totally unsuitable for integration, but let me know if you can think of a better way to do this. bash-3.00$ /suspool/home/rob/8/tl/build/solaris-sparcv9-normal-server-release/jdk/bin/java FDLeakTest 21360 <--- this is the pid 10 3010 358 3358 850 3850 1288 4288 1636 4636 10 -Rob On 28/07/13 22:18, Alan Bateman wrote: > On 25/07/2013 09:17, Rob McKenna wrote: >> Thanks a lot Erik, >> >> I've added the dependency to the makefile here: >> >> http://cr.openjdk.java.net/~robm/5049299/webrev.05/ >> >> >> Is it ok between the ifeq block? >> >> Alan, >> >> I've altered the launchMechanism code to use valueOf (and lower case >> names) - much cleaner, thanks for that. I've also limited each >> platform to supported mechanisms only. With the new layout I don't >> believe a separate test is needed here. (the default is now >> posix_spawn/vfork and Basic.java has been altered to run with fork too) >> >> -Rob > Thanks Rob, I've taken another pass over the latest webrev and I think > the finish line is close. > > The launchMechanism determination is much cleaner now (thanks). For > consistency the enum values should probably be in uppercase and so > this means you'll need to uppercase the property value to use valueOf. > > It would be nice if launchMechanism were final too (which you do by > having the privileged action be of type LaunchMechanism rather than Void). > > The comment in UNIXProcess.java.bsd references vfork/exec which I > assume is copied from the Linux version and should be removed. > > Did you consider having forkAndExec take the helper as a parameter? > Just wonder if this would be cleaner than having to use JNI to grab > the field value. > > It's usually best to use sprintnf rather than sprintf (in spawnChild) > to avoid any concerns (or static analysis tools) that wonder about > buffer overflow. > > Style nit in the C code is that many places have spurious space > between the function name and the parentheses. > > A pre-existing bug (only noticed because it has moved from > UNIXProcess_md.c to childproc.c) is that close is not restartable. > > The comment in in makefiles/CompileLauncher.gmk references the old > build, is that needed? > > So overall I don't see any issues, it would be really good to stress > this to make sure that we aren't leaking file descriptors. I don't > know if we have an existing test that would help with that. > > One final comment is that the new files seems to have the pure GPL > comment, I assume you will add the GPL+ Classpath Exception comment > before you push this. > > -Alan. > From kumar.x.srinivasan at oracle.com Sun Aug 11 00:25:06 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Sat, 10 Aug 2013 17:25:06 -0700 Subject: RFR: 8022547: [verifier] move DefaultMethodRegressionTests.java to jdk In-Reply-To: References: <5202E564.7020405@oracle.com> Message-ID: <5206D9E2.2010601@oracle.com> Hi Karen, > Kumar, > > Looks good. And thank you - we definitely needed the URLClassLoader so that we > actually test the verifier, unless we had a force -Xverify:all flag. Thank you for > fixing the major version from 0x33 ->0x34. You are welcome. During jprt testing there was an issue with some debugging code I had in there, this turned out to be a problem on Windows, as I was not closing the DirectoryStream. I have removed that code and the updated webrev is here: http://cr.openjdk.java.net/~ksrini/8022547/webrev.1/ to make it easier, the delta webrev showing only the changes since the last is here: http://cr.openjdk.java.net/~ksrini/8022547/webrev.1/webrev.delta/index.html > > I presume the push will also delete the file from the current location :-) Of course :-) , however since those are in langtools repository and already in ignored state, I will get that done separately. Thanks Kumar > > thanks, > Karen > > On Aug 7, 2013, at 8:25 PM, Kumar Srinivasan wrote: > >> Hello, >> >> Testing this functionality in langtools does not seem to be the appropriate location, >> and the teams have decided to move it to jdk/test/vm/verifier, which seems to be the >> logical place. >> >> I have modified the test to remove testng dependencies, also added a variant which >> involves loading classes via an URLClassLoader which exposed a test bug wrt. the >> class.version.major not being correct, therefore it is useful to have this variant anyway. >> >> The webrev: >> http://cr.openjdk.java.net/~ksrini/8022547/webrev.0/ >> >> The bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022547 >> >> Thanks >> Kumar >> >> >> >> From peter.levart at gmail.com Sun Aug 11 11:39:17 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 11 Aug 2013 13:39:17 +0200 Subject: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters synchronized method In-Reply-To: <520278DF.2060102@oracle.com> References: <5202733D.60205@gmail.com> <520278DF.2060102@oracle.com> Message-ID: <520777E5.3050304@gmail.com> On 08/07/2013 06:42 PM, Aleksey Shipilev wrote: > Hi Peter, > > On 08/07/2013 08:18 PM, Peter Levart wrote: >> http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.01/ > Yeah, looks familiar. The install loop is very complicated though, can > we simplify it? It seems profitable to move the retry loop up into > annotationData(): you then don't have to pass the $annotationData, you > can merge the exit paths for $classRedefinedCount, etc. Hi Aleksey, Right, the retry-loop can be simplified. There are still two methods, but the 2nd is only a factory method now: http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.02/ 10 LOC saved. Regards, Peter > -Aleksey. > > > From aleksey.shipilev at oracle.com Sun Aug 11 18:12:13 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sun, 11 Aug 2013 22:12:13 +0400 Subject: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters synchronized method In-Reply-To: <520777E5.3050304@gmail.com> References: <5202733D.60205@gmail.com> <520278DF.2060102@oracle.com> <520777E5.3050304@gmail.com> Message-ID: <5207D3FD.2010202@oracle.com> On 08/11/2013 03:39 PM, Peter Levart wrote: > http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.02/ Thanks Peter, this looks good to me (not a capital Reviewer). -Aleksey. From xuelei.fan at oracle.com Mon Aug 12 01:22:09 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 12 Aug 2013 01:22:09 +0000 Subject: hg: jdk8/tl/jdk: 8022487: DEREncodedKeyValue.supportedKeyTypes should be private Message-ID: <20130812012258.BACF2487A1@hg.openjdk.java.net> Changeset: ea4f4164422e Author: xuelei Date: 2013-08-11 18:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ea4f4164422e 8022487: DEREncodedKeyValue.supportedKeyTypes should be private Reviewed-by: mullan ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/DEREncodedKeyValue.java From weijun.wang at oracle.com Mon Aug 12 04:18:02 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 12 Aug 2013 12:18:02 +0800 Subject: A 8021788 regression? 8022761: SQE test regression on wrongly signed indexed jar file Message-ID: <520861FA.4090605@oracle.com> Hi Sherman SQE observes a regression in their test suite and the reason is my recent fix for 8021788 at http://hg.openjdk.java.net/jdk8/tl/jdk/rev/758e3117899c The jar file mentioned contains 66 Mon Jun 04 15:42:18 CST 2007 META-INF/INDEX.LIST 323 Sat Apr 01 15:47:28 CST 2000 META-INF/MANIFEST.MF 376 Mon Jun 04 15:41:00 CST 2007 META-INF/MYKEY.SF 972 Sat Apr 01 15:47:38 CST 2000 META-INF/MYKEY.DSA 0 Sat Apr 01 15:46:58 CST 2000 META-INF/ 0 Sat Apr 01 15:45:16 CST 2000 test/ 21 Sat Apr 01 15:46:24 CST 2000 test/test0 21 Sat Apr 01 15:46:18 CST 2000 test/test1 21 Sat Apr 01 15:46:04 CST 2000 test/test2 21 Sat Apr 01 15:46:10 CST 2000 test/test3 After JDK-8021788, the file is regarded as an unsigned jar because the updated JarVerifier goes thru all signature-related files and treats all others not. Here the first one is not signature-related so none is. Is fix for JDK-8021788 wrong? Inside JarVerifier.java, we have * Assumptions: * 1. The manifest should be the first entry in the META-INF directory. * 2. The .SF/.DSA/.EC files follow the manifest, before any normal entries Is this INDEX.LIST an exception? Thanks Max From david.holmes at oracle.com Mon Aug 12 05:59:43 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 Aug 2013 15:59:43 +1000 Subject: RFR 8022259 MakeClasslist tool is buggy and its README is out of date. In-Reply-To: <5202A528.5060504@oracle.com> References: <5202A528.5060504@oracle.com> Message-ID: <520879CF.6000509@oracle.com> Hi Harold, On 8/08/2013 5:51 AM, harold seigel wrote: > Hi, > > Please review this small fix for bug 8022259. This change fixes a bug > in the MakeClasslist tool and updates its README.txt file. Is there something significant about the "preorder" listing that makes it preferable to the list produced by -verbose:class ? Thanks, David > webrev: http://cr.openjdk.java.net/~hseigel/bug_8022259/ > > > bug: http://bugs.sun.com/view_bug.do?bug_id=8022259 > > JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8022259 > > I tested the change by creating a testlist using the modified > MakeClasslist tool and following the information in the changed > README.txt file. > > Thanks! Harold From paul.sandoz at oracle.com Mon Aug 12 08:20:39 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Aug 2013 10:20:39 +0200 Subject: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters synchronized method In-Reply-To: <5207D3FD.2010202@oracle.com> References: <5202733D.60205@gmail.com> <520278DF.2060102@oracle.com> <520777E5.3050304@gmail.com> <5207D3FD.2010202@oracle.com> Message-ID: On Aug 11, 2013, at 8:12 PM, Aleksey Shipilev wrote: > On 08/11/2013 03:39 PM, Peter Levart wrote: >> http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.02/ > > Thanks Peter, this looks good to me (not a capital Reviewer). > +1 (with no reviewer mojo). Paul. From amy.lu at oracle.com Mon Aug 12 08:36:20 2013 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 12 Aug 2013 16:36:20 +0800 Subject: Code review request 8022779: ProblemList.txt updates (8/2013) Message-ID: <52089E84.2040007@oracle.com> ProblemList updates to remove three tests, the related issues have been fixed. Please review: https://dl.dropboxusercontent.com/u/5812451/yl153753/8022779/webrev/index.html Thanks, From Alan.Bateman at oracle.com Mon Aug 12 08:46:47 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Aug 2013 09:46:47 +0100 Subject: RFR 8022259 MakeClasslist tool is buggy and its README is out of date. In-Reply-To: <5202A528.5060504@oracle.com> References: <5202A528.5060504@oracle.com> Message-ID: <5208A0F7.2000003@oracle.com> On 07/08/2013 20:51, harold seigel wrote: > Hi, > > Please review this small fix for bug 8022259. This change fixes a bug > in the MakeClasslist tool and updates its README.txt file. > > webrev: http://cr.openjdk.java.net/~hseigel/bug_8022259/ > > > bug: http://bugs.sun.com/view_bug.do?bug_id=8022259 > > JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8022259 > > I tested the change by creating a testlist using the modified > MakeClasslist tool and following the information in the changed > README.txt file. > > Thanks! Harold Can you explain it further as to why TraceClassLoadingPreorder traces should be used rather than the TraceClassLoading traces? I ask because we rarely see changes to the *.classlist files and to my knowledge, all previous versions used the TraceClassLoading output. Also, are you planning to update the *.classlist files too? They haven't been refreshed in a long time and would be good to get them updated (it should also sort out a slew of warnings emitted in the build about missing classes). -Alan. From chris.hegarty at oracle.com Mon Aug 12 08:57:03 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 12 Aug 2013 09:57:03 +0100 Subject: Code review request 8022779: ProblemList.txt updates (8/2013) In-Reply-To: <52089E84.2040007@oracle.com> References: <52089E84.2040007@oracle.com> Message-ID: <5208A35F.5030805@oracle.com> Thanks for doing this Amy. The changes look fine to me. I wonder if there would be any opposition to adding java/util/Collection/MOAT.java, until 8020536 can be addressed. -Chris. P.S. I can sponsor this change for you, if you need a sponsor. On 12/08/2013 09:36, Amy Lu wrote: > ProblemList updates to remove three tests, the related issues have been > fixed. > > Please review: > https://dl.dropboxusercontent.com/u/5812451/yl153753/8022779/webrev/index.html > > > Thanks, > From Alan.Bateman at oracle.com Mon Aug 12 09:10:20 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Aug 2013 10:10:20 +0100 Subject: RFR: JAXP in JDK8/7u40 : 8022548 : SPECJVM2008 has errors introduced in 7u40-b34 In-Reply-To: <5205815C.2000503@oracle.com> References: <520484E6.4020204@oracle.com> <52055661.1040301@oracle.com> <5205815C.2000503@oracle.com> Message-ID: <5208A67C.8030408@oracle.com> On 10/08/2013 00:55, huizhe wang wrote: > : > > It's not using a standard interface. It goes straight to the > implementation, here's how it's done: > class JDK15XML1_0Parser extends SAXParser { > > JDK15XML1_0Parser() throws org.xml.sax.SAXException { > > super(new DTDConfiguration()); > // workaround for Java 1.5 beta 2 bugs > com.sun.org.apache.xerces.internal.util.SecurityManager manager = > new > com.sun.org.apache.xerces.internal.util.SecurityManager(); > setProperty(Constants.XERCES_PROPERTY_PREFIX + > Constants.SECURITY_MANAGER_PROPERTY, manager); > > } > } > > where: > SAXParser is com.sun.org.apache.xerces.internal.parsers.SAXParser > DTDConfiguration is > com.sun.org.apache.xerces.internal.parsers.DTDConfiguration > Okay, I see it now: $ jdeps --verbose-level=class xom-1.2.10.jar |grep "JDK internal API" -> com.sun.org.apache.xerces.internal.parsers.DTDConfiguration JDK internal API (rt.jar) -> com.sun.org.apache.xerces.internal.parsers.SAXParser JDK internal API (rt.jar) -> com.sun.org.apache.xerces.internal.util.SecurityManager JDK internal API (rt.jar) -> com.sun.org.apache.xerces.internal.xni.parser.XMLParserConfiguration JDK internal API (rt.jar) In that case, this is not really a bug, it's that XOM needs to realize that extending com.sun.org.apache.xerces.internal.** means they have a dependency on JDK internal classes so they can break at any time. Also as com.sun.org.apache.xerces.internal.** is on the restricted package list then I assume they have problems running with a security manager. I wasn't aware that SPECjvm2008 uses XOM. Unless XOM is fixed then I can imagine this causing problems in the future, in particular if/when visibility of JDK internal classes is restricted. -Alan From Alan.Bateman at oracle.com Mon Aug 12 09:12:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Aug 2013 10:12:28 +0100 Subject: Code review request 8022779: ProblemList.txt updates (8/2013) In-Reply-To: <5208A35F.5030805@oracle.com> References: <52089E84.2040007@oracle.com> <5208A35F.5030805@oracle.com> Message-ID: <5208A6FC.7060607@oracle.com> On 12/08/2013 09:57, Chris Hegarty wrote: > Thanks for doing this Amy. > > The changes look fine to me. I wonder if there would be any opposition > to adding java/util/Collection/MOAT.java, until 8020536 can be addressed. > > -Chris. > > P.S. I can sponsor this change for you, if you need a sponsor. Amy's change looks fine to me too. I don't think that java/util/Collection/MOAT.java should be excluded. If it's causing noise then the simplest might be to remove the +AggressiveOpts run until the underlying issue is resolved. -Alan. From Alan.Bateman at oracle.com Mon Aug 12 09:17:00 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Aug 2013 10:17:00 +0100 Subject: RFR: 8022749: Convert junit tests to testng in test/java/lang/invoke In-Reply-To: <5205887D.9070204@oracle.com> References: <5205887D.9070204@oracle.com> Message-ID: <5208A80C.6030002@oracle.com> On 10/08/2013 01:25, Henry Jen wrote: > Hi, > > Please review a webrev contributed by Mani Sarkar that converts junit > tests in test/java/lang/invoke to testng. > > http://cr.openjdk.java.net/~henryjen/tl/8022749/0/webrev/ > > Cheers, > Henry This looks good to me (but cc'ing mlvm-dev so that John/Christian/others that might run these tests interactively are aware of this). -Alan. From paul.sandoz at oracle.com Mon Aug 12 09:17:36 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Aug 2013 11:17:36 +0200 Subject: RFR 8014824: Document Spliterator characteristics and binding policy of java util collection impls In-Reply-To: References: <1C62EB3E-11FF-484B-BC00-2DED97C33A8F@oracle.com> <52036BF6.3050807@oracle.com> <036F6A65-8192-4C70-876B-5F4A65C06DB7@oracle.com> <520376A3.1020300@gmail.com> <4B9C62F5-215F-42B4-AFD3-CA22B50B252D@oracle.com> Message-ID: <13BC2129-5049-458A-B1F8-FFC6A6C185E9@oracle.com> On Aug 9, 2013, at 9:01 PM, Mike Duigou wrote: > > On Aug 9 2013, at 06:04 , Paul Sandoz wrote: > >> Hi Peter, >> >> On Aug 8, 2013, at 12:44 PM, Peter Levart wrote: >> >>> Hi Paul, >>> >>> Shouldn't Spliterators.EmptySpliterator also be IMMUTABLE, DISTINCT and ORDERED? Like Collections.singletonSpliterator... >>> >> >> Perhaps, for consistency. IIRC at the time it was felt a little odd to declare such characteristics when no elements are present. > > Not commenting on the specific decisions but to express general policy: > > For the empty/singleton cases it seems like the flags should match as close as possible those which would be found on a "real" collection used in the same context. The "specialness" of singleton/empty should be mostly for source efficiency and not alter the computation. To be clear: computation may be altered (that is the why the characteristics are useful) but the results should be consistent. The characteristics allow for "wiggle room" to optimize. This email thread promoted to me think a little more and while i don't think there is any issue spliterators of empty collections, there could be an issue with singletons when used with flatMap. Collections.singletonList(1).flatMap(x -> Stream.of(1, 2, 3)).parallel()... Collections.singleton(1).flatMap(x -> Stream.of(1, 2, 3)).parallel()... The first stream should retain encounter order for 1 substituted for 1, 2, 3, where as the second stream does not have to. It just so happens the current flatMap implementation imputes order and thus preserves any order (elements are substituted sequentially at the leafs after splitting has occurred, which for this case is no splits). The flatMap implementation could change to have better parallel performance, although it is currently hard to imagine it doing so at least for JDK 8. To be on the safe side the shared singleton implementation should report ORDERED (which it currently does), but this implies we will need to specify this for any shared use between singleton collections. OK, i am gonna about turn on singletons, and keep things simple, and update the package private Collection.singletonSpliterator to take a characteristics parameter to ensure consistency with the collection type. >> >> There are currently no type safe ways to obtain a singleton NavigableMap/SortedSet, but perhaps there could be in the future? (there was probably a good reason for not adding them with the empty versions but i dunno what that reason was). > > They weren't added mostly to keep the scope of adding the checked/unmodifiable/synchronized issue from being too involved. They could still be added. > OK. >> Reporting SORTED for all singletons is problematic because the singleton element may not be Comparable. > > There's also the question of what to do when someone calls sort on it. There's an open question on whether Collections.sort should pre-check for size <= 1 and do nothing rather than throw UOE for Collections.singletonList(). It turns out most people find the UOE merely annoying and not useful. > AFAICT: - Collections/Arrays.sort do not throw UOE and Collections.singletonList(...).sort(...) is a no-op. - Collections.unmodifiableList(...).sort(...) throws a UOE. In a hybrid world of the mutable and unmodifiable it is likely there will be subtle differences: Collections.singletonList(1).sort(...) List l = new ArrayList(Arrays.asList(1)); l.sort(...); Collections.unmodifiableList(l).sort(...) When can i have persistent collections in Java? :-) Paul. From chris.hegarty at oracle.com Mon Aug 12 09:45:50 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 12 Aug 2013 10:45:50 +0100 Subject: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters synchronized method In-Reply-To: References: <5202733D.60205@gmail.com> <520278DF.2060102@oracle.com> <520777E5.3050304@gmail.com> <5207D3FD.2010202@oracle.com> Message-ID: <5208AECE.7050000@oracle.com> Looks good to me too. -Chris. On 12/08/2013 09:20, Paul Sandoz wrote: > > On Aug 11, 2013, at 8:12 PM, Aleksey Shipilev wrote: > >> On 08/11/2013 03:39 PM, Peter Levart wrote: >>> http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.02/ >> >> Thanks Peter, this looks good to me (not a capital Reviewer). >> > > +1 (with no reviewer mojo). > > Paul. From chris.hegarty at oracle.com Mon Aug 12 09:50:38 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 12 Aug 2013 10:50:38 +0100 Subject: Code review request 8022779: ProblemList.txt updates (8/2013) In-Reply-To: <5208A6FC.7060607@oracle.com> References: <52089E84.2040007@oracle.com> <5208A35F.5030805@oracle.com> <5208A6FC.7060607@oracle.com> Message-ID: <5208AFEE.3070509@oracle.com> Thanks Alan, To clarify, I there are no objections, I'll push the following change along with Amy's updates for the ProblemList diff -r ce1c874903cb test/java/util/Collection/MOAT.java --- a/test/java/util/Collection/MOAT.java Fri Aug 09 17:56:38 2013 +0100 +++ b/test/java/util/Collection/MOAT.java Mon Aug 12 10:46:52 2013 +0100 @@ -30,7 +30,6 @@ * @summary Run many tests on many Collection and Map implementations * @author Martin Buchholz * @run main MOAT - * @run main/othervm -XX:+AggressiveOpts MOAT */ /* Mother Of All (Collection) Tests -Chris. On 12/08/2013 10:12, Alan Bateman wrote: > On 12/08/2013 09:57, Chris Hegarty wrote: >> Thanks for doing this Amy. >> >> The changes look fine to me. I wonder if there would be any opposition >> to adding java/util/Collection/MOAT.java, until 8020536 can be addressed. >> >> -Chris. >> >> P.S. I can sponsor this change for you, if you need a sponsor. > Amy's change looks fine to me too. > > I don't think that java/util/Collection/MOAT.java should be excluded. If > it's causing noise then the simplest might be to remove the > +AggressiveOpts run until the underlying issue is resolved. > > -Alan. From Alan.Bateman at oracle.com Mon Aug 12 10:06:24 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Aug 2013 11:06:24 +0100 Subject: Code review request 8022779: ProblemList.txt updates (8/2013) In-Reply-To: <5208AFEE.3070509@oracle.com> References: <52089E84.2040007@oracle.com> <5208A35F.5030805@oracle.com> <5208A6FC.7060607@oracle.com> <5208AFEE.3070509@oracle.com> Message-ID: <5208B3A0.4090903@oracle.com> On 12/08/2013 10:50, Chris Hegarty wrote: > Thanks Alan, > > To clarify, I there are no objections, I'll push the following change > along with Amy's updates for the ProblemList > > diff -r ce1c874903cb test/java/util/Collection/MOAT.java > --- a/test/java/util/Collection/MOAT.java Fri Aug 09 17:56:38 > 2013 +0100 > +++ b/test/java/util/Collection/MOAT.java Mon Aug 12 10:46:52 > 2013 +0100 > @@ -30,7 +30,6 @@ > * @summary Run many tests on many Collection and Map implementations > * @author Martin Buchholz > * @run main MOAT > - * @run main/othervm -XX:+AggressiveOpts MOAT > */ > > /* Mother Of All (Collection) Tests That looks fine for now. -Alan From joel.franck at oracle.com Mon Aug 12 10:54:39 2013 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Mon, 12 Aug 2013 12:54:39 +0200 Subject: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters synchronized method In-Reply-To: <520777E5.3050304@gmail.com> References: <5202733D.60205@gmail.com> <520278DF.2060102@oracle.com> <520777E5.3050304@gmail.com> Message-ID: <20130812105439.GC6420@jfranck-desktop.jrpg.bea.com> Hi Peter, Thank you for looking in to this! On 2013-08-11, Peter Levart wrote: > > On 08/07/2013 06:42 PM, Aleksey Shipilev wrote: > >Hi Peter, > > > >On 08/07/2013 08:18 PM, Peter Levart wrote: > >>http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.01/ > >Yeah, looks familiar. The install loop is very complicated though, can > >we simplify it? It seems profitable to move the retry loop up into > >annotationData(): you then don't have to pass the $annotationData, you > >can merge the exit paths for $classRedefinedCount, etc. > > Hi Aleksey, > > Right, the retry-loop can be simplified. There are still two > methods, but the 2nd is only a factory method now: > > http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.02/ > I realize the interaction between probably any reflective operation and a redefine is blurry, but if a redefine occurs between line 3308 and 3309 annotationData() will return a possibly outdated AnnotationData. 3307 if (Atomic.casAnnotationData(this, annotationData, newAnnotationData)) { 3308 // successfully installed new AnnotationData redefine here 3309 return newAnnotationData; 3310 } I suppose there is a sequencing of events where this will be inevitable, but this got me thinking about the state model of annotations (and reflective objects) through an redefine. I think we need to be a bit more explicit about documenting that state model. If you have a good mental model of this perhaps now is a good time to write it down? 3326 if (annotations == null) { // lazy construction 3327 annotations = new HashMap<>(); 3328 } I think this should be a LinkedHashMap, so that iteration is predictable (I know it isn't in the current code). Also the size of the map is known so you can use a constructor with an explicit initial capacity. Since this is a fairly significant rewrite I think it might be good to make sure our tests exercise the new code. Can you run some kind of coverage report on this? Otherwise this looks good (not an R kind of reviewer). cheers /Joel From peter.levart at gmail.com Mon Aug 12 11:00:59 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 12 Aug 2013 13:00:59 +0200 Subject: RFR 8014824: Document Spliterator characteristics and binding policy of java util collection impls In-Reply-To: <13BC2129-5049-458A-B1F8-FFC6A6C185E9@oracle.com> References: <1C62EB3E-11FF-484B-BC00-2DED97C33A8F@oracle.com> <52036BF6.3050807@oracle.com> <036F6A65-8192-4C70-876B-5F4A65C06DB7@oracle.com> <520376A3.1020300@gmail.com> <4B9C62F5-215F-42B4-AFD3-CA22B50B252D@oracle.com> <13BC2129-5049-458A-B1F8-FFC6A6C185E9@oracle.com> Message-ID: <5208C06B.4000008@gmail.com> On 08/12/2013 11:17 AM, Paul Sandoz wrote: > On Aug 9, 2013, at 9:01 PM, Mike Duigou wrote: >> On Aug 9 2013, at 06:04 , Paul Sandoz wrote: >> >>> Hi Peter, >>> >>> On Aug 8, 2013, at 12:44 PM, Peter Levart wrote: >>> >>>> Hi Paul, >>>> >>>> Shouldn't Spliterators.EmptySpliterator also be IMMUTABLE, DISTINCT and ORDERED? Like Collections.singletonSpliterator... >>>> >>> Perhaps, for consistency. IIRC at the time it was felt a little odd to declare such characteristics when no elements are present. >> Not commenting on the specific decisions but to express general policy: >> >> For the empty/singleton cases it seems like the flags should match as close as possible those which would be found on a "real" collection used in the same context. The "specialness" of singleton/empty should be mostly for source efficiency and not alter the computation. > To be clear: computation may be altered (that is the why the characteristics are useful) but the results should be consistent. The characteristics allow for "wiggle room" to optimize. > > This email thread promoted to me think a little more and while i don't think there is any issue spliterators of empty collections, there could be an issue with singletons when used with flatMap. > > Collections.singletonList(1).flatMap(x -> Stream.of(1, 2, 3)).parallel()... > Collections.singleton(1).flatMap(x -> Stream.of(1, 2, 3)).parallel()... > > The first stream should retain encounter order for 1 substituted for 1, 2, 3, where as the second stream does not have to. It just so happens the current flatMap implementation imputes order and thus preserves any order (elements are substituted sequentially at the leafs after splitting has occurred, which for this case is no splits). > > The flatMap implementation could change to have better parallel performance, although it is currently hard to imagine it doing so at least for JDK 8. To be on the safe side the shared singleton implementation should report ORDERED (which it currently does), but this implies we will need to specify this for any shared use between singleton collections. > > OK, i am gonna about turn on singletons, and keep things simple, and update the package private Collection.singletonSpliterator to take a characteristics parameter to ensure consistency with the collection type. Hi Paul, Concatenating two ORDERED streams normally produces an ORDERED stream. Now if one is concatenating an ORDERED stream with an empty stream, what comes out should also be an ORDERED stream, don't you think? Regards, Peter > > >>> There are currently no type safe ways to obtain a singleton NavigableMap/SortedSet, but perhaps there could be in the future? (there was probably a good reason for not adding them with the empty versions but i dunno what that reason was). >> They weren't added mostly to keep the scope of adding the checked/unmodifiable/synchronized issue from being too involved. They could still be added. >> > OK. > > >>> Reporting SORTED for all singletons is problematic because the singleton element may not be Comparable. >> There's also the question of what to do when someone calls sort on it. There's an open question on whether Collections.sort should pre-check for size <= 1 and do nothing rather than throw UOE for Collections.singletonList(). It turns out most people find the UOE merely annoying and not useful. >> > AFAICT: > > - Collections/Arrays.sort do not throw UOE and Collections.singletonList(...).sort(...) is a no-op. > > - Collections.unmodifiableList(...).sort(...) throws a UOE. > > In a hybrid world of the mutable and unmodifiable it is likely there will be subtle differences: > > Collections.singletonList(1).sort(...) > > List l = new ArrayList(Arrays.asList(1)); > l.sort(...); > > Collections.unmodifiableList(l).sort(...) > > > When can i have persistent collections in Java? :-) > > Paul. From paul.sandoz at oracle.com Mon Aug 12 11:35:17 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Aug 2013 13:35:17 +0200 Subject: RFR 8014824: Document Spliterator characteristics and binding policy of java util collection impls In-Reply-To: <5208C06B.4000008@gmail.com> References: <1C62EB3E-11FF-484B-BC00-2DED97C33A8F@oracle.com> <52036BF6.3050807@oracle.com> <036F6A65-8192-4C70-876B-5F4A65C06DB7@oracle.com> <520376A3.1020300@gmail.com> <4B9C62F5-215F-42B4-AFD3-CA22B50B252D@oracle.com> <13BC2129-5049-458A-B1F8-FFC6A6C185E9@oracle.com> <5208C06B.4000008@gmail.com> Message-ID: <7A18968A-6E29-4619-97E6-557276CAD616@oracle.com> On Aug 12, 2013, at 1:00 PM, Peter Levart wrote: >> To be clear: computation may be altered (that is the why the characteristics are useful) but the results should be consistent. The characteristics allow for "wiggle room" to optimize. >> >> This email thread promoted to me think a little more and while i don't think there is any issue spliterators of empty collections, there could be an issue with singletons when used with flatMap. >> >> Collections.singletonList(1).flatMap(x -> Stream.of(1, 2, 3)).parallel()... >> Collections.singleton(1).flatMap(x -> Stream.of(1, 2, 3)).parallel()... >> >> The first stream should retain encounter order for 1 substituted for 1, 2, 3, where as the second stream does not have to. It just so happens the current flatMap implementation imputes order and thus preserves any order (elements are substituted sequentially at the leafs after splitting has occurred, which for this case is no splits). >> >> The flatMap implementation could change to have better parallel performance, although it is currently hard to imagine it doing so at least for JDK 8. To be on the safe side the shared singleton implementation should report ORDERED (which it currently does), but this implies we will need to specify this for any shared use between singleton collections. >> >> OK, i am gonna about turn on singletons, and keep things simple, and update the package private Collection.singletonSpliterator to take a characteristics parameter to ensure consistency with the collection type. > > Hi Paul, > > Concatenating two ORDERED streams normally produces an ORDERED stream. Now if one is concatenating an ORDERED stream with an empty stream, what comes out should also be an ORDERED stream, don't you think? > Yes, good point, but I suppose the general expectation is that the stream returned from Stream.concat(s, Stream.emptyStream()) is equivalent to or is s. We can easily do this by checking if a spliterator is SIZED and the estimate is zero, which will also work for any SIZED empty stream regardless of how it was created. In this case it would appear sufficient to state that a spliterator of a collection covering zero elements need only report SIZED and is not required to report all the characters as defined by the collection. Paul. From Alan.Bateman at oracle.com Mon Aug 12 12:08:06 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Aug 2013 13:08:06 +0100 Subject: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion In-Reply-To: <5206674D.4090207@oracle.com> References: <50AE98B1.2040200@oracle.com> <50B81A8D.2040403@oracle.com> <50B82C94.90109@oracle.com> <50D277BE.8060705@oracle.com> <50D65C3F.2040004@oracle.com> <51D2F496.6050400@oracle.com> <51D57B88.3050707@oracle.com> <51D674B5.7020100@oracle.com> <51F14F85.1010601@oracle.com> <51F58A99.8050402@oracle.com> <5206674D.4090207@oracle.com> Message-ID: <5208D026.5090606@oracle.com> On 10/08/2013 17:16, Rob McKenna wrote: > Thanks for the build review Erik, > > Hi Alan, > > Thanks for the review. I'm hoping this webrev has dealt with your > comments. > > http://cr.openjdk.java.net/~robm/5049299/webrev.06/ > > > A couple of notes: > > - The jexec comments in CompileLauncher referenced the old build too. > I figured it was a handy way to find the corresponding makefile in the > old build. Removed though. > > - I've added a return -1 default case to startChild to avoid a > "control reaches end of non-void function" warning on mac & linux. > forkAndExec looks for a negative integer specifically, but this should > never actually be reached. > > - Added the ifdef's around spawnChild and its use to avoid an implicit > declaration warning on Linux. (posix_spawn) > > I've tested with the attached (quick and very dirty) test. Forgive the > System.gc & the sleep, but as you can see from the output below, it > looks like we're correctly closing our fd's. (a much longer running > version followed the same pattern) Clearly the test is totally > unsuitable for integration, but let me know if you can think of a > better way to do this. > > bash-3.00$ > /suspool/home/rob/8/tl/build/solaris-sparcv9-normal-server-release/jdk/bin/java > FDLeakTest > 21360 <--- this is the pid > 10 > 3010 > 358 > 3358 > 850 > 3850 > 1288 > 4288 > 1636 > 4636 > 10 > > -Rob Thanks for the update. In UnixProcess.java.XXX then it looks like the statics javaHome and arch aren't needed now. You should be able to change LaunchMechanism to private static too. One suggestion to consider too is save the byte representation of the jspawnhelper path as it shouldn't be necessary to have to convert that to bytes each time. It's okay to do this with change-set if you want to get the current patch push. Otherwise I think this is good, you've sorted out all other issues. Also thanks for double checking that we aren't leaking file descriptors. -Alan From paul.sandoz at oracle.com Mon Aug 12 12:12:20 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Aug 2013 14:12:20 +0200 Subject: Take 2 Re: RFR 8014824: Document Spliterator characteristics and binding policy of java util collection impls In-Reply-To: <1C62EB3E-11FF-484B-BC00-2DED97C33A8F@oracle.com> References: <1C62EB3E-11FF-484B-BC00-2DED97C33A8F@oracle.com> Message-ID: Hi, I have updated this webrev to remove documenting empty/singleton collections (that will be tackled as a separate issue): http://cr.openjdk.java.net/~psandoz/tl/JDK-8014824-split-docs/webrev/ Paul. On Aug 8, 2013, at 11:00 AM, Paul Sandoz wrote: > Hi, > > The following patch updates documentation for various spliterators: > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8014824-split-docs/webrev/ > > Mostly this is just clarifying stuff that was missing, but there are a few cases of a spec change to Collections (CCC will be created): > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8014824-split-docs/specdiff/overview-summary.html > > This is for the Collection.empty/singleton/nCopies relaxing the reporting of characteristics for spliterators containing 0 or 1 elements. It's more efficient to share code for empty and singleton spliterator implementations (and instance for the former) rather than attempting to conform the required characteristics of the collection, which will anyway have little or no benefit in terms of the client trying to optimize based on those characteristics. > > Paul. From paul.sandoz at oracle.com Mon Aug 12 12:22:42 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Aug 2013 14:22:42 +0200 Subject: RFR 8022318: Document Spliterator characteristics and binding policy of java util concurrent collection impls Message-ID: <6E333CCC-C11A-40D1-AF9B-AF822216ED21@oracle.com> Hi, The following patch updates documentation for various spliterators in the j.u.concurrent package: http://cr.openjdk.java.net/~psandoz/tl/JDK-8022318-concurrent-split-docs/webrev/ This syncs from the 166 repo and the documentation is just clarifying stuff that was missing. Many thanks to Martin for helping out with this. There are a few additional tweaks here and there that are included, the only non-formating/non-documentation tweak is to SynchronousQueue.iterator(): - @SuppressWarnings("unchecked") public Iterator iterator() { - return (Iterator) EmptyIterator.EMPTY_ITERATOR; - } - - // Replicated from a previous version of Collections - private static class EmptyIterator implements Iterator { - static final EmptyIterator EMPTY_ITERATOR - = new EmptyIterator(); - - public boolean hasNext() { return false; } - public E next() { throw new NoSuchElementException(); } - public void remove() { throw new IllegalStateException(); } + return Collections.emptyIterator(); } Paul. From ivan.gerasimov at oracle.com Mon Aug 12 12:33:48 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 12 Aug 2013 16:33:48 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5204DE28.5090805@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> <52047C66.2080001@oracle.com> <52048269.7000501@oracle.com> <5204997B.3090601@oracle.com> <5204B5F3.6000506@oracle.com> <5204C626.3000102@oracle.com> <5204DE28.5090805@oracle.com> Message-ID: <5208D62C.3030107@oracle.com> David, Chris, I reverted back NULL-checking. Now the change consists of one line removal and a regression test. Webrev: http://cr.openjdk.java.net/~igerasim/8022584/6/webrev/ Hg export: http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch Sincerely yours, Ivan On 09.08.2013 16:18, David Holmes wrote: > Hi Chris, > > On 9/08/2013 8:36 PM, Chris Hegarty wrote: >> Firstly, I think the memory leak issue should be moved forward >> separately to this cleanup effort. They are unrelated, and I'm starting >> to get the feeling that this could take some time to reach conclusion. >> It seems reasonable to separate the issues. > > I agree. I'm sure when Alan suggested to check the return he didn't > expect it to unravel like this :) As we know hotspot will never > actually return NULL there is no urgency to add this in. > >> On 09/08/2013 10:27, Ivan Gerasimov wrote: >>> Chris, >>> >>> I would use this >>> >>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == >>> NULL) { >>> JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed"); >>> return NULL/JNI_False/-1; >>> } >>> >>> If I understand it correctly, JNU_ThrowOutOfMemoryError throws an >>> exception only if it hasn't been already thrown. >> >> JNU_ThrowOutOfMemoryError is simply a convenience wrapper for >> JNU_ThrowByName(env, "java/lang/OutOfMemoryError", msg); >> >> ...and JNU_ThrowByName [1] is defined as... >> >> JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg) { >> class cls = (*env)->FindClass(env, name); >> if (cls != 0) /* Otherwise an exception has already been thrown */ >> (*env)->ThrowNew(env, cls, msg); >> } >> } >> >> Neither FindClass or ThrowNew is safe to call if there is a pending >> exception [1]. > > Right - we have to check for a pending exception before trying to > throw one. > >> Now the issue comes down to; could there ever be a pending exception if >> GetStringUTFChars returns NULL? The latest specs doesn't indicate that >> there could be, but every copy of "The Java Native Interface >> Programmer's Guide and Specification" I can find does. There also >> appears to be an assumption of this if you look at the usages in the >> JDK. > > AFAIK there is only one version of the JNI spec book and it never got > updated. The official spec says no throw, but when people have the > book on their bookshelf that is what they tend to rely on. I looked at > some of the usages and they seem exception agnostic - many of them > don't even check for NULL :( > > The implementation as it stands will not throw and will not return NULL. > >> I would really like to get a definitive answer on the JNI specification >> for GetStringUTFChars before making any changes here. > > The JNI spec (as opposed to the book) is definitive. If we don't like > what is there then it requires a spec change. > > I can't find any reference to this particular issue being raised before. > > Cheers, > David > >> -Chris. >> >> [1] >> http://hg.openjdk.java.net/jdk8/tl/jdk/file/54f0ccdd9ad7/src/share/native/common/jni_util.c >> >> >> [2] >> http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp17626 >> >> >> >>> >>> Sincerely yours, >>> Ivan >>> >>> >>> On 09.08.2013 11:25, Chris Hegarty wrote: >>>> On 09/08/2013 06:47, David Holmes wrote: >>>>> Sorry I messed this up. The JNI book says GetStringUTFChars will >>>>> return >>>>> NULL and post OOME but the JNI spec (latest version 6.0) does not >>>>> - it >>>>> only says it will return NULL on failure. >>>> >>>> This is indeed strange. Most usages of this function in the jdk expect >>>> the former. If this is not the case, then we may need to do an audit >>>> of all usages. >>>> >>>>> So your previous version was the more correct. Given we just >>>>> failed to >>>>> allocate C-heap I think we are on thin ice anyway, but better to at >>>>> least attempt to do the right thing. >>>> >>>> I'm not sure what the right thing to do here is? It seems a little >>>> unwieldy! >>>> >>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == >>>> NULL) { >>>> if ((*env)->ExceptionOccurred(env)) { >>>> return NULL/JNI_False/-1; >>>> } else { >>>> throwException(env, "java/lang/InternalError", "GetStringUTFChars >>>> failed"); >>>> return NULL/JNI_False/-1; >>>> } >>>> >>>> Given we have no idea why GetStringUTFChars may have failed, what >>>> exception do we throw? >>>> >>>> Also worth noting is that this bug fix has moved away from the >>>> original problem (memory leak), and is now focused on code cleanup. >>>> >>>> If we cannot get agreement on the cleanup, or it looks like more >>>> clarification is needed around the cleanup effort, then I would like >>>> to suggest that we proceed with the original fix for the memory leak >>>> and separate out the cleanup effort. >>>> >>>> -Chris. >>>> >>>>> FYI I filed 8022683 to fix GetStringUTFChars. >>>>> >>>>> David >>>>> ----- >>>>> >>>>> On 9/08/2013 3:21 PM, David Holmes wrote: >>>>>> Thumbs up! >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote: >>>>>>> Thanks David! >>>>>>> >>>>>>> On 09.08.2013 1:15, David Holmes wrote: >>>>>>>> Main fix looks good to me. >>>>>>>> >>>>>>>> Regression test may need some tweaking eg I think othervm will be >>>>>>>> needed. >>>>>>>> >>>>>>> Yes, it's a good point. >>>>>>> Since there may be a memory leak in the test, it'd better not >>>>>>> interfere >>>>>>> with other tests in jtreg. >>>>>>> >>>>>>>> Also this: >>>>>>>> >>>>>>>> System.out.println("WARNING: Cannot perform memory leak >>>>>>>> detection on >>>>>>>> this OS"); >>>>>>>> >>>>>>>> should probably just say something like "Test skipped on this >>>>>>>> OS" - >>>>>>>> there are other tests that do this so just check if there is >>>>>>>> common >>>>>>>> terminology. (In the future we may have keyword tags to flag >>>>>>>> this as >>>>>>>> linux only etc.) >>>>>>>> >>>>>>> OK, I changed the phrase to "Test only runs on Linux". >>>>>>> >>>>>>> Updated webrev is here: >>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ >>>>>>> >>>>>>> Updated export is at the same place: >>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>>>>>>> Chris, if it's not too late, I'd like to include a regtest in the >>>>>>>>> fix. >>>>>>>>> >>>>>>>>> Here's webrev that includes the test: >>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>>>>>>> >>>>>>>>> The test gets past with the fixed jdk8 and fails with >>>>>>>>> jdk8-b101 and >>>>>>>>> jdk7 >>>>>>>>> as expected. >>>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>>>>>>> Looks good to me. Thanks Ivan. >>>>>>>>>> >>>>>>>>>> -Chris. >>>>>>>>>> >>>>>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>>>>>>> Hello Chris! >>>>>>>>>>> >>>>>>>>>>> Here's the update: >>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>>>>>>> >>>>>>>>>>> Thanks for offering the sponsorship! >>>>>>>>>>> Here's the hg-export >>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Sincerely yours, >>>>>>>>>>> Ivan >>>>>>>>>>> >>>>>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>>>>>>> Thanks for taking this Ivan. >>>>>>>>>>>> >>>>>>>>>>>> Can you please make the changes suggested by both David and >>>>>>>>>>>> Alan ( >>>>>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>>>>>>> GetStringUTFChars >>>>>>>>>>>> fails ( returns NULL ), then I will sponsor this change into >>>>>>>>>>>> jdk8 >>>>>>>>>>>> for >>>>>>>>>>>> you. >>>>>>>>>>>> >>>>>>>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>>>>>>> >>>>>>>>>>>> -Chris. >>>>>>>>>>>> >>>>>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>>>>>>> Ivan, >>>>>>>>>>>>> >>>>>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>>>>>>> David, Alan, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I added checking for NULL results and throwing >>>>>>>>>>>>>> OOMException if >>>>>>>>>>>>>> necessary. >>>>>>>>>>>>> >>>>>>>>>>>>> You don't need to throw it yourself: >>>>>>>>>>>>> >>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>>>>>>> >>>>>>>>>>>>> Assuming a correct VM implementation if NULL is returned >>>>>>>>>>>>> then an >>>>>>>>>>>>> OOME >>>>>>>>>>>>> should already be pending and will be thrown as soon as your >>>>>>>>>>>>> native >>>>>>>>>>>>> code >>>>>>>>>>>>> returns to Java. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>>>>>>> indentation. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Would you please review the updated webrev? >>>>>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars >>>>>>>>>>>>>>>> cannot >>>>>>>>>>>>>>>> return >>>>>>>>>>>>>>>> NULL. >>>>>>>>>>>>>>>> For allocation of the result string it calls >>>>>>>>>>>>>>>> AllocateHeap() >>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply >>>>>>>>>>>>>>>> stops >>>>>>>>>>>>>>>> VM. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is >>>>>>>>>>>>>>> supposed to >>>>>>>>>>>>>>> throw >>>>>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I recommend that you check for NULL and/or a pending >>>>>>>>>>>>>>> exception. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you >>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>> there) is >>>>>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the >>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>> returns >>>>>>>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -Alan. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to >>>>>>>>>>>>>>>>>> leak >>>>>>>>>>>>>>>>>> memory. >>>>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not >>>>>>>>>>>>>>>>>> yet >>>>>>>>>>>>>>>>>> available.) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>>>>>> allocation? >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>> >>>> >>> > > From peter.levart at gmail.com Mon Aug 12 12:40:07 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 12 Aug 2013 14:40:07 +0200 Subject: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters synchronized method In-Reply-To: <20130812105439.GC6420@jfranck-desktop.jrpg.bea.com> References: <5202733D.60205@gmail.com> <520278DF.2060102@oracle.com> <520777E5.3050304@gmail.com> <20130812105439.GC6420@jfranck-desktop.jrpg.bea.com> Message-ID: <5208D7A7.9070608@gmail.com> Hi Joel, Thanks for review. Comments inline... On 08/12/2013 12:54 PM, Joel Borggren-Franck wrote: > Hi Peter, > > Thank you for looking in to this! > > On 2013-08-11, Peter Levart wrote: >> On 08/07/2013 06:42 PM, Aleksey Shipilev wrote: >>> Hi Peter, >>> >>> On 08/07/2013 08:18 PM, Peter Levart wrote: >>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.01/ >>> Yeah, looks familiar. The install loop is very complicated though, can >>> we simplify it? It seems profitable to move the retry loop up into >>> annotationData(): you then don't have to pass the $annotationData, you >>> can merge the exit paths for $classRedefinedCount, etc. >> Hi Aleksey, >> >> Right, the retry-loop can be simplified. There are still two >> methods, but the 2nd is only a factory method now: >> >> http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.02/ >> > I realize the interaction between probably any reflective operation and > a redefine is blurry, but if a redefine occurs between line 3308 and 3309 > annotationData() will return a possibly outdated AnnotationData. > > 3307 if (Atomic.casAnnotationData(this, annotationData, newAnnotationData)) { > 3308 // successfully installed new AnnotationData > > redefine here > > 3309 return newAnnotationData; > 3310 } > > I suppose there is a sequencing of events where this will be inevitable, > but this got me thinking about the state model of annotations (and > reflective objects) through an redefine. The AnnotationData created and returned concurrently with class redefinition can contain old or new version, yes, but that's not a problem, since the AnnotationData also contains a "redefinedCount" field, so any further requests for annotations will trigger re-computation. This assumes that VM either changes the state returned by getRawAnnotations() and "classRedefinedCount" field atomically (during a safepoint?) or at least in order: 1st getRawAnnotations(), 2nd "classRedefinedCount". We 1st read "classRedefinedCount" and then getRawAnnotations(), so there's no danger of keeping and returning stale data after redefinition. This is more or less the same as with ReflectionData caching. > > I think we need to be a bit more explicit about documenting that state > model. If you have a good mental model of this perhaps now is a good > time to write it down? Inconsistencies remain that are hard to solve: - inherited annotations. They are combined with declared annotations in a Map that is cached in the AnnotationData. If superclass is redefined, the inherited annotations are not invalidated. Unless the VM increments classRedefinedCount for the redefined class and all currently loaded subclasses. I don't know if this is the case. If this is not the case, we could keep both classRedefinedCount and superclassRedefinedCount in the AnnotationData and invalidate it if any of them changes. This would slow-down any access to annotations though. - annotation (@interface) declarations can themselves be redefined (for example, defaults changed). Such redefinitions don't affect already initialized annotations. Default values are cached in AnnotationType which is not invalidated as a result of class redefinition. Maybe it should be. And even if AnnotationType was invalidated as a result of class redefinition, the defaults are looked-up when particular annotations are initialized and then combined with parsed values in a single values map inside each annotation instance (proxy), so invalidating AnnotationType would have no effect on those annotations. > > 3326 if (annotations == null) { // lazy construction > 3327 annotations = new HashMap<>(); > 3328 } > > I think this should be a LinkedHashMap, so that iteration is predictable > (I know it isn't in the current code). Also the size of the map is known > so you can use a constructor with an explicit initial capacity. Right, AnnotationParser does return LinkedHashMap, so at least decalredAnnotations are in parse-order. I will change the code to use LinkedHashMap for inherited/combined case too. The number of annotations that end-up in inherited/combined Map is not known in advance. I could make a separate pre-scan for superclass annotations that are @Inheritable and don't have the same key as any of declared annotations and then sum this count with declared annotations count, but I don't think this will be very effective. I could allocate a large-enough Map to always fit (the count of superclass annotations + the count of declared annotations), but that could sometimes lead to much over-allocated Maps. I could take the min(DEFAULT_CAPACITY, superclass annotations count + declared annotations count) as the initial capacity for the Map. What do you think which of those 3 alternatives is the best? > > Since this is a fairly significant rewrite I think it might be good to > make sure our tests exercise the new code. Can you run some kind of > coverage report on this? I successfully ran the jdk_lang jtreg tests which contain several tests for annotations. > > Otherwise this looks good (not an R kind of reviewer). > > cheers > /Joel Regards, Peter From chris.hegarty at oracle.com Mon Aug 12 12:43:09 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 12 Aug 2013 13:43:09 +0100 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5208D62C.3030107@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> <52047C66.2080001@oracle.com> <52048269.7000501@oracle.com> <5204997B.3090601@oracle.com> <5204B5F3.6000506@oracle.com> <5204C626.3000102@oracle.com> <5204DE28.5090805@oracle.com> <5208D62C.3030107@oracle.com> Message-ID: <5208D85D.1090606@oracle.com> Thank you Ivan. This looks good to me. -Chris. P.S. I will give others a chance to comment. If no objections, I will push this tomorrow for you. On 12/08/2013 13:33, Ivan Gerasimov wrote: > David, Chris, > > I reverted back NULL-checking. > Now the change consists of one line removal and a regression test. > > Webrev: http://cr.openjdk.java.net/~igerasim/8022584/6/webrev/ > Hg export: > http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch > > > Sincerely yours, > Ivan > > On 09.08.2013 16:18, David Holmes wrote: >> Hi Chris, >> >> On 9/08/2013 8:36 PM, Chris Hegarty wrote: >>> Firstly, I think the memory leak issue should be moved forward >>> separately to this cleanup effort. They are unrelated, and I'm starting >>> to get the feeling that this could take some time to reach conclusion. >>> It seems reasonable to separate the issues. >> >> I agree. I'm sure when Alan suggested to check the return he didn't >> expect it to unravel like this :) As we know hotspot will never >> actually return NULL there is no urgency to add this in. >> >>> On 09/08/2013 10:27, Ivan Gerasimov wrote: >>>> Chris, >>>> >>>> I would use this >>>> >>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == >>>> NULL) { >>>> JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed"); >>>> return NULL/JNI_False/-1; >>>> } >>>> >>>> If I understand it correctly, JNU_ThrowOutOfMemoryError throws an >>>> exception only if it hasn't been already thrown. >>> >>> JNU_ThrowOutOfMemoryError is simply a convenience wrapper for >>> JNU_ThrowByName(env, "java/lang/OutOfMemoryError", msg); >>> >>> ...and JNU_ThrowByName [1] is defined as... >>> >>> JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg) { >>> class cls = (*env)->FindClass(env, name); >>> if (cls != 0) /* Otherwise an exception has already been thrown */ >>> (*env)->ThrowNew(env, cls, msg); >>> } >>> } >>> >>> Neither FindClass or ThrowNew is safe to call if there is a pending >>> exception [1]. >> >> Right - we have to check for a pending exception before trying to >> throw one. >> >>> Now the issue comes down to; could there ever be a pending exception if >>> GetStringUTFChars returns NULL? The latest specs doesn't indicate that >>> there could be, but every copy of "The Java Native Interface >>> Programmer's Guide and Specification" I can find does. There also >>> appears to be an assumption of this if you look at the usages in the >>> JDK. >> >> AFAIK there is only one version of the JNI spec book and it never got >> updated. The official spec says no throw, but when people have the >> book on their bookshelf that is what they tend to rely on. I looked at >> some of the usages and they seem exception agnostic - many of them >> don't even check for NULL :( >> >> The implementation as it stands will not throw and will not return NULL. >> >>> I would really like to get a definitive answer on the JNI specification >>> for GetStringUTFChars before making any changes here. >> >> The JNI spec (as opposed to the book) is definitive. If we don't like >> what is there then it requires a spec change. >> >> I can't find any reference to this particular issue being raised before. >> >> Cheers, >> David >> >>> -Chris. >>> >>> [1] >>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/54f0ccdd9ad7/src/share/native/common/jni_util.c >>> >>> >>> [2] >>> http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp17626 >>> >>> >>> >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>> On 09.08.2013 11:25, Chris Hegarty wrote: >>>>> On 09/08/2013 06:47, David Holmes wrote: >>>>>> Sorry I messed this up. The JNI book says GetStringUTFChars will >>>>>> return >>>>>> NULL and post OOME but the JNI spec (latest version 6.0) does not >>>>>> - it >>>>>> only says it will return NULL on failure. >>>>> >>>>> This is indeed strange. Most usages of this function in the jdk expect >>>>> the former. If this is not the case, then we may need to do an audit >>>>> of all usages. >>>>> >>>>>> So your previous version was the more correct. Given we just >>>>>> failed to >>>>>> allocate C-heap I think we are on thin ice anyway, but better to at >>>>>> least attempt to do the right thing. >>>>> >>>>> I'm not sure what the right thing to do here is? It seems a little >>>>> unwieldy! >>>>> >>>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == >>>>> NULL) { >>>>> if ((*env)->ExceptionOccurred(env)) { >>>>> return NULL/JNI_False/-1; >>>>> } else { >>>>> throwException(env, "java/lang/InternalError", "GetStringUTFChars >>>>> failed"); >>>>> return NULL/JNI_False/-1; >>>>> } >>>>> >>>>> Given we have no idea why GetStringUTFChars may have failed, what >>>>> exception do we throw? >>>>> >>>>> Also worth noting is that this bug fix has moved away from the >>>>> original problem (memory leak), and is now focused on code cleanup. >>>>> >>>>> If we cannot get agreement on the cleanup, or it looks like more >>>>> clarification is needed around the cleanup effort, then I would like >>>>> to suggest that we proceed with the original fix for the memory leak >>>>> and separate out the cleanup effort. >>>>> >>>>> -Chris. >>>>> >>>>>> FYI I filed 8022683 to fix GetStringUTFChars. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> On 9/08/2013 3:21 PM, David Holmes wrote: >>>>>>> Thumbs up! >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote: >>>>>>>> Thanks David! >>>>>>>> >>>>>>>> On 09.08.2013 1:15, David Holmes wrote: >>>>>>>>> Main fix looks good to me. >>>>>>>>> >>>>>>>>> Regression test may need some tweaking eg I think othervm will be >>>>>>>>> needed. >>>>>>>>> >>>>>>>> Yes, it's a good point. >>>>>>>> Since there may be a memory leak in the test, it'd better not >>>>>>>> interfere >>>>>>>> with other tests in jtreg. >>>>>>>> >>>>>>>>> Also this: >>>>>>>>> >>>>>>>>> System.out.println("WARNING: Cannot perform memory leak >>>>>>>>> detection on >>>>>>>>> this OS"); >>>>>>>>> >>>>>>>>> should probably just say something like "Test skipped on this >>>>>>>>> OS" - >>>>>>>>> there are other tests that do this so just check if there is >>>>>>>>> common >>>>>>>>> terminology. (In the future we may have keyword tags to flag >>>>>>>>> this as >>>>>>>>> linux only etc.) >>>>>>>>> >>>>>>>> OK, I changed the phrase to "Test only runs on Linux". >>>>>>>> >>>>>>>> Updated webrev is here: >>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ >>>>>>>> >>>>>>>> Updated export is at the same place: >>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>>>>>>>> Chris, if it's not too late, I'd like to include a regtest in the >>>>>>>>>> fix. >>>>>>>>>> >>>>>>>>>> Here's webrev that includes the test: >>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>>>>>>>> >>>>>>>>>> The test gets past with the fixed jdk8 and fails with >>>>>>>>>> jdk8-b101 and >>>>>>>>>> jdk7 >>>>>>>>>> as expected. >>>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>>>>>>>> Looks good to me. Thanks Ivan. >>>>>>>>>>> >>>>>>>>>>> -Chris. >>>>>>>>>>> >>>>>>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>>>>>>>> Hello Chris! >>>>>>>>>>>> >>>>>>>>>>>> Here's the update: >>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> Thanks for offering the sponsorship! >>>>>>>>>>>> Here's the hg-export >>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>> Ivan >>>>>>>>>>>> >>>>>>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>>>>>>>> Thanks for taking this Ivan. >>>>>>>>>>>>> >>>>>>>>>>>>> Can you please make the changes suggested by both David and >>>>>>>>>>>>> Alan ( >>>>>>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>>>>>>>> GetStringUTFChars >>>>>>>>>>>>> fails ( returns NULL ), then I will sponsor this change into >>>>>>>>>>>>> jdk8 >>>>>>>>>>>>> for >>>>>>>>>>>>> you. >>>>>>>>>>>>> >>>>>>>>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>>>>>>>> >>>>>>>>>>>>> -Chris. >>>>>>>>>>>>> >>>>>>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>>>>>>>> Ivan, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>>>>>>>> David, Alan, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I added checking for NULL results and throwing >>>>>>>>>>>>>>> OOMException if >>>>>>>>>>>>>>> necessary. >>>>>>>>>>>>>> >>>>>>>>>>>>>> You don't need to throw it yourself: >>>>>>>>>>>>>> >>>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>>>>>>>> >>>>>>>>>>>>>> Assuming a correct VM implementation if NULL is returned >>>>>>>>>>>>>> then an >>>>>>>>>>>>>> OOME >>>>>>>>>>>>>> should already be pending and will be thrown as soon as your >>>>>>>>>>>>>> native >>>>>>>>>>>>>> code >>>>>>>>>>>>>> returns to Java. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>>>>>>>> indentation. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Would you please review the updated webrev? >>>>>>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars >>>>>>>>>>>>>>>>> cannot >>>>>>>>>>>>>>>>> return >>>>>>>>>>>>>>>>> NULL. >>>>>>>>>>>>>>>>> For allocation of the result string it calls >>>>>>>>>>>>>>>>> AllocateHeap() >>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply >>>>>>>>>>>>>>>>> stops >>>>>>>>>>>>>>>>> VM. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is >>>>>>>>>>>>>>>> supposed to >>>>>>>>>>>>>>>> throw >>>>>>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I recommend that you check for NULL and/or a pending >>>>>>>>>>>>>>>> exception. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you >>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>> there) is >>>>>>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the >>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>> returns >>>>>>>>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -Alan. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to >>>>>>>>>>>>>>>>>>> leak >>>>>>>>>>>>>>>>>>> memory. >>>>>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not >>>>>>>>>>>>>>>>>>> yet >>>>>>>>>>>>>>>>>>> available.) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>>>>>>> allocation? >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>> >>>>> >>>> >> >> > From ivan.gerasimov at oracle.com Mon Aug 12 12:44:26 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 12 Aug 2013 16:44:26 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5208D85D.1090606@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> <52047C66.2080001@oracle.com> <52048269.7000501@oracle.com> <5204997B.3090601@oracle.com> <5204B5F3.6000506@oracle.com> <5204C626.3000102@oracle.com> <5204DE28.5090805@oracle.com> <5208D62C.3030107@oracle.com> <5208D85D.1090606@oracle.com> Message-ID: <5208D8AA.5090302@oracle.com> Thank you Chris! On 12.08.2013 16:43, Chris Hegarty wrote: > Thank you Ivan. This looks good to me. > > -Chris. > > P.S. I will give others a chance to comment. If no objections, I will > push this tomorrow for you. > > On 12/08/2013 13:33, Ivan Gerasimov wrote: >> David, Chris, >> >> I reverted back NULL-checking. >> Now the change consists of one line removal and a regression test. >> >> Webrev: http://cr.openjdk.java.net/~igerasim/8022584/6/webrev/ >> Hg export: >> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >> >> >> >> Sincerely yours, >> Ivan >> >> On 09.08.2013 16:18, David Holmes wrote: >>> Hi Chris, >>> >>> On 9/08/2013 8:36 PM, Chris Hegarty wrote: >>>> Firstly, I think the memory leak issue should be moved forward >>>> separately to this cleanup effort. They are unrelated, and I'm >>>> starting >>>> to get the feeling that this could take some time to reach conclusion. >>>> It seems reasonable to separate the issues. >>> >>> I agree. I'm sure when Alan suggested to check the return he didn't >>> expect it to unravel like this :) As we know hotspot will never >>> actually return NULL there is no urgency to add this in. >>> >>>> On 09/08/2013 10:27, Ivan Gerasimov wrote: >>>>> Chris, >>>>> >>>>> I would use this >>>>> >>>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == >>>>> NULL) { >>>>> JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed"); >>>>> return NULL/JNI_False/-1; >>>>> } >>>>> >>>>> If I understand it correctly, JNU_ThrowOutOfMemoryError throws an >>>>> exception only if it hasn't been already thrown. >>>> >>>> JNU_ThrowOutOfMemoryError is simply a convenience wrapper for >>>> JNU_ThrowByName(env, "java/lang/OutOfMemoryError", msg); >>>> >>>> ...and JNU_ThrowByName [1] is defined as... >>>> >>>> JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg) { >>>> class cls = (*env)->FindClass(env, name); >>>> if (cls != 0) /* Otherwise an exception has already been thrown */ >>>> (*env)->ThrowNew(env, cls, msg); >>>> } >>>> } >>>> >>>> Neither FindClass or ThrowNew is safe to call if there is a pending >>>> exception [1]. >>> >>> Right - we have to check for a pending exception before trying to >>> throw one. >>> >>>> Now the issue comes down to; could there ever be a pending >>>> exception if >>>> GetStringUTFChars returns NULL? The latest specs doesn't indicate that >>>> there could be, but every copy of "The Java Native Interface >>>> Programmer's Guide and Specification" I can find does. There also >>>> appears to be an assumption of this if you look at the usages in the >>>> JDK. >>> >>> AFAIK there is only one version of the JNI spec book and it never got >>> updated. The official spec says no throw, but when people have the >>> book on their bookshelf that is what they tend to rely on. I looked at >>> some of the usages and they seem exception agnostic - many of them >>> don't even check for NULL :( >>> >>> The implementation as it stands will not throw and will not return >>> NULL. >>> >>>> I would really like to get a definitive answer on the JNI >>>> specification >>>> for GetStringUTFChars before making any changes here. >>> >>> The JNI spec (as opposed to the book) is definitive. If we don't like >>> what is there then it requires a spec change. >>> >>> I can't find any reference to this particular issue being raised >>> before. >>> >>> Cheers, >>> David >>> >>>> -Chris. >>>> >>>> [1] >>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/54f0ccdd9ad7/src/share/native/common/jni_util.c >>>> >>>> >>>> >>>> [2] >>>> http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp17626 >>>> >>>> >>>> >>>> >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> >>>>> On 09.08.2013 11:25, Chris Hegarty wrote: >>>>>> On 09/08/2013 06:47, David Holmes wrote: >>>>>>> Sorry I messed this up. The JNI book says GetStringUTFChars will >>>>>>> return >>>>>>> NULL and post OOME but the JNI spec (latest version 6.0) does not >>>>>>> - it >>>>>>> only says it will return NULL on failure. >>>>>> >>>>>> This is indeed strange. Most usages of this function in the jdk >>>>>> expect >>>>>> the former. If this is not the case, then we may need to do an audit >>>>>> of all usages. >>>>>> >>>>>>> So your previous version was the more correct. Given we just >>>>>>> failed to >>>>>>> allocate C-heap I think we are on thin ice anyway, but better to at >>>>>>> least attempt to do the right thing. >>>>>> >>>>>> I'm not sure what the right thing to do here is? It seems a little >>>>>> unwieldy! >>>>>> >>>>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == >>>>>> NULL) { >>>>>> if ((*env)->ExceptionOccurred(env)) { >>>>>> return NULL/JNI_False/-1; >>>>>> } else { >>>>>> throwException(env, "java/lang/InternalError", "GetStringUTFChars >>>>>> failed"); >>>>>> return NULL/JNI_False/-1; >>>>>> } >>>>>> >>>>>> Given we have no idea why GetStringUTFChars may have failed, what >>>>>> exception do we throw? >>>>>> >>>>>> Also worth noting is that this bug fix has moved away from the >>>>>> original problem (memory leak), and is now focused on code cleanup. >>>>>> >>>>>> If we cannot get agreement on the cleanup, or it looks like more >>>>>> clarification is needed around the cleanup effort, then I would like >>>>>> to suggest that we proceed with the original fix for the memory leak >>>>>> and separate out the cleanup effort. >>>>>> >>>>>> -Chris. >>>>>> >>>>>>> FYI I filed 8022683 to fix GetStringUTFChars. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> On 9/08/2013 3:21 PM, David Holmes wrote: >>>>>>>> Thumbs up! >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote: >>>>>>>>> Thanks David! >>>>>>>>> >>>>>>>>> On 09.08.2013 1:15, David Holmes wrote: >>>>>>>>>> Main fix looks good to me. >>>>>>>>>> >>>>>>>>>> Regression test may need some tweaking eg I think othervm >>>>>>>>>> will be >>>>>>>>>> needed. >>>>>>>>>> >>>>>>>>> Yes, it's a good point. >>>>>>>>> Since there may be a memory leak in the test, it'd better not >>>>>>>>> interfere >>>>>>>>> with other tests in jtreg. >>>>>>>>> >>>>>>>>>> Also this: >>>>>>>>>> >>>>>>>>>> System.out.println("WARNING: Cannot perform memory leak >>>>>>>>>> detection on >>>>>>>>>> this OS"); >>>>>>>>>> >>>>>>>>>> should probably just say something like "Test skipped on this >>>>>>>>>> OS" - >>>>>>>>>> there are other tests that do this so just check if there is >>>>>>>>>> common >>>>>>>>>> terminology. (In the future we may have keyword tags to flag >>>>>>>>>> this as >>>>>>>>>> linux only etc.) >>>>>>>>>> >>>>>>>>> OK, I changed the phrase to "Test only runs on Linux". >>>>>>>>> >>>>>>>>> Updated webrev is here: >>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ >>>>>>>>> >>>>>>>>> Updated export is at the same place: >>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>>>>>>>>> Chris, if it's not too late, I'd like to include a regtest >>>>>>>>>>> in the >>>>>>>>>>> fix. >>>>>>>>>>> >>>>>>>>>>> Here's webrev that includes the test: >>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>>>>>>>>> >>>>>>>>>>> The test gets past with the fixed jdk8 and fails with >>>>>>>>>>> jdk8-b101 and >>>>>>>>>>> jdk7 >>>>>>>>>>> as expected. >>>>>>>>>>> >>>>>>>>>>> Sincerely yours, >>>>>>>>>>> Ivan >>>>>>>>>>> >>>>>>>>>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>>>>>>>>> Looks good to me. Thanks Ivan. >>>>>>>>>>>> >>>>>>>>>>>> -Chris. >>>>>>>>>>>> >>>>>>>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>>>>>>>>> Hello Chris! >>>>>>>>>>>>> >>>>>>>>>>>>> Here's the update: >>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for offering the sponsorship! >>>>>>>>>>>>> Here's the hg-export >>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>> Ivan >>>>>>>>>>>>> >>>>>>>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>>>>>>>>> Thanks for taking this Ivan. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can you please make the changes suggested by both David and >>>>>>>>>>>>>> Alan ( >>>>>>>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>>>>>>>>> GetStringUTFChars >>>>>>>>>>>>>> fails ( returns NULL ), then I will sponsor this change into >>>>>>>>>>>>>> jdk8 >>>>>>>>>>>>>> for >>>>>>>>>>>>>> you. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Chris. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>>>>>>>>> Ivan, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>> David, Alan, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I added checking for NULL results and throwing >>>>>>>>>>>>>>>> OOMException if >>>>>>>>>>>>>>>> necessary. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You don't need to throw it yourself: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Assuming a correct VM implementation if NULL is returned >>>>>>>>>>>>>>> then an >>>>>>>>>>>>>>> OOME >>>>>>>>>>>>>>> should already be pending and will be thrown as soon as >>>>>>>>>>>>>>> your >>>>>>>>>>>>>>> native >>>>>>>>>>>>>>> code >>>>>>>>>>>>>>> returns to Java. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>>>>>>>>> indentation. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Would you please review the updated webrev? >>>>>>>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I've checked that and it turns out that >>>>>>>>>>>>>>>>>> GetStringUTFChars >>>>>>>>>>>>>>>>>> cannot >>>>>>>>>>>>>>>>>> return >>>>>>>>>>>>>>>>>> NULL. >>>>>>>>>>>>>>>>>> For allocation of the result string it calls >>>>>>>>>>>>>>>>>> AllocateHeap() >>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>>>>>>>>> Thus, in case of being unable to allocate memory it >>>>>>>>>>>>>>>>>> simply >>>>>>>>>>>>>>>>>> stops >>>>>>>>>>>>>>>>>> VM. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is >>>>>>>>>>>>>>>>> supposed to >>>>>>>>>>>>>>>>> throw >>>>>>>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort >>>>>>>>>>>>>>>>> the VM! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I recommend that you check for NULL and/or a pending >>>>>>>>>>>>>>>>> exception. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you >>>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>> there) is >>>>>>>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the >>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>>> returns >>>>>>>>>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -Alan. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Some methods of NetworkInterface class were >>>>>>>>>>>>>>>>>>>> reported to >>>>>>>>>>>>>>>>>>>> leak >>>>>>>>>>>>>>>>>>>> memory. >>>>>>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 >>>>>>>>>>>>>>>>>>>> (not >>>>>>>>>>>>>>>>>>>> yet >>>>>>>>>>>>>>>>>>>> available.) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>>>>>>>> allocation? >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>> >>> >>> >> > > From paul.sandoz at oracle.com Mon Aug 12 13:19:32 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Aug 2013 15:19:32 +0200 Subject: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters synchronized method In-Reply-To: <5208D7A7.9070608@gmail.com> References: <5202733D.60205@gmail.com> <520278DF.2060102@oracle.com> <520777E5.3050304@gmail.com> <20130812105439.GC6420@jfranck-desktop.jrpg.bea.com> <5208D7A7.9070608@gmail.com> Message-ID: On Aug 12, 2013, at 2:40 PM, Peter Levart wrote: > Hi Joel, > > Thanks for review. Comments inline... > > On 08/12/2013 12:54 PM, Joel Borggren-Franck wrote: >> Hi Peter, >> >> Thank you for looking in to this! >> >> On 2013-08-11, Peter Levart wrote: >>> On 08/07/2013 06:42 PM, Aleksey Shipilev wrote: >>>> Hi Peter, >>>> >>>> On 08/07/2013 08:18 PM, Peter Levart wrote: >>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.01/ >>>> Yeah, looks familiar. The install loop is very complicated though, can >>>> we simplify it? It seems profitable to move the retry loop up into >>>> annotationData(): you then don't have to pass the $annotationData, you >>>> can merge the exit paths for $classRedefinedCount, etc. >>> Hi Aleksey, >>> >>> Right, the retry-loop can be simplified. There are still two >>> methods, but the 2nd is only a factory method now: >>> >>> http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.02/ >>> >> I realize the interaction between probably any reflective operation and >> a redefine is blurry, but if a redefine occurs between line 3308 and 3309 >> annotationData() will return a possibly outdated AnnotationData. >> >> 3307 if (Atomic.casAnnotationData(this, annotationData, newAnnotationData)) { >> 3308 // successfully installed new AnnotationData >> >> redefine here >> >> 3309 return newAnnotationData; >> 3310 } >> >> I suppose there is a sequencing of events where this will be inevitable, >> but this got me thinking about the state model of annotations (and >> reflective objects) through an redefine. > > The AnnotationData created and returned concurrently with class redefinition can contain old or new version, yes, but that's not a problem, since the AnnotationData also contains a "redefinedCount" field, so any further requests for annotations will trigger re-computation. This assumes that VM either changes the state returned by getRawAnnotations() and "classRedefinedCount" field atomically (during a safepoint?) or at least in order: 1st getRawAnnotations(), 2nd "classRedefinedCount". We 1st read "classRedefinedCount" and then > getRawAnnotations(), so there's no danger of keeping and returning stale data after redefinition. > > This is more or less the same as with ReflectionData caching. > I suppose one could do the cas without checking it's result: 3296 private AnnotationData annotationData() { 3297 while (true) { // retry loop 3298 AnnotationData annotationData = this.annotationData; 3299 int classRedefinedCount = this.classRedefinedCount; 3300 if (annotationData != null && 3301 annotationData.redefinedCount == classRedefinedCount) { 3302 return annotationData; 3303 } 3304 // null or stale annotationData -> optimistically create new instance 3306 // try to install it 3307 Atomic.casAnnotationData(this, annotationData, createAnnotationData(classRedefinedCount)); // re-check conditions in case a re-defintion occurred while creating 3311 } 3312 } Don't really know if it is worth it though, plus it might be better to break out the loop once set. Note frameworks, such as JAXB and JAX-RS will cache results of processing reflection and annotation information and need to be given a kick to re-process (e.g. like from JRebel). >> >> I think we need to be a bit more explicit about documenting that state >> model. If you have a good mental model of this perhaps now is a good >> time to write it down? > > Inconsistencies remain that are hard to solve: > > - inherited annotations. They are combined with declared annotations in a Map that is cached in the AnnotationData. If superclass is redefined, the inherited annotations are not invalidated. Unless the VM increments classRedefinedCount for the redefined class and all currently loaded subclasses. I don't know if this is the case. Same here. There is a comment which implies it does get updated: 2389 // Incremented by the VM on each call to JVM TI RedefineClasses() 2390 // that redefines this class or a superclass. 2391 private volatile transient int classRedefinedCount = 0; Paul. From harold.seigel at oracle.com Mon Aug 12 13:26:26 2013 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 12 Aug 2013 09:26:26 -0400 Subject: RFR 8022259 MakeClasslist tool is buggy and its README is out of date. In-Reply-To: <5208A0F7.2000003@oracle.com> References: <5202A528.5060504@oracle.com> <5208A0F7.2000003@oracle.com> Message-ID: <5208E282.1090209@oracle.com> Hi David and Alan, Thank you for your comments. The change to the MakeClasslist tool to use TraceClassLoadingPreorder was made prior to my changes. The following code has been in MakeClasslist.java for a long time. I was unable to determine who had made this change or why. // Understand only "Loading" from -XX:+TraceClassLoadingPreorder. // This ignores old "Loaded" from -verbose:class to force correct // classlist generation on Mustang. if (t.equals("Loading")) { t = tok.nextToken(); t = t.replace('.', '/'); So, I don't know why TraceClassLoadingPreorder was chosen instead of -verbose:class or TraceClassLoading. The purpose of my changes are to update the comments to accurately reflect what the code currently does and to fix a bug in MakeClasslist.java's 'for' loop where the wrong set of strings is used. I plan to file a bug stating that the classlists need to be updated for JDK 8 and assign it to release engineering. Thanks, Harold On 8/12/2013 4:46 AM, Alan Bateman wrote: > On 07/08/2013 20:51, harold seigel wrote: >> Hi, >> >> Please review this small fix for bug 8022259. This change fixes a >> bug in the MakeClasslist tool and updates its README.txt file. >> >> webrev: http://cr.openjdk.java.net/~hseigel/bug_8022259/ >> >> >> bug: http://bugs.sun.com/view_bug.do?bug_id=8022259 >> >> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8022259 >> >> I tested the change by creating a testlist using the modified >> MakeClasslist tool and following the information in the changed >> README.txt file. >> >> Thanks! Harold > Can you explain it further as to why TraceClassLoadingPreorder traces > should be used rather than the TraceClassLoading traces? I ask because > we rarely see changes to the *.classlist files and to my knowledge, > all previous versions used the TraceClassLoading output. > > Also, are you planning to update the *.classlist files too? They > haven't been refreshed in a long time and would be good to get them > updated (it should also sort out a slew of warnings emitted in the > build about missing classes). > > -Alan. From sean.mullan at oracle.com Mon Aug 12 13:54:59 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Mon, 12 Aug 2013 13:54:59 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130812135553.CEA46487BD@hg.openjdk.java.net> Changeset: ffacf3e7a130 Author: mullan Date: 2013-08-12 09:03 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ffacf3e7a130 8016848: javax_security/auth/login tests fail in compact 1 and 2 profiles Summary: Change the default value of the "login.configuration.provider" security property to sun.security.provider.ConfigFile Reviewed-by: xuelei ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/javax/security/auth/login/Configuration.java + src/share/classes/sun/security/provider/ConfigFile.java - src/share/classes/sun/security/provider/ConfigSpiFile.java ! src/share/classes/sun/security/provider/SunEntries.java ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: d73fbf005f5f Author: mullan Date: 2013-08-12 09:29 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d73fbf005f5f Merge - src/share/classes/java/net/package.html - test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java - test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh From sundararajan.athijegannathan at oracle.com Mon Aug 12 15:14:44 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 12 Aug 2013 15:14:44 +0000 Subject: hg: jdk8/tl/nashorn: 9 new changesets Message-ID: <20130812151453.0397A487BF@hg.openjdk.java.net> Changeset: 14ea21d58f83 Author: jlaskey Date: 2013-08-08 11:20 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/14ea21d58f83 Merge - src/jdk/internal/dynalink/support/Backport.java Changeset: 47e2b609fe31 Author: sundar Date: 2013-08-09 20:48 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/47e2b609fe31 8022707: Revisit all doPrivileged blocks Reviewed-by: jlaskey, hannesw ! make/project.properties ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/linker/ClassAndLoader.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/tools/Shell.java Changeset: 01304b0550fb Author: sundar Date: 2013-08-12 14:43 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/01304b0550fb 8022782: publicLookup access failures in ScriptObject, ScriptFunction and ScriptFunction Reviewed-by: lagergren, attila, hannesw ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java Changeset: 3c13fba4d727 Author: attila Date: 2013-08-12 12:46 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3c13fba4d727 8022789: Revisit doPrivileged blocks in Dynalink Reviewed-by: lagergren, sundar ! src/jdk/internal/dynalink/DynamicLinkerFactory.java + src/jdk/internal/dynalink/support/ClassLoaderGetterContextProvider.java ! src/jdk/internal/dynalink/support/ClassMap.java ! src/jdk/internal/dynalink/support/TypeConverterFactory.java Changeset: 0bbaa0ac36ab Author: sundar Date: 2013-08-12 16:52 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0bbaa0ac36ab 8022614: Please exclude test test/script/trusted/JDK-8020809.js from Nashorn code coverage run Reviewed-by: jlaskey, lagergren ! exclude/exclude_list_cc.txt Changeset: 03ba1cd734c0 Author: hannesw Date: 2013-08-12 13:31 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/03ba1cd734c0 8022731: NativeArguments has wrong implementation of isMapped() Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/NativeArguments.java + test/script/basic/JDK-8022731.js + test/script/basic/JDK-8022731.js.EXPECTED Changeset: 821b605c7046 Author: sundar Date: 2013-08-12 17:08 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/821b605c7046 8022615: [nightly] Two nashorn print tests fail in nightly builds on Windows Reviewed-by: lagergren, jlaskey ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: f2e1673db03b Author: sundar Date: 2013-08-12 18:16 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f2e1673db03b 8022598: Object.getPrototypeOf should return null for host objects rather than throwing TypeError Reviewed-by: lagergren, jlaskey, attila, hannesw ! src/jdk/nashorn/internal/objects/NativeObject.java + test/script/basic/JDK-8022598.js Changeset: a0807e889be3 Author: sundar Date: 2013-08-12 20:37 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a0807e889be3 Merge From paul.sandoz at oracle.com Mon Aug 12 15:24:40 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Aug 2013 17:24:40 +0200 Subject: RFR 8022797 Clarify spliterator characteristics for collections containing no elements Message-ID: Hi, Here is another go at characteristics reported for spliterators of empty collections: diff -r f8d92ce66886 src/share/classes/java/util/Collection.java --- a/src/share/classes/java/util/Collection.java Mon Aug 12 13:59:01 2013 +0200 +++ b/src/share/classes/java/util/Collection.java Mon Aug 12 16:12:10 2013 +0200 @@ -504,7 +504,10 @@ * *

The returned {@code Spliterator} must report the characteristic * {@link Spliterator#SIZED}; implementations should document any additional - * characteristic values reported by the returned Spliterator. + * characteristic values reported by the returned spliterator. If + * this collection contains no elements then the returned spliterator is + * only required to report {@link Spliterator#SIZED} and is not required to + * report additional characteristics (if any). * *

The default implementation should be overridden by subclasses that * can return a more efficient spliterator. In order to @@ -535,6 +538,13 @@ * The returned {@code Spliterator} additionally reports * {@link Spliterator#SUBSIZED}. * + *

If a spliterator covers no elements then the reporting of additional + * characteristics, beyond that of {@code SIZED} and {@code SUBSIZED}, does + * not aid clients to control specialize or simplify computation. However, + * this does enable shared use of an empty spliterator (see + * {@link Spliterators#emptySpliterator()} for empty collections, and + * enables clients to determine if a spliterator covers no elements. + * * @return a {@code Spliterator} over the elements in this collection * @since 1.8 */ It might be preferable to also document this on List/Set/SortedSet since the documentation is overridden and i don't think we have many precedents for overriding what the sub-types define (are there any?). -- I logged issue 8022805 for Stream.concat(s, Stream.emptyStream()). Paul. From peter.levart at gmail.com Mon Aug 12 15:34:06 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 12 Aug 2013 17:34:06 +0200 Subject: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters synchronized method In-Reply-To: References: <5202733D.60205@gmail.com> <520278DF.2060102@oracle.com> <520777E5.3050304@gmail.com> <20130812105439.GC6420@jfranck-desktop.jrpg.bea.com> <5208D7A7.9070608@gmail.com> Message-ID: <5209006E.2070700@gmail.com> On 08/12/2013 03:19 PM, Paul Sandoz wrote: >> >- inherited annotations. They are combined with declared annotations in a Map that is cached in the AnnotationData. If superclass is redefined, the inherited annotations are not invalidated. Unless the VM increments classRedefinedCount for the redefined class and all currently loaded subclasses. I don't know if this is the case. > Same here. There is a comment which implies it does get updated: > > 2389 // Incremented by the VM on each call to JVM TI RedefineClasses() > 2390 // that redefines this class or a superclass. > 2391 private volatile transient int classRedefinedCount = 0; Oh, I missed that. Thanks for pointing it out. There's no problem for inherited annotations then. But if a default in the annotation declaration changes, then it only affects annotations that are constructed after that... Regards, Peter From Alan.Bateman at oracle.com Mon Aug 12 15:41:02 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Aug 2013 16:41:02 +0100 Subject: RFR 8022259 MakeClasslist tool is buggy and its README is out of date. In-Reply-To: <5208E282.1090209@oracle.com> References: <5202A528.5060504@oracle.com> <5208A0F7.2000003@oracle.com> <5208E282.1090209@oracle.com> Message-ID: <5209020E.2050506@oracle.com> On 12/08/2013 14:26, harold seigel wrote: > Hi David and Alan, > > Thank you for your comments. > > The change to the MakeClasslist tool to use TraceClassLoadingPreorder > was made prior to my changes. The following code has been in > MakeClasslist.java for a long time. I was unable to determine who had > made this change or why. > > // Understand only "Loading" from > -XX:+TraceClassLoadingPreorder. > // This ignores old "Loaded" from -verbose:class to force > correct > // classlist generation on Mustang. > if (t.equals("Loading")) { > t = tok.nextToken(); > t = t.replace('.', '/'); > > So, I don't know why TraceClassLoadingPreorder was chosen instead of > -verbose:class or TraceClassLoading. > > The purpose of my changes are to update the comments to accurately > reflect what the code currently does and to fix a bug in > MakeClasslist.java's 'for' loop where the wrong set of strings is used. > > I plan to file a bug stating that the classlists need to be updated > for JDK 8 and assign it to release engineering. > > Thanks, Harold Okay, I see this was changed to use TraceClassLoadingPreorder in 2006 (prior to OpenJDK). Brent might know more about the history. In any case, the changes looks okay to me and wonderful to hear that the classlists will be refreshed. -Alan. From ivan.gerasimov at oracle.com Mon Aug 12 16:02:31 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 12 Aug 2013 20:02:31 +0400 Subject: RFR [6883354] File.mkdirs() method doesn't behave well when given /../ Message-ID: <52090717.3040106@oracle.com> Hello everybody! Would you please help review a small change to File.mkdirs() method? The current implementation of the method, when past an argument "dir1/../dir2" only tries to create dir2. mkdir -p 'dir1/../dir2' command on Linux creates both dir1 and dir2. java.nio.file.Files.createDirectories() also creates both dir1 and dir2. The proposed fix makes File.mkdirs() method to behave in the same way on all the platforms except for Windows. The problem with Windows is that it reports 'dir1/..' as existent even if dir1 does not exist. Because of that Files.createDirectories() doesn't work this way on Windows either. Proposed fix: - makes File.mkdirs() match the behavior of 'mkdir -p' on Linux, Solaris and MacOS, and - doesn't change its behavior on Windows. http://cr.openjdk.java.net/~igerasim/6883354/0/webrev/ Sincerely yours, Ivan Gerasimov From maurizio.cimadamore at oracle.com Mon Aug 12 16:29:08 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 12 Aug 2013 16:29:08 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20130812162917.4FA16487C5@hg.openjdk.java.net> Changeset: f7f271bd74a2 Author: mcimadamore Date: 2013-08-12 17:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f7f271bd74a2 6537020: JCK tests: a compile-time error should be given in case of ambiguously imported fields (types, methods) Summary: Hiding check does not support interface multiple inheritance Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/4980495/static/Test.out ! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/AlreadDefinedStaticImport.java ! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E1.java ! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E2.java + test/tools/javac/staticImport/6537020/T6537020.java + test/tools/javac/staticImport/6537020/T6537020.out Changeset: af80273f630a Author: mcimadamore Date: 2013-08-12 17:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/af80273f630a 8021567: Javac doesn't report \"java: reference to method is ambiguous\" any more Summary: Javac incorrectly forgets about constant folding results within lambdas Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/8021567/T8021567.java + test/tools/javac/lambda/8021567/T8021567.out + test/tools/javac/lambda/8021567/T8021567b.java From Alan.Bateman at oracle.com Mon Aug 12 16:32:37 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Aug 2013 17:32:37 +0100 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5204DE28.5090805@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> <52047C66.2080001@oracle.com> <52048269.7000501@oracle.com> <5204997B.3090601@oracle.com> <5204B5F3.6000506@oracle.com> <5204C626.3000102@oracle.com> <5204DE28.5090805@oracle.com> Message-ID: <52090E25.6050300@oracle.com> On 09/08/2013 13:18, David Holmes wrote: > > I agree. I'm sure when Alan suggested to check the return he didn't > expect it to unravel like this :) As we know hotspot will never > actually return NULL there is no urgency to add this in. Sorry about this, I wasn't aware of the issue in the JNI spec, we should follow up on that. Ivan's latest webrev (which limits the change to just removing the GetStringUTFChars is fine). The test is okay but it might need time to bed down. -Alan From huizhe.wang at oracle.com Mon Aug 12 16:33:41 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 12 Aug 2013 09:33:41 -0700 Subject: RFR: JAXP in JDK8/7u40 : 8022548 : SPECJVM2008 has errors introduced in 7u40-b34 In-Reply-To: <5208A67C.8030408@oracle.com> References: <520484E6.4020204@oracle.com> <52055661.1040301@oracle.com> <5205815C.2000503@oracle.com> <5208A67C.8030408@oracle.com> Message-ID: <52090E65.8080405@oracle.com> On 8/12/2013 2:10 AM, Alan Bateman wrote: > On 10/08/2013 00:55, huizhe wang wrote: >> : >> >> It's not using a standard interface. It goes straight to the >> implementation, here's how it's done: >> class JDK15XML1_0Parser extends SAXParser { >> >> JDK15XML1_0Parser() throws org.xml.sax.SAXException { >> >> super(new DTDConfiguration()); >> // workaround for Java 1.5 beta 2 bugs >> com.sun.org.apache.xerces.internal.util.SecurityManager manager = >> new >> com.sun.org.apache.xerces.internal.util.SecurityManager(); >> setProperty(Constants.XERCES_PROPERTY_PREFIX + >> Constants.SECURITY_MANAGER_PROPERTY, manager); >> >> } >> } >> >> where: >> SAXParser is com.sun.org.apache.xerces.internal.parsers.SAXParser >> DTDConfiguration is >> com.sun.org.apache.xerces.internal.parsers.DTDConfiguration >> > Okay, I see it now: > > $ jdeps --verbose-level=class xom-1.2.10.jar |grep "JDK internal API" > -> com.sun.org.apache.xerces.internal.parsers.DTDConfiguration > JDK internal API (rt.jar) > -> com.sun.org.apache.xerces.internal.parsers.SAXParser JDK > internal API (rt.jar) > -> com.sun.org.apache.xerces.internal.util.SecurityManager JDK > internal API (rt.jar) > -> > com.sun.org.apache.xerces.internal.xni.parser.XMLParserConfiguration > JDK internal API (rt.jar) > > In that case, this is not really a bug, it's that XOM needs to realize > that extending com.sun.org.apache.xerces.internal.** means they have a > dependency on JDK internal classes so they can break at any time. Also > as com.sun.org.apache.xerces.internal.** is on the restricted package > list then I assume they have problems running with a security manager. I agree it's not a bug. But in light of the history and tradition of using internal Xerces, we decided to accommodate XOM's usage. The order by which XOM look for a parser is Xerces, JDK, and XMLReaderFactory. So if Xerces is not on the path, and security manager is present, it will fall back to the SAX/XMLReaderFactory API. > > I wasn't aware that SPECjvm2008 uses XOM. Unless XOM is fixed then I > can imagine this causing problems in the future, in particular if/when > visibility of JDK internal classes is restricted. I will discuss with the owner and others on these issues. -Joe > > -Alan > > From vicente.romero at oracle.com Mon Aug 12 16:41:24 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 12 Aug 2013 16:41:24 +0000 Subject: hg: jdk8/tl/jdk: 8015780: java/lang/reflect/Method/GenericStringTest.java failing Message-ID: <20130812164149.C5B8B487C9@hg.openjdk.java.net> Changeset: 70c8f4a4b8d6 Author: vromero Date: 2013-08-12 17:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70c8f4a4b8d6 8015780: java/lang/reflect/Method/GenericStringTest.java failing Reviewed-by: darcy, jfranck ! test/ProblemList.txt ! test/java/lang/reflect/Method/GenericStringTest.java From ivan.gerasimov at oracle.com Mon Aug 12 17:07:07 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 12 Aug 2013 21:07:07 +0400 Subject: RFR [6883354] File.mkdirs() method doesn't behave well when given /../ In-Reply-To: <52090717.3040106@oracle.com> References: <52090717.3040106@oracle.com> Message-ID: <5209163B.3030306@oracle.com> Forgot the link to the bug record http://bugs.sun.com/view_bug.do?bug_id=6883354 Sincerely, Ivan On 12.08.2013 20:02, Ivan Gerasimov wrote: > Hello everybody! > > Would you please help review a small change to File.mkdirs() method? > > The current implementation of the method, when past an argument > "dir1/../dir2" only tries to create dir2. > mkdir -p 'dir1/../dir2' command on Linux creates both dir1 and dir2. > java.nio.file.Files.createDirectories() also creates both dir1 and dir2. > > The proposed fix makes File.mkdirs() method to behave in the same way > on all the platforms except for Windows. > > The problem with Windows is that it reports 'dir1/..' as existent even > if dir1 does not exist. > Because of that Files.createDirectories() doesn't work this way on > Windows either. > > Proposed fix: > - makes File.mkdirs() match the behavior of 'mkdir -p' on Linux, > Solaris and MacOS, and > - doesn't change its behavior on Windows. > > http://cr.openjdk.java.net/~igerasim/6883354/0/webrev/ > > Sincerely yours, > Ivan Gerasimov > > > From roger.riggs at oracle.com Mon Aug 12 18:03:52 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 12 Aug 2013 14:03:52 -0400 Subject: Request for review, two java.time test bugs Message-ID: <52092388.1080500@oracle.com> Please review test fixes related to changes of Hijrah localization data. [1] 8022770: java/time/tck/java/time/chrono/TCKChronology.java start failing [2] 8022766: java/time/test/java/time/chrono/TestUmmAlQuraChronology.java failed Webrev: http://cr.openjdk.java.net/~rriggs/webrev-JDK-8022766/ Thanks, Roger [1] http://bugs.sun.com/view_bug.do?bug_id=8022770 [2] http://bugs.sun.com/view_bug.do?bug_id=8022766 From Lance.Andersen at oracle.com Mon Aug 12 18:05:50 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 12 Aug 2013 14:05:50 -0400 Subject: Reviewer needed for 8022753: SQLXML example typo in the SQLXML javadoc Message-ID: Hi all, Need a reviewer for the following trivial javadoc typo. Bug is 8022753 Best Lance hg diff SQLXML.java diff -r a4eb59bffb60 src/share/classes/java/sql/SQLXML.java --- a/src/share/classes/java/sql/SQLXML.java Sat Jun 29 06:12:28 2013 -0400 +++ b/src/share/classes/java/sql/SQLXML.java Mon Aug 12 13:59:31 2013 -0400 @@ -98,7 +98,7 @@ * or, to set the result value from SAX events: * 

  *   SAXResult saxResult = sqlxml.setResult(SAXResult.class);
- *   ContentHandler contentHandler = saxResult.getXMLReader().getContentHandler();
+ *   ContentHandler contentHandler = saxResult.getHandler();
  *   contentHandler.startDocument();
  *   // set the XML elements and attributes into the result
  *   contentHandler.endDocument();


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com



From Alan.Bateman at oracle.com  Mon Aug 12 18:15:53 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 12 Aug 2013 19:15:53 +0100
Subject: Reviewer needed for 8022753: SQLXML example typo in the SQLXML
	javadoc
In-Reply-To: 
References: 
Message-ID: <52092659.1010109@oracle.com>

On 12/08/2013 19:05, Lance Andersen - Oracle wrote:
> Hi all,
>
> Need a reviewer for the following trivial javadoc typo.  Bug is 8022753
>
> Best
> Lance
This looks fine to me.

-Alan


>
>
> hg diff SQLXML.java
> diff -r a4eb59bffb60 src/share/classes/java/sql/SQLXML.java
> --- a/src/share/classes/java/sql/SQLXML.java	Sat Jun 29 06:12:28 2013 -0400
> +++ b/src/share/classes/java/sql/SQLXML.java	Mon Aug 12 13:59:31 2013 -0400
> @@ -98,7 +98,7 @@
>    * or, to set the result value from SAX events:
>    *
>    *   SAXResult saxResult = sqlxml.setResult(SAXResult.class);
> - *   ContentHandler contentHandler = saxResult.getXMLReader().getContentHandler();
> + *   ContentHandler contentHandler = saxResult.getHandler();
>    *   contentHandler.startDocument();
>    *   // set the XML elements and attributes into the result
>    *   contentHandler.endDocument();
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>



From scolebourne at joda.org  Mon Aug 12 18:16:32 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 12 Aug 2013 19:16:32 +0100
Subject: Request for review, two java.time test bugs
In-Reply-To: <52092388.1080500@oracle.com>
References: <52092388.1080500@oracle.com>
Message-ID: 

Looks fine to me
Stephen

On 12 August 2013 19:03, roger riggs  wrote:
> Please review test fixes related to changes of Hijrah localization data.
>
> [1] 8022770: java/time/tck/java/time/chrono/TCKChronology.java start failing
> [2] 8022766: java/time/test/java/time/chrono/TestUmmAlQuraChronology.java
> failed
>
> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-JDK-8022766/
>
> Thanks, Roger
>
>
> [1] http://bugs.sun.com/view_bug.do?bug_id=8022770
> [2] http://bugs.sun.com/view_bug.do?bug_id=8022766


From mandy.chung at oracle.com  Mon Aug 12 18:22:24 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 12 Aug 2013 11:22:24 -0700
Subject: Reviewer needed for 8022753: SQLXML example typo in the SQLXML
	javadoc
In-Reply-To: 
References: 
Message-ID: <520927E0.8060407@oracle.com>

Looks fine.

Mandy

On 8/12/2013 11:05 AM, Lance Andersen - Oracle wrote:
> Hi all,
>
> Need a reviewer for the following trivial javadoc typo.  Bug is 8022753
>
> Best
> Lance
>
>
> hg diff SQLXML.java
> diff -r a4eb59bffb60 src/share/classes/java/sql/SQLXML.java
> --- a/src/share/classes/java/sql/SQLXML.java	Sat Jun 29 06:12:28 2013 -0400
> +++ b/src/share/classes/java/sql/SQLXML.java	Mon Aug 12 13:59:31 2013 -0400
> @@ -98,7 +98,7 @@
>    * or, to set the result value from SAX events:
>    * 
>    *   SAXResult saxResult = sqlxml.setResult(SAXResult.class);
> - *   ContentHandler contentHandler = saxResult.getXMLReader().getContentHandler();
> + *   ContentHandler contentHandler = saxResult.getHandler();
>    *   contentHandler.startDocument();
>    *   // set the XML elements and attributes into the result
>    *   contentHandler.endDocument();
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>



From Alan.Bateman at oracle.com  Mon Aug 12 18:25:17 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 12 Aug 2013 19:25:17 +0100
Subject: RFR 8022797 Clarify spliterator characteristics for collections
	containing no elements
In-Reply-To: 
References: 
Message-ID: <5209288D.7040801@oracle.com>

On 12/08/2013 16:24, Paul Sandoz wrote:
> Hi,
>
> Here is another go at characteristics reported for spliterators of empty collections:
>
> diff -r f8d92ce66886 src/share/classes/java/util/Collection.java
> --- a/src/share/classes/java/util/Collection.java	Mon Aug 12 13:59:01 2013 +0200
> +++ b/src/share/classes/java/util/Collection.java	Mon Aug 12 16:12:10 2013 +0200
> @@ -504,7 +504,10 @@
>        *
>        *
The returned {@code Spliterator} must report the characteristic
>        * {@link Spliterator#SIZED}; implementations should document any additional
> -     * characteristic values reported by the returned Spliterator.
> +     * characteristic values reported by the returned spliterator.  If
> +     * this collection contains no elements then the returned spliterator is
> +     * only required to report {@link Spliterator#SIZED} and is not required to
> +     * report additional characteristics (if any).
>        *
>        *
The default implementation should be overridden by subclasses that
>        * can return a more efficient spliterator.  In order to
> @@ -535,6 +538,13 @@
>        * The returned {@code Spliterator} additionally reports
>        * {@link Spliterator#SUBSIZED}.
>        *
> +     *
If a spliterator covers no elements then the reporting of additional
> +     * characteristics, beyond that of {@code SIZED} and {@code SUBSIZED}, does
> +     * not aid clients to control specialize or simplify computation.  However,
> +     * this does enable shared use of an empty spliterator (see
> +     * {@link Spliterators#emptySpliterator()} for empty collections, and
> +     * enables clients to determine if a spliterator covers no elements.
> +     *
>        * @return a {@code Spliterator} over the elements in this collection
>        * @since 1.8
>        */
>
> It might be preferable to also document this on List/Set/SortedSet since the documentation is overridden and i don't think we have many precedents for overriding what the sub-types define (are there any?).
>
> --
>
> I logged issue 8022805 for Stream.concat(s, Stream.emptyStream()).
>
> Paul.
>
The wording looks okay to me except "specialize" -> "specialization".

When the spec is overridden then it would require clicks on the link 
under the "Specified by" but I think that should be okay here.

-Alan.






From henry.jen at oracle.com  Mon Aug 12 19:12:06 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Mon, 12 Aug 2013 19:12:06 +0000
Subject: hg: jdk8/tl/jdk: 8022749: Convert junit tests to testng in
	test/java/lang/invoke
Message-ID: <20130812191235.BC88E487D6@hg.openjdk.java.net>

Changeset: 7758bcf0ab6b
Author:    henryjen
Date:      2013-08-12 12:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7758bcf0ab6b

8022749: Convert junit tests to testng in test/java/lang/invoke
Reviewed-by: mduigou, alanb
Contributed-by: Mani Sarkar 

! test/java/lang/invoke/AccessControlTest.java
! test/java/lang/invoke/ClassValueTest.java
! test/java/lang/invoke/InvokeGenericTest.java
! test/java/lang/invoke/JavaDocExamplesTest.java
! test/java/lang/invoke/MethodTypeTest.java
! test/java/lang/invoke/PermuteArgsTest.java
! test/java/lang/invoke/ThrowExceptionsTest.java



From lance.andersen at oracle.com  Mon Aug 12 20:09:57 2013
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Mon, 12 Aug 2013 20:09:57 +0000
Subject: hg: jdk8/tl/jdk: 8022753: SQLXML javadoc example typo
Message-ID: <20130812201011.0221F487E1@hg.openjdk.java.net>

Changeset: cc64a05836a7
Author:    lancea
Date:      2013-08-12 16:09 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc64a05836a7

8022753: SQLXML javadoc example typo
Reviewed-by: alanb, mchung

! src/share/classes/java/sql/SQLXML.java



From mike.duigou at oracle.com  Mon Aug 12 20:30:15 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 12 Aug 2013 13:30:15 -0700
Subject: Possible HashMap update
In-Reply-To: <51DAD99F.9030705@cs.oswego.edu>
References: <51D4ABDA.7010801@cs.oswego.edu> <51DAD99F.9030705@cs.oswego.edu>
Message-ID: <9F896672-012F-40A7-B7A3-AF9823CF7BB9@oracle.com>

Hi Doug;

Several minor recent cleanups and proposed cleanups in HashMap made me wonder how things are progressing on this work. Do you feel it's nearly ready to integrate into the jdk8 repos? What additional work remains? Are you tracking changes going in to the jdk8 repos?

Mike

On Jul 8 2013, at 08:24 , Doug Lea wrote:

> 
> On 07/05/13 04:55, Paul Sandoz wrote:
>>> I played with these in the lambda repo.
>>> 
>>> I needed to make the following additional change for things to compile:
>>> 
>>> --- a/src/share/classes/java/io/ExpiringCache.java    Fri Jul 05 10:04:00 2013 +0200
>>> +++ b/src/share/classes/java/io/ExpiringCache.java    Fri Jul 05 10:45:10 2013 +0200
>>> ...
> 
> Thanks to those chasing this down, now recorded as a CR at:
>  http://bugs.sun.com/view_bug.do?bug_id=8017219
> 
> Some might think this is a fun javac corner case to read about,
> but for present purposes, the moral is that the name of
> the internal LinkedHashMap.Entry class, even though it is never
> exported, cannot be changed without impacting re-compilability of
> some external usages. Fine. We can cope.
> 
> For people still following along, see updates at...
> 
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/dl/java/util/HashMap.java?view=log
> 
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/dl/java/util/LinkedHashMap.java?view=log 



From Alan.Bateman at oracle.com  Mon Aug 12 20:54:51 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 12 Aug 2013 21:54:51 +0100
Subject: Request for review, two java.time test bugs
In-Reply-To: <52092388.1080500@oracle.com>
References: <52092388.1080500@oracle.com>
Message-ID: <52094B9B.2090700@oracle.com>

On 12/08/2013 19:03, roger riggs wrote:
> Please review test fixes related to changes of Hijrah localization data.
>
> [1] 8022770: java/time/tck/java/time/chrono/TCKChronology.java start 
> failing
> [2] 8022766: 
> java/time/test/java/time/chrono/TestUmmAlQuraChronology.java failed
>
> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-JDK-8022766/
>
> Thanks, Roger
>
>
> [1] http://bugs.sun.com/view_bug.do?bug_id=8022770
> [2] http://bugs.sun.com/view_bug.do?bug_id=8022766
This looks fine to me too.

-Alan


From Alan.Bateman at oracle.com  Mon Aug 12 21:05:42 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 12 Aug 2013 22:05:42 +0100
Subject: Java 8 RFR 8022180: BigInteger Burnikel-Ziegler quotient and
	remainder calculation assumes quotient parameter is zero
In-Reply-To: <6F5A74F5-C71E-441D-84CB-E71492F31E0B@oracle.com>
References: <6F5A74F5-C71E-441D-84CB-E71492F31E0B@oracle.com>
Message-ID: <52094E26.5080102@oracle.com>

On 10/08/2013 01:39, Brian Burkhalter wrote:
> Please review at your convenience:
>
> Issue	http://bugs.sun.com/view_bug.do?bug_id=8022180
> Webrev	http://cr.openjdk.java.net/~bpb/8022180/
>
> The update is to clear the quotient if the divisor is larger than the dividend in divideAndRemainderBurnikelZiegler().
>
> Thanks,
>
> Brian
Could the quotient be cleared at the top of the method as it is cleared 
for the schoolbook division anyway?

-Alan.


From brian.burkhalter at oracle.com  Mon Aug 12 21:08:05 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 12 Aug 2013 14:08:05 -0700
Subject: Java 8 RFR 8022180: BigInteger Burnikel-Ziegler quotient and
	remainder calculation assumes quotient parameter is zero
In-Reply-To: <52094E26.5080102@oracle.com>
References: <6F5A74F5-C71E-441D-84CB-E71492F31E0B@oracle.com>
	<52094E26.5080102@oracle.com>
Message-ID: 


On Aug 12, 2013, at 2:05 PM, Alan Bateman wrote:

> On 10/08/2013 01:39, Brian Burkhalter wrote:
>> Please review at your convenience:
>> 
>> Issue	http://bugs.sun.com/view_bug.do?bug_id=8022180
>> Webrev	http://cr.openjdk.java.net/~bpb/8022180/
>> 
>> The update is to clear the quotient if the divisor is larger than the dividend in divideAndRemainderBurnikelZiegler().
>> 
>> Thanks,
>> 
>> Brian
> Could the quotient be cleared at the top of the method as it is cleared for the schoolbook division anyway?

Yes, that would be a bit clearer.

Thanks,

Brian

From brian.burkhalter at oracle.com  Mon Aug 12 23:27:50 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 12 Aug 2013 16:27:50 -0700
Subject: Java 8 RFR 8022180: BigInteger Burnikel-Ziegler quotient and
	remainder calculation assumes quotient parameter is zero
In-Reply-To: 
References: <6F5A74F5-C71E-441D-84CB-E71492F31E0B@oracle.com>
	<52094E26.5080102@oracle.com>
	
Message-ID: 

On Aug 12, 2013, at 2:08 PM, Brian Burkhalter wrote:

>>> Webrev	http://cr.openjdk.java.net/~bpb/8022180/
>>> 
>>> The update is to clear the quotient if the divisor is larger than the dividend in divideAndRemainderBurnikelZiegler().
>>> 
>>> Thanks,
>>> 
>>> Brian
>> Could the quotient be cleared at the top of the method as it is cleared for the schoolbook division anyway?
> 
> Yes, that would be a bit clearer.

Webrev updated at the same location.

Thanks,

Brian

From mike.duigou at oracle.com  Mon Aug 12 23:56:47 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 12 Aug 2013 16:56:47 -0700
Subject: RFR 8022797 Clarify spliterator characteristics for collections
	containing no elements
In-Reply-To: <5209288D.7040801@oracle.com>
References: 
	<5209288D.7040801@oracle.com>
Message-ID: <36BF6F8D-571A-4F6E-BAB7-142BFCD1F347@oracle.com>

Looks fine to me.

On Aug 12 2013, at 11:25 , Alan Bateman wrote:

> On 12/08/2013 16:24, Paul Sandoz wrote:
>> Hi,
>> 
>> Here is another go at characteristics reported for spliterators of empty collections:
>> 
>> diff -r f8d92ce66886 src/share/classes/java/util/Collection.java
>> --- a/src/share/classes/java/util/Collection.java	Mon Aug 12 13:59:01 2013 +0200
>> +++ b/src/share/classes/java/util/Collection.java	Mon Aug 12 16:12:10 2013 +0200
>> @@ -504,7 +504,10 @@
>>       *
>>       *
The returned {@code Spliterator} must report the characteristic
>>       * {@link Spliterator#SIZED}; implementations should document any additional
>> -     * characteristic values reported by the returned Spliterator.
>> +     * characteristic values reported by the returned spliterator.  If
>> +     * this collection contains no elements then the returned spliterator is
>> +     * only required to report {@link Spliterator#SIZED} and is not required to
>> +     * report additional characteristics (if any).
>>       *
>>       *
The default implementation should be overridden by subclasses that
>>       * can return a more efficient spliterator.  In order to
>> @@ -535,6 +538,13 @@
>>       * The returned {@code Spliterator} additionally reports
>>       * {@link Spliterator#SUBSIZED}.
>>       *
>> +     *
If a spliterator covers no elements then the reporting of additional
>> +     * characteristics, beyond that of {@code SIZED} and {@code SUBSIZED}, does
>> +     * not aid clients to control specialize or simplify computation.  However,
>> +     * this does enable shared use of an empty spliterator (see
>> +     * {@link Spliterators#emptySpliterator()} for empty collections, and
>> +     * enables clients to determine if a spliterator covers no elements.
>> +     *
>>       * @return a {@code Spliterator} over the elements in this collection
>>       * @since 1.8
>>       */
>> 
>> It might be preferable to also document this on List/Set/SortedSet since the documentation is overridden and i don't think we have many precedents for overriding what the sub-types define (are there any?).
>> 
>> --
>> 
>> I logged issue 8022805 for Stream.concat(s, Stream.emptyStream()).
>> 
>> Paul.
>> 
> The wording looks okay to me except "specialize" -> "specialization".
> 
> When the spec is overridden then it would require clicks on the link under the "Specified by" but I think that should be okay here.
> 
> -Alan.
> 
> 
> 
> 



From henry.jen at oracle.com  Tue Aug 13 03:26:40 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 12 Aug 2013 20:26:40 -0700
Subject: RFR: 8019401: Collectors.collectingAndThen
Message-ID: <5209A770.50308@oracle.com>

Hi,

Please review the webrev[1] adds an API to help compose a Collector with
an additional "finish" function.

Cheers,
Henry

[1] http://cr.openjdk.java.net/~henryjen/ccc/8019401/0/webrev/


From david.holmes at oracle.com  Tue Aug 13 05:33:04 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 13 Aug 2013 15:33:04 +1000
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <5208D62C.3030107@oracle.com>
References: <5202EA83.70207@oracle.com>
	<5202EEC6.8050106@oracle.com>	<5202F244.6070006@oracle.com>
	<5202F5D4.7070806@oracle.com>	<520318F3.7080609@oracle.com>
	<52032625.3000501@oracle.com>	<52035A18.8020803@oracle.com>
	<52039E2E.6090504@oracle.com>	<5203A243.60505@oracle.com>
	<5203E642.40005@oracle.com>	<52040A76.3060602@oracle.com>
	<52041988.80705@oracle.com>	<52047C66.2080001@oracle.com>
	<52048269.7000501@oracle.com> <5204997B.3090601@oracle.com>
	<5204B5F3.6000506@oracle.com> <5204C626.3000102@oracle.com>
	<5204DE28.5090805@oracle.com> <5208D62C.3030107@oracle.com>
Message-ID: <5209C510.5000001@oracle.com>

Thanks Ivan.

David

On 12/08/2013 10:33 PM, Ivan Gerasimov wrote:
> David, Chris,
>
> I reverted back NULL-checking.
> Now the change consists of one line removal and a regression test.
>
> Webrev: http://cr.openjdk.java.net/~igerasim/8022584/6/webrev/
> Hg export:
> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>
>
> Sincerely yours,
> Ivan
>
> On 09.08.2013 16:18, David Holmes wrote:
>> Hi Chris,
>>
>> On 9/08/2013 8:36 PM, Chris Hegarty wrote:
>>> Firstly, I think the memory leak issue should be moved forward
>>> separately to this cleanup effort. They are unrelated, and I'm starting
>>> to get the feeling that this could take some time to reach conclusion.
>>> It seems reasonable to separate the issues.
>>
>> I agree. I'm sure when Alan suggested to check the return he didn't
>> expect it to unravel like this :) As we know hotspot will never
>> actually return NULL there is no urgency to add this in.
>>
>>> On 09/08/2013 10:27, Ivan Gerasimov wrote:
>>>> Chris,
>>>>
>>>> I would use this
>>>>
>>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) ==
>>>> NULL) {
>>>> JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed");
>>>> return NULL/JNI_False/-1;
>>>> }
>>>>
>>>> If I understand it correctly, JNU_ThrowOutOfMemoryError throws an
>>>> exception only if it hasn't been already thrown.
>>>
>>> JNU_ThrowOutOfMemoryError is simply a convenience wrapper for
>>>    JNU_ThrowByName(env, "java/lang/OutOfMemoryError", msg);
>>>
>>>   ...and JNU_ThrowByName [1] is defined as...
>>>
>>>   JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg) {
>>>      class cls = (*env)->FindClass(env, name);
>>>      if (cls != 0) /* Otherwise an exception has already been thrown */
>>>          (*env)->ThrowNew(env, cls, msg);
>>>      }
>>>   }
>>>
>>> Neither FindClass or ThrowNew is safe to call if there is a pending
>>> exception [1].
>>
>> Right - we have to check for a pending exception before trying to
>> throw one.
>>
>>> Now the issue comes down to; could there ever be a pending exception if
>>> GetStringUTFChars returns NULL? The latest specs doesn't indicate that
>>> there could be, but every copy of "The Java Native Interface
>>> Programmer's Guide and Specification" I can find does. There also
>>> appears to be an assumption of this if you look at the usages in the
>>> JDK.
>>
>> AFAIK there is only one version of the JNI spec book and it never got
>> updated. The official spec says no throw, but when people have the
>> book on their bookshelf that is what they tend to rely on. I looked at
>> some of the usages and they seem exception agnostic - many of them
>> don't even check for NULL :(
>>
>> The implementation as it stands will not throw and will not return NULL.
>>
>>> I would really like to get a definitive answer on the JNI specification
>>> for GetStringUTFChars before making any changes here.
>>
>> The JNI spec (as opposed to the book) is definitive. If we don't like
>> what is there then it requires a spec change.
>>
>> I can't find any reference to this particular issue being raised before.
>>
>> Cheers,
>> David
>>
>>> -Chris.
>>>
>>> [1]
>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/54f0ccdd9ad7/src/share/native/common/jni_util.c
>>>
>>>
>>> [2]
>>> http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp17626
>>>
>>>
>>>
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>>
>>>>
>>>> On 09.08.2013 11:25, Chris Hegarty wrote:
>>>>> On 09/08/2013 06:47, David Holmes wrote:
>>>>>> Sorry I messed this up. The JNI book says GetStringUTFChars will
>>>>>> return
>>>>>> NULL and post OOME but the JNI spec (latest version 6.0) does not
>>>>>> - it
>>>>>> only says it will return NULL on failure.
>>>>>
>>>>> This is indeed strange. Most usages of this function in the jdk expect
>>>>> the former. If this is not the case, then we may need to do an audit
>>>>> of all usages.
>>>>>
>>>>>> So your previous version was the more correct. Given we just
>>>>>> failed to
>>>>>> allocate C-heap I think we are on thin ice anyway, but better to at
>>>>>> least attempt to do the right thing.
>>>>>
>>>>> I'm not sure what the right thing to do here is? It seems a little
>>>>> unwieldy!
>>>>>
>>>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) ==
>>>>> NULL) {
>>>>> if ((*env)->ExceptionOccurred(env)) {
>>>>> return NULL/JNI_False/-1;
>>>>> } else {
>>>>> throwException(env, "java/lang/InternalError", "GetStringUTFChars
>>>>> failed");
>>>>> return NULL/JNI_False/-1;
>>>>> }
>>>>>
>>>>> Given we have no idea why GetStringUTFChars may have failed, what
>>>>> exception do we throw?
>>>>>
>>>>> Also worth noting is that this bug fix has moved away from the
>>>>> original problem (memory leak), and is now focused on code cleanup.
>>>>>
>>>>> If we cannot get agreement on the cleanup, or it looks like more
>>>>> clarification is needed around the cleanup effort, then I would like
>>>>> to suggest that we proceed with the original fix for the memory leak
>>>>> and separate out the cleanup effort.
>>>>>
>>>>> -Chris.
>>>>>
>>>>>> FYI I filed 8022683 to fix GetStringUTFChars.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>> On 9/08/2013 3:21 PM, David Holmes wrote:
>>>>>>> Thumbs up!
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote:
>>>>>>>> Thanks David!
>>>>>>>>
>>>>>>>> On 09.08.2013 1:15, David Holmes wrote:
>>>>>>>>> Main fix looks good to me.
>>>>>>>>>
>>>>>>>>> Regression test may need some tweaking eg I think othervm will be
>>>>>>>>> needed.
>>>>>>>>>
>>>>>>>> Yes, it's a good point.
>>>>>>>> Since there may be a memory leak in the test, it'd better not
>>>>>>>> interfere
>>>>>>>> with other tests in jtreg.
>>>>>>>>
>>>>>>>>> Also this:
>>>>>>>>>
>>>>>>>>> System.out.println("WARNING: Cannot perform memory leak
>>>>>>>>> detection on
>>>>>>>>> this OS");
>>>>>>>>>
>>>>>>>>> should probably just say something like "Test skipped on this
>>>>>>>>> OS" -
>>>>>>>>> there are other tests that do this so just check if there is
>>>>>>>>> common
>>>>>>>>> terminology. (In the future we may have keyword tags to flag
>>>>>>>>> this as
>>>>>>>>> linux only etc.)
>>>>>>>>>
>>>>>>>> OK, I changed the phrase to "Test only runs on Linux".
>>>>>>>>
>>>>>>>> Updated webrev is here:
>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/
>>>>>>>>
>>>>>>>> Updated export is at the same place:
>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sincerely yours,
>>>>>>>> Ivan
>>>>>>>>
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote:
>>>>>>>>>> Chris, if it's not too late, I'd like to include a regtest in the
>>>>>>>>>> fix.
>>>>>>>>>>
>>>>>>>>>> Here's webrev that includes the test:
>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/
>>>>>>>>>>
>>>>>>>>>> The test gets past with the fixed jdk8 and fails with
>>>>>>>>>> jdk8-b101 and
>>>>>>>>>> jdk7
>>>>>>>>>> as expected.
>>>>>>>>>>
>>>>>>>>>> Sincerely yours,
>>>>>>>>>> Ivan
>>>>>>>>>>
>>>>>>>>>> On 08.08.2013 17:50, Chris Hegarty wrote:
>>>>>>>>>>> Looks good to me. Thanks Ivan.
>>>>>>>>>>>
>>>>>>>>>>> -Chris.
>>>>>>>>>>>
>>>>>>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
>>>>>>>>>>>> Hello Chris!
>>>>>>>>>>>>
>>>>>>>>>>>> Here's the update:
>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for offering the sponsorship!
>>>>>>>>>>>> Here's the hg-export
>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>> Ivan
>>>>>>>>>>>>
>>>>>>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote:
>>>>>>>>>>>>> Thanks for taking this Ivan.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Can you please make the changes suggested by both David and
>>>>>>>>>>>>> Alan (
>>>>>>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if
>>>>>>>>>>>>> GetStringUTFChars
>>>>>>>>>>>>> fails ( returns NULL ), then I will sponsor this change into
>>>>>>>>>>>>> jdk8
>>>>>>>>>>>>> for
>>>>>>>>>>>>> you.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please post an update webrev to cr.openjdk.java.net.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Chris.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>>>>>>>>>>>>> Ivan,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>>>>>>>>>>>>> David, Alan,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I added checking for NULL results and throwing
>>>>>>>>>>>>>>> OOMException if
>>>>>>>>>>>>>>> necessary.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You don't need to throw it yourself:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Assuming a correct VM implementation if NULL is returned
>>>>>>>>>>>>>> then an
>>>>>>>>>>>>>> OOME
>>>>>>>>>>>>>> should already be pending and will be thrown as soon as your
>>>>>>>>>>>>>> native
>>>>>>>>>>>>>> code
>>>>>>>>>>>>>> returns to Java.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've also added some spaces along the code to improve
>>>>>>>>>>>>>>> indentation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Would you please review the updated webrev?
>>>>>>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>>>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>>>>>>>>>>>>> Thanks Alan!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars
>>>>>>>>>>>>>>>>> cannot
>>>>>>>>>>>>>>>>> return
>>>>>>>>>>>>>>>>> NULL.
>>>>>>>>>>>>>>>>> For allocation of the result string it calls
>>>>>>>>>>>>>>>>> AllocateHeap()
>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> default EXIT_OOM fail strategy.
>>>>>>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply
>>>>>>>>>>>>>>>>> stops
>>>>>>>>>>>>>>>>> VM.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is
>>>>>>>>>>>>>>>> supposed to
>>>>>>>>>>>>>>>> throw
>>>>>>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I recommend that you check for NULL and/or a pending
>>>>>>>>>>>>>>>> exception.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>>>>>>>>>>>>> (cc'ing net-dev).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you
>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>> there) is
>>>>>>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the
>>>>>>>>>>>>>>>>>> name
>>>>>>>>>>>>>>>>>> returns
>>>>>>>>>>>>>>>>>> when it fails with NULL.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -Alan.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>>>>>>>>>>>>> Hello everybody!
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to
>>>>>>>>>>>>>>>>>>> leak
>>>>>>>>>>>>>>>>>>> memory.
>>>>>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not
>>>>>>>>>>>>>>>>>>> yet
>>>>>>>>>>>>>>>>>>> available.)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Would you please review a simple fix that removes the
>>>>>>>>>>>>>>>>>>> unnecessary
>>>>>>>>>>>>>>>>>>> allocation?
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>


From david.holmes at oracle.com  Tue Aug 13 05:47:16 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 13 Aug 2013 15:47:16 +1000
Subject: RFR 8022259 MakeClasslist tool is buggy and its README is out
	of date.
In-Reply-To: <5208E282.1090209@oracle.com>
References: <5202A528.5060504@oracle.com> <5208A0F7.2000003@oracle.com>
	<5208E282.1090209@oracle.com>
Message-ID: <5209C864.4060304@oracle.com>

On 12/08/2013 11:26 PM, harold seigel wrote:
> Hi David and Alan,
>
> Thank you for your comments.
>
> The change to the MakeClasslist tool to use TraceClassLoadingPreorder
> was made prior to my changes.  The following code has been in
> MakeClasslist.java for a long time.  I was unable to determine who had
> made this change or why.
>
>              // Understand only "Loading" from
> -XX:+TraceClassLoadingPreorder.
>              // This ignores old "Loaded" from -verbose:class to force
> correct
>              // classlist generation on Mustang.
>              if (t.equals("Loading")) {
>                t = tok.nextToken();
>                t = t.replace('.', '/');
>
> So, I don't know why TraceClassLoadingPreorder was chosen instead of
> -verbose:class or TraceClassLoading.
>
> The purpose of my changes are to update the comments to accurately
> reflect what the code currently does and to fix a bug in
> MakeClasslist.java's 'for' loop where the wrong set of strings is used.

Thanks for clarifying.

> I plan to file a bug stating that the classlists need to be updated for
> JDK 8 and assign it to release engineering.

I'm pretty sure such a bug already exists. See JDK-8005688.

Thanks,
David

> Thanks, Harold
>
> On 8/12/2013 4:46 AM, Alan Bateman wrote:
>> On 07/08/2013 20:51, harold seigel wrote:
>>> Hi,
>>>
>>> Please review this small fix for bug 8022259.  This change fixes a
>>> bug in the MakeClasslist tool and updates its README.txt file.
>>>
>>> webrev: http://cr.openjdk.java.net/~hseigel/bug_8022259/
>>> 
>>>
>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8022259
>>>
>>> JBS bug: https://jbs.oracle.com/bugs/browse/JDK-8022259
>>>
>>> I tested the change by creating a testlist using the modified
>>> MakeClasslist tool and following the information in the changed
>>> README.txt file.
>>>
>>> Thanks! Harold
>> Can you explain it further as to why TraceClassLoadingPreorder traces
>> should be used rather than the TraceClassLoading traces? I ask because
>> we rarely see changes to the *.classlist files and to my knowledge,
>> all previous versions used the TraceClassLoading output.
>>
>> Also, are you planning to update the *.classlist files too? They
>> haven't been refreshed in a long time and would be good to get them
>> updated (it should also sort out a slew of warnings emitted in the
>> build about missing classes).
>>
>> -Alan.
>


From joel.franck at oracle.com  Tue Aug 13 07:52:36 2013
From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Tue, 13 Aug 2013 09:52:36 +0200
Subject: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters
	synchronized method
In-Reply-To: <5208D7A7.9070608@gmail.com>
References: <5202733D.60205@gmail.com> <520278DF.2060102@oracle.com>
	<520777E5.3050304@gmail.com>
	<20130812105439.GC6420@jfranck-desktop.jrpg.bea.com>
	<5208D7A7.9070608@gmail.com>
Message-ID: <5253559F-B078-4ABF-9D5C-3BA2879669BB@oracle.com>

Hi,

Comments inline,

On 12 aug 2013, at 14:40, Peter Levart  wrote:
> 
> On 08/12/2013 12:54 PM, Joel Borggren-Franck wrote:
>> 
> 
> - annotation (@interface)  declarations can themselves be redefined (for example, defaults changed). Such redefinitions don't affect already initialized annotations. Default values are cached in AnnotationType which is not invalidated as a result of class redefinition. Maybe it should be. And even if AnnotationType was invalidated as a result of class redefinition, the defaults are looked-up when particular annotations are initialized and then combined with parsed values in a single values map inside each annotation instance (proxy), so invalidating AnnotationType would have no effect on those annotations.
> 
>> 
>> 3326                 if (annotations == null) { // lazy construction
>> 3327                     annotations = new HashMap<>();
>> 3328                 }
>> 
>> I think this should be a LinkedHashMap, so that iteration is predictable
>> (I know it isn't in the current code). Also the size of the map is known
>> so you can use a constructor with an explicit initial capacity.
> 
> Right, AnnotationParser does return LinkedHashMap, so at least decalredAnnotations are in parse-order. I will change the code to use LinkedHashMap for inherited/combined case too.

Thanks.

> The number of annotations that end-up in inherited/combined Map is not known in advance. I could make a separate pre-scan for superclass annotations that are @Inheritable and don't have the same key as any of declared annotations and then sum this count with declared annotations count, but I don't think this will be very effective. I could allocate a large-enough Map to always fit (the count of superclass annotations + the count of declared annotations), but that could sometimes lead to much over-allocated Maps. I could take the min(DEFAULT_CAPACITY, superclass annotations count + declared annotations count) as the initial capacity for the Map. What do you think which of those 3 alternatives is the best?

My bad. I was thinking of the case where every inherited annotation was overridden, in that case annotations.size() == declaredAnnotations.size(). That is of course not generally true. I'm fine with handling this as a follow up since the situation is no worse than today and the surrounding code is better. However,

1) We should really measure this.
2) My gut feeling is that the ratio of not overridden inherited annotations to declared annotations is small IE the expected nr of annotations is much closer to declare annotations than to declared + superclass annotations.
3) The default initial capacity is 16 and load factor is 0.75. I do think the mean nr of annotations is closer to 3 than to 12. We are probably wasting some space here.

Perhaps use min(default cap, (total annotations/0.75 (+ 1?))) for now as that will make the situation no worse than today and often better?

> 
>> 
>> Since this is a fairly significant rewrite I think it might be good to
>> make sure our tests exercise the new code. Can you run some kind of
>> coverage report on this?
> 
> I successfully ran the jdk_lang jtreg tests which contain several tests for annotations.

I'm a bit worried these tests doesn't cover annotations + class redefine. But I might be persuaded to have more extensive testing as a follow up as well.

cheers
/Joel

From joel.franck at oracle.com  Tue Aug 13 08:02:42 2013
From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Tue, 13 Aug 2013 10:02:42 +0200
Subject: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters
	synchronized method
In-Reply-To: 
References: <5202733D.60205@gmail.com> <520278DF.2060102@oracle.com>
	<520777E5.3050304@gmail.com>
	<20130812105439.GC6420@jfranck-desktop.jrpg.bea.com>
	<5208D7A7.9070608@gmail.com>
	
Message-ID: <0AF1B729-D2F0-4A9F-8A62-725BC2EDABD4@oracle.com>

Hi all,

Comments inline,

On 12 aug 2013, at 15:19, Paul Sandoz  wrote:
> On Aug 12, 2013, at 2:40 PM, Peter Levart  wrote:
>> On 08/12/2013 12:54 PM, Joel Borggren-Franck wrote:

>>> I realize the interaction between probably any reflective operation and
>>> a redefine is blurry, but if a redefine occurs between line 3308 and 3309
>>> annotationData() will return a possibly outdated AnnotationData.
>>> 
>>> 3307             if (Atomic.casAnnotationData(this, annotationData, newAnnotationData)) {
>>> 3308                 // successfully installed new AnnotationData
>>> 
>>> redefine here
>>> 
>>> 3309                 return newAnnotationData;
>>> 3310             }
>>> 
>>> I suppose there is a sequencing of events where this will be inevitable,
>>> but this got me thinking about the state model of annotations (and
>>> reflective objects) through an redefine.
>> 
>> The AnnotationData created and returned concurrently with class redefinition can contain old or new version, yes, but that's not a problem, since the AnnotationData also contains a "redefinedCount" field, so any further requests for annotations will trigger re-computation. This assumes that VM either changes the state returned by getRawAnnotations() and "classRedefinedCount" field atomically (during a safepoint?) or at least in order: 1st getRawAnnotations(), 2nd "classRedefinedCount". We 1st read "classRedefinedCount" and then
>> getRawAnnotations(), so there's no danger of keeping and returning stale data after redefinition.
>> 
>> This is more or less the same as with ReflectionData caching.
>> 
> 
> I suppose one could do the cas without checking it's result:
> 
> 3296     private AnnotationData annotationData() {
> 3297         while (true) { // retry loop
> 3298             AnnotationData annotationData = this.annotationData;
> 3299             int classRedefinedCount = this.classRedefinedCount;
> 3300             if (annotationData != null &&
> 3301                 annotationData.redefinedCount == classRedefinedCount) {
> 3302                 return annotationData;
> 3303             }
> 3304             // null or stale annotationData -> optimistically create new instance
> 3306             // try to install it
> 3307             Atomic.casAnnotationData(this, annotationData, createAnnotationData(classRedefinedCount));
>                 // re-check conditions in case a re-defintion occurred while creating
> 3311         }
> 3312     }
> 
> Don't really know if it is worth it though, plus it might be better to break out the loop once set. Note frameworks, such as JAXB and JAX-RS will cache results of processing reflection and annotation information and need to be given a kick to re-process (e.g. like from JRebel).

I would guess it is not worth it. There still exists a sequencing of events such that the AnnotationData will be stale, the redefine just needs to happen after the return in this case. I suspect this is a fundamental issue with having reflective object that are not immutable. I think the fundamental problem here (which has nothing to do with Peters work) is that in general developers' mental model of core reflective objects is that they are immutable and suitable for caching. With class redefine that is not true and to make matters worse, we don't have a good story for "cache invalidation" of reflective objets. Again, this has nothing to do with Peters work.

cheers
/Joel

From paul.sandoz at Oracle.com  Tue Aug 13 09:14:00 2013
From: paul.sandoz at Oracle.com (Paul Sandoz)
Date: Tue, 13 Aug 2013 11:14:00 +0200
Subject: RFR 8022797 Clarify spliterator characteristics for collections
	containing no elements
In-Reply-To: <5209288D.7040801@oracle.com>
References: 
	<5209288D.7040801@oracle.com>
Message-ID: <073306B3-57F4-47DE-A32B-71816F0033D4@Oracle.com>


On Aug 12, 2013, at 8:25 PM, Alan Bateman  wrote:

> On 12/08/2013 16:24, Paul Sandoz wrote:
>> Hi,
>> 
>> Here is another go at characteristics reported for spliterators of empty collections:
>> 
>> diff -r f8d92ce66886 src/share/classes/java/util/Collection.java
>> --- a/src/share/classes/java/util/Collection.java	Mon Aug 12 13:59:01 2013 +0200
>> +++ b/src/share/classes/java/util/Collection.java	Mon Aug 12 16:12:10 2013 +0200
>> @@ -504,7 +504,10 @@
>>       *
>>       *
The returned {@code Spliterator} must report the characteristic
>>       * {@link Spliterator#SIZED}; implementations should document any additional
>> -     * characteristic values reported by the returned Spliterator.
>> +     * characteristic values reported by the returned spliterator.  If
>> +     * this collection contains no elements then the returned spliterator is
>> +     * only required to report {@link Spliterator#SIZED} and is not required to
>> +     * report additional characteristics (if any).
>>       *
>>       *
The default implementation should be overridden by subclasses that
>>       * can return a more efficient spliterator.  In order to
>> @@ -535,6 +538,13 @@
>>       * The returned {@code Spliterator} additionally reports
>>       * {@link Spliterator#SUBSIZED}.
>>       *
>> +     *
If a spliterator covers no elements then the reporting of additional
>> +     * characteristics, beyond that of {@code SIZED} and {@code SUBSIZED}, does
>> +     * not aid clients to control specialize or simplify computation.  However,
>> +     * this does enable shared use of an empty spliterator (see
>> +     * {@link Spliterators#emptySpliterator()} for empty collections, and
>> +     * enables clients to determine if a spliterator covers no elements.
>> +     *
>>       * @return a {@code Spliterator} over the elements in this collection
>>       * @since 1.8
>>       */
>> 
>> It might be preferable to also document this on List/Set/SortedSet since the documentation is overridden and i don't think we have many precedents for overriding what the sub-types define (are there any?).
>> 
>> --
>> 
>> I logged issue 8022805 for Stream.concat(s, Stream.emptyStream()).
>> 
>> Paul.
>> 
> The wording looks okay to me except "specialize" -> "specialization".
> 

Thanks there is a comma missing, it should be:

     * 
If a spliterator covers no elements then the reporting of additional
     * characteristic values, beyond that of {@code SIZED} and {@code SUBSIZED},
     * does not aid clients to control, specialize or simplify computation.

Paul.

From aleksej.efimov at oracle.com  Tue Aug 13 09:20:17 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Tue, 13 Aug 2013 13:20:17 +0400
Subject: RFR 8021820: Number of opened files used in select() is limited
	to 1024 [macosx]
In-Reply-To: <5202FDFF.1030906@oracle.com>
References: <51F9007D.8090801@oracle.com> <51F9150B.4000008@oracle.com>
	<51F920A7.3000600@oracle.com> <51FF90BD.6070600@oracle.com>
	<52004DD9.4040202@oracle.com> <5202453F.2080409@oracle.com>
	<5202FDFF.1030906@oracle.com>
Message-ID: <5209FA51.9060907@oracle.com>

Stuart,
Thanks for your comments.
New webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.03/ 

Comments below.

Thanks,
Aleksej

On 08/08/2013 06:10 AM, Stuart Marks wrote:
> Hi Aleksej,
>
> Thanks for the update. The situation is a bit twisted.
>
> I picked up a couple clues from David Holmes and Jon Gibbons. The 
> NoClassDefFoundError occurs when the JVM has hit its resource limit 
> for the number of open files, *and* it is being run in a development 
> environment with individual class files in a hierarchy, e.g. within
>
>     ROOT/build//jdk/classes
>
> In this case, since each class is in its own file, it's quite likely 
> that the loading of an individual class will fail because of lack of 
> file descriptors. If the JVM itself encounters this, it will generate 
> a NoClassDefFoundError without a stack trace such as the ones we've seen.
>
> If the test is being run against a fully built JDK image, classes are 
> loaded from rt.jar. This is usually already open, so quite often 
> classes can be loaded without having to open additional files. In this 
> case we get the FileNotFoundException as expected.
It was very interesting and enlightening information. Thank you for 
that, I'll keep it in mind.
>
> The resource limits seem to vary from system to system, and even from 
> one Ubuntu version to the next (mine has a default hard limit of 1024 
> open files). Unfortunately, while it might seem reasonable to have 
> minimum specifications for systems on which we run tests, in practice 
> this has proven very difficult. Since the bug being fixed is Mac-only, 
> and the default open file limit for Mac seems to be unlimited, perhaps 
> it makes most sense for this to be a Mac-only test.
>
> From the discussion here [1] which refers to an Apple technote [2] it 
> seems like the best way to test for being on a Mac is something like 
> this:
>
>     if (! System.getProperty("os.name").contains("OS X")) {
>         return;
>     }
>
> That is, report success if we're on anything other than a Mac.
Agreed, there is no need to run this test on other platforms (the bug 
states only MacOSX) and as a good addition we don't need to worry about 
limits on other platforms. The suggested check was added to test. And it 
was executed on all platforms (without fix): all except MacOSX passes, 
on MacOSX expected result - "java.net.SocketException: Invalid argument".
>
> Once we're sure we're on a Mac, having the test fail if it can't open 
> enough files seems reasonable.
>
> I'd suggest putting a comment at the top of the test class saying that 
> this test *must* be run in othervm mode, to ensure that files are 
> closed properly. That way, you can take out the cleanupFiles() method 
> too, as well as avoiding lots of exception handling and related 
> cleanup code.
Comment was added and cleanupFiles() method was removed as suggested.
>
> Finally, a style point: try/catch statements are conventionally 
> indented as a single multi-block, not as separate statements. I'd 
> suggest something like this:
>
>         // The accept() call will throw SocketException if the
>         // select() has failed due to limitation on fds size,
>         // indicating test failure. A SocketTimeoutException
>         // is expected, so it is caught and ignored, and the test
>         // passes.
>
>         try {
>             socket.accept();
>         } catch (SocketTimeoutException e) { }
Fixed.
>
> s'marks
>
>
> [1] 
> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-November/005148.html
>
> [2] https://developer.apple.com/library/mac/#technotes/tn2002/tn2110.html
>
>
>
> On 8/7/13 6:01 AM, Aleksej Efimov wrote:
>> Stuart, thank you for you comments, responses are below.
>> New webrev:
>> http://cr.openjdk.java.net/~aefimov/8021820/webrev.02/
>> 
>>
>>
>> -Aleksej
>>
>> On 08/06/2013 05:14 AM, Stuart Marks wrote:
>>> Hi Aleksej,
>>>
>>> Thanks for the update. I took a look at the revised test, and there 
>>> are still
>>> some issues. (I didn't look at the build changes.)
>>>
>>> 1) System-specific resource limits.
>>>
>>> I think the biggest issue is resource limits on the number of open 
>>> files per
>>> process that might vary from system to system. On my Ubuntu system, 
>>> the hard
>>> limit on the number of open files is 1,024. The test opens 1,023 
>>> files and
>>> then one more for the socket. Unfortunately the JVM and jtreg have 
>>> several
>>> files open already, and the test crashes before the openFiles() method
>>> completes.
>>>
>>> (Oddly it crashes with a NoClassDefFoundError from the main thread's 
>>> uncaught
>>> exception handler, and then the test reports that it passed! Placing a
>>> try/catch of Throwable in main() or openFiles() doesn't catch this 
>>> error. I
>>> have no explanation for this. When run standalone -- i.e., not from 
>>> jtreg --
>>> the test throws FileNotFoundException (too many open files) from 
>>> openFiles(),
>>> which is expected.)
>>>
>>> On my Mac (10.7.5) the soft limit is 256 files, but the hard limit is
>>> unlimited. The test succeeds in opening all its files but fails 
>>> because of
>>> the select() bug you're fixing. (This is expected; I didn't rebuild 
>>> my JDK
>>> with your patch.) I guess the soft limit doesn't do anything on Mac.
>>>
>>> Amazingly, the test passed fine on both Windows XP and Windows 8.
>>>
>>> I'm not entirely sure what to do about resource limits. Since the 
>>> test is
>>> able to open >1024 files on Mac, Windows, and possibly other 
>>> Linuxes, it
>>> seems reasonable to continue with this approach. If it's possible to 
>>> catch
>>> the error that occurs if the test cannot open its initial 1,024 files,
>>> perhaps it should do this, log a message indicating what happened, and
>>> consider the test to have passed. I'm mystified by the 
>>> uncaught/uncatchable
>>> NoClassDefFoundError though.
>> I wonder if this is a question of test environment required for JTREG 
>> tests: if
>> we'll execute JTREG tests with low value assigned to fd hard limit 
>> (for example
>> 10) we'll see a lot of unrelated test failures. So, I suggest that we 
>> can
>> assume that there is no hard limits set (or at least default ones, 
>> i.e. default
>> fd limit on Ubuntu is 4096) on test machine. But we should consider 
>> test as
>> Failed if test failed to prepare it's environment because of some 
>> external
>> limitations. The JTREG doesn't meet this criteria (log test as PASS 
>> and prints
>> incorrect Exception). To illustrate it I have repeated your 
>> experiments on
>> ubuntu linux: set fd hard limit to 1024 (ulimit -Hn 1024) and got 
>> this error by
>> manual run of test:
>> Exception in thread "main" java.io.FileNotFoundException: testfile 
>> (Too many
>> open files)
>>      at java.io.FileInputStream.open(Native Method)
>>      at java.io.FileInputStream.(FileInputStream.java:128)
>>      at SelectFdsLimit.openFiles(SelectFdsLimit.java:63)
>>      at SelectFdsLimit.main(SelectFdsLimit.java:81)
>>
>> Seems correct to me.
>> An by JTREG (also with hard limit set to 1024):
>> ----------messages:(3/123)----------
>> command: main SelectFdsLimit
>> reason: User specified action: run main/othervm SelectFdsLimit
>> elapsed time (seconds): 0.168
>> ----------System.out:(0/0)----------
>> ----------System.err:(5/250)----------
>>
>> Exception: java.lang.NoClassDefFoundError thrown from the
>> UncaughtExceptionHandler in thread "MainThread"
>> STATUS:Passed.
>> Exception in thread "main"
>> Exception: java.lang.NoClassDefFoundError thrown from the
>> UncaughtExceptionHandler in thread "main"
>> result: Passed. Execution successful
>>
>>
>> test result: Passed. Execution successful
>>
>>
>> The results are identical to results mentioned by you. It seems to me 
>> that
>> jtreg doesn't correctly processes such test error (at least it 
>> shouldn't be
>> considered as Pass). And I suggest two ways of resolving it:
>> 1. If we don't have official limitations (or default) on what 
>> resources test
>> can use then we shouldn't do any modifications to test.
>> 2. If there is some limitations that we should honor then we'll need 
>> to figure
>> out what to do with NoClassDefFoundError exception in JTREG.
>>
>>>
>>> 2) Closing files.
>>>
>>> If an exception is thrown while opening the initial set of files, or 
>>> sometime
>>> during the closing process, the test can still leak files.
>>>
>>> One approach would be to keep a data structure representing the 
>>> current set
>>> of open files, and close them all in a finally-block around all the 
>>> test
>>> logic, and making sure that exceptions from the close() call are 
>>> caught and
>>> do not prevent the rest of the files from being closed.
>>>
>>> This seems like a lot of work. Perhaps a more effective approach 
>>> would be to
>>> run the test in "othervm" mode, as follows:
>>>
>>>     @run main/othervm SelectFdsLimit
>>>
>>> This will cause the test to run in a dedicated JVM, so all files 
>>> will be
>>> closed automatically when it exits. (It would be good to add a comment
>>> explaining the need for othervm, if you do this.)
>>>
>> main/othervm and comments were added.
>>> 3) Port number for sockets.
>>>
>>> It's fairly common for tests to fail occasionally because they use some
>>> constant port number that sometimes happens to be in use at the same 
>>> time by
>>> another process on the system. I have to say, 8080 is a pretty 
>>> common port
>>> number. :-)
>>>
>>> For purposes of this test, you can let the system assign a port. 
>>> Just use:
>>>
>>>     new ServerSocket(0)
>>>
>> Completely agree that 8080 port - bad port for testing =). Changed to 0.
>>> 4) Style.
>>>
>>> It's probably possible to use the same File object for the test 
>>> file, instead
>>> of creating new File objects repeatedly.
>> Agree and corrected.
>>>
>>> It might be nice to add a comment explaining the logic of the test, 
>>> that
>>> SocketTimeoutException is expected, and that failure will be 
>>> indicated if the
>>> accept() throws SocketException caused by the underlying mishandling 
>>> of large
>>> fds by select().
>> Comments were added.
>>>
>>> Thanks,
>>>
>>> s'marks
>>>
>>>
>>>
>>> On 8/5/13 4:47 AM, Aleksej Efimov wrote:
>>>> Alan, Tim,
>>>>
>>>> I have addressed your comments and as a result - new webrev:
>>>> http://cr.openjdk.java.net/~aefimov/8021820/webrev.01
>>>>
>>>> The list of changes:
>>>> 1. The connection to Oracle site is removed (it's not internal, but 
>>>> anyway it's
>>>> better not to rely on availability of external resource in test). 
>>>> In current
>>>> version a server socket is created and accept() method is used for bug
>>>> disclosure.
>>>> 2. The cleanup method is added for closing file streams. The JTREG 
>>>> successfully
>>>> cleaned-up on windows after this modification.
>>>> 3. common/autoconf/toolchain.m4 untouched, but 'bash
>>>> common/autoconf/autogen.sh' was executed to update 
>>>> generated-configure.sh.
>>>>
>>>> Aleksej
>>>>
>>>>
>>>> On 07/31/2013 06:35 PM, Tim Bell wrote:
>>>>> Aleksej, Alan
>>>>>
>>>>> The change in common/autoconf/toolchain.m4 looks correct to me, 
>>>>> and I think
>>>>> that is a good place to have it.  Remember to run 'bash
>>>>> common/autoconf/autogen.sh' and check in the 
>>>>> generated-configure.sh files as
>>>>> part of the changeset.
>>>>>
>>>>> I didn't look at the test case, but I think Alan has some good 
>>>>> points.
>>>>>
>>>>> Tim
>>>>>
>>>>> On 07/31/13 06:45 AM, Alan Bateman wrote:
>>>>>> On 31/07/2013 05:18, Aleksej Efimov wrote:
>>>>>>> Hi,
>>>>>>> Can I have a review for the following problem:
>>>>>>> The MACOSX JDK (more precisely - the java.net classes) uses the 
>>>>>>> select()
>>>>>>> system call to wait for different events on sockets fds. And the 
>>>>>>> default
>>>>>>> behaviour for select() on Darwin is to fail when fdset contains 
>>>>>>> the fd with
>>>>>>> id greater than FDSET_SIZE(=1024). Test case in webrev 
>>>>>>> illustrates this
>>>>>>> behavior.
>>>>>>> There is at least one solution for it: use 
>>>>>>> -D_DARWIN_UNLIMITED_SELECT
>>>>>>> compilation flag for all macosx sources: this won't affect other 
>>>>>>> parts of
>>>>>>> JDK because they are not using select().
>>>>>>> Currently, I have added this compilation flag to
>>>>>>> common/autoconf/generated-configure.sh and
>>>>>>> common/autoconf/generated-configure.sh. I wonder, if there is a 
>>>>>>> better
>>>>>>> place where I can put this flag?
>>>>>>>
>>>>>>> The webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.00/
>>>>>>> BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021820
>>>>>>
>>>>>> Thanks for looking into this one. The build changes look okay to 
>>>>>> me but it's
>>>>>> probably best that someone on build-dev agree to those.
>>>>>> Michael McMahon can probably explain why the net code is using 
>>>>>> select for
>>>>>> timed read/accept (I have a vague recollection of there being an 
>>>>>> issue with
>>>>>> poll due to the way that it is implemented on kqueue with the 
>>>>>> result that it
>>>>>> had to be changed to use select).
>>>>>>
>>>>>> I think the test needs re-work. It looks to me that the it 
>>>>>> attempts to
>>>>>> connect to an Oracle internal site so that's not going to work 
>>>>>> everywhere.
>>>>>> In general we don't want the tests to be dependent on hosts that 
>>>>>> may or may
>>>>>> not exist (we had tests that used to this in the past but they 
>>>>>> caused a lot
>>>>>> of grief). It also looks like the test doesn't close the 1023 
>>>>>> files that it
>>>>>> opens at the start and so I assume this test will always fail on 
>>>>>> Windows
>>>>>> when jtreg tries to clean-up.
>>>>>>
>>>>>> -Alan.
>>>>>
>>>>
>>



From Alan.Bateman at oracle.com  Tue Aug 13 12:36:02 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 13 Aug 2013 13:36:02 +0100
Subject: Java 8 RFR 8022180: BigInteger Burnikel-Ziegler quotient and
	remainder calculation assumes quotient parameter is zero
In-Reply-To: 
References: <6F5A74F5-C71E-441D-84CB-E71492F31E0B@oracle.com>
	<52094E26.5080102@oracle.com>
	
	
Message-ID: <520A2832.9040305@oracle.com>

On 13/08/2013 00:27, Brian Burkhalter wrote:
> On Aug 12, 2013, at 2:08 PM, Brian Burkhalter wrote:
>
>>>> Webrev	http://cr.openjdk.java.net/~bpb/8022180/
>>>>
>>>> The update is to clear the quotient if the divisor is larger than the dividend in divideAndRemainderBurnikelZiegler().
>>>>
>>>> Thanks,
>>>>
>>>> Brian
>>> Could the quotient be cleared at the top of the method as it is cleared for the schoolbook division anyway?
>> Yes, that would be a bit clearer.
> Webrev updated at the same location.
>
Looks good, I'll push it for you shortly.

-Alan.


From Alan.Bateman at oracle.com  Tue Aug 13 12:36:55 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 13 Aug 2013 13:36:55 +0100
Subject: RFR 8022797 Clarify spliterator characteristics for collections
	containing no elements
In-Reply-To: <073306B3-57F4-47DE-A32B-71816F0033D4@Oracle.com>
References: 
	<5209288D.7040801@oracle.com>
	<073306B3-57F4-47DE-A32B-71816F0033D4@Oracle.com>
Message-ID: <520A2867.9010400@oracle.com>

On 13/08/2013 10:14, Paul Sandoz wrote:
> :
> Thanks there is a comma missing, it should be:
>
>       *
If a spliterator covers no elements then the reporting of additional
>       * characteristic values, beyond that of {@code SIZED} and {@code SUBSIZED},
>       * does not aid clients to control, specialize or simplify computation.
>
Looks fine now.

-Alan.


From sean.mullan at oracle.com  Tue Aug 13 13:05:47 2013
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Tue, 13 Aug 2013 13:05:47 +0000
Subject: hg: jdk8/tl/jdk: 8020081: Cipher with OAEPPadding and
	OAEPParameterSpec can't be created
Message-ID: <20130813130623.337D448806@hg.openjdk.java.net>

Changeset: 5b14d702b0b8
Author:    ascarpino
Date:      2013-08-12 11:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b14d702b0b8

8020081: Cipher with OAEPPadding and OAEPParameterSpec can't be created
Reviewed-by: mullan

! src/share/classes/com/sun/crypto/provider/SunJCE.java
+ test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java



From paul.sandoz at oracle.com  Tue Aug 13 13:35:00 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 13 Aug 2013 15:35:00 +0200
Subject: RFR 8012940 More than 50 tests failed in
	Serialization/DeSerialization testing (test-mangled)
Message-ID: <3F3FDF0C-AF78-4E65-8CB8-D92433487E33@oracle.com>

Hi,

The updates to stream tests below are in preparation for when the lambda serialization/deserialization tests (SAND tests) transition from testing with lambda to tl. Doing this now so we don't forget later.

The SAND tests do a clever trick of byte code re-writing our existing tests but for certain tests this does not work. Some of those tests are grouped in the "serialisation-hostile" test group, but in certain cases, such as for data providers, it is not possible to do this and we need to resort to some runtime check, one such case is sub lists of array lists.

Paul.

diff -r cc64a05836a7 test/java/util/stream/bootlib/java/util/stream/LambdaTestMode.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/test/java/util/stream/bootlib/java/util/stream/LambdaTestMode.java	Tue Aug 13 15:29:24 2013 +0200
@@ -0,0 +1,71 @@
+/*
+ * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+ * or visit www.oracle.com if you need additional information or have any
+ * questions.
+ */
+package java.util.stream;
+
+/**
+ * Runtime modes of test execution.
+ */
+public enum LambdaTestMode {
+    /**
+     * Execution mode with no particular runtime constraints.
+     */
+    NORMAL,
+
+    /**
+     * Execution mode where tests are executed for testing lambda serialization
+     * and deserialization.
+     *
+     * 
This mode may be queried by tests or data supplied by data
+     * providers, which cannot otherwise be assigned to the test group
+     * serialization-hostile, to not execute or declare
+     * serialization-hostile code or data.
+     *
+     * 
This mode is enabled if the boolean system property
+     * {@code org.openjdk.java.util.stream.sand.mode} is declared with a
+     * {@code true} value.
+     */
+    SERIALIZATION;
+
+    /**
+     * {@code true} if tests are executed in the mode for testing lambda
+     * Serialization ANd Deserialization (SAND).
+     */
+    private static final boolean IS_LAMBDA_SERIALIZATION_MODE =
+            Boolean.getBoolean("org.openjdk.java.util.stream.sand.mode");
+
+    /**
+     *
+     * @return the mode of test execution.
+     */
+    public static LambdaTestMode getMode() {
+        return IS_LAMBDA_SERIALIZATION_MODE ? SERIALIZATION : NORMAL;
+    }
+
+    /**
+     *
+     * @return {@code true} if normal test mode.
+     */
+    public static boolean isNormalMode() {
+        return getMode() == NORMAL;
+    }
+}
diff -r cc64a05836a7 test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java
--- a/test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java	Mon Aug 12 16:09:24 2013 -0400
+++ b/test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java	Tue Aug 13 15:29:24 2013 +0200
@@ -96,8 +96,14 @@
                 list.add(streamDataDescr("DelegatingStream(ArrayList):" + name,
                                          () -> new ArrayList<>(intsAsList).stream()));
                 List aList = new ArrayList<>(intsAsList);
-                list.add(collectionDataDescr("ArrayList.Sublist:" + name,
-                                             (ints.length) <= 1 ? aList.subList(0, 0) : aList.subList(1, ints.length / 2)));
+                if (LambdaTestMode.isNormalMode()) {
+                    // Only include sub-lists for normal test execution mode
+                    // This data is serialization-hostile since the state of the
+                    // deserialized sub-list will be out of sync with the
+                    // enclosing list.
+                    list.add(collectionDataDescr("ArrayList.Sublist:" + name,
+                                                 (ints.length) <= 1 ? aList.subList(0, 0) : aList.subList(1, ints.length / 2)));
+                }
                 list.add(collectionDataDescr("LinkedList:" + name, new LinkedList<>(intsAsList)));
                 list.add(collectionDataDescr("HashSet:" + name, new HashSet<>(intsAsList)));
                 list.add(collectionDataDescr("LinkedHashSet:" + name, new LinkedHashSet<>(intsAsList)));

From vincent.x.ryan at oracle.com  Tue Aug 13 13:19:13 2013
From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com)
Date: Tue, 13 Aug 2013 13:19:13 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130813131940.272B248807@hg.openjdk.java.net>

Changeset: 818c3f82269c
Author:    vinnie
Date:      2013-08-13 14:15 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/818c3f82269c

8013170: Spec for PBEParameterSpec does not specify behavior when paramSpec is null
Reviewed-by: mullan

! src/share/classes/javax/crypto/spec/PBEParameterSpec.java

Changeset: 26753a05859a
Author:    vinnie
Date:      2013-08-13 14:18 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/26753a05859a

Merge




From paul.sandoz at oracle.com  Tue Aug 13 13:46:41 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 13 Aug 2013 15:46:41 +0200
Subject: RFR 8022898 java/util/Spliterator/SpliteratorCollisions.java fails in
	HashableIntSpliteratorWithNull data provider
Message-ID: 

Hi,

This patch fixes a bug in the data provider of the SpliteratorCollisions.java test, which was attempting to add an element to an unmodifable map.

Interestingly although this caused the data provider to barf, and therefore tests using such a provider were not run, it did not result in jtreg reporting the test-infrastructure failure.

Paul.

diff -r 35483a6aa27e test/java/util/Spliterator/SpliteratorCollisions.java
--- a/test/java/util/Spliterator/SpliteratorCollisions.java	Tue Aug 13 15:24:53 2013 +0200
+++ b/test/java/util/Spliterator/SpliteratorCollisions.java	Tue Aug 13 15:41:39 2013 +0200
@@ -148,7 +148,6 @@
         List data = new ArrayList<>();
         for (int size : SIZES) {
             List exp = listIntRange(size, true);
-            exp.add(0, null);
             SpliteratorDataBuilder db = new SpliteratorDataBuilder<>(data, exp);
 
             // Maps

From ivan.gerasimov at oracle.com  Tue Aug 13 13:46:37 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 13 Aug 2013 17:46:37 +0400
Subject: RFR [8016018] Typo in AbstractStringBuilder#indexOf and #lastIndexOf
	description
Message-ID: <520A38BD.9000905@oracle.com>

Hello!

Would you please help review a simple fix of a typo in the Java doc?

s/str/this/

The fix if for jdk8.

BUGURL: http://bugs.sun.com/view_bug.do?bug_id=8016018
WEBREV: http://cr.openjdk.java.net/~igerasim/8016018/0/webrev/

Sincerely yours,
Ivan Gerasimov


From alan.bateman at oracle.com  Tue Aug 13 13:46:41 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 13 Aug 2013 13:46:41 +0000
Subject: hg: jdk8/tl/jdk: 8022180: BigInteger Burnikel-Ziegler quotient and
	remainder calculation assumes quotient parameter is zero
Message-ID: <20130813134655.5EFA14880A@hg.openjdk.java.net>

Changeset: 834faf2081b3
Author:    bpb
Date:      2013-08-12 16:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/834faf2081b3

8022180: BigInteger Burnikel-Ziegler quotient and remainder calculation assumes quotient parameter is zero
Summary: Clear the quotient in divideAndRemainderBurnikelZiegler() if the divisor is larger than the dividend.
Reviewed-by: alanb, bpb
Contributed-by: Timothy Buktu 

! src/share/classes/java/math/MutableBigInteger.java
! test/java/math/BigInteger/BigIntegerTest.java



From daniel.fuchs at oracle.com  Tue Aug 13 14:01:14 2013
From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com)
Date: Tue, 13 Aug 2013 14:01:14 +0000
Subject: hg: jdk8/tl/jdk: 8019948:
	java/util/logging/bundlesearch/ResourceBundleSearchTest.java is
	failing intermittently
Message-ID: <20130813140126.A06E14880E@hg.openjdk.java.net>

Changeset: 78c102c3eefc
Author:    dfuchs
Date:      2013-08-13 16:00 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78c102c3eefc

8019948: java/util/logging/bundlesearch/ResourceBundleSearchTest.java is failing intermittently
Reviewed-by: mchung, dholmes

! test/java/util/logging/bundlesearch/ResourceBundleSearchTest.java



From kumar.x.srinivasan at oracle.com  Tue Aug 13 14:07:16 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 13 Aug 2013 07:07:16 -0700
Subject: RFR 8012940 More than 50 tests failed in
	Serialization/DeSerialization testing (test-mangled)
In-Reply-To: <3F3FDF0C-AF78-4E65-8CB8-D92433487E33@oracle.com>
References: <3F3FDF0C-AF78-4E65-8CB8-D92433487E33@oracle.com>
Message-ID: <520A3D94.1070805@oracle.com>

Hi Paul,

Looks good, you can add me as reviewer.

Thanks for doing this.

Kumar

> Hi,
>
> The updates to stream tests below are in preparation for when the lambda serialization/deserialization tests (SAND tests) transition from testing with lambda to tl. Doing this now so we don't forget later.
>
> The SAND tests do a clever trick of byte code re-writing our existing tests but for certain tests this does not work. Some of those tests are grouped in the "serialisation-hostile" test group, but in certain cases, such as for data providers, it is not possible to do this and we need to resort to some runtime check, one such case is sub lists of array lists.
>
> Paul.
>
> diff -r cc64a05836a7 test/java/util/stream/bootlib/java/util/stream/LambdaTestMode.java
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/test/java/util/stream/bootlib/java/util/stream/LambdaTestMode.java	Tue Aug 13 15:29:24 2013 +0200
> @@ -0,0 +1,71 @@
> +/*
> + * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> + *
> + * This code is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 only, as
> + * published by the Free Software Foundation.
> + *
> + * This code is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> + * version 2 for more details (a copy is included in the LICENSE file that
> + * accompanied this code).
> + *
> + * You should have received a copy of the GNU General Public License version
> + * 2 along with this work; if not, write to the Free Software Foundation,
> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> + *
> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
> + * or visit www.oracle.com if you need additional information or have any
> + * questions.
> + */
> +package java.util.stream;
> +
> +/**
> + * Runtime modes of test execution.
> + */
> +public enum LambdaTestMode {
> +    /**
> +     * Execution mode with no particular runtime constraints.
> +     */
> +    NORMAL,
> +
> +    /**
> +     * Execution mode where tests are executed for testing lambda serialization
> +     * and deserialization.
> +     *
> +     * 
This mode may be queried by tests or data supplied by data
> +     * providers, which cannot otherwise be assigned to the test group
> +     * serialization-hostile, to not execute or declare
> +     * serialization-hostile code or data.
> +     *
> +     * 
This mode is enabled if the boolean system property
> +     * {@code org.openjdk.java.util.stream.sand.mode} is declared with a
> +     * {@code true} value.
> +     */
> +    SERIALIZATION;
> +
> +    /**
> +     * {@code true} if tests are executed in the mode for testing lambda
> +     * Serialization ANd Deserialization (SAND).
> +     */
> +    private static final boolean IS_LAMBDA_SERIALIZATION_MODE =
> +            Boolean.getBoolean("org.openjdk.java.util.stream.sand.mode");
> +
> +    /**
> +     *
> +     * @return the mode of test execution.
> +     */
> +    public static LambdaTestMode getMode() {
> +        return IS_LAMBDA_SERIALIZATION_MODE ? SERIALIZATION : NORMAL;
> +    }
> +
> +    /**
> +     *
> +     * @return {@code true} if normal test mode.
> +     */
> +    public static boolean isNormalMode() {
> +        return getMode() == NORMAL;
> +    }
> +}
> diff -r cc64a05836a7 test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java
> --- a/test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java	Mon Aug 12 16:09:24 2013 -0400
> +++ b/test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java	Tue Aug 13 15:29:24 2013 +0200
> @@ -96,8 +96,14 @@
>                   list.add(streamDataDescr("DelegatingStream(ArrayList):" + name,
>                                            () -> new ArrayList<>(intsAsList).stream()));
>                   List aList = new ArrayList<>(intsAsList);
> -                list.add(collectionDataDescr("ArrayList.Sublist:" + name,
> -                                             (ints.length) <= 1 ? aList.subList(0, 0) : aList.subList(1, ints.length / 2)));
> +                if (LambdaTestMode.isNormalMode()) {
> +                    // Only include sub-lists for normal test execution mode
> +                    // This data is serialization-hostile since the state of the
> +                    // deserialized sub-list will be out of sync with the
> +                    // enclosing list.
> +                    list.add(collectionDataDescr("ArrayList.Sublist:" + name,
> +                                                 (ints.length) <= 1 ? aList.subList(0, 0) : aList.subList(1, ints.length / 2)));
> +                }
>                   list.add(collectionDataDescr("LinkedList:" + name, new LinkedList<>(intsAsList)));
>                   list.add(collectionDataDescr("HashSet:" + name, new HashSet<>(intsAsList)));
>                   list.add(collectionDataDescr("LinkedHashSet:" + name, new LinkedHashSet<>(intsAsList)));



From sean.mullan at oracle.com  Tue Aug 13 14:10:00 2013
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Tue, 13 Aug 2013 14:10:00 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130813141024.7A95E4880F@hg.openjdk.java.net>

Changeset: 412b2f0950a9
Author:    mullan
Date:      2013-08-13 10:06 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/412b2f0950a9

8022897: Add test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java to ProblemList
Reviewed-by: vinnie, chegar

! test/ProblemList.txt

Changeset: 19133b3af95f
Author:    mullan
Date:      2013-08-13 10:07 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19133b3af95f

Merge

! test/ProblemList.txt



From chris.hegarty at oracle.com  Tue Aug 13 13:57:59 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 13 Aug 2013 13:57:59 +0000
Subject: hg: jdk8/tl/jdk: 8022779: ProblemList.txt updates (8/2013)
Message-ID: <20130813135811.2FB3A4880C@hg.openjdk.java.net>

Changeset: 18e15d92610b
Author:    chegar
Date:      2013-08-13 14:57 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18e15d92610b

8022779: ProblemList.txt updates (8/2013)
Summary: Update ProblemList and remove AggressiveOpts MOAT test run
Reviewed-by: chegar, alanb
Contributed-by: Amy Lu 

! test/ProblemList.txt
! test/java/util/Collection/MOAT.java



From Alan.Bateman at oracle.com  Tue Aug 13 15:24:28 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 13 Aug 2013 16:24:28 +0100
Subject: RFR [8016018] Typo in AbstractStringBuilder#indexOf and
	#lastIndexOf description
In-Reply-To: <520A38BD.9000905@oracle.com>
References: <520A38BD.9000905@oracle.com>
Message-ID: <520A4FAC.20405@oracle.com>

On 13/08/2013 14:46, Ivan Gerasimov wrote:
> Hello!
>
> Would you please help review a simple fix of a typo in the Java doc?
>
> s/str/this/
>
> The fix if for jdk8.
>
> BUGURL: http://bugs.sun.com/view_bug.do?bug_id=8016018
> WEBREV: http://cr.openjdk.java.net/~igerasim/8016018/0/webrev/
This looks okay to me.

-Alan


From chris.hegarty at oracle.com  Tue Aug 13 15:42:17 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 13 Aug 2013 16:42:17 +0100
Subject: RFR [8016018] Typo in AbstractStringBuilder#indexOf and
	#lastIndexOf description
In-Reply-To: <520A4FAC.20405@oracle.com>
References: <520A38BD.9000905@oracle.com> <520A4FAC.20405@oracle.com>
Message-ID: <520A53D9.3040804@oracle.com>

On 08/13/2013 04:24 PM, Alan Bateman wrote:
> On 13/08/2013 14:46, Ivan Gerasimov wrote:
>> Hello!
>>
>> Would you please help review a simple fix of a typo in the Java doc?
>>
>> s/str/this/
>>
>> The fix if for jdk8.
>>
>> BUGURL: http://bugs.sun.com/view_bug.do?bug_id=8016018
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8016018/0/webrev/
> This looks okay to me.
+1

-Chris.


From mike.duigou at oracle.com  Tue Aug 13 16:12:10 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 13 Aug 2013 09:12:10 -0700
Subject: RFR: 8019401: Collectors.collectingAndThen
In-Reply-To: <5209A770.50308@oracle.com>
References: <5209A770.50308@oracle.com>
Message-ID: <2509D893-42EA-45DB-A7D9-5B5EB9959BA4@oracle.com>

Looks good to me.

Mike

On Aug 12 2013, at 20:26 , Henry Jen wrote:

> Hi,
> 
> Please review the webrev[1] adds an API to help compose a Collector with
> an additional "finish" function.
> 
> Cheers,
> Henry
> 
> [1] http://cr.openjdk.java.net/~henryjen/ccc/8019401/0/webrev/
> 



From henry.jen at oracle.com  Tue Aug 13 16:36:26 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 13 Aug 2013 09:36:26 -0700
Subject: RFR 8022898 java/util/Spliterator/SpliteratorCollisions.java
	fails in HashableIntSpliteratorWithNull data provider
In-Reply-To: 
References: 
Message-ID: 

Looks good to me.

Cheers,
Henry

On Aug 13, 2013, at 6:46 AM, Paul Sandoz  wrote:

> Hi,
> 
> This patch fixes a bug in the data provider of the SpliteratorCollisions.java test, which was attempting to add an element to an unmodifable map.
> 
> Interestingly although this caused the data provider to barf, and therefore tests using such a provider were not run, it did not result in jtreg reporting the test-infrastructure failure.
> 
> Paul.
> 
> diff -r 35483a6aa27e test/java/util/Spliterator/SpliteratorCollisions.java
> --- a/test/java/util/Spliterator/SpliteratorCollisions.java	Tue Aug 13 15:24:53 2013 +0200
> +++ b/test/java/util/Spliterator/SpliteratorCollisions.java	Tue Aug 13 15:41:39 2013 +0200
> @@ -148,7 +148,6 @@
>         List data = new ArrayList<>();
>         for (int size : SIZES) {
>             List exp = listIntRange(size, true);
> -            exp.add(0, null);
>             SpliteratorDataBuilder db = new SpliteratorDataBuilder<>(data, exp);
> 
>             // Maps



From joe.darcy at oracle.com  Tue Aug 13 16:43:19 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 13 Aug 2013 09:43:19 -0700
Subject: RFR JDK 8: another doclint fix in java.util.zip
Message-ID: <520A6227.7080901@oracle.com>

Hello,

Please review this simple patch below which corrects a recently 
introduced doclint issue (8015666: test/tools/pack200/TimeStamp.java 
failing).

Thanks,

-Joe

diff -r cc64a05836a7 src/share/classes/java/util/zip/ZipEntry.java
--- a/src/share/classes/java/util/zip/ZipEntry.java    Mon Aug 12 
16:09:24 2013 -0400
+++ b/src/share/classes/java/util/zip/ZipEntry.java    Tue Aug 13 
09:40:04 2013 -0700
@@ -239,7 +239,7 @@
       *
       * @return The last access time of the entry, null if not specified

-     * @see #setLastAccessTime(long)
+     * @see #setLastAccessTime(FileTime)
       * @since 1.8
       */
      public FileTime getLastAccessTime() {



From chris.hegarty at oracle.com  Tue Aug 13 16:51:57 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 13 Aug 2013 17:51:57 +0100
Subject: RFR JDK 8: another doclint fix in java.util.zip
In-Reply-To: <520A6227.7080901@oracle.com>
References: <520A6227.7080901@oracle.com>
Message-ID: <520A642D.3070800@oracle.com>

Looks fine Joe.

-Chris.

On 08/13/2013 05:43 PM, Joe Darcy wrote:
> Hello,
>
> Please review this simple patch below which corrects a recently
> introduced doclint issue (8015666: test/tools/pack200/TimeStamp.java
> failing).
>
> Thanks,
>
> -Joe
>
> diff -r cc64a05836a7 src/share/classes/java/util/zip/ZipEntry.java
> --- a/src/share/classes/java/util/zip/ZipEntry.java    Mon Aug 12
> 16:09:24 2013 -0400
> +++ b/src/share/classes/java/util/zip/ZipEntry.java    Tue Aug 13
> 09:40:04 2013 -0700
> @@ -239,7 +239,7 @@
>        *
>        * @return The last access time of the entry, null if not specified
>
> -     * @see #setLastAccessTime(long)
> +     * @see #setLastAccessTime(FileTime)
>        * @since 1.8
>        */
>       public FileTime getLastAccessTime() {
>


From joe.darcy at oracle.com  Tue Aug 13 17:12:46 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 13 Aug 2013 17:12:46 +0000
Subject: hg: jdk8/tl/jdk: 8022959: Fix new doclint issues in java.util.zip
Message-ID: <20130813171336.4A95548827@hg.openjdk.java.net>

Changeset: cd9379e348d0
Author:    darcy
Date:      2013-08-13 10:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd9379e348d0

8022959: Fix new doclint issues in java.util.zip
Reviewed-by: chegar

! src/share/classes/java/util/zip/ZipEntry.java



From rob.mckenna at oracle.com  Tue Aug 13 18:09:34 2013
From: rob.mckenna at oracle.com (rob.mckenna at oracle.com)
Date: Tue, 13 Aug 2013 18:09:34 +0000
Subject: hg: jdk8/tl/jdk: 5049299: (process) Use posix_spawn, not fork,
	on S10 to avoid swap exhaustion
Message-ID: <20130813181025.5211F4882B@hg.openjdk.java.net>

Changeset: a4b0be7341ef
Author:    robm
Date:      2013-08-13 19:10 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a4b0be7341ef

5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion
Reviewed-by: alanb, dholmes, martin, erikj, coffeys

! make/java/java/Exportedfiles.gmk
! make/java/java/Makefile
! makefiles/CompileLaunchers.gmk
! makefiles/CompileNativeLibraries.gmk
! src/solaris/classes/java/lang/UNIXProcess.java.bsd
! src/solaris/classes/java/lang/UNIXProcess.java.linux
! src/solaris/classes/java/lang/UNIXProcess.java.solaris
! src/solaris/native/java/lang/UNIXProcess_md.c
+ src/solaris/native/java/lang/childproc.c
+ src/solaris/native/java/lang/childproc.h
+ src/solaris/native/java/lang/jspawnhelper.c
! test/java/lang/ProcessBuilder/Basic.java



From brent.christian at oracle.com  Tue Aug 13 19:05:28 2013
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 13 Aug 2013 12:05:28 -0700
Subject: RFR 8022259 MakeClasslist tool is buggy and its README is out
	of date.
In-Reply-To: <5209020E.2050506@oracle.com>
References: <5202A528.5060504@oracle.com> <5208A0F7.2000003@oracle.com>
	<5208E282.1090209@oracle.com> <5209020E.2050506@oracle.com>
Message-ID: <520A8378.7040305@oracle.com>

On 8/12/13 8:41 AM, Alan Bateman wrote:
> On 12/08/2013 14:26, harold seigel wrote:
>>
>> The change to the MakeClasslist tool to use TraceClassLoadingPreorder
>> was made prior to my changes.  The following code has been in
>> MakeClasslist.java for a long time.  I was unable to determine who had
>> made this change or why.
>>
>>             // Understand only "Loading" from
>> -XX:+TraceClassLoadingPreorder.
>>             // This ignores old "Loaded" from -verbose:class to force
>> correct
>>             // classlist generation on Mustang.
>>             if (t.equals("Loading")) {
>>               t = tok.nextToken();
>>               t = t.replace('.', '/');
>>
>> So, I don't know why TraceClassLoadingPreorder was chosen instead of
>> -verbose:class or TraceClassLoading.
>>
>> The purpose of my changes are to update the comments to accurately
>> reflect what the code currently does and to fix a bug in
>> MakeClasslist.java's 'for' loop where the wrong set of strings is used.
>>
> Okay, I see this was changed to use TraceClassLoadingPreorder in 2006
> (prior to OpenJDK). Brent might know more about the history.

I know that for a long while, -verbose:class output was used to generate 
the classlist.  I did some digging...

In JDK 6, we started using TraceClassLoadingPreorder because it helped 
line things up better for cold start [1] - better order of disk reads, 
cut down on seeks, etc.  I myself am not familiar with the details of 
how this was made to work.

There was a short-lived version of MakeClasslist that understood output 
from both -verbose:class and -XX:+TraceClassLoadingPreorder.   The 
nightly build scripts at the time were used for building both JDK 5 & 
JDK 6 trains, so it had to work with both.

Later, support for -verbose:class was removed to ensure that the 
classlist for 6+ was always created based on TraceClassLoadingPreorder, 
to be sure we'd get the cold start benefit.

So that's what the comment about ignoring -verbose:class output is about.

-Brent

[1] http://bugs.sun.com/view_bug.do?bug_id=6449635 : "Optimize shared 
archive object ordering for better cold startup performance"


From roger.riggs at oracle.com  Tue Aug 13 19:06:32 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Tue, 13 Aug 2013 15:06:32 -0400
Subject: Please review java.util.formatter bug fix
Message-ID: <520A83B8.4080502@oracle.com>

Hi,

The tests for java.util.Formatter were failing in the th_TH locale.
The test incorrectly relied on the locale defined calendar instantiation.
Java.util.formatter should be using YEAR_OF_ERA to extract the year
to get consistent results with the Japanese Calendar, for the other
calendars it does not change the values.
The tests are extended to explicitly test the Gregorian, Japanese, and
ThaiBuddist calendar formatting using both the Java.util.Calendar and
ChronoZonedDateTime calendars.

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-fixed-locale-8022193/

Thanks, Roger



From dl at cs.oswego.edu  Tue Aug 13 19:54:52 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Tue, 13 Aug 2013 15:54:52 -0400
Subject: Possible HashMap update
In-Reply-To: <9F896672-012F-40A7-B7A3-AF9823CF7BB9@oracle.com>
References: <51D4ABDA.7010801@cs.oswego.edu> <51DAD99F.9030705@cs.oswego.edu>
	<9F896672-012F-40A7-B7A3-AF9823CF7BB9@oracle.com>
Message-ID: <520A8F0C.2070503@cs.oswego.edu>

On 08/12/13 16:30, Mike Duigou wrote:
> Hi Doug;
>
> Several minor recent cleanups and proposed cleanups in HashMap made me wonder how things are progressing on this work. Do you feel it's nearly ready to integrate into the jdk8 repos? What additional work remains? Are you tracking changes going in to the jdk8 repos?
>

While I haven't touched it lately (I've been distracted with a
lot of other things), last I left it, it seemed integratable.
I haven't seen any list traffic that seems applicable,
except for Remi's, that I ought to reply to...

>
>> I've noticed that Doug's version doesn't have the patch from Igor Gerasimov that
>> use Integer.highestOneBit to find the power of two.

It uses the same efficient tableSizeFor method CHM has used for a decade.
Why mess with success? :-)

>>
>> And that the iterators on entrySet, keySet and values doesn't have their method
>> forEachRemaining overriden
>> (unlike java.util.ArrayList).

Are you saying that all iterators should define forEachRemaining?
Seems excessive.

-Doug




> Mike
>
> On Jul 8 2013, at 08:24 , Doug Lea wrote:
>
>>
>> On 07/05/13 04:55, Paul Sandoz wrote:
>>>> I played with these in the lambda repo.
>>>>
>>>> I needed to make the following additional change for things to compile:
>>>>
>>>> --- a/src/share/classes/java/io/ExpiringCache.java    Fri Jul 05 10:04:00 2013 +0200
>>>> +++ b/src/share/classes/java/io/ExpiringCache.java    Fri Jul 05 10:45:10 2013 +0200
>>>> ...
>>
>> Thanks to those chasing this down, now recorded as a CR at:
>>   http://bugs.sun.com/view_bug.do?bug_id=8017219
>>
>> Some might think this is a fun javac corner case to read about,
>> but for present purposes, the moral is that the name of
>> the internal LinkedHashMap.Entry class, even though it is never
>> exported, cannot be changed without impacting re-compilability of
>> some external usages. Fine. We can cope.
>>
>> For people still following along, see updates at...
>>
>> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/dl/java/util/HashMap.java?view=log
>>
>> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/dl/java/util/LinkedHashMap.java?view=log
>
>



From cs at schulte.it  Tue Aug 13 20:12:01 2013
From: cs at schulte.it (Christian Schulte)
Date: Tue, 13 Aug 2013 22:12:01 +0200
Subject: MIME-Type inquiry.
Message-ID: <520A9311.7000500@schulte.it>

Hello,

are there any well-known MIME types recommended to be used for:

1. java.text.MessageFormat: MessageFormatPattern
2. java.util.Formatter: Format String Syntax
3. Javadoc

?

Regards,
-- 
Christian



From xueming.shen at oracle.com  Tue Aug 13 20:16:12 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 13 Aug 2013 13:16:12 -0700
Subject: Please review java.util.formatter bug fix
In-Reply-To: <520A83B8.4080502@oracle.com>
References: <520A83B8.4080502@oracle.com>
Message-ID: <520A940C.3050600@oracle.com>

Looks fine.

Since you have already turned the verbose off and reduced the locales, it
might be worth still letting it run N=12. The original idea with 12 is that
it increases the chance of running into daylight saving on and off cases.

-Sherman

On 08/13/2013 12:06 PM, roger riggs wrote:
> Hi,
>
> The tests for java.util.Formatter were failing in the th_TH locale.
> The test incorrectly relied on the locale defined calendar instantiation.
> Java.util.formatter should be using YEAR_OF_ERA to extract the year
> to get consistent results with the Japanese Calendar, for the other
> calendars it does not change the values.
> The tests are extended to explicitly test the Gregorian, Japanese, and
> ThaiBuddist calendar formatting using both the Java.util.Calendar and
> ChronoZonedDateTime calendars.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-fixed-locale-8022193/
>
> Thanks, Roger
>



From roger.riggs at oracle.com  Tue Aug 13 20:47:34 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Tue, 13 Aug 2013 16:47:34 -0400
Subject: Please review java.util.formatter bug fix
In-Reply-To: <520A940C.3050600@oracle.com>
References: <520A83B8.4080502@oracle.com> <520A940C.3050600@oracle.com>
Message-ID: <520A9B66.8020109@oracle.com>

HI Sherman,

Thanks for the review, I should have restored N=12 after debugging;
the previous  non-error output was hiding what I needed to see.

If we want to hit DST changes then blanketing 2/3 weeks or weekends
in the spring or fall might have a greater chance of a hit then 12/365.

Thanks, Roger

On 8/13/2013 4:16 PM, Xueming Shen wrote:
> Looks fine.
>
> Since you have already turned the verbose off and reduced the locales, it
> might be worth still letting it run N=12. The original idea with 12 is 
> that
> it increases the chance of running into daylight saving on and off cases.
>
> -Sherman
>
> On 08/13/2013 12:06 PM, roger riggs wrote:
>> Hi,
>>
>> The tests for java.util.Formatter were failing in the th_TH locale.
>> The test incorrectly relied on the locale defined calendar 
>> instantiation.
>> Java.util.formatter should be using YEAR_OF_ERA to extract the year
>> to get consistent results with the Japanese Calendar, for the other
>> calendars it does not change the values.
>> The tests are extended to explicitly test the Gregorian, Japanese, and
>> ThaiBuddist calendar formatting using both the Java.util.Calendar and
>> ChronoZonedDateTime calendars.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-fixed-locale-8022193/
>>
>> Thanks, Roger
>>
>



From forax at univ-mlv.fr  Tue Aug 13 20:56:59 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 13 Aug 2013 22:56:59 +0200
Subject: Possible HashMap update
In-Reply-To: <520A8F0C.2070503@cs.oswego.edu>
References: <51D4ABDA.7010801@cs.oswego.edu> <51DAD99F.9030705@cs.oswego.edu>
	<9F896672-012F-40A7-B7A3-AF9823CF7BB9@oracle.com>
	<520A8F0C.2070503@cs.oswego.edu>
Message-ID: <520A9D9B.6010303@univ-mlv.fr>

On 08/13/2013 09:54 PM, Doug Lea wrote:
> On 08/12/13 16:30, Mike Duigou wrote:
>> Hi Doug;
>>
>> Several minor recent cleanups and proposed cleanups in HashMap made 
>> me wonder how things are progressing on this work. Do you feel it's 
>> nearly ready to integrate into the jdk8 repos? What additional work 
>> remains? Are you tracking changes going in to the jdk8 repos?
>>
>
> While I haven't touched it lately (I've been distracted with a
> lot of other things), last I left it, it seemed integratable.
> I haven't seen any list traffic that seems applicable,
> except for Remi's, that I ought to reply to...
>
>>
>>> I've noticed that Doug's version doesn't have the patch from Igor 
>>> Gerasimov that
>>> use Integer.highestOneBit to find the power of two.
>
> It uses the same efficient tableSizeFor method CHM has used for a decade.
> Why mess with success? :-)

I've checked, Integer.highestOneBit is not an intrinsic, and uses the 
same trick, so I agree :)

>
>>>
>>> And that the iterators on entrySet, keySet and values doesn't have 
>>> their method
>>> forEachRemaining overriden
>>> (unlike java.util.ArrayList).
>
> Are you saying that all iterators should define forEachRemaining?
> Seems excessive.

All iterators for ArrayList, HashMap and their views should have 
forEachRemaining,
I don't care about the other collections :)

forEachRemaining internally use local variables instead of fields as the 
traditional iterator does,
so it may be faster than a plain old iterator loop. Moreover, the call 
to the Consumer inside
the default method defined in Iterable can be megamorphic,
if each iterator's view have they own implementation, you create a 
several of different callsites
(I know, I know, it's a kind of poor's man optimization) that mitigates 
the profile pollution problem.

>
> -Doug

R?mi

>
>
>
>
>> Mike
>>
>> On Jul 8 2013, at 08:24 , Doug Lea wrote:
>>
>>>
>>> On 07/05/13 04:55, Paul Sandoz wrote:
>>>>> I played with these in the lambda repo.
>>>>>
>>>>> I needed to make the following additional change for things to 
>>>>> compile:
>>>>>
>>>>> --- a/src/share/classes/java/io/ExpiringCache.java    Fri Jul 05 
>>>>> 10:04:00 2013 +0200
>>>>> +++ b/src/share/classes/java/io/ExpiringCache.java    Fri Jul 05 
>>>>> 10:45:10 2013 +0200
>>>>> ...
>>>
>>> Thanks to those chasing this down, now recorded as a CR at:
>>>   http://bugs.sun.com/view_bug.do?bug_id=8017219
>>>
>>> Some might think this is a fun javac corner case to read about,
>>> but for present purposes, the moral is that the name of
>>> the internal LinkedHashMap.Entry class, even though it is never
>>> exported, cannot be changed without impacting re-compilability of
>>> some external usages. Fine. We can cope.
>>>
>>> For people still following along, see updates at...
>>>
>>> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/dl/java/util/HashMap.java?view=log 
>>>
>>>
>>> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/dl/java/util/LinkedHashMap.java?view=log 
>>>
>>
>>
>



From joe.darcy at oracle.com  Tue Aug 13 21:18:41 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 13 Aug 2013 14:18:41 -0700
Subject: Possible HashMap update
In-Reply-To: <520A8F0C.2070503@cs.oswego.edu>
References: <51D4ABDA.7010801@cs.oswego.edu> <51DAD99F.9030705@cs.oswego.edu>
	<9F896672-012F-40A7-B7A3-AF9823CF7BB9@oracle.com>
	<520A8F0C.2070503@cs.oswego.edu>
Message-ID: <520AA2B1.1030507@oracle.com>

Hi Doug,

On 08/13/2013 12:54 PM, Doug Lea wrote:
> On 08/12/13 16:30, Mike Duigou wrote:
>> Hi Doug;
>>
>> Several minor recent cleanups and proposed cleanups in HashMap made 
>> me wonder how things are progressing on this work. Do you feel it's 
>> nearly ready to integrate into the jdk8 repos? What additional work 
>> remains? Are you tracking changes going in to the jdk8 repos?
>>
>
> While I haven't touched it lately (I've been distracted with a
> lot of other things), last I left it, it seemed integratable.
> I haven't seen any list traffic that seems applicable,
> except for Remi's, that I ought to reply to...

Have you seen the patch from Dan Smith which would revolve all the javac 
lint warnings in HashMap?

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019618.html

Thanks,

-Joe



From lana.steuck at oracle.com  Wed Aug 14 02:47:11 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 14 Aug 2013 02:47:11 +0000
Subject: hg: jdk8/tl/nashorn: 3 new changesets
Message-ID: <20130814024719.4B06448856@hg.openjdk.java.net>

Changeset: 795cff5c1b5c
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/795cff5c1b5c

Added tag jdk8-b102 for changeset e966ff0a3ffe

! .hgtags

Changeset: 414203de4374
Author:    lana
Date:      2013-08-13 10:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/414203de4374

Merge


Changeset: 8ecf68b292d0
Author:    lana
Date:      2013-08-13 18:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8ecf68b292d0

Merge




From lana.steuck at oracle.com  Wed Aug 14 02:47:11 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 14 Aug 2013 02:47:11 +0000
Subject: hg: jdk8/tl/jaxp: 2 new changesets
Message-ID: <20130814024727.1676748858@hg.openjdk.java.net>

Changeset: b1ceab582fc6
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b1ceab582fc6

Added tag jdk8-b102 for changeset 7cffafa606e9

! .hgtags

Changeset: 9800647936dd
Author:    lana
Date:      2013-08-13 18:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/9800647936dd

Merge




From lana.steuck at oracle.com  Wed Aug 14 02:47:03 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 14 Aug 2013 02:47:03 +0000
Subject: hg: jdk8/tl/corba: 2 new changesets
Message-ID: <20130814024709.852E048855@hg.openjdk.java.net>

Changeset: f8ed09af1df6
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/f8ed09af1df6

Added tag jdk8-b102 for changeset 528c7e76eaee

! .hgtags

Changeset: 49c4a777fdfd
Author:    lana
Date:      2013-08-13 10:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/49c4a777fdfd

Merge




From lana.steuck at oracle.com  Wed Aug 14 02:47:08 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 14 Aug 2013 02:47:08 +0000
Subject: hg: jdk8/tl: Added tag jdk8-b102 for changeset 5eb3c1dc348f
Message-ID: <20130814024709.7C73148854@hg.openjdk.java.net>

Changeset: b7e64be81c8a
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/b7e64be81c8a

Added tag jdk8-b102 for changeset 5eb3c1dc348f

! .hgtags



From lana.steuck at oracle.com  Wed Aug 14 02:47:11 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 14 Aug 2013 02:47:11 +0000
Subject: hg: jdk8/tl/langtools: 3 new changesets
Message-ID: <20130814024733.007B548859@hg.openjdk.java.net>

Changeset: 6718df4cd616
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6718df4cd616

Added tag jdk8-b102 for changeset 453a305e1165

! .hgtags

Changeset: 76cfe7c61f25
Author:    lana
Date:      2013-08-13 10:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/76cfe7c61f25

Merge


Changeset: 32b6a99cc74e
Author:    lana
Date:      2013-08-13 18:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/32b6a99cc74e

Merge




From lana.steuck at oracle.com  Wed Aug 14 02:47:20 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 14 Aug 2013 02:47:20 +0000
Subject: hg: jdk8/tl/hotspot: 25 new changesets
Message-ID: <20130814024823.802374885A@hg.openjdk.java.net>

Changeset: b9a927798f12
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b9a927798f12

Added tag jdk8-b102 for changeset c4697c1c4484

! .hgtags

Changeset: 79ce055063e9
Author:    amurillo
Date:      2013-08-02 03:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/79ce055063e9

8022124: new hotspot build - hs25-b45
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 9bd314787fad
Author:    mseledtsov
Date:      2013-08-01 22:15 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9bd314787fad

8020614: OutputAnalyzer.shouldHaveExitValue() should print stdout/stderr output
Summary: OutputAnalyzer.shouldHaveExitValue() should print stdout/stderr output
Reviewed-by: kvn, ctornqvi, dholmes

+ test/testlibrary/OutputAnalyzerReportingTest.java
! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java
! test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java

Changeset: c01913206da5
Author:    ctornqvi
Date:      2013-08-01 22:20 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c01913206da5

8014294: Assert in ThreadTimesClosure::do_thread() due to use of naked oop instead of handle
Summary: Assert in ThreadTimesClosure::do_thread() due to use of naked oop instead of handle
Reviewed-by: coleenp, sspitsyn

! src/share/vm/services/management.cpp

Changeset: 81e0f17ade64
Author:    ctornqvi
Date:      2013-08-01 22:25 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/81e0f17ade64

8009407: runtime/8000968/Test8000968.sh has incorrect check for proper config
Summary: runtime/8000968/Test8000968.sh has incorrect check for proper config
Reviewed-by: coleenp, mseledtsov, sspitsyn, hseigel

- test/runtime/8000968/Test8000968.sh
+ test/runtime/CompressedOops/CompressedKlassPointerAndOops.java

Changeset: 32e3bada0978
Author:    kevinw
Date:      2013-08-02 12:26 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/32e3bada0978

8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str()
Reviewed-by: mgerdin, fparain, dcubed

! src/share/vm/services/gcNotifier.cpp

Changeset: dee4c330acd4
Author:    dcubed
Date:      2013-08-02 08:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dee4c330acd4

Merge

- test/runtime/8000968/Test8000968.sh

Changeset: fa57c8104b76
Author:    ctornqvi
Date:      2013-08-02 18:12 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fa57c8104b76

8009585: test/runtime/7196045 times out
Summary: test/runtime/7196045 times out
Reviewed-by: dholmes, mseledtsov

- test/runtime/7196045/Test7196045.java
+ test/runtime/InternalApi/ThreadCpuTimesDeadlock.java

Changeset: 0f209afdfcf8
Author:    ctornqvi
Date:      2013-08-02 18:26 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0f209afdfcf8

Merge


Changeset: d02de8cac823
Author:    ctornqvi
Date:      2013-08-02 22:34 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d02de8cac823

Merge

- test/runtime/7196045/Test7196045.java

Changeset: e0379d5ba5d2
Author:    kevinw
Date:      2013-08-05 10:27 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e0379d5ba5d2

8021444: SA: ClassDump.run() should not ignore existing ClassFilter.
Reviewed-by: minqi, poonam

! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java

Changeset: b67604b59546
Author:    hseigel
Date:      2013-08-04 16:30 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b67604b59546

7073961: [TESTBUG] closed/runtime/4845371/DBB.java failed on solaris 10 X65
Summary: Added a x86 64-bit Solaris shared library and rewrote test in Java
Reviewed-by: dholmes, ctornqvi

! test/testlibrary/com/oracle/java/testlibrary/Platform.java

Changeset: 9064e3a19525
Author:    hseigel
Date:      2013-08-05 08:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9064e3a19525

Merge

- test/runtime/7196045/Test7196045.java
- test/runtime/8000968/Test8000968.sh

Changeset: 22a5aff0df0b
Author:    dsamersoff
Date:      2013-08-06 14:28 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/22a5aff0df0b

8019396: SA-JDI OSThread class initialization throws an exception
Summary: Method sun.jvm.hotspot.runtime.OSThread.initialize throws a sun.jvm.hotspot.types.WrongTypeException
Reviewed-by: dholmes, mgerdin

! agent/src/share/classes/sun/jvm/hotspot/jdi/JVMTIThreadState.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/OSThread.java

Changeset: cd25d3be91c5
Author:    vladidan
Date:      2013-08-06 20:01 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd25d3be91c5

8012144: multiple SIGSEGVs fails on staxf
Summary: Forward port of 7u change to add additional fence() on RMO platforms, with a load_acquire on all platforms
Reviewed-by: dholmes, kvn

! src/share/vm/utilities/taskqueue.hpp

Changeset: f5bed20f2492
Author:    dholmes
Date:      2013-08-08 08:29 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f5bed20f2492

Merge


Changeset: 79a5283f4595
Author:    iignatyev
Date:      2013-07-29 11:54 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/79a5283f4595

8021120: TieredCompilation can be enabled even if TIERED is undefined
Reviewed-by: kvn, dholmes

! src/share/vm/runtime/arguments.cpp

Changeset: 8d77d02828d9
Author:    twisti
Date:      2013-07-29 16:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8d77d02828d9

8016474: Crash in sun.reflect.UnsafeObjectFieldAccessorImpl.get
Summary: C1's GetUnsafeObject G1 pre-barrier uses the wrong type to read the klass pointer.
Reviewed-by: iveresov, kvn

! src/share/vm/c1/c1_LIRGenerator.cpp
+ test/compiler/unsafe/GetUnsafeObjectG1PreBarrier.java

Changeset: 446cb5d25d03
Author:    anoll
Date:      2013-08-01 16:01 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/446cb5d25d03

8020531: Test compiler/codecache/CheckUpperLimit.java fails when memory limited
Summary: Removed part of the test that required the VM to start up with -XX:ReservedCodeCacheSize=2048m
Reviewed-by: kvn, rbackman

! test/compiler/codecache/CheckUpperLimit.java

Changeset: 6e04c193845f
Author:    anoll
Date:      2013-08-02 10:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6e04c193845f

8021301: better event messages
Summary: made event messages better readable
Reviewed-by: kvn, rbackman

! src/share/vm/classfile/classLoader.cpp
! src/share/vm/utilities/exceptions.cpp

Changeset: 5e0b3d7df485
Author:    rbackman
Date:      2013-08-05 17:15 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5e0b3d7df485

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: 71526a36ebb4
Author:    twisti
Date:      2013-08-05 15:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/71526a36ebb4

8022029: GetUnsafeObjectG1PreBarrier fails on 32-bit with: Unrecognized VM option 'ObjectAlignmentInBytes=32'
Reviewed-by: kvn

! test/compiler/unsafe/GetUnsafeObjectG1PreBarrier.java

Changeset: dadf62510ae4
Author:    rbackman
Date:      2013-08-08 23:49 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dadf62510ae4

Merge


Changeset: 7f55137d6aa8
Author:    amurillo
Date:      2013-08-09 01:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7f55137d6aa8

Merge

- test/runtime/7196045/Test7196045.java
- test/runtime/8000968/Test8000968.sh

Changeset: 6f9be7f87b96
Author:    amurillo
Date:      2013-08-09 01:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6f9be7f87b96

Added tag hs25-b45 for changeset 7f55137d6aa8

! .hgtags



From lana.steuck at oracle.com  Wed Aug 14 02:47:11 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 14 Aug 2013 02:47:11 +0000
Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b102 for changeset 988a5f2ac559
Message-ID: <20130814024722.7F86B48857@hg.openjdk.java.net>

Changeset: 6cdc6ed98780
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/6cdc6ed98780

Added tag jdk8-b102 for changeset 988a5f2ac559

! .hgtags



From lana.steuck at oracle.com  Wed Aug 14 02:48:48 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 14 Aug 2013 02:48:48 +0000
Subject: hg: jdk8/tl/jdk: 21 new changesets
Message-ID: <20130814025338.ABC014885B@hg.openjdk.java.net>

Changeset: e057cddf0d6c
Author:    cl
Date:      2013-08-08 10:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e057cddf0d6c

Added tag jdk8-b102 for changeset 8ed8e2b4b90e

! .hgtags

Changeset: 1c6bfb303ffc
Author:    prr
Date:      2013-08-06 13:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c6bfb303ffc

8022175: Fix doclint warnings in javax.print
Reviewed-by: darcy

! src/share/classes/javax/print/DocFlavor.java
! src/share/classes/javax/print/MultiDocPrintJob.java
! src/share/classes/javax/print/PrintService.java
! src/share/classes/javax/print/ServiceUI.java
! src/share/classes/javax/print/ServiceUIFactory.java
! src/share/classes/javax/print/attribute/AttributeSet.java
! src/share/classes/javax/print/attribute/DateTimeSyntax.java
! src/share/classes/javax/print/attribute/DocAttributeSet.java
! src/share/classes/javax/print/attribute/EnumSyntax.java
! src/share/classes/javax/print/attribute/HashAttributeSet.java
! src/share/classes/javax/print/attribute/IntegerSyntax.java
! src/share/classes/javax/print/attribute/PrintJobAttributeSet.java
! src/share/classes/javax/print/attribute/PrintRequestAttributeSet.java
! src/share/classes/javax/print/attribute/PrintServiceAttributeSet.java
! src/share/classes/javax/print/attribute/ResolutionSyntax.java
! src/share/classes/javax/print/attribute/Size2DSyntax.java
! src/share/classes/javax/print/attribute/standard/Chromaticity.java
! src/share/classes/javax/print/attribute/standard/Compression.java
! src/share/classes/javax/print/attribute/standard/Finishings.java
! src/share/classes/javax/print/attribute/standard/JobKOctets.java
! src/share/classes/javax/print/attribute/standard/MediaPrintableArea.java
! src/share/classes/javax/print/attribute/standard/MediaSize.java
! src/share/classes/javax/print/attribute/standard/PresentationDirection.java
! src/share/classes/javax/print/attribute/standard/PrinterMoreInfoManufacturer.java
! src/share/classes/javax/print/attribute/standard/PrinterResolution.java

Changeset: c3b91dc2504a
Author:    jgodinez
Date:      2013-08-06 14:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c3b91dc2504a

8021583: test/javax/print/autosense/PrintAutoSenseData.java throwing NPE
Reviewed-by: jchen, prr

! src/solaris/classes/sun/print/UnixPrintJob.java
! src/windows/classes/sun/print/Win32PrintJob.java
! test/javax/print/attribute/autosense/PrintAutoSenseData.java
+ test/javax/print/attribute/autosense/sample.txt

Changeset: fe04f40cf469
Author:    prr
Date:      2013-08-06 17:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe04f40cf469

8022455: Fix doclint warnings in javax.imageio
Reviewed-by: darcy

! src/share/classes/javax/imageio/ImageIO.java
! src/share/classes/javax/imageio/ImageReadParam.java
! src/share/classes/javax/imageio/ImageReader.java
! src/share/classes/javax/imageio/ImageTypeSpecifier.java
! src/share/classes/javax/imageio/ImageWriteParam.java
! src/share/classes/javax/imageio/ImageWriter.java
! src/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java
! src/share/classes/javax/imageio/plugins/bmp/BMPImageWriteParam.java
! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageReadParam.java
! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageWriteParam.java
! src/share/classes/javax/imageio/spi/ImageReaderSpi.java
! src/share/classes/javax/imageio/spi/ImageWriterSpi.java
! src/share/classes/javax/imageio/spi/ServiceRegistry.java
! src/share/classes/javax/imageio/stream/ImageInputStream.java
! src/share/classes/javax/imageio/stream/ImageInputStreamImpl.java
! src/share/classes/javax/imageio/stream/ImageOutputStream.java

Changeset: c827ad8c1101
Author:    prr
Date:      2013-08-06 17:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c827ad8c1101

8022447: Fix doclint warnings in java.awt.image
Reviewed-by: darcy

! src/share/classes/java/awt/image/BufferStrategy.java
! src/share/classes/java/awt/image/BufferedImage.java
! src/share/classes/java/awt/image/ByteLookupTable.java
! src/share/classes/java/awt/image/ColorModel.java
! src/share/classes/java/awt/image/DirectColorModel.java
! src/share/classes/java/awt/image/ImageProducer.java
! src/share/classes/java/awt/image/IndexColorModel.java
! src/share/classes/java/awt/image/MemoryImageSource.java
! src/share/classes/java/awt/image/MultiPixelPackedSampleModel.java
! src/share/classes/java/awt/image/PixelGrabber.java
! src/share/classes/java/awt/image/RGBImageFilter.java
! src/share/classes/java/awt/image/ShortLookupTable.java
! src/share/classes/java/awt/image/SinglePixelPackedSampleModel.java
! src/share/classes/java/awt/image/WritableRaster.java

Changeset: 9314c199003d
Author:    lana
Date:      2013-08-06 22:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9314c199003d

Merge

- src/share/classes/java/net/package.html

Changeset: ab64c138d5bd
Author:    prr
Date:      2013-08-07 18:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ab64c138d5bd

8014883: java.awt.container.add(component comp object constraints) doesn't work as expected on some linux platforms
Reviewed-by: jgodinez

! makefiles/CompileNativeLibraries.gmk
! src/solaris/native/sun/java2d/x11/XRBackendNative.c

Changeset: 645a37a3559f
Author:    leonidr
Date:      2013-08-01 01:26 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/645a37a3559f

8021815: Add regression test for JDK-8007267
Reviewed-by: serb

+ test/com/apple/eawt/DefaultMenuBar/DefaultMenuBarTest.java

Changeset: 495ca130cbde
Author:    alexsch
Date:      2013-08-01 17:09 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/495ca130cbde

7161568: [macosx] api/javax_swing/JTabbedPane/index2.html#varios fails
Reviewed-by: malenkov, serb

! src/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java
! src/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java
+ test/javax/swing/JTabbedPane/4361477/bug4361477.java
+ test/javax/swing/JTabbedPane/6495408/bug6495408.java
+ test/javax/swing/JTabbedPane/7161568/bug7161568.java

Changeset: e76b1568d002
Author:    leonidr
Date:      2013-08-02 15:42 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e76b1568d002

8021381: JavaFX scene included in Swing JDialog not starting from Web Start
Reviewed-by: art, dcherepanov

! src/share/classes/sun/awt/AppContext.java

Changeset: 07abddc1d7f2
Author:    leonidr
Date:      2013-08-06 17:07 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07abddc1d7f2

8022247: java/awt/EventDispatchThread/LoopRobustness/LoopRobustness throws NPE
Reviewed-by: art

! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java

Changeset: 27d1bdf2f7d9
Author:    mcherkas
Date:      2013-08-06 17:29 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27d1bdf2f7d9

8016833: Underlines and strikethrough not rendering correctly
Reviewed-by: alexsch, serb
Contributed-by: anton.nashatyrev at oracle.com

! src/share/classes/javax/swing/text/GlyphView.java
+ test/javax/swing/text/StyledEditorKit/8016833/bug8016833.java

Changeset: f8ed88f5ed87
Author:    alexsch
Date:      2013-08-07 18:32 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8ed88f5ed87

8022532: [parfait] Potential memory leak in gtk2_interface.c
Reviewed-by: art, serb

! src/solaris/native/sun/awt/gtk2_interface.c

Changeset: 7706a622d35f
Author:    alexsch
Date:      2013-08-07 18:58 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7706a622d35f

8013849: Awt assert on Hashtable.cpp:124
Reviewed-by: serb

! src/windows/native/sun/windows/awt_Component.cpp
+ test/java/awt/event/KeyEvent/DeadKey/DeadKeySystemAssertionDialog.java

Changeset: f70492d969e7
Author:    serb
Date:      2013-08-07 19:57 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f70492d969e7

7124339: [macosx] setIconImage is not endlessly tolerant to the broken image-arguments
Reviewed-by: alexsch, leonidr

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java

Changeset: 540192229a69
Author:    art
Date:      2013-08-07 21:31 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/540192229a69

6551589: ContainerListener Documentation may be incorrect
Reviewed-by: serb

! src/share/classes/java/awt/event/ContainerListener.java

Changeset: 9bcc3f2af980
Author:    lana
Date:      2013-08-07 12:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9bcc3f2af980

Merge

- src/share/classes/java/net/package.html

Changeset: e193c4ad940a
Author:    lana
Date:      2013-08-07 19:52 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e193c4ad940a

Merge


Changeset: 23e68a8e4b91
Author:    lana
Date:      2013-08-07 19:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23e68a8e4b91

Merge

- test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java
- test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh

Changeset: e0f6039c0290
Author:    lana
Date:      2013-08-13 10:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0f6039c0290

Merge


Changeset: 18ce880b5fb4
Author:    lana
Date:      2013-08-13 18:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18ce880b5fb4

Merge

! makefiles/CompileNativeLibraries.gmk



From pbouchard8 at gmail.com  Wed Aug 14 03:08:02 2013
From: pbouchard8 at gmail.com (Phil Bouchard)
Date: Tue, 13 Aug 2013 23:08:02 -0400
Subject: Deterministic memory manager of constant complexity
Message-ID: <520AF492.6080809@gmail.com>

Hello,

I am a software engineer who wrote the following:
http://finitetheory.com/author.html

I would like to propose Java a new deterministic memory manager of constant complexity that will make applications run smoothly and never to lag again.  Its documentation is available at:
https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/index.html

As a practical example, the applications on the Android will run much better.


Sincerely yours,
Phil Bouchard



From thomas.schatzl at oracle.com  Wed Aug 14 09:19:30 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 14 Aug 2013 11:19:30 +0200
Subject: [Fwd: Missing merge for 8014890: Reference queues may return more
	entries than expected]
Message-ID: <1376471970.2828.41.camel@cirrus>

Hi all,

  could somebody take care of the missing merge for the fix below?

Thanks,
Thomas

-------- Forwarded Message --------
> From: Thomas Schatzl 
> To: mandy.chung at oracle.com
> Subject: Missing merge for 8014890: Reference queues may return more
> entries than expected
> Date: Wed, 07 Aug 2013 09:47:30 +0200
> 
> Hi Mandy,
> 
>   while checking out latest sources, I saw that the commit for that
> patch has not been merged to the default branch in the repository. It
> represents its own head.
> 
> Could you fix this?
> 
> Here's the relevant hg output:
> 
> $ hg heads
> changeset:   7764:8ed8e2b4b90e
> tag:         tip
> parent:      7763:0741b19835b0
> parent:      7692:b52a2ecdb803
> user:        lana
> date:        Tue Aug 06 10:10:39 2013 -0700
> summary:     Merge
> 
> changeset:   7605:2c04ce2f782c
> user:        mchung
> date:        Mon Jul 08 14:05:59 2013 +0200
> summary:     8014890: (ref) Reference queues may return more entries
> than expected
> 




From Alan.Bateman at oracle.com  Wed Aug 14 09:43:19 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 14 Aug 2013 10:43:19 +0100
Subject: [Fwd: Missing merge for 8014890: Reference queues may return
	more entries than expected]
In-Reply-To: <1376471970.2828.41.camel@cirrus>
References: <1376471970.2828.41.camel@cirrus>
Message-ID: <520B5137.2020203@oracle.com>


Mandy is just back from vacation and might not have got to your mail 
yet. However it's not clear to me that there is an actual problem as it 
looks like you've just ended up with two heads, maybe a hg fetch when 
you had changes where you forgot to merge? As I understand, the hg 
server is setup to limit the heads to 1 so it's not possible for any of 
us to push changes that would result in a new head. Maybe start with a 
fresh clone of jdk8/tl or jdk8/jdk8?

-Alan.


On 14/08/2013 10:19, Thomas Schatzl wrote:
> Hi all,
>
>    could somebody take care of the missing merge for the fix below?
>
> Thanks,
> Thomas
>
> -------- Forwarded Message --------
>> From: Thomas Schatzl
>> To: mandy.chung at oracle.com
>> Subject: Missing merge for 8014890: Reference queues may return more
>> entries than expected
>> Date: Wed, 07 Aug 2013 09:47:30 +0200
>>
>> Hi Mandy,
>>
>>    while checking out latest sources, I saw that the commit for that
>> patch has not been merged to the default branch in the repository. It
>> represents its own head.
>>
>> Could you fix this?
>>
>> Here's the relevant hg output:
>>
>> $ hg heads
>> changeset:   7764:8ed8e2b4b90e
>> tag:         tip
>> parent:      7763:0741b19835b0
>> parent:      7692:b52a2ecdb803
>> user:        lana
>> date:        Tue Aug 06 10:10:39 2013 -0700
>> summary:     Merge
>>
>> changeset:   7605:2c04ce2f782c
>> user:        mchung
>> date:        Mon Jul 08 14:05:59 2013 +0200
>> summary:     8014890: (ref) Reference queues may return more entries
>> than expected
>>
>



From thomas.schatzl at oracle.com  Wed Aug 14 09:56:00 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 14 Aug 2013 11:56:00 +0200
Subject: [Fwd: Missing merge for 8014890: Reference queues may return
	more entries than expected]
In-Reply-To: <520B5137.2020203@oracle.com>
References: <1376471970.2828.41.camel@cirrus> <520B5137.2020203@oracle.com>
Message-ID: <1376474160.2828.56.camel@cirrus>

Hi,

On Wed, 2013-08-14 at 10:43 +0100, Alan Bateman wrote:
> Mandy is just back from vacation and might not have got to your mail 
> yet. However it's not clear to me that there is an actual problem as it 
> looks like you've just ended up with two heads, maybe a hg fetch when 
> you had changes where you forgot to merge? As I understand, the hg 
> server is setup to limit the heads to 1 so it's not possible for any of 
> us to push changes that would result in a new head. Maybe start with a 
> fresh clone of jdk8/tl or jdk8/jdk8?

  I had the impression that I had a fresh checkout at that time, and did
not recheck right now.

A fresh checkout is okay.

Sorry for the noise,
  Thomas



From vicente.romero at oracle.com  Wed Aug 14 09:56:50 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Wed, 14 Aug 2013 09:56:50 +0000
Subject: hg: jdk8/tl/langtools: 8013394: compile of iterator use fails with
	error \"defined in an inaccessible class or interface\"
Message-ID: <20130814095656.1A4184886E@hg.openjdk.java.net>

Changeset: 0ad781399706
Author:    vromero
Date:      2013-08-14 10:53 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0ad781399706

8013394: compile of iterator use fails with error \"defined in an inaccessible class or interface\"
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/T8013394/CompileErrorWithIteratorTest.java



From Alan.Bateman at oracle.com  Wed Aug 14 10:18:16 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 14 Aug 2013 11:18:16 +0100
Subject: Possible HashMap update
In-Reply-To: <520AA2B1.1030507@oracle.com>
References: <51D4ABDA.7010801@cs.oswego.edu> <51DAD99F.9030705@cs.oswego.edu>
	<9F896672-012F-40A7-B7A3-AF9823CF7BB9@oracle.com>
	<520A8F0C.2070503@cs.oswego.edu> <520AA2B1.1030507@oracle.com>
Message-ID: <520B5968.2050302@oracle.com>

On 13/08/2013 22:18, Joe Darcy wrote:
>
> Have you seen the patch from Dan Smith which would revolve all the 
> javac lint warnings in HashMap?
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019618.html 
>
My preference would be to get Doug's update in as soon as we can, mostly 
because the changes are significant and it would be good to get them 
well exercised (and the performance/memory characterized too) before 
jdk8 starts to get locked down. I know the javac lint warnings are 
important but it's lower risk and at least some of the code in the lint 
patch will be replaced. I would expect it would be straight-forward to 
sort out any remaining issues later.

-Alan.


From Alan.Bateman at oracle.com  Wed Aug 14 10:21:16 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 14 Aug 2013 11:21:16 +0100
Subject: RFR 8022898 java/util/Spliterator/SpliteratorCollisions.java
	fails in HashableIntSpliteratorWithNull data provider
In-Reply-To: 
References: 
Message-ID: <520B5A1C.9080506@oracle.com>

On 13/08/2013 14:46, Paul Sandoz wrote:
> Hi,
>
> This patch fixes a bug in the data provider of the SpliteratorCollisions.java test, which was attempting to add an element to an unmodifable map.
>
> Interestingly although this caused the data provider to barf, and therefore tests using such a provider were not run, it did not result in jtreg reporting the test-infrastructure failure.
>
Good catch, I often wonder how often we have cases where a test fails 
but is reported as passed. Anyway, the change looks fine to me too.

-Alan.


From paul.sandoz at oracle.com  Wed Aug 14 10:34:09 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 14 Aug 2013 12:34:09 +0200
Subject: Possible HashMap update
In-Reply-To: <520B5968.2050302@oracle.com>
References: <51D4ABDA.7010801@cs.oswego.edu> <51DAD99F.9030705@cs.oswego.edu>
	<9F896672-012F-40A7-B7A3-AF9823CF7BB9@oracle.com>
	<520A8F0C.2070503@cs.oswego.edu> <520AA2B1.1030507@oracle.com>
	<520B5968.2050302@oracle.com>
Message-ID: 

On Aug 14, 2013, at 12:18 PM, Alan Bateman  wrote:
> On 13/08/2013 22:18, Joe Darcy wrote:
>> 
>> Have you seen the patch from Dan Smith which would revolve all the javac lint warnings in HashMap?
>> 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019618.html 
> My preference would be to get Doug's update in as soon as we can, mostly because the changes are significant and it would be good to get them well exercised (and the performance/memory characterized too) before jdk8 starts to get locked down. I know the javac lint warnings are important but it's lower risk and at least some of the code in the lint patch will be replaced. I would expect it would be straight-forward to sort out any remaining issues later.
> 

+1

If no one else volunteers i can try and sort this out and sync up stuff from the current HashMap/LinkedHashMap (e.g. forEachRem. as reported by Remi) and the lint warnings in one go, and submit for review. 

I do have a vested interest since it fixes another bug related to the incorrect reporting of splitrerator characteristics in LInkedHashMap (they should report ORDERED).

Paul.

From dl at cs.oswego.edu  Wed Aug 14 11:02:39 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 14 Aug 2013 07:02:39 -0400
Subject: Possible HashMap update
In-Reply-To: <520AA2B1.1030507@oracle.com>
References: <51D4ABDA.7010801@cs.oswego.edu> <51DAD99F.9030705@cs.oswego.edu>
	<9F896672-012F-40A7-B7A3-AF9823CF7BB9@oracle.com>
	<520A8F0C.2070503@cs.oswego.edu> <520AA2B1.1030507@oracle.com>
Message-ID: <520B63CF.5000705@cs.oswego.edu>

On 08/13/13 17:18, Joe Darcy wrote:

>> While I haven't touched it lately (I've been distracted with a
>> lot of other things), last I left it, it seemed integratable.
>> I haven't seen any list traffic that seems applicable,
>> except for Remi's, that I ought to reply to...
>
> Have you seen the patch from Dan Smith which would revolve all the javac lint
> warnings in HashMap?
>

I don't think any of these apply.

Courtesy of Martin, we now screen every build/commit for lint and
doclint warnings. I just reran with current version and doclint picked
up a ">" in a "pre". Now fixed.

Aside: What's up with doclint complaining about no comments
on package declarations? Who puts doc comments on package
declarations?


     [javac] /home/dl/concurrent/src/main/java/util/HashMap.java:26: warning: no 
comment
     [javac] package java.util;

-Doug



From dl at cs.oswego.edu  Wed Aug 14 11:16:23 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 14 Aug 2013 07:16:23 -0400
Subject: Possible HashMap update
In-Reply-To: <520A9D9B.6010303@univ-mlv.fr>
References: <51D4ABDA.7010801@cs.oswego.edu> <51DAD99F.9030705@cs.oswego.edu>
	<9F896672-012F-40A7-B7A3-AF9823CF7BB9@oracle.com>
	<520A8F0C.2070503@cs.oswego.edu> <520A9D9B.6010303@univ-mlv.fr>
Message-ID: <520B6707.9020601@cs.oswego.edu>

On 08/13/13 16:56, Remi Forax wrote:
>>>>
>>>> And that the iterators on entrySet, keySet and values doesn't have their method
>>>> forEachRemaining overriden
>>>> (unlike java.util.ArrayList).
>>
>> Are you saying that all iterators should define forEachRemaining?
>> Seems excessive.
>
> All iterators for ArrayList, HashMap and their views should have forEachRemaining,
> I don't care about the other collections :)
>
> forEachRemaining internally use local variables instead of fields as the
> traditional iterator does,
> so it may be faster than a plain old iterator loop. Moreover, the call to the
> Consumer inside
> the default method defined in Iterable can be megamorphic,
> if each iterator's view have they own implementation, you create a several of
> different callsites
> (I know, I know, it's a kind of poor's man optimization) that mitigates the
> profile pollution problem.
>

Could you explain exactly when these trigger? Most Stream-related
operations should pick up spliterator, not iterator, so won't
encounter this.

I resist this a bit because it would require 6 more
methods, each redundant with a spliterator method.
(The HashMap view ones must be overridden in LinkedHashMap.)
But if the situation is common, it might be worthwhile.

-Doug






From Alan.Bateman at oracle.com  Wed Aug 14 12:30:14 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 14 Aug 2013 13:30:14 +0100
Subject: 8022921: Remove experimental Profile attribute
Message-ID: <520B7856.6070008@oracle.com>


As part of the Compact Profiles [1] solution we updated the JAR File 
specification to define a new attribute named "Profile" to allow both 
main application and library JAR files specify the minimum subset 
Profile of Java SE that the code in the JAR file requires.

The Profile attribute has been in for more than 6 months now and on 
reflection it may not be the right thing to do. For starters there has 
been push-back from folks that have license or other reasons that 
prevent them from updating the manifest of main application JAR files. 
Another issue is that the value of the attribute is the minimum subset 
Profile so there isn't a way to specify that the code requires the full 
Java SE platform. Another concern is that it might conflict with future 
direction where we have a way to require standard Java SE or JDK 
modules. So overall I think the best thing is to remove this attribute, 
even though it means the solution doesn't no longer has a way to catch 
mis-matches between the compile time and runtime environments.

The webrev with the changes to remove this attribute are here:

http://cr.openjdk.java.net/~alanb/8022921/webrev/

It should be easy to remove because it's code deletion.  I plan to 
update the JEP so that it reflects the updated solution.

Thanks,
Alan.

[1] http://openjdk.java.net/jeps/161


From Alan.Bateman at oracle.com  Wed Aug 14 12:34:19 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 14 Aug 2013 13:34:19 +0100
Subject: Possible HashMap update
In-Reply-To: <520B63CF.5000705@cs.oswego.edu>
References: <51D4ABDA.7010801@cs.oswego.edu> <51DAD99F.9030705@cs.oswego.edu>
	<9F896672-012F-40A7-B7A3-AF9823CF7BB9@oracle.com>
	<520A8F0C.2070503@cs.oswego.edu> <520AA2B1.1030507@oracle.com>
	<520B63CF.5000705@cs.oswego.edu>
Message-ID: <520B794B.50501@oracle.com>

On 14/08/2013 12:02, Doug Lea wrote:
> :
>
> Aside: What's up with doclint complaining about no comments
> on package declarations? Who puts doc comments on package
> declarations?
>
>
>     [javac] /home/dl/concurrent/src/main/java/util/HashMap.java:26: 
> warning: no comment
>     [javac] package java.util;
I think Jon fixed this one recently:

http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1476d54fdc61

-Alan.


From Roger.Riggs at Oracle.com  Wed Aug 14 13:21:19 2013
From: Roger.Riggs at Oracle.com (Roger RIggs)
Date: Wed, 14 Aug 2013 09:21:19 -0400
Subject: RFR 8022898 java/util/Spliterator/SpliteratorCollisions.java
	fails in HashableIntSpliteratorWithNull data provider
In-Reply-To: <520B5A1C.9080506@oracle.com>
References: 
	<520B5A1C.9080506@oracle.com>
Message-ID: <520B844F.2050101@Oracle.com>

I fixed a jtreg bug a while back when I had a problem with exceptions
in dataProviders. I don't know if it has propagated into the latest 
promotion.

Roger


changeset:   37:ec890bad20b5
user:        jjg
date:        Tue Jul 09 13:16:13 2013 +0100
description:
7900130: Test summary does not show TestNg dataProvider arguments
7900165: Exception in TestNG DataSource does not result in a reported 
test failure
7900112: don't print unnecessary stack traces
Summary: Added formatted parameters to test title reporting;
          If a test is skipped due to an exception report it as a failure
          Skip printing of exception if the test result is success
Contributed-By roger.riggs at oracle.com


On 08/14/2013 06:21 AM, Alan Bateman wrote:
> On 13/08/2013 14:46, Paul Sandoz wrote:
>> Hi,
>>
>> This patch fixes a bug in the data provider of the 
>> SpliteratorCollisions.java test, which was attempting to add an 
>> element to an unmodifable map.
>>
>> Interestingly although this caused the data provider to barf, and 
>> therefore tests using such a provider were not run, it did not result 
>> in jtreg reporting the test-infrastructure failure.
>>
> Good catch, I often wonder how often we have cases where a test fails 
> but is reported as passed. Anyway, the change looks fine to me too.
>
> -Alan.



From forax at univ-mlv.fr  Wed Aug 14 13:23:41 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 14 Aug 2013 15:23:41 +0200
Subject: Possible HashMap update
In-Reply-To: <520B6707.9020601@cs.oswego.edu>
References: <51D4ABDA.7010801@cs.oswego.edu> <51DAD99F.9030705@cs.oswego.edu>
	<9F896672-012F-40A7-B7A3-AF9823CF7BB9@oracle.com>
	<520A8F0C.2070503@cs.oswego.edu> <520A9D9B.6010303@univ-mlv.fr>
	<520B6707.9020601@cs.oswego.edu>
Message-ID: <520B84DD.8030207@univ-mlv.fr>

On 08/14/2013 01:16 PM, Doug Lea wrote:
> On 08/13/13 16:56, Remi Forax wrote:
>>>>>
>>>>> And that the iterators on entrySet, keySet and values doesn't have 
>>>>> their method
>>>>> forEachRemaining overriden
>>>>> (unlike java.util.ArrayList).
>>>
>>> Are you saying that all iterators should define forEachRemaining?
>>> Seems excessive.
>>
>> All iterators for ArrayList, HashMap and their views should have 
>> forEachRemaining,
>> I don't care about the other collections :)
>>
>> forEachRemaining internally use local variables instead of fields as the
>> traditional iterator does,
>> so it may be faster than a plain old iterator loop. Moreover, the 
>> call to the
>> Consumer inside
>> the default method defined in Iterable can be megamorphic,
>> if each iterator's view have they own implementation, you create a 
>> several of
>> different callsites
>> (I know, I know, it's a kind of poor's man optimization) that 
>> mitigates the
>> profile pollution problem.
>>
>
> Could you explain exactly when these trigger? Most Stream-related
> operations should pick up spliterator, not iterator, so won't
> encounter this.

Yes, it's not related to Stream.
I see two obvious scenarios when forEachRemaining should be used.

The first one is bug 6360734 [1], for(:) doesn't support Iterator but 
there are
plenty of methods in the wild that returns an Iterator.
In the JDK, at least
   BeanContextServices.getCurrentServiceClasses(),
   BenContextSupport.bcsChildren() or
   ServiceRegistry.getCategories(),
all return something like map.[views()].iterator()

The second scenario is when you have an algorithm that do something for 
first value
and do something else for the other value, in that case, you need to get 
the iterator,
calls next to get the first value and calls forEachRemaining for 
processing the
remaining values.

>
> I resist this a bit because it would require 6 more
> methods, each redundant with a spliterator method.
> (The HashMap view ones must be overridden in LinkedHashMap.)
> But if the situation is common, it might be worthwhile.

I suppose that it depends on what is your definition of common :)

>
> -Doug
>
>
>
>

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6360734



From kumar.x.srinivasan at oracle.com  Wed Aug 14 14:12:00 2013
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Wed, 14 Aug 2013 14:12:00 +0000
Subject: hg: jdk8/tl/langtools: 8007517: DefaultMethodRegressionTests.java
	fail in TL
Message-ID: <20130814141207.40C9548882@hg.openjdk.java.net>

Changeset: 3ab468194f11
Author:    ksrini
Date:      2013-08-14 07:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3ab468194f11

8007517: DefaultMethodRegressionTests.java fail in TL
Reviewed-by: jjg, vromero

- test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java



From coleen.phillimore at oracle.com  Wed Aug 14 14:22:53 2013
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 14 Aug 2013 14:22:53 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130814142330.58BF748884@hg.openjdk.java.net>

Changeset: cb74d71fd02f
Author:    hseigel
Date:      2013-08-13 10:56 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cb74d71fd02f

8022259: MakeClasslist is buggy and its README is out of date.
Summary: Fixed bug in FOR loop and updated comments and README
Reviewed-by: dholmes, alanb

! make/tools/sharing/README.txt
! make/tools/src/build/tools/makeclasslist/MakeClasslist.java

Changeset: f9cf6ecf596c
Author:    coleenp
Date:      2013-08-14 10:14 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f9cf6ecf596c

Merge




From Alan.Bateman at oracle.com  Wed Aug 14 15:22:37 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 14 Aug 2013 16:22:37 +0100
Subject: RFR: JDK-4858457 -- File.getCanonicalPath() throws IOException
	when invoked with "nul" (win)
In-Reply-To: <52040323.3040505@oracle.com>
References: <52040323.3040505@oracle.com>
Message-ID: <520BA0BD.9010109@oracle.com>

On 08/08/2013 21:44, Dan Xu wrote:
> Hi All,
>
> Windows platforms have reserved a few names for device usages, and 
> "nul" is one of them. And Windows API, such as _wfullpath() and 
> GetFullPathNameW, returns its full path with the prefix "\\.\", which 
> represents win32 device namespaces.
>
> For example, "nul", whose full path name is "\\.\nul", is a valid 
> device name. But our current Canonicalization logicfails to generate 
> its canonicalpath and throws an IOException. This fix is going to 
> address the problem. Thanks!
>
> Webrev: http://cr.openjdk.java.net/~dxu/4858457/webrev.00/
> Bug: http://bugs.sun.com/view_bug.do?bug_id=4858457
>
> -Dan
The change looks okay to me, I just wonder if it might make sense to 
combine the test with WinDeviceName so that there is only one set of 
inputs to test.

-Alan


From kumar.x.srinivasan at oracle.com  Wed Aug 14 15:14:11 2013
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Wed, 14 Aug 2013 15:14:11 +0000
Subject: hg: jdk8/tl/jdk: 8022547: [verifier] move
	DefaultMethodRegressionTests.java to jdk
Message-ID: <20130814151438.4906648890@hg.openjdk.java.net>

Changeset: bc3cafb17c09
Author:    ksrini
Date:      2013-08-14 08:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc3cafb17c09

8022547: [verifier] move DefaultMethodRegressionTests.java to jdk
Reviewed-by: acorn

+ test/vm/verifier/defaultMethods/DefaultMethodRegressionTests.java
+ test/vm/verifier/defaultMethods/DefaultMethodRegressionTestsRun.java



From mandy.chung at oracle.com  Wed Aug 14 17:45:14 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 14 Aug 2013 10:45:14 -0700
Subject: [Fwd: Missing merge for 8014890: Reference queues may return
	more entries than expected]
In-Reply-To: <1376474160.2828.56.camel@cirrus>
References: <1376471970.2828.41.camel@cirrus> <520B5137.2020203@oracle.com>
	<1376474160.2828.56.camel@cirrus>
Message-ID: <520BC22A.9050602@oracle.com>

Thomas,

I haven't got to your mail as Alan suspects.  I'm happy that you 
confirmed this is no longer an issue.

Mandy

On 8/14/2013 2:56 AM, Thomas Schatzl wrote:
> Hi,
>
> On Wed, 2013-08-14 at 10:43 +0100, Alan Bateman wrote:
>> Mandy is just back from vacation and might not have got to your mail
>> yet. However it's not clear to me that there is an actual problem as it
>> looks like you've just ended up with two heads, maybe a hg fetch when
>> you had changes where you forgot to merge? As I understand, the hg
>> server is setup to limit the heads to 1 so it's not possible for any of
>> us to push changes that would result in a new head. Maybe start with a
>> fresh clone of jdk8/tl or jdk8/jdk8?
>    I had the impression that I had a fresh checkout at that time, and did
> not recheck right now.
>
> A fresh checkout is okay.
>
> Sorry for the noise,
>    Thomas
>



From christian.thalinger at oracle.com  Wed Aug 14 17:59:53 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 14 Aug 2013 10:59:53 -0700
Subject: Classes on the stack trace (was:
	getElementClass/StackTraceElement, was: @CallerSensitive public API,
	was: sun.reflect.Reflection.getCallerClass)
In-Reply-To: <50B05474-BD3F-47C7-8412-F0F305E0F0FF@nicholaswilliams.net>
References: 
	<51F7AEEE.4040305@gmail.com> <51F7BD75.4030708@gmx.org>
	<51F7CACD.2070703@gmail.com> <51F7DCD0.1030306@gmx.org>
	<50B05474-BD3F-47C7-8412-F0F305E0F0FF@nicholaswilliams.net>
Message-ID: <0F2322D3-40CF-44C6-8B16-048DEE824180@oracle.com>


On Jul 30, 2013, at 4:11 PM, Nick Williams  wrote:

> Quick question for those of you that know anything about @CallerSensitive...
> 
> After looking at the code and experimenting some, I've discovered that getCallerClass() doesn't actually keep going until it finds the first method without @CallerSensitive. It only returns the caller of the caller. So, for example:
> 
> Stack 1
> @CallerSensitive Reflection.getCallerClass()
> @CallerSensitive MyClass1.method1();
> MyClass2.method2();
> 
> In this case, getCallerClass() returns MyClass2.class. BUT:
> 
> Stack 2
> @CallerSensitive Reflection.getCallerClass()
> @CallerSensitive MyClass1.method1();
> @CallerSensitive MyClass2.method2();
> MyClass3.method3();
> 
> In this case, getCallerClass() STILL returns MyClass2.class. Based on the plain-language meaning of @CallerSensitive, I would expect getCallerClass() to return MyClass3.class in the second case. But, indeed, the JavaDoc for Reflection.getCallerClass() says: "Returns the class of the caller of the method calling this method." So, then, what's the point of @CallerSensitive? Looking at the code:
> 
>   vframeStream vfst(thread);
>   // Cf. LibraryCallKit::inline_native_Reflection_getCallerClass
>   for (int n = 0; !vfst.at_end(); vfst.security_next(), n++) {
>     Method* m = vfst.method();
>     assert(m != NULL, "sanity");
>     switch (n) {
>     case 0:
>       // This must only be called from Reflection.getCallerClass
>       if (m->intrinsic_id() != vmIntrinsics::_getCallerClass) {
>         THROW_MSG_NULL(vmSymbols::java_lang_InternalError(), "JVM_GetCallerClass must only be called from Reflection.getCallerClass");
>       }
>       // fall-through
>     case 1:
>       // Frame 0 and 1 must be caller sensitive.
>       if (!m->caller_sensitive()) {
>         THROW_MSG_NULL(vmSymbols::java_lang_InternalError(), err_msg("CallerSensitive annotation expected at frame %d", n));
>       }
>       break;
>     default:
>       if (!m->is_ignored_by_security_stack_walk()) {
>         // We have reached the desired frame; return the holder class.
>         return (jclass) JNIHandles::make_local(env, m->method_holder()->java_mirror());
>       }
>       break;
>     }
>   }
> 
> It seems to me that @CallerSensitive is completely pointless. This is ALWAYS going to return the first non-reflection frame after frame 1, regardless of @CallerSensitive. If @CallerSensitive were really supposed to have an actual purpose, it would seem to me that the last part should be this:
> 
>       if (!m->is_ignored_by_security_stack_walk() && !m->caller_sensitive()) {
>         // We have reached the desired frame; return the holder class.
>         return (jclass) JNIHandles::make_local(env, m->method_holder()->java_mirror());
>       }
> 
> Am I completely missing the point here? I just don't see a reason for @CallerSensitive. The code could do the exact same thing it currently is without @CallerSensitive (except for enforcing that frame 1 is @CallerSensitive, which really isn't necessary if you aren't using it in further frames).
> 
> Thoughts?

You are missing the second (and perhaps more important) part of this change.  Read:

http://openjdk.java.net/jeps/176

-- Chris

> 
> Nick
> 
> On Jul 30, 2013, at 10:33 AM, Jochen Theodorou wrote:
> 
>> Am 30.07.2013 16:16, schrieb Peter Levart:
>>> 
>>> On 07/30/2013 03:19 PM, Jochen Theodorou wrote:
>>>> Am 30.07.2013 14:17, schrieb Peter Levart:
>>>> [...]
>>>>> So what would give Groovy or other language runtimes headaches when all
>>>>> there was was a parameter-less getCallerClass() API? Aren't the
>>>>> intermediate frames inserted by those runtimes controlled by the
>>>>> runtimes? Couldn't the "surface" runtime-inserted methods capture the
>>>>> caller and pass it down? I guess the problem is supporting calling the
>>>>> caller-sensitive methods like Class.forName(String) and such which don't
>>>>> have the overloaded variant taking caller Class or ClassLoader as an
>>>>> argument...
>>>> Speaking for Groovy...
>>>> those intermediate frames are runtime controlled, yes, but passing down
>>>> the caller class is exactly the problem. Imagine I would suggest that
>>>> each and every method definition in Java automatically gets an
>>>> additional parameter for the caller class, just to have access to it
>>>> inside the method. You would not accept that for Java, would you? And so
>>>> we cannot accept that for Groovy if we want to keep integration with
>>>> Java...
>>> 
>>> Are you talking about internal Groovy implementation (the
>>> runtime-inserted methods) or the publicly visible API?
>> 
>> that's the problem, it is a mix, some internal, other not. We are going to change that in Groovy 3
>> 
>>> One solution for
>>> internal implementation of Groovy could be (speaking by heart since I
>>> don't know the internals of Groovy) for the "surface" public API method
>>> which doesn't have to have the special caller parameter, to capture the
>>> caller with getCallerClass() parameterless API (possibly enclosed with a
>>> quick check confirming that it might actually be needed) and bind it to
>>> a ThreadLocal, then use this ThreadLocal down at the end...
>> 
>> confirming that it might actually be needed is a problem. In the old fallback path we don't know what we call until after we are deep in runtime code, and there it is too late. In the other paths we could mark those methods in a @CallerSensitive style and do it in that case only.
>> 
>>>> and the good integration with Java is one of the key points of
>>>> Groovy. Even if we make something like that @CallerSensitive and add the
>>>> parameter only in those cases, we break being able to override methods.
>>> 
>>> I guess I don't know every Groovy need to obtain the caller class. I
>>> thought the problem was to support calling caller-sensitive methods in
>>> Java API (like Class.forName(String)) from within Groovy code, where
>>> there are runtime-inserted frames between the "call-site" and the target
>>> method. Are there any other needs?
>> 
>> ok, there is a misunderstanding...
>> 
>> if we call a Java implemented method from Groovy, which is using getCallerClass() it may or may not work. In general this does not work and our problem is not about that at all. With the change to let getCallerClass() ignore some reflective frames it will work actually better as long as we use our custom callsite caching implementation, it will not work if indy is used or the fallback path.
>> 
>> To be able to call a method Class#forName(String), we need to "replace" it with an implementation of our own, which we do with an approach similar to extension methods (only that ours can hide existing implementation methods for groovy). And in there we need to get to the caller class
>> 
>> Our problem though is @Grab which is an annotation to add elements to the classpath while running a script.
>> 
>>>> Plus, before Groovy3 is not done we have to support several call paths.
>>>> And the oldest one, which is still a fallback, does not support
>>>> transporting the caller class through the runtime layers at all.
>>>> Changing here is a breaking change.
>>> 
>>> Could you describe those call-paths? Examples of Groovy code and to what
>>> it gets translated (equivalent Java code at call site) with a brief
>>> description of what each intermediate layer (between the call-site and
>>> the target method) does and at which point the caller class is extracted...
>> 
>> the code generated at the call site depends on several factors actually... The call site code itself is usually not very informative
>> 
>> I start with Groovy 1.0, since that is basically the fallback path. Here this.foo() translates more or less to
>> ScriptBytecodeAdapter.invokeMethod0(staticCallerClass, this,"foo")
>> which basically does this.getMetaClass().invokeMethod(staticCallerClass, this, "foo"). The problem is that the meta class might be user supplied and the code executed in invokeMethod as well. The invocation is then finally done by reflection. That means we have frames from ScriptBytecodeAdapter, from the meta class, as well as maybe frames from a custom meta class and reflection frames. At the level of ScriptBytecodeAdapter there is a means of transporting the caller class, but that is the static one. Once there is a subclass, this information is different from what is needed here and it cannot simply be exchanged. Even if the bytecode adapter is changed, we cannot change the public API for MetaClass#invokeMethod now. And then the information would be lost.
>> 
>> In later versions of Groovy (since 1.6) we introduced a custom call site caching technique, which uses runtime generated classes to create a helper class per call site and is then used for invocation. At the callsite we basically have something like callsiteArray[i].invoke(..). Here again the staticCallerClass can be found. In this version we are able to "get" the method we want to invoke, before invoking it (bypassing MetaClass#invokeMethod). But to be able to get the method, certain conditions have to be met (like no user supplied meta class). If they are not met, then we do basically the same path as in 1.0, only that we don't use ScriptBytecodeAdapter. Instead We use our CallSite class as entrance point, which then makes the call to the meta class. In the "efficent" case we have now frames from the callsite handling code between the callsite and the target method only. This includes reflection in the first instantiation, later the generated class is used so it reduces !
> to two frames of which one is the Callsite entrance point, the other a frame form the generated method. In the fallback case we have frames from the callsite handling code, plus meta class code, plus reflection of course. Again the fallback case prevents us from transporting the caller information to the target method. If we ignore the fallback case, then we could here maybe use the Threadlocal information. It will require a new callsite interface for the bytecode though, meaning this code will not work for precompiled grovvy of older version, excluding from getting into Groovy 2.1.x, since it would be a breaking change. The earliest version for that would be Groovy 2.2.0, which is almost in RC now. Effectively it would mean we would have to do a 2.3.0 very soon after most probably.
>> 
>> In Groovy 2 we added an indy implementation, which replaces the callsite caching code.  At the callsite we have here basically invokedynamic "foo" with IndyInterface#bootstrap. bootstrap will first introduce a target for IndyInterface#selectMethod, since I need the runtime types instead of the static ones. The static caller class information is here part of the bootstrap method as Lookup object, added by invokedynamic itself. After selectMethod is done we have an initial invocation using invokeExact and later invocations by the handle stored in the callsite. Of course the same conditions as for the callsite caching above have to be met, meaning the fallback path might appear. That makes initially one IndyInterface frame, then invokedynamic and lambda related frames, then optionally the traget method, or in the fallback case the meta class frames plus reflection
>> 
>> 
>> bye Jochen
>> 
>> -- 
>> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
>> blog: http://blackdragsview.blogspot.com/
>> german groovy discussion newsgroup: de.comp.lang.misc
>> For Groovy programming sources visit http://groovy-lang.org
>> 
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



From xueming.shen at oracle.com  Wed Aug 14 18:35:20 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 14 Aug 2013 11:35:20 -0700
Subject: RFR:  JDK-8022178: System.console() throws IOE on some Windows
Message-ID: <520BCDE8.2040303@oracle.com>

Hi,

Please help review the trivial change for 8022178.

http://cr.openjdk.java.net/~sherman/console/webrev

System.console() is not specified to throw an IOE. It is supposed to
return a null silently if there is no system console or anything goes
wrong to get one. The Windows implementation obviously has some
leftover code from the old/original implementation to throw a IOE
if it fails to get the std in/out handler in certain use scenario. The
proposed change is to simply remove the IOE throwing code and
return silently.

Thanks,
-Sherman





From Alan.Bateman at oracle.com  Wed Aug 14 18:35:23 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 14 Aug 2013 19:35:23 +0100
Subject: RFR:  JDK-8022178: System.console() throws IOE on some Windows
In-Reply-To: <520BCDE8.2040303@oracle.com>
References: <520BCDE8.2040303@oracle.com>
Message-ID: <520BCDEB.4020908@oracle.com>

On 14/08/2013 19:35, Xueming Shen wrote:
> Hi,
>
> Please help review the trivial change for 8022178.
>
> http://cr.openjdk.java.net/~sherman/console/webrev
>
> System.console() is not specified to throw an IOE. It is supposed to
> return a null silently if there is no system console or anything goes
> wrong to get one. The Windows implementation obviously has some
> leftover code from the old/original implementation to throw a IOE
> if it fails to get the std in/out handler in certain use scenario. The
> proposed change is to simply remove the IOE throwing code and
> return silently.
It does look like left over code, the change looks fine to me.

-Alan


From xueming.shen at oracle.com  Wed Aug 14 18:40:18 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Wed, 14 Aug 2013 18:40:18 +0000
Subject: hg: jdk8/tl/jdk: 8022178: System.console() throws IOE on some Windows
Message-ID: <20130814184030.A190B48897@hg.openjdk.java.net>

Changeset: c138d1b608e0
Author:    sherman
Date:      2013-08-14 11:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c138d1b608e0

8022178: System.console() throws IOE on some Windows
Summary: to remove the IOE throwing code
Reviewed-by: alanb

! src/windows/native/java/io/Console_md.c



From dan.xu at oracle.com  Wed Aug 14 18:45:48 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Wed, 14 Aug 2013 11:45:48 -0700
Subject: RFR:  JDK-8022178: System.console() throws IOE on some Windows
In-Reply-To: <520BCDEB.4020908@oracle.com>
References: <520BCDE8.2040303@oracle.com> <520BCDEB.4020908@oracle.com>
Message-ID: <520BD05C.8010300@oracle.com>

Looks good to me.

-Dan

On 08/14/2013 11:35 AM, Alan Bateman wrote:
> On 14/08/2013 19:35, Xueming Shen wrote:
>> Hi,
>>
>> Please help review the trivial change for 8022178.
>>
>> http://cr.openjdk.java.net/~sherman/console/webrev
>>
>> System.console() is not specified to throw an IOE. It is supposed to
>> return a null silently if there is no system console or anything goes
>> wrong to get one. The Windows implementation obviously has some
>> leftover code from the old/original implementation to throw a IOE
>> if it fails to get the std in/out handler in certain use scenario. The
>> proposed change is to simply remove the IOE throwing code and
>> return silently.
> It does look like left over code, the change looks fine to me.
>
> -Alan



From joe.darcy at oracle.com  Wed Aug 14 18:27:21 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Wed, 14 Aug 2013 18:27:21 +0000
Subject: hg: jdk8/tl/jdk: 8022990: Fix dep_ann lint warnings in swing code
Message-ID: <20130814182745.46DDC48895@hg.openjdk.java.net>

Changeset: 444a7edcf367
Author:    darcy
Date:      2013-08-14 11:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/444a7edcf367

8022990: Fix dep_ann lint warnings in swing code
Reviewed-by: alexsch

! src/share/classes/com/sun/java/swing/Painter.java
! src/share/classes/com/sun/java/swing/plaf/nimbus/AbstractRegionPainter.java
! src/share/classes/com/sun/java/swing/plaf/nimbus/NimbusLookAndFeel.java



From xueming.shen at oracle.com  Wed Aug 14 19:10:10 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 14 Aug 2013 12:10:10 -0700
Subject: RFR: JDK-7154662: {CRC32, Adler32}.update(byte[] b, int off, int len):
	undocumented ArrayIndexOutOfBoundsException
Message-ID: <520BD612.7000206@oracle.com>

Hi,

Please help review the change to document the AIOBE exception
for CRC32/Adler32.update() methods (may need a followup CCC).
This has been the behavior probably from day one, but the exception
is just not explicitly listed. Ideally it probably should be in Checksum.update(),
but that probably is too late for a public interface that has been there
for so many years.

http://cr.openjdk.java.net/~sherman/7154662/webrev/

Thanks!
-Sherman


From roger.riggs at oracle.com  Wed Aug 14 19:48:13 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Wed, 14 Aug 2013 15:48:13 -0400
Subject: Please review Meiji era tidyup
Message-ID: <520BDEFD.9070600@oracle.com>

The issue 8019185: Inconsistency between JapaneseEra start dates and 
java.util.JapaneseImperialDate
Observes a minor discrepancy between the java.util.Calendar Japanese 
implementation
and the java.time JapaneseEra.

This fix aligns the start dates of the Meiji Era to avoid the inconsistency.

http://cr.openjdk.java.net/~rriggs/webrev-meiji-start-8019185/

Thanks, Roger



From dan.xu at oracle.com  Wed Aug 14 19:54:46 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Wed, 14 Aug 2013 12:54:46 -0700
Subject: RFR: JDK-4858457 -- File.getCanonicalPath() throws IOException
	when invoked with "nul" (win)
In-Reply-To: <520BA0BD.9010109@oracle.com>
References: <52040323.3040505@oracle.com> <520BA0BD.9010109@oracle.com>
Message-ID: <520BE086.70907@oracle.com>

Hi Alan,

Thanks for pointing out. I have updated my fix in the new webrev, 
http://cr.openjdk.java.net/~dxu/4858457/webrev.01/. Please take a look!

-Dan

On 08/14/2013 08:22 AM, Alan Bateman wrote:
> On 08/08/2013 21:44, Dan Xu wrote:
>> Hi All,
>>
>> Windows platforms have reserved a few names for device usages, and 
>> "nul" is one of them. And Windows API, such as _wfullpath() and 
>> GetFullPathNameW, returns its full path with the prefix "\\.\", which 
>> represents win32 device namespaces.
>>
>> For example, "nul", whose full path name is "\\.\nul", is a valid 
>> device name. But our current Canonicalization logicfails to generate 
>> its canonicalpath and throws an IOException. This fix is going to 
>> address the problem. Thanks!
>>
>> Webrev: http://cr.openjdk.java.net/~dxu/4858457/webrev.00/
>> Bug: http://bugs.sun.com/view_bug.do?bug_id=4858457
>>
>> -Dan
> The change looks okay to me, I just wonder if it might make sense to 
> combine the test with WinDeviceName so that there is only one set of 
> inputs to test.
>
> -Alan



From mandy.chung at oracle.com  Wed Aug 14 21:01:08 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 14 Aug 2013 14:01:08 -0700
Subject: 8022921: Remove experimental Profile attribute
In-Reply-To: <520B7856.6070008@oracle.com>
References: <520B7856.6070008@oracle.com>
Message-ID: <520BF014.6020907@oracle.com>

On 8/14/2013 5:30 AM, Alan Bateman wrote:
>
> As part of the Compact Profiles [1] solution we updated the JAR File 
> specification to define a new attribute named "Profile" to allow both 
> main application and library JAR files specify the minimum subset 
> Profile of Java SE that the code in the JAR file requires.
>
> The Profile attribute has been in for more than 6 months now and on 
> reflection it may not be the right thing to do. For starters there has 
> been push-back from folks that have license or other reasons that 
> prevent them from updating the manifest of main application JAR files. 
> Another issue is that the value of the attribute is the minimum subset 
> Profile so there isn't a way to specify that the code requires the 
> full Java SE platform. Another concern is that it might conflict with 
> future direction where we have a way to require standard Java SE or 
> JDK modules. So overall I think the best thing is to remove this 
> attribute, even though it means the solution doesn't no longer has a 
> way to catch mis-matches between the compile time and runtime 
> environments.
>
> The webrev with the changes to remove this attribute are here:
>
> http://cr.openjdk.java.net/~alanb/8022921/webrev/
>

This change looks fine and I also think removing this attribute is the 
best thing to do.

Mandy

> It should be easy to remove because it's code deletion.  I plan to 
> update the JEP so that it reflects the updated solution.
>
> Thanks,
> Alan.
>
> [1] http://openjdk.java.net/jeps/161



From mike.duigou at oracle.com  Wed Aug 14 20:38:36 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 14 Aug 2013 20:38:36 +0000
Subject: hg: jdk8/tl/jdk: 8022109: Evaluate adding incrementExact,
	decrementExact, negateExact to java.lang.Math
Message-ID: <20130814203859.9BC0F4889C@hg.openjdk.java.net>

Changeset: 17dfbb3f60d3
Author:    bpb
Date:      2013-08-12 10:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/17dfbb3f60d3

8022109: Evaluate adding incrementExact, decrementExact, negateExact to java.lang.Math
Summary: Add the methods for parameter types int and long.
Reviewed-by: mduigou
Contributed-by: Brian Burkhalter 

! src/share/classes/java/lang/Math.java
! test/java/lang/Math/ExactArithTests.java



From Alan.Bateman at oracle.com  Wed Aug 14 21:19:12 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 14 Aug 2013 22:19:12 +0100
Subject: RFR: JDK-7154662: {CRC32, Adler32}.update(byte[] b, int off,
	int len): undocumented ArrayIndexOutOfBoundsException
In-Reply-To: <520BD612.7000206@oracle.com>
References: <520BD612.7000206@oracle.com>
Message-ID: <520BF450.5000901@oracle.com>

On 14/08/2013 20:10, Xueming Shen wrote:
> Hi,
>
> Please help review the change to document the AIOBE exception
> for CRC32/Adler32.update() methods (may need a followup CCC).
> This has been the behavior probably from day one, but the exception
> is just not explicitly listed. Ideally it probably should be in 
> Checksum.update(),
> but that probably is too late for a public interface that has been there
> for so many years.
>
> http://cr.openjdk.java.net/~sherman/7154662/webrev/
This looks fine to me.

-Alan


From chris.hegarty at oracle.com  Wed Aug 14 21:33:44 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 14 Aug 2013 22:33:44 +0100
Subject: RFR: JDK-7154662: {CRC32, Adler32}.update(byte[] b, int off,
	int len): undocumented ArrayIndexOutOfBoundsException
In-Reply-To: <520BD612.7000206@oracle.com>
References: <520BD612.7000206@oracle.com>
Message-ID: <520BF7B8.4030106@oracle.com>


 > * @throws  ArrayIndexOutOfBoundsException
 > *          if the {@code off} is negative, or the {@code len} is
 > *          negative, or the {@code off+len} is greater than the
 > *          length of the array {@code b}

I agree that specifying this in CRC32 and Adler32 is the right thing to 
do. Trivially I'd drop the 'the' before the arguments, or maybe take the 
working from InputStream.read(byte[],int,int) :

   "If off is negative, len is negative, or len is greater than b.length
    - off"

Either is ok with me. Is it worth adding a test? or will JCK be updated 
to catch this.

-Chris.

On 14/08/2013 20:10, Xueming Shen wrote:
> Hi,
>
> Please help review the change to document the AIOBE exception
> for CRC32/Adler32.update() methods (may need a followup CCC).
> This has been the behavior probably from day one, but the exception
> is just not explicitly listed. Ideally it probably should be in
> Checksum.update(),
> but that probably is too late for a public interface that has been there
> for so many years.
>
> http://cr.openjdk.java.net/~sherman/7154662/webrev/
>
> Thanks!
> -Sherman


From xueming.shen at oracle.com  Wed Aug 14 21:49:04 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 14 Aug 2013 14:49:04 -0700
Subject: RFR: JDK-7154662: {CRC32, Adler32}.update(byte[] b, int off,
	int len): undocumented ArrayIndexOutOfBoundsException
In-Reply-To: <520BF7B8.4030106@oracle.com>
References: <520BD612.7000206@oracle.com> <520BF7B8.4030106@oracle.com>
Message-ID: <520BFB50.2040800@oracle.com>

Thanks Chris!

"the" removed.

I would assume the jck team probably will add a unit test for it. They filed the
bug originally.

-Sherman

On 08/14/2013 02:33 PM, Chris Hegarty wrote:
>
> > * @throws  ArrayIndexOutOfBoundsException
> > *          if the {@code off} is negative, or the {@code len} is
> > *          negative, or the {@code off+len} is greater than the
> > *          length of the array {@code b}
>
> I agree that specifying this in CRC32 and Adler32 is the right thing to do. Trivially I'd drop the 'the' before the arguments, or maybe take the working from InputStream.read(byte[],int,int) :
>
>   "If off is negative, len is negative, or len is greater than b.length
>    - off"
>
> Either is ok with me. Is it worth adding a test? or will JCK be updated to catch this.
>
> -Chris.
>
> On 14/08/2013 20:10, Xueming Shen wrote:
>> Hi,
>>
>> Please help review the change to document the AIOBE exception
>> for CRC32/Adler32.update() methods (may need a followup CCC).
>> This has been the behavior probably from day one, but the exception
>> is just not explicitly listed. Ideally it probably should be in
>> Checksum.update(),
>> but that probably is too late for a public interface that has been there
>> for so many years.
>>
>> http://cr.openjdk.java.net/~sherman/7154662/webrev/
>>
>> Thanks!
>> -Sherman



From chris.hegarty at oracle.com  Wed Aug 14 21:45:56 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 14 Aug 2013 22:45:56 +0100
Subject: 8022921: Remove experimental Profile attribute
In-Reply-To: <520B7856.6070008@oracle.com>
References: <520B7856.6070008@oracle.com>
Message-ID: <520BFA94.4000705@oracle.com>

The code changes look ok to me.

-Chris.

On 14/08/2013 13:30, Alan Bateman wrote:
>
> As part of the Compact Profiles [1] solution we updated the JAR File
> specification to define a new attribute named "Profile" to allow both
> main application and library JAR files specify the minimum subset
> Profile of Java SE that the code in the JAR file requires.
>
> The Profile attribute has been in for more than 6 months now and on
> reflection it may not be the right thing to do. For starters there has
> been push-back from folks that have license or other reasons that
> prevent them from updating the manifest of main application JAR files.
> Another issue is that the value of the attribute is the minimum subset
> Profile so there isn't a way to specify that the code requires the full
> Java SE platform. Another concern is that it might conflict with future
> direction where we have a way to require standard Java SE or JDK
> modules. So overall I think the best thing is to remove this attribute,
> even though it means the solution doesn't no longer has a way to catch
> mis-matches between the compile time and runtime environments.
>
> The webrev with the changes to remove this attribute are here:
>
> http://cr.openjdk.java.net/~alanb/8022921/webrev/
>
> It should be easy to remove because it's code deletion. I plan to update
> the JEP so that it reflects the updated solution.
>
> Thanks,
> Alan.
>
> [1] http://openjdk.java.net/jeps/161


From chris.hegarty at oracle.com  Wed Aug 14 21:59:15 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 14 Aug 2013 22:59:15 +0100
Subject: RFR FJ parallelism zero
Message-ID: <520BFDB3.4080707@oracle.com>

Source changes that follow Doug's mail on lambda-libs-spec-observers

http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-August/002361.html

These changes are already in the jsr166 CVS, and there is a test in 
OpenJDK that verifies the change.

diff --git a/src/share/classes/java/util/concurrent/ForkJoinPool.java 
b/src/share/classes/java/util/concurrent/ForkJoinPool.java
--- a/src/share/classes/java/util/concurrent/ForkJoinPool.java
+++ b/src/share/classes/java/util/concurrent/ForkJoinPool.java
@@ -144,7 +144,8 @@ import java.util.concurrent.TimeUnit;
   * Upon any error in establishing these settings, default parameters
   * are used. It is possible to disable or limit the use of threads in
   * the common pool by setting the parallelism property to zero, and/or
- * using a factory that may return {@code null}.
+ * using a factory that may return {@code null}. However doing so may
+ * cause unjoined tasks to never be executed.
   *
   * 
Implementation notes: This implementation restricts the
   * maximum number of running threads to 32767. Attempts to create
@@ -3303,8 +3304,8 @@ public class ForkJoinPool extends Abstra
          }

          if (parallelism < 0 && // default 1 less than #cores
-            (parallelism = Runtime.getRuntime().availableProcessors() - 
1) < 0)
-            parallelism = 0;
+            (parallelism = Runtime.getRuntime().availableProcessors() - 
1) <= 0)
+            parallelism = 1;
          if (parallelism > MAX_CAP)
              parallelism = MAX_CAP;
          return new ForkJoinPool(parallelism, factory, handler, LIFO_QUEUE,

-Chris.


From chris.hegarty at oracle.com  Wed Aug 14 22:08:01 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 14 Aug 2013 23:08:01 +0100
Subject: RFR  ConcurrentHashMap typo
Message-ID: <520BFFC1.6060903@oracle.com>

Typo that crept in during a refactoring.

http://cs.oswego.edu/pipermail/concurrency-interest/2013-August/011695.html

This change is already in the jsr166 CVS.

diff --git 
a/src/share/classes/java/util/concurrent/ConcurrentHashMap.java 
b/src/share/classes/java/util/concurrent/ConcurrentHashMap.java
--- a/src/share/classes/java/util/concurrent/ConcurrentHashMap.java
+++ b/src/share/classes/java/util/concurrent/ConcurrentHashMap.java
@@ -2785,7 +2785,7 @@ public class ConcurrentHashMap exte
                          return;
                      }
                  }
-                else if ((s | WAITER) == 0) {
+                else if ((s & WAITER) == 0) {
                      if (U.compareAndSwapInt(this, LOCKSTATE, s, s | 
WAITER)) {
                          waiting = true;
                          waiter = Thread.currentThread();

-Chris.


From mike.duigou at oracle.com  Wed Aug 14 22:38:45 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 14 Aug 2013 15:38:45 -0700
Subject: RFR FJ parallelism zero
In-Reply-To: <520BFDB3.4080707@oracle.com>
References: <520BFDB3.4080707@oracle.com>
Message-ID: 

Looks fine.

Mike

On Aug 14 2013, at 14:59 , Chris Hegarty wrote:

> Source changes that follow Doug's mail on lambda-libs-spec-observers
> 
> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-August/002361.html
> 
> These changes are already in the jsr166 CVS, and there is a test in OpenJDK that verifies the change.
> 
> diff --git a/src/share/classes/java/util/concurrent/ForkJoinPool.java b/src/share/classes/java/util/concurrent/ForkJoinPool.java
> --- a/src/share/classes/java/util/concurrent/ForkJoinPool.java
> +++ b/src/share/classes/java/util/concurrent/ForkJoinPool.java
> @@ -144,7 +144,8 @@ import java.util.concurrent.TimeUnit;
>  * Upon any error in establishing these settings, default parameters
>  * are used. It is possible to disable or limit the use of threads in
>  * the common pool by setting the parallelism property to zero, and/or
> - * using a factory that may return {@code null}.
> + * using a factory that may return {@code null}. However doing so may
> + * cause unjoined tasks to never be executed.
>  *
>  * 
Implementation notes: This implementation restricts the
>  * maximum number of running threads to 32767. Attempts to create
> @@ -3303,8 +3304,8 @@ public class ForkJoinPool extends Abstra
>         }
> 
>         if (parallelism < 0 && // default 1 less than #cores
> -            (parallelism = Runtime.getRuntime().availableProcessors() - 1) < 0)
> -            parallelism = 0;
> +            (parallelism = Runtime.getRuntime().availableProcessors() - 1) <= 0)
> +            parallelism = 1;
>         if (parallelism > MAX_CAP)
>             parallelism = MAX_CAP;
>         return new ForkJoinPool(parallelism, factory, handler, LIFO_QUEUE,
> 
> -Chris.



From mike.duigou at oracle.com  Wed Aug 14 23:11:09 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 14 Aug 2013 16:11:09 -0700
Subject: RFR  ConcurrentHashMap typo
In-Reply-To: <520BFFC1.6060903@oracle.com>
References: <520BFFC1.6060903@oracle.com>
Message-ID: 

Looks correct.

mike

On Aug 14 2013, at 15:08 , Chris Hegarty wrote:

> Typo that crept in during a refactoring.
> 
> http://cs.oswego.edu/pipermail/concurrency-interest/2013-August/011695.html
> 
> This change is already in the jsr166 CVS.
> 
> diff --git a/src/share/classes/java/util/concurrent/ConcurrentHashMap.java b/src/share/classes/java/util/concurrent/ConcurrentHashMap.java
> --- a/src/share/classes/java/util/concurrent/ConcurrentHashMap.java
> +++ b/src/share/classes/java/util/concurrent/ConcurrentHashMap.java
> @@ -2785,7 +2785,7 @@ public class ConcurrentHashMap exte
>                         return;
>                     }
>                 }
> -                else if ((s | WAITER) == 0) {
> +                else if ((s & WAITER) == 0) {
>                     if (U.compareAndSwapInt(this, LOCKSTATE, s, s | WAITER)) {
>                         waiting = true;
>                         waiter = Thread.currentThread();
> 
> -Chris.



From jonathan.gibbons at oracle.com  Wed Aug 14 23:41:29 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 14 Aug 2013 23:41:29 +0000
Subject: hg: jdk8/tl/langtools: 8017191: Javadoc is confused by @link to
	imported classes outside of the set of generated packages
Message-ID: <20130814234134.907F4488A5@hg.openjdk.java.net>

Changeset: 14faef2b51eb
Author:    jjg
Date:      2013-08-14 16:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/14faef2b51eb

8017191: Javadoc is confused by @link to imported classes outside of the set of generated packages
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java
+ test/com/sun/javadoc/testSeeTag/TestSeeTag.java
+ test/com/sun/javadoc/testSeeTag/pkg/Test.java



From kumar.x.srinivasan at oracle.com  Thu Aug 15 01:59:33 2013
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Thu, 15 Aug 2013 01:59:33 +0000
Subject: hg: jdk8/tl/langtools: 6840442: JavaCompiler.getTask() has incomplete
	specification for IllegalArgumentException
Message-ID: <20130815015938.49FDB488A8@hg.openjdk.java.net>

Changeset: fac0d1bb87f2
Author:    ksrini
Date:      2013-08-14 18:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fac0d1bb87f2

6840442: JavaCompiler.getTask() has incomplete specification for IllegalArgumentException
Reviewed-by: jjg

! src/share/classes/javax/tools/JavaCompiler.java



From bhavesh.x.patel at oracle.com  Thu Aug 15 04:49:20 2013
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Thu, 15 Aug 2013 04:49:20 +0000
Subject: hg: jdk8/tl/langtools: 8016921: Change the profiles table on
	overview-summary.html page to a list
Message-ID: <20130815044923.A3925488B2@hg.openjdk.java.net>

Changeset: 3d4f0fa2ad05
Author:    bpatel
Date:      2013-08-14 21:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3d4f0fa2ad05

8016921: Change the profiles table on overview-summary.html page to a list
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! test/com/sun/javadoc/testProfiles/TestProfiles.java



From bradford.wetmore at oracle.com  Thu Aug 15 02:21:36 2013
From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com)
Date: Thu, 15 Aug 2013 02:21:36 +0000
Subject: hg: jdk8/tl/jdk: 8023075: JDK-5049299 has broken old make in jdk8
Message-ID: <20130815022202.8E3A8488AA@hg.openjdk.java.net>

Changeset: f8af3499c1fb
Author:    wetmore
Date:      2013-08-14 19:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8af3499c1fb

8023075: JDK-5049299 has broken old make in jdk8
Reviewed-by: katleman

! make/java/java/Makefile



From yong.huang at oracle.com  Thu Aug 15 06:00:07 2013
From: yong.huang at oracle.com (yong.huang at oracle.com)
Date: Thu, 15 Aug 2013 06:00:07 +0000
Subject: hg: jdk8/tl/jdk: 8021121: ISO 4217 Amendment Number 156
Message-ID: <20130815060019.9A492488B3@hg.openjdk.java.net>

Changeset: 2f6523abab08
Author:    yhuang
Date:      2013-08-14 22:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2f6523abab08

8021121: ISO 4217 Amendment Number 156
Reviewed-by: naoto

! src/share/classes/java/util/CurrencyData.properties
! src/share/classes/sun/util/resources/lv/CurrencyNames_lv_LV.properties
! test/java/util/Currency/tablea1.txt
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java



From scolebourne at joda.org  Thu Aug 15 07:28:04 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 15 Aug 2013 08:28:04 +0100
Subject: Please review Meiji era tidyup
In-Reply-To: <520BDEFD.9070600@oracle.com>
References: <520BDEFD.9070600@oracle.com>
Message-ID: 

Fine by me

On 14 August 2013 20:48, roger riggs  wrote:
> The issue 8019185: Inconsistency between JapaneseEra start dates and
> java.util.JapaneseImperialDate
> Observes a minor discrepancy between the java.util.Calendar Japanese
> implementation
> and the java.time JapaneseEra.
>
> This fix aligns the start dates of the Meiji Era to avoid the inconsistency.
>
> http://cr.openjdk.java.net/~rriggs/webrev-meiji-start-8019185/
>
> Thanks, Roger
>


From Alan.Bateman at oracle.com  Thu Aug 15 10:18:14 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 15 Aug 2013 11:18:14 +0100
Subject: RFR FJ parallelism zero
In-Reply-To: <520BFDB3.4080707@oracle.com>
References: <520BFDB3.4080707@oracle.com>
Message-ID: <520CAAE6.30705@oracle.com>

On 14/08/2013 22:59, Chris Hegarty wrote:
> Source changes that follow Doug's mail on lambda-libs-spec-observers
>
> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-August/002361.html 
>
>
> These changes are already in the jsr166 CVS, and there is a test in 
> OpenJDK that verifies the change.
This looks good to me too.

-Alan.


From alan.bateman at oracle.com  Thu Aug 15 10:59:11 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Thu, 15 Aug 2013 10:59:11 +0000
Subject: hg: jdk8/tl/jdk: 8022921: Remove experimental Profile attribute
Message-ID: <20130815105950.DE270488BB@hg.openjdk.java.net>

Changeset: 5ff3b55df2d4
Author:    alanb
Date:      2013-08-15 11:54 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ff3b55df2d4

8022921: Remove experimental Profile attribute
Reviewed-by: mchung, chegar

! src/share/classes/java/net/URLClassLoader.java
! src/share/classes/java/util/jar/Attributes.java
! src/share/classes/java/util/jar/JarFile.java
! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java
- src/share/classes/java/util/jar/UnsupportedProfileException.java
! src/share/classes/sun/launcher/LauncherHelper.java
! src/share/classes/sun/launcher/resources/launcher.properties
! src/share/classes/sun/misc/JavaUtilJarAccess.java
! src/share/classes/sun/misc/URLClassPath.java
! src/share/classes/sun/misc/Version.java.template
! src/share/classes/sun/tools/jar/Main.java
! src/share/classes/sun/tools/jar/resources/jar.properties
- test/java/net/URLClassLoader/profiles/Basic.java
- test/java/net/URLClassLoader/profiles/Lib.java
- test/java/net/URLClassLoader/profiles/basic.sh
- test/tools/jar/AddAndUpdateProfile.java
- test/tools/launcher/profiles/Basic.java
- test/tools/launcher/profiles/Logging.java
- test/tools/launcher/profiles/Main.java
- test/tools/launcher/profiles/VersionCheck.java



From fweimer at redhat.com  Thu Aug 15 12:15:52 2013
From: fweimer at redhat.com (Florian Weimer)
Date: Thu, 15 Aug 2013 14:15:52 +0200
Subject: RFR: JDK-7154662: {CRC32, Adler32}.update(byte[] b, int off,
	int len): undocumented ArrayIndexOutOfBoundsException
In-Reply-To: <520BF7B8.4030106@oracle.com>
References: <520BD612.7000206@oracle.com> <520BF7B8.4030106@oracle.com>
Message-ID: <520CC678.9010101@redhat.com>

On 08/14/2013 11:33 PM, Chris Hegarty wrote:
>
>  > * @throws  ArrayIndexOutOfBoundsException
>  > *          if the {@code off} is negative, or the {@code len} is
>  > *          negative, or the {@code off+len} is greater than the
>  > *          length of the array {@code b}
>
> I agree that specifying this in CRC32 and Adler32 is the right thing to
> do. Trivially I'd drop the 'the' before the arguments, or maybe take the
> working from InputStream.read(byte[],int,int) :
>
>    "If off is negative, len is negative, or len is greater than b.length
>     - off"

The InputStream wording is much better because it correctly covers the 
off + len < 0 case. :-)

-- 
Florian Weimer / Red Hat Product Security Team


From Alan.Bateman at oracle.com  Thu Aug 15 12:42:11 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 15 Aug 2013 13:42:11 +0100
Subject: RFR: JDK-4858457 -- File.getCanonicalPath() throws IOException
	when invoked with "nul" (win)
In-Reply-To: <520BE086.70907@oracle.com>
References: <52040323.3040505@oracle.com> <520BA0BD.9010109@oracle.com>
	<520BE086.70907@oracle.com>
Message-ID: <520CCCA3.9070808@oracle.com>

On 14/08/2013 20:54, Dan Xu wrote:
> Hi Alan,
>
> Thanks for pointing out. I have updated my fix in the new webrev, 
> http://cr.openjdk.java.net/~dxu/4858457/webrev.01/. Please take a look!
Thanks, much better to have this in the one test. Looks good.

-Alan.


From alan.bateman at oracle.com  Thu Aug 15 12:47:15 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Thu, 15 Aug 2013 12:47:15 +0000
Subject: hg: jdk8/tl/jdk: 8015765: TEST_BUG:
	java/nio/channels/ServerSocketChannel/AdaptServerSocket.java
	failing intermittently
Message-ID: <20130815124748.AA4E2488BC@hg.openjdk.java.net>

Changeset: b7b0beef5ded
Author:    alanb
Date:      2013-08-15 13:42 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b7b0beef5ded

8015765: TEST_BUG: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failing intermittently
Reviewed-by: chegar, dholmes, alanb
Contributed-by: yiming.wang at oracle.com

! test/java/nio/channels/ServerSocketChannel/AdaptServerSocket.java



From chris.hegarty at oracle.com  Thu Aug 15 13:52:27 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Thu, 15 Aug 2013 13:52:27 +0000
Subject: hg: jdk8/tl/jdk: 8022584: Memory leak in some NetworkInterface methods
Message-ID: <20130815135302.BDDF0488C0@hg.openjdk.java.net>

Changeset: 7d7d553a8c61
Author:    igerasim
Date:      2013-08-13 13:04 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d7d553a8c61

8022584: Memory leak in some NetworkInterface methods
Reviewed-by: alanb, dholmes, chegar, michaelm

! src/solaris/native/java/net/NetworkInterface.c
+ test/java/net/NetworkInterface/MemLeakTest.java



From chris.hegarty at oracle.com  Thu Aug 15 14:01:52 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Thu, 15 Aug 2013 14:01:52 +0000
Subject: hg: jdk8/tl/jdk: 8023103: FJ parallelism zero; ...
Message-ID: <20130815140204.0D5EE488C1@hg.openjdk.java.net>

Changeset: 3223342fb76e
Author:    dl
Date:      2013-08-15 15:01 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3223342fb76e

8023103: FJ parallelism zero
8020537: java/util/concurrent/forkjoin/ThrowingRunnable.java
Reviewed-by: chegar, mduigou, alanb

! src/share/classes/java/util/concurrent/ForkJoinPool.java



From chris.hegarty at oracle.com  Thu Aug 15 14:05:14 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Thu, 15 Aug 2013 14:05:14 +0000
Subject: hg: jdk8/tl/jdk: 8023104: ConcurrentHashMap typo
Message-ID: <20130815140526.9587B488C2@hg.openjdk.java.net>

Changeset: b07b19182e40
Author:    dl
Date:      2013-08-15 15:04 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b07b19182e40

8023104: ConcurrentHashMap typo
Reviewed-by: chegar, mduigou

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java



From chris.hegarty at oracle.com  Thu Aug 15 14:16:47 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Thu, 15 Aug 2013 14:16:47 +0000
Subject: hg: jdk8/tl/jdk: 8022126: Remove throws SocketException from
	DatagramPacket constructors accepting SocketAddress
Message-ID: <20130815141659.619C8488C3@hg.openjdk.java.net>

Changeset: e7137695dce3
Author:    chegar
Date:      2013-08-15 15:16 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7137695dce3

8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress
Reviewed-by: smarks, alanb, michaelm, darcy

! src/share/classes/java/net/DatagramPacket.java



From dl at cs.oswego.edu  Thu Aug 15 14:33:02 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 15 Aug 2013 10:33:02 -0400
Subject: Possible HashMap update
In-Reply-To: <520B84DD.8030207@univ-mlv.fr>
References: <51D4ABDA.7010801@cs.oswego.edu> <51DAD99F.9030705@cs.oswego.edu>
	<9F896672-012F-40A7-B7A3-AF9823CF7BB9@oracle.com>
	<520A8F0C.2070503@cs.oswego.edu> <520A9D9B.6010303@univ-mlv.fr>
	<520B6707.9020601@cs.oswego.edu> <520B84DD.8030207@univ-mlv.fr>
Message-ID: <520CE69E.5060701@cs.oswego.edu>

On 08/14/13 09:23, Remi Forax wrote:
> On 08/14/2013 01:16 PM, Doug Lea wrote:
>> On 08/13/13 16:56, Remi Forax wrote:
>>>>>>
>>>>>> And that the iterators on entrySet, keySet and values doesn't have their
>>>>>> method
>>>>>> forEachRemaining overriden
>>>>>> (unlike java.util.ArrayList).
>>>>
>> Could you explain exactly when these trigger? Most Stream-related
>> operations should pick up spliterator, not iterator, so won't
>> encounter this.
>
> Yes, it's not related to Stream.
> I see two obvious scenarios when forEachRemaining should be used.
>
> The first one is bug 6360734 [1], for(:) doesn't support Iterator but there are
> plenty of methods in the wild that returns an Iterator.
> In the JDK, at least
>    BeanContextServices.getCurrentServiceClasses(),
>    BenContextSupport.bcsChildren() or
>    ServiceRegistry.getCategories(),
> all return something like map.[views()].iterator()
>
> The second scenario is when you have an algorithm that do something for first value
> and do something else for the other value, in that case, you need to get the
> iterator,
> calls next to get the first value and calls forEachRemaining for processing the
> remaining values.
>
>>
>> I resist this a bit because it would require 6 more
>> methods, each redundant with a spliterator method.
>> (The HashMap view ones must be overridden in LinkedHashMap.)
>> But if the situation is common, it might be worthwhile.
>
> I suppose that it depends on what is your definition of common :)
>

Neither of these cases apply to existing usages, so I'm thinking
that they are not common enough to support. Does anyone else
think otherwise?

-Doug



From forax at univ-mlv.fr  Thu Aug 15 14:57:30 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 15 Aug 2013 16:57:30 +0200
Subject: Possible HashMap update
In-Reply-To: <520CE69E.5060701@cs.oswego.edu>
References: <51D4ABDA.7010801@cs.oswego.edu> <51DAD99F.9030705@cs.oswego.edu>
	<9F896672-012F-40A7-B7A3-AF9823CF7BB9@oracle.com>
	<520A8F0C.2070503@cs.oswego.edu> <520A9D9B.6010303@univ-mlv.fr>
	<520B6707.9020601@cs.oswego.edu> <520B84DD.8030207@univ-mlv.fr>
	<520CE69E.5060701@cs.oswego.edu>
Message-ID: <520CEC5A.3070502@univ-mlv.fr>

On 08/15/2013 04:33 PM, Doug Lea wrote:
> On 08/14/13 09:23, Remi Forax wrote:
>> On 08/14/2013 01:16 PM, Doug Lea wrote:
>>> On 08/13/13 16:56, Remi Forax wrote:
>>>>>>>
>>>>>>> And that the iterators on entrySet, keySet and values doesn't 
>>>>>>> have their
>>>>>>> method
>>>>>>> forEachRemaining overriden
>>>>>>> (unlike java.util.ArrayList).
>>>>>
>>> Could you explain exactly when these trigger? Most Stream-related
>>> operations should pick up spliterator, not iterator, so won't
>>> encounter this.
>>
>> Yes, it's not related to Stream.
>> I see two obvious scenarios when forEachRemaining should be used.
>>
>> The first one is bug 6360734 [1], for(:) doesn't support Iterator but 
>> there are
>> plenty of methods in the wild that returns an Iterator.
>> In the JDK, at least
>>    BeanContextServices.getCurrentServiceClasses(),
>>    BenContextSupport.bcsChildren() or
>>    ServiceRegistry.getCategories(),
>> all return something like map.[views()].iterator()
>>
>> The second scenario is when you have an algorithm that do something 
>> for first value
>> and do something else for the other value, in that case, you need to 
>> get the
>> iterator,
>> calls next to get the first value and calls forEachRemaining for 
>> processing the
>> remaining values.
>>
>>>
>>> I resist this a bit because it would require 6 more
>>> methods, each redundant with a spliterator method.
>>> (The HashMap view ones must be overridden in LinkedHashMap.)
>>> But if the situation is common, it might be worthwhile.
>>
>> I suppose that it depends on what is your definition of common :)
>>
>
> Neither of these cases apply to existing usages, so I'm thinking
> that they are not common enough to support. Does anyone else
> think otherwise?

What, ?, it seems we don't live in the same world.
Google the query: apache .java "public Iterator" -Iterable
and you will get hundred of methods that returns an iterator with the 
top level class non Iterable,
currently calling forEachRemainig on these iterators will be optimized 
if the iterator was produced
by an ArrayList but not if it was created from one of the views of HashMap ?

Or do you suggest that we should not provide a better implementations 
for this particular default method,
which in that case indicates that this default method should be removed ?

>
> -Doug
>

R?mi



From erik.joelsson at oracle.com  Thu Aug 15 15:38:22 2013
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 15 Aug 2013 15:38:22 +0000
Subject: hg: jdk8/tl/langtools: 8015145: Smartjavac needs more flexibility
	with linking to sources
Message-ID: <20130815153832.4D627488C6@hg.openjdk.java.net>

Changeset: 71b0089b146f
Author:    erikj
Date:      2013-08-15 17:24 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/71b0089b146f

8015145: Smartjavac needs more flexibility with linking to sources
Reviewed-by: jjg, ohrstrom

! src/share/classes/com/sun/tools/sjavac/JavacState.java
! src/share/classes/com/sun/tools/sjavac/Main.java
! test/tools/sjavac/SJavac.java



From xueming.shen at oracle.com  Thu Aug 15 17:05:05 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 15 Aug 2013 10:05:05 -0700
Subject: RFR: JDK-7154662: {CRC32, Adler32}.update(byte[] b, int off,
	int len): undocumented ArrayIndexOutOfBoundsException
In-Reply-To: <520CC678.9010101@redhat.com>
References: <520BD612.7000206@oracle.com> <520BF7B8.4030106@oracle.com>
	<520CC678.9010101@redhat.com>
Message-ID: <520D0A41.3030209@oracle.com>

On 08/15/2013 05:15 AM, Florian Weimer wrote:
> On 08/14/2013 11:33 PM, Chris Hegarty wrote:
>>
>> > * @throws  ArrayIndexOutOfBoundsException
>> > *          if the {@code off} is negative, or the {@code len} is
>> > *          negative, or the {@code off+len} is greater than the
>> > *          length of the array {@code b}
>>
>> I agree that specifying this in CRC32 and Adler32 is the right thing to
>> do. Trivially I'd drop the 'the' before the arguments, or maybe take the
>> working from InputStream.read(byte[],int,int) :
>>
>>    "If off is negative, len is negative, or len is greater than b.length
>>     - off"
>
> The InputStream wording is much better because it correctly covers the off + len < 0 case. :-)
>

The one I have (without that "the") is the outputstream version. I would
assume it is equivalent to the inputstream version, given we have
exclude the off < 0 and len < 0 cases :-)

-Sherman


From xueming.shen at oracle.com  Thu Aug 15 17:39:16 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Thu, 15 Aug 2013 17:39:16 +0000
Subject: hg: jdk8/tl/jdk: 7154662: {CRC32, Adler32}.update(byte[] b, int off, 
	int len): undocumented ArrayIndexOutOfBoundsException
Message-ID: <20130815173953.E887D488DF@hg.openjdk.java.net>

Changeset: 6c307b4d0dd8
Author:    sherman
Date:      2013-08-15 10:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6c307b4d0dd8

7154662: {CRC32, Adler32}.update(byte[] b, int off, int len): undocumented ArrayIndexOutOfBoundsException
Summary: to add the throws clause
Reviewed-by: alanb, chegar

! src/share/classes/java/util/zip/Adler32.java
! src/share/classes/java/util/zip/CRC32.java



From vincent.x.ryan at oracle.com  Thu Aug 15 18:57:28 2013
From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com)
Date: Thu, 15 Aug 2013 18:57:28 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130815185828.D4AEB488F8@hg.openjdk.java.net>

Changeset: b4645069238a
Author:    vinnie
Date:      2013-08-15 19:49 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4645069238a

8023108: Remove ShortRSAKey1024.sh from ProblemList.txt
Reviewed-by: mullan

! test/ProblemList.txt

Changeset: 3211caab58ba
Author:    vinnie
Date:      2013-08-15 19:56 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3211caab58ba

Merge




From dan.xu at oracle.com  Thu Aug 15 19:37:01 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Thu, 15 Aug 2013 19:37:01 +0000
Subject: hg: jdk8/tl/jdk: 4858457: File.getCanonicalPath() throws IOException
	when invoked with "nul" (win)
Message-ID: <20130815193727.9F60848905@hg.openjdk.java.net>

Changeset: 5bb196aa183c
Author:    dxu
Date:      2013-08-15 12:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bb196aa183c

4858457: File.getCanonicalPath() throws IOException when invoked with "nul" (win)
Reviewed-by: alanb

! src/windows/native/java/io/canonicalize_md.c
! test/java/io/File/WinDeviceName.java



From dan.xu at oracle.com  Thu Aug 15 21:11:34 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Thu, 15 Aug 2013 21:11:34 +0000
Subject: hg: jdk8/tl/jdk: 8017109: Cleanup overrides warning in
	src/solaris/classes/sun/print/AttributeClass.java
Message-ID: <20130815211147.0FDCE48913@hg.openjdk.java.net>

Changeset: 0d27309a87e0
Author:    dxu
Date:      2013-08-15 14:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0d27309a87e0

8017109: Cleanup overrides warning in src/solaris/classes/sun/print/AttributeClass.java
Reviewed-by: jgodinez

! src/solaris/classes/sun/print/AttributeClass.java



From henry.jen at oracle.com  Thu Aug 15 23:14:21 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Thu, 15 Aug 2013 23:14:21 +0000
Subject: hg: jdk8/tl/jdk: 8019401: Collectors.collectingAndThen
Message-ID: <20130815231432.C0BFB48918@hg.openjdk.java.net>

Changeset: 5649837a4cfa
Author:    briangoetz
Date:      2013-08-12 12:06 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5649837a4cfa

8019401: Collectors.collectingAndThen
Reviewed-by: mduigou
Contributed-by: brian.goetz at oracle.com

! src/share/classes/java/util/stream/Collectors.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java



From fweimer at redhat.com  Fri Aug 16 07:54:06 2013
From: fweimer at redhat.com (Florian Weimer)
Date: Fri, 16 Aug 2013 09:54:06 +0200
Subject: RFR: JDK-7154662: {CRC32, Adler32}.update(byte[] b, int off,
	int len): undocumented ArrayIndexOutOfBoundsException
In-Reply-To: <520D0A41.3030209@oracle.com>
References: <520BD612.7000206@oracle.com> <520BF7B8.4030106@oracle.com>
	<520CC678.9010101@redhat.com> <520D0A41.3030209@oracle.com>
Message-ID: <520DDA9E.4090604@redhat.com>

On 08/15/2013 07:05 PM, Xueming Shen wrote:
> On 08/15/2013 05:15 AM, Florian Weimer wrote:
>> On 08/14/2013 11:33 PM, Chris Hegarty wrote:
>>>
>>> > * @throws  ArrayIndexOutOfBoundsException
>>> > *          if the {@code off} is negative, or the {@code len} is
>>> > *          negative, or the {@code off+len} is greater than the
>>> > *          length of the array {@code b}
>>>
>>> I agree that specifying this in CRC32 and Adler32 is the right thing to
>>> do. Trivially I'd drop the 'the' before the arguments, or maybe take the
>>> working from InputStream.read(byte[],int,int) :
>>>
>>>    "If off is negative, len is negative, or len is greater than b.length
>>>     - off"
>>
>> The InputStream wording is much better because it correctly covers the
>> off + len < 0 case. :-)

> The one I have (without that "the") is the outputstream version. I would
> assume it is equivalent to the inputstream version, given we have
> exclude the off < 0 and len < 0 cases :-)

It's not because off + len can overflow and turn into a negative value 
even if both operands are positive.  To me, using {@code ...} strongly 
suggests Java semantics.

(I might be wrong about this?I have made incorrect suggestions related 
to integer overflow detection in the past.)

-- 
Florian Weimer / Red Hat Product Security Team


From yiming.wang at oracle.com  Fri Aug 16 08:37:59 2013
From: yiming.wang at oracle.com (Eric Wang)
Date: Fri, 16 Aug 2013 16:37:59 +0800
Subject: Review quest for bug 8022879: sun/nio/cs/MalformedSurrogates.java
	fails intermittently
Message-ID: <520DE4E7.2070007@oracle.com>

Hi,

Please help to review the fix below for bug 
https://jbs.oracle.com/bugs/browse/JDK-8022879

http://cr.openjdk.java.net/~ewang/8022879/webrev.00/

The test has defect as it wouldn't be executed if the file.encoding is 
UTF-8 (lots of test machines in nightly are UTF-8), it also doesn't 
check UTF-16 and UTF-32 which can cause test fail too.

The fix is to check whether the default charset is unicode, if yes, use 
US-ASCII to test instead.

Thanks,
Eric


From vicente.romero at oracle.com  Fri Aug 16 09:33:30 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Fri, 16 Aug 2013 09:33:30 +0000
Subject: hg: jdk8/tl/langtools: 8022053: javac generates unverifiable
	initializer for nested subclass of local class
Message-ID: <20130816093341.F3A3D48927@hg.openjdk.java.net>

Changeset: a6378c19836b
Author:    vromero
Date:      2013-08-16 10:32 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a6378c19836b

8022053: javac generates unverifiable initializer for nested subclass of local class
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/T8022053/UnverifiableInitForNestedLocalClassTest.java



From miroslav.kos at oracle.com  Fri Aug 16 10:15:29 2013
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Fri, 16 Aug 2013 12:15:29 +0200
Subject: Update jdk8/tl/jaxws to v2.2.9-b14140 ready for review
Message-ID: <520DFBC1.3020207@oracle.com>

There is an update syncing JAX-WS sources in jdk8/tl/jaxws to most 
recent development version.

It is quite big changeset (13k+ LOC changed) and includes several bug fixes:

http://java.net/jira/browse/JAX_WS-1114 problem sending XML primitive 
type gMonth (the request ends up null on server)
http://java.net/jira/browse/JAX_WS-723 Provide target 2.1 option to 
generate classes as per JAX-WS 2.1
http://java.net/jira/browse/JAX_WS-653 Erroneous Class-Path ref. in 
Manifest of several jar files

http://java.net/jira/browse/JAXB-937 Nested unmarshalling can lead to 
NullPointerException
http://java.net/jira/browse/JAXB-643 Cannot use gMonth on jdk/jre 6

Please, see weberev here: 
http://cr.openjdk.java.net/~mkos/8022885/webrev.00/

Thanks
Miran


From paul.sandoz at oracle.com  Fri Aug 16 10:27:21 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 16 Aug 2013 12:27:21 +0200
Subject: RFR 8023150 java/util/stream tests no longer compiling following
	JDK-8019401 
Message-ID: <35458751-E905-4E43-A922-103EB91F7EAA@oracle.com>

Hi,

This patch fixes a compilation failure in the stream-based tests:

diff -r 5649837a4cfa test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java
--- a/test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java	Mon Aug 12 12:06:50 2013 -0400
+++ b/test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java	Fri Aug 16 12:13:18 2013 +0200
@@ -609,7 +609,7 @@
     @Test(dataProvider = "StreamTestData", dataProviderClass = StreamTestDataProvider.class)
     public void testComposeFinisher(String name, TestData.OfRef data) throws ReflectiveOperationException {
         List asList = exerciseTerminalOps(data, s -> s.collect(toList()));
-        List asImmutableList = exerciseTerminalOps(data, s -> s.collect(collectingAndThen(toList(), Collections::unmodifiableList)));
+        List asImmutableList = exerciseTerminalOps(data, s -> s.collect(collectingAndThen(toList(), Collections::unmodifiableList)));
         assertEquals(asList, asImmutableList);
         try {
             asImmutableList.add(0);


This test is the same (without the above patch applied) in the lambda repo and the code compiles without error. I suspect this is due to differences between javac behaviour in both repos.

Paul.

From chris.hegarty at oracle.com  Fri Aug 16 10:35:24 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 16 Aug 2013 11:35:24 +0100
Subject: RFR 8021820: Number of opened files used in select() is limited
	to 1024 [macosx]
In-Reply-To: <5209FA51.9060907@oracle.com>
References: <51F9007D.8090801@oracle.com> <51F9150B.4000008@oracle.com>
	<51F920A7.3000600@oracle.com> <51FF90BD.6070600@oracle.com>
	<52004DD9.4040202@oracle.com> <5202453F.2080409@oracle.com>
	<5202FDFF.1030906@oracle.com> <5209FA51.9060907@oracle.com>
Message-ID: <520E006C.8020009@oracle.com>

I see no objections to this, and I think it has been through enough 
review. I'll sponsor this change for Aleksej.

-Chris.

On 13/08/2013 10:20, Aleksej Efimov wrote:
> Stuart,
> Thanks for your comments.
> New webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.03/
> 
> Comments below.
>
> Thanks,
> Aleksej
>
> On 08/08/2013 06:10 AM, Stuart Marks wrote:
>> Hi Aleksej,
>>
>> Thanks for the update. The situation is a bit twisted.
>>
>> I picked up a couple clues from David Holmes and Jon Gibbons. The
>> NoClassDefFoundError occurs when the JVM has hit its resource limit
>> for the number of open files, *and* it is being run in a development
>> environment with individual class files in a hierarchy, e.g. within
>>
>> ROOT/build//jdk/classes
>>
>> In this case, since each class is in its own file, it's quite likely
>> that the loading of an individual class will fail because of lack of
>> file descriptors. If the JVM itself encounters this, it will generate
>> a NoClassDefFoundError without a stack trace such as the ones we've seen.
>>
>> If the test is being run against a fully built JDK image, classes are
>> loaded from rt.jar. This is usually already open, so quite often
>> classes can be loaded without having to open additional files. In this
>> case we get the FileNotFoundException as expected.
> It was very interesting and enlightening information. Thank you for
> that, I'll keep it in mind.
>>
>> The resource limits seem to vary from system to system, and even from
>> one Ubuntu version to the next (mine has a default hard limit of 1024
>> open files). Unfortunately, while it might seem reasonable to have
>> minimum specifications for systems on which we run tests, in practice
>> this has proven very difficult. Since the bug being fixed is Mac-only,
>> and the default open file limit for Mac seems to be unlimited, perhaps
>> it makes most sense for this to be a Mac-only test.
>>
>> From the discussion here [1] which refers to an Apple technote [2] it
>> seems like the best way to test for being on a Mac is something like
>> this:
>>
>> if (! System.getProperty("os.name").contains("OS X")) {
>> return;
>> }
>>
>> That is, report success if we're on anything other than a Mac.
> Agreed, there is no need to run this test on other platforms (the bug
> states only MacOSX) and as a good addition we don't need to worry about
> limits on other platforms. The suggested check was added to test. And it
> was executed on all platforms (without fix): all except MacOSX passes,
> on MacOSX expected result - "java.net.SocketException: Invalid argument".
>>
>> Once we're sure we're on a Mac, having the test fail if it can't open
>> enough files seems reasonable.
>>
>> I'd suggest putting a comment at the top of the test class saying that
>> this test *must* be run in othervm mode, to ensure that files are
>> closed properly. That way, you can take out the cleanupFiles() method
>> too, as well as avoiding lots of exception handling and related
>> cleanup code.
> Comment was added and cleanupFiles() method was removed as suggested.
>>
>> Finally, a style point: try/catch statements are conventionally
>> indented as a single multi-block, not as separate statements. I'd
>> suggest something like this:
>>
>> // The accept() call will throw SocketException if the
>> // select() has failed due to limitation on fds size,
>> // indicating test failure. A SocketTimeoutException
>> // is expected, so it is caught and ignored, and the test
>> // passes.
>>
>> try {
>> socket.accept();
>> } catch (SocketTimeoutException e) { }
> Fixed.
>>
>> s'marks
>>
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-November/005148.html
>>
>>
>> [2] https://developer.apple.com/library/mac/#technotes/tn2002/tn2110.html
>>
>>
>>
>> On 8/7/13 6:01 AM, Aleksej Efimov wrote:
>>> Stuart, thank you for you comments, responses are below.
>>> New webrev:
>>> http://cr.openjdk.java.net/~aefimov/8021820/webrev.02/
>>> 
>>>
>>>
>>> -Aleksej
>>>
>>> On 08/06/2013 05:14 AM, Stuart Marks wrote:
>>>> Hi Aleksej,
>>>>
>>>> Thanks for the update. I took a look at the revised test, and there
>>>> are still
>>>> some issues. (I didn't look at the build changes.)
>>>>
>>>> 1) System-specific resource limits.
>>>>
>>>> I think the biggest issue is resource limits on the number of open
>>>> files per
>>>> process that might vary from system to system. On my Ubuntu system,
>>>> the hard
>>>> limit on the number of open files is 1,024. The test opens 1,023
>>>> files and
>>>> then one more for the socket. Unfortunately the JVM and jtreg have
>>>> several
>>>> files open already, and the test crashes before the openFiles() method
>>>> completes.
>>>>
>>>> (Oddly it crashes with a NoClassDefFoundError from the main thread's
>>>> uncaught
>>>> exception handler, and then the test reports that it passed! Placing a
>>>> try/catch of Throwable in main() or openFiles() doesn't catch this
>>>> error. I
>>>> have no explanation for this. When run standalone -- i.e., not from
>>>> jtreg --
>>>> the test throws FileNotFoundException (too many open files) from
>>>> openFiles(),
>>>> which is expected.)
>>>>
>>>> On my Mac (10.7.5) the soft limit is 256 files, but the hard limit is
>>>> unlimited. The test succeeds in opening all its files but fails
>>>> because of
>>>> the select() bug you're fixing. (This is expected; I didn't rebuild
>>>> my JDK
>>>> with your patch.) I guess the soft limit doesn't do anything on Mac.
>>>>
>>>> Amazingly, the test passed fine on both Windows XP and Windows 8.
>>>>
>>>> I'm not entirely sure what to do about resource limits. Since the
>>>> test is
>>>> able to open >1024 files on Mac, Windows, and possibly other
>>>> Linuxes, it
>>>> seems reasonable to continue with this approach. If it's possible to
>>>> catch
>>>> the error that occurs if the test cannot open its initial 1,024 files,
>>>> perhaps it should do this, log a message indicating what happened, and
>>>> consider the test to have passed. I'm mystified by the
>>>> uncaught/uncatchable
>>>> NoClassDefFoundError though.
>>> I wonder if this is a question of test environment required for JTREG
>>> tests: if
>>> we'll execute JTREG tests with low value assigned to fd hard limit
>>> (for example
>>> 10) we'll see a lot of unrelated test failures. So, I suggest that we
>>> can
>>> assume that there is no hard limits set (or at least default ones,
>>> i.e. default
>>> fd limit on Ubuntu is 4096) on test machine. But we should consider
>>> test as
>>> Failed if test failed to prepare it's environment because of some
>>> external
>>> limitations. The JTREG doesn't meet this criteria (log test as PASS
>>> and prints
>>> incorrect Exception). To illustrate it I have repeated your
>>> experiments on
>>> ubuntu linux: set fd hard limit to 1024 (ulimit -Hn 1024) and got
>>> this error by
>>> manual run of test:
>>> Exception in thread "main" java.io.FileNotFoundException: testfile
>>> (Too many
>>> open files)
>>> at java.io.FileInputStream.open(Native Method)
>>> at java.io.FileInputStream.(FileInputStream.java:128)
>>> at SelectFdsLimit.openFiles(SelectFdsLimit.java:63)
>>> at SelectFdsLimit.main(SelectFdsLimit.java:81)
>>>
>>> Seems correct to me.
>>> An by JTREG (also with hard limit set to 1024):
>>> ----------messages:(3/123)----------
>>> command: main SelectFdsLimit
>>> reason: User specified action: run main/othervm SelectFdsLimit
>>> elapsed time (seconds): 0.168
>>> ----------System.out:(0/0)----------
>>> ----------System.err:(5/250)----------
>>>
>>> Exception: java.lang.NoClassDefFoundError thrown from the
>>> UncaughtExceptionHandler in thread "MainThread"
>>> STATUS:Passed.
>>> Exception in thread "main"
>>> Exception: java.lang.NoClassDefFoundError thrown from the
>>> UncaughtExceptionHandler in thread "main"
>>> result: Passed. Execution successful
>>>
>>>
>>> test result: Passed. Execution successful
>>>
>>>
>>> The results are identical to results mentioned by you. It seems to me
>>> that
>>> jtreg doesn't correctly processes such test error (at least it
>>> shouldn't be
>>> considered as Pass). And I suggest two ways of resolving it:
>>> 1. If we don't have official limitations (or default) on what
>>> resources test
>>> can use then we shouldn't do any modifications to test.
>>> 2. If there is some limitations that we should honor then we'll need
>>> to figure
>>> out what to do with NoClassDefFoundError exception in JTREG.
>>>
>>>>
>>>> 2) Closing files.
>>>>
>>>> If an exception is thrown while opening the initial set of files, or
>>>> sometime
>>>> during the closing process, the test can still leak files.
>>>>
>>>> One approach would be to keep a data structure representing the
>>>> current set
>>>> of open files, and close them all in a finally-block around all the
>>>> test
>>>> logic, and making sure that exceptions from the close() call are
>>>> caught and
>>>> do not prevent the rest of the files from being closed.
>>>>
>>>> This seems like a lot of work. Perhaps a more effective approach
>>>> would be to
>>>> run the test in "othervm" mode, as follows:
>>>>
>>>> @run main/othervm SelectFdsLimit
>>>>
>>>> This will cause the test to run in a dedicated JVM, so all files
>>>> will be
>>>> closed automatically when it exits. (It would be good to add a comment
>>>> explaining the need for othervm, if you do this.)
>>>>
>>> main/othervm and comments were added.
>>>> 3) Port number for sockets.
>>>>
>>>> It's fairly common for tests to fail occasionally because they use some
>>>> constant port number that sometimes happens to be in use at the same
>>>> time by
>>>> another process on the system. I have to say, 8080 is a pretty
>>>> common port
>>>> number. :-)
>>>>
>>>> For purposes of this test, you can let the system assign a port.
>>>> Just use:
>>>>
>>>> new ServerSocket(0)
>>>>
>>> Completely agree that 8080 port - bad port for testing =). Changed to 0.
>>>> 4) Style.
>>>>
>>>> It's probably possible to use the same File object for the test
>>>> file, instead
>>>> of creating new File objects repeatedly.
>>> Agree and corrected.
>>>>
>>>> It might be nice to add a comment explaining the logic of the test,
>>>> that
>>>> SocketTimeoutException is expected, and that failure will be
>>>> indicated if the
>>>> accept() throws SocketException caused by the underlying mishandling
>>>> of large
>>>> fds by select().
>>> Comments were added.
>>>>
>>>> Thanks,
>>>>
>>>> s'marks
>>>>
>>>>
>>>>
>>>> On 8/5/13 4:47 AM, Aleksej Efimov wrote:
>>>>> Alan, Tim,
>>>>>
>>>>> I have addressed your comments and as a result - new webrev:
>>>>> http://cr.openjdk.java.net/~aefimov/8021820/webrev.01
>>>>>
>>>>> The list of changes:
>>>>> 1. The connection to Oracle site is removed (it's not internal, but
>>>>> anyway it's
>>>>> better not to rely on availability of external resource in test).
>>>>> In current
>>>>> version a server socket is created and accept() method is used for bug
>>>>> disclosure.
>>>>> 2. The cleanup method is added for closing file streams. The JTREG
>>>>> successfully
>>>>> cleaned-up on windows after this modification.
>>>>> 3. common/autoconf/toolchain.m4 untouched, but 'bash
>>>>> common/autoconf/autogen.sh' was executed to update
>>>>> generated-configure.sh.
>>>>>
>>>>> Aleksej
>>>>>
>>>>>
>>>>> On 07/31/2013 06:35 PM, Tim Bell wrote:
>>>>>> Aleksej, Alan
>>>>>>
>>>>>> The change in common/autoconf/toolchain.m4 looks correct to me,
>>>>>> and I think
>>>>>> that is a good place to have it. Remember to run 'bash
>>>>>> common/autoconf/autogen.sh' and check in the
>>>>>> generated-configure.sh files as
>>>>>> part of the changeset.
>>>>>>
>>>>>> I didn't look at the test case, but I think Alan has some good
>>>>>> points.
>>>>>>
>>>>>> Tim
>>>>>>
>>>>>> On 07/31/13 06:45 AM, Alan Bateman wrote:
>>>>>>> On 31/07/2013 05:18, Aleksej Efimov wrote:
>>>>>>>> Hi,
>>>>>>>> Can I have a review for the following problem:
>>>>>>>> The MACOSX JDK (more precisely - the java.net classes) uses the
>>>>>>>> select()
>>>>>>>> system call to wait for different events on sockets fds. And the
>>>>>>>> default
>>>>>>>> behaviour for select() on Darwin is to fail when fdset contains
>>>>>>>> the fd with
>>>>>>>> id greater than FDSET_SIZE(=1024). Test case in webrev
>>>>>>>> illustrates this
>>>>>>>> behavior.
>>>>>>>> There is at least one solution for it: use
>>>>>>>> -D_DARWIN_UNLIMITED_SELECT
>>>>>>>> compilation flag for all macosx sources: this won't affect other
>>>>>>>> parts of
>>>>>>>> JDK because they are not using select().
>>>>>>>> Currently, I have added this compilation flag to
>>>>>>>> common/autoconf/generated-configure.sh and
>>>>>>>> common/autoconf/generated-configure.sh. I wonder, if there is a
>>>>>>>> better
>>>>>>>> place where I can put this flag?
>>>>>>>>
>>>>>>>> The webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.00/
>>>>>>>> BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021820
>>>>>>>
>>>>>>> Thanks for looking into this one. The build changes look okay to
>>>>>>> me but it's
>>>>>>> probably best that someone on build-dev agree to those.
>>>>>>> Michael McMahon can probably explain why the net code is using
>>>>>>> select for
>>>>>>> timed read/accept (I have a vague recollection of there being an
>>>>>>> issue with
>>>>>>> poll due to the way that it is implemented on kqueue with the
>>>>>>> result that it
>>>>>>> had to be changed to use select).
>>>>>>>
>>>>>>> I think the test needs re-work. It looks to me that the it
>>>>>>> attempts to
>>>>>>> connect to an Oracle internal site so that's not going to work
>>>>>>> everywhere.
>>>>>>> In general we don't want the tests to be dependent on hosts that
>>>>>>> may or may
>>>>>>> not exist (we had tests that used to this in the past but they
>>>>>>> caused a lot
>>>>>>> of grief). It also looks like the test doesn't close the 1023
>>>>>>> files that it
>>>>>>> opens at the start and so I assume this test will always fail on
>>>>>>> Windows
>>>>>>> when jtreg tries to clean-up.
>>>>>>>
>>>>>>> -Alan.
>>>>>>
>>>>>
>>>
>


From Alan.Bateman at oracle.com  Fri Aug 16 10:37:50 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 16 Aug 2013 11:37:50 +0100
Subject: RFR 8023150 java/util/stream tests no longer compiling following
	JDK-8019401
In-Reply-To: <35458751-E905-4E43-A922-103EB91F7EAA@oracle.com>
References: <35458751-E905-4E43-A922-103EB91F7EAA@oracle.com>
Message-ID: <520E00FE.8000005@oracle.com>

On 16/08/2013 11:27, Paul Sandoz wrote:
> Hi,
>
> This patch fixes a compilation failure in the stream-based tests:
>
> diff -r 5649837a4cfa test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java
> --- a/test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java	Mon Aug 12 12:06:50 2013 -0400
> +++ b/test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java	Fri Aug 16 12:13:18 2013 +0200
> @@ -609,7 +609,7 @@
>       @Test(dataProvider = "StreamTestData", dataProviderClass = StreamTestDataProvider.class)
>       public void testComposeFinisher(String name, TestData.OfRef  data) throws ReflectiveOperationException {
>           List  asList = exerciseTerminalOps(data, s ->  s.collect(toList()));
> -        List  asImmutableList = exerciseTerminalOps(data, s ->  s.collect(collectingAndThen(toList(), Collections::unmodifiableList)));
> +        List  asImmutableList = exerciseTerminalOps(data, s ->  s.collect(collectingAndThen(toList(), Collections::unmodifiableList)));
>           assertEquals(asList, asImmutableList);
>           try {
>               asImmutableList.add(0);
>
>
> This test is the same (without the above patch applied) in the lambda repo and the code compiles without error. I suspect this is due to differences between javac behaviour in both repos.
>
> Paul.
Looks okay to me, thanks for jumping on this.

-Alan.


From Alan.Bateman at oracle.com  Fri Aug 16 10:40:51 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 16 Aug 2013 11:40:51 +0100
Subject: RFR [6883354] File.mkdirs() method doesn't behave well when given
	/../
In-Reply-To: <52090717.3040106@oracle.com>
References: <52090717.3040106@oracle.com>
Message-ID: <520E01B3.5090808@oracle.com>

On 12/08/2013 17:02, Ivan Gerasimov wrote:
> Hello everybody!
>
> Would you please help review a small change to File.mkdirs() method?
>
> The current implementation of the method, when past an argument 
> "dir1/../dir2" only tries to create dir2.
> mkdir -p 'dir1/../dir2' command on Linux creates both dir1 and dir2.
> java.nio.file.Files.createDirectories() also creates both dir1 and dir2.
>
> The proposed fix makes File.mkdirs() method to behave in the same way 
> on all the platforms except for Windows.
>
> The problem with Windows is that it reports 'dir1/..' as existent even 
> if dir1 does not exist.
> Because of that Files.createDirectories() doesn't work this way on 
> Windows either.
>
> Proposed fix:
> - makes File.mkdirs() match the behavior of 'mkdir -p' on Linux, 
> Solaris and MacOS, and
> - doesn't change its behavior on Windows.
>
> http://cr.openjdk.java.net/~igerasim/6883354/0/webrev/
This is old code so we have to be cautious about changing it (and 
understanding why it used the canonical path in the first place). What 
would you think about adding a few tests to cover more types of file 
path, Windows drive-relative and directory-relative paths in particular 
as these are cases where we would need to confident that it doesn't break.

As an aside, Dan Xu and I were chatting recently about just replacing 
most of the java.io.File implementation to just use java.nio.file. This 
specific one is a case where it might be easier to just change the 
method to Files.createDirectories(toPath()).

-Alan.




From paul.sandoz at oracle.com  Fri Aug 16 10:41:09 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Fri, 16 Aug 2013 10:41:09 +0000
Subject: hg: jdk8/tl/jdk: 8023150: java/util/stream tests no longer compiling
	following JDK-8019401
Message-ID: <20130816104126.AC1FD4892A@hg.openjdk.java.net>

Changeset: 5fe19566b6f0
Author:    psandoz
Date:      2013-08-16 12:29 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5fe19566b6f0

8023150: java/util/stream tests no longer compiling following JDK-8019401
Reviewed-by: alanb

! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java



From Alan.Bateman at oracle.com  Fri Aug 16 10:43:37 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 16 Aug 2013 11:43:37 +0100
Subject: Update jdk8/tl/jaxws to v2.2.9-b14140 ready for review
In-Reply-To: <520DFBC1.3020207@oracle.com>
References: <520DFBC1.3020207@oracle.com>
Message-ID: <520E0259.6070206@oracle.com>

On 16/08/2013 11:15, Miroslav Kos wrote:
> There is an update syncing JAX-WS sources in jdk8/tl/jaxws to most 
> recent development version.
>
> It is quite big changeset (13k+ LOC changed) and includes several bug 
> fixes:
>
> http://java.net/jira/browse/JAX_WS-1114 problem sending XML primitive 
> type gMonth (the request ends up null on server)
> http://java.net/jira/browse/JAX_WS-723 Provide target 2.1 option to 
> generate classes as per JAX-WS 2.1
> http://java.net/jira/browse/JAX_WS-653 Erroneous Class-Path ref. in 
> Manifest of several jar files
>
> http://java.net/jira/browse/JAXB-937 Nested unmarshalling can lead to 
> NullPointerException
> http://java.net/jira/browse/JAXB-643 Cannot use gMonth on jdk/jre 6
>
> Please, see weberev here: 
> http://cr.openjdk.java.net/~mkos/8022885/webrev.00/
>
> Thanks
> Miran
I can't really comment on the changes as I don't know the JAX-WS code 
but you might need to double-check some of the copyrights. I see for 
example that the patch removes (rather than replaces) the copyright 
header on org/relaxng/datatype classes. I don't know if that is intended 
or not.

-Alan.


From paul.sandoz at oracle.com  Fri Aug 16 10:50:51 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Fri, 16 Aug 2013 10:50:51 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130816105116.052784892B@hg.openjdk.java.net>

Changeset: 2eebaff52a94
Author:    psandoz
Date:      2013-08-16 12:46 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2eebaff52a94

8012940: More than 50 tests failed in Serialization/DeSerialization testing (test-mangled)
Reviewed-by: ksrini

+ test/java/util/stream/bootlib/java/util/stream/LambdaTestMode.java
! test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java

Changeset: 02ce5a0e4b98
Author:    psandoz
Date:      2013-08-16 12:46 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/02ce5a0e4b98

8022898: java/util/Spliterator/SpliteratorCollisions.java fails in HashableIntSpliteratorWithNull data provider
Reviewed-by: henryjen, alanb, rriggs

! test/java/util/Spliterator/SpliteratorCollisions.java



From maurizio.cimadamore at oracle.com  Fri Aug 16 11:02:10 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 16 Aug 2013 11:02:10 +0000
Subject: hg: jdk8/tl/langtools: 2 new changesets
Message-ID: <20130816110219.73A474892C@hg.openjdk.java.net>

Changeset: ec77c7b46c37
Author:    jlahoda
Date:      2013-08-15 22:33 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ec77c7b46c37

8015809: More user friendly compile-time errors for uncaught exceptions in lambda expression
Summary: Producing individual errors for uncaught undeclared exceptions inside lambda expressions, rather than one error for the whole lambda
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
- test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java
+ test/tools/javac/lambda/ExceptionsInLambda.java
+ test/tools/javac/lambda/ExceptionsInLambda.out
! test/tools/javac/lambda/TargetType21.out

Changeset: f657d400c736
Author:    jlahoda
Date:      2013-08-15 22:36 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f657d400c736

8022508: javac crashes if the generics arity of a base class is wrong
Reviewed-by: mcimadamore, vromero

! src/share/classes/com/sun/tools/javac/comp/Check.java
! test/tools/javac/generics/8016640/T8016640.java



From paul.sandoz at oracle.com  Fri Aug 16 11:24:39 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Fri, 16 Aug 2013 11:24:39 +0000
Subject: hg: jdk8/tl/jdk: 8022797: Clarify spliterator characteristics for
	collections containing no elements
Message-ID: <20130816112450.C13654892E@hg.openjdk.java.net>

Changeset: 737b6c298d81
Author:    psandoz
Date:      2013-08-13 11:16 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/737b6c298d81

8022797: Clarify spliterator characteristics for collections containing no elements
Reviewed-by: alanb, mduigou

! src/share/classes/java/util/Collection.java



From scolebourne at joda.org  Fri Aug 16 12:09:23 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 16 Aug 2013 13:09:23 +0100
Subject: Java 8 RFR 8022109: Evaluate adding incrementExact,
	decrementExact, negateExact to java.lang.Math
In-Reply-To: <05756DEE-B95F-43DA-BF0A-0EECEF9EFD64@oracle.com>
References: <89EF1DE7-44AE-4099-A4CF-B7F97FA4A493@oracle.com>
	<05756DEE-B95F-43DA-BF0A-0EECEF9EFD64@oracle.com>
Message-ID: 

Thanks for getting these in.
Stephen

On 10 August 2013 02:26, Mike Duigou  wrote:
> Looks good to me. I am glad we were able to get this back into Java 8.
>
> Mike
>
> On Aug 9 2013, at 17:39 , Brian Burkhalter wrote:
>
>> Please review at your convenience:
>>
>> Issue http://bugs.sun.com/view_bug.do?bug_id=8022109
>> Webrev        http://cr.openjdk.java.net/~bpb/8022109/
>>
>> The update is to add the methods incrementExact(), decrementExact(), and negateExact() for int and long parameters to java.lang.Math.
>>
>> Thanks,
>>
>> Brian
>


From joel.franck at oracle.com  Fri Aug 16 12:17:39 2013
From: joel.franck at oracle.com (Joel Borggren-Franck)
Date: Fri, 16 Aug 2013 14:17:39 +0200
Subject: RFR: 8022343: j.l.Class.getAnnotatedSuperclass() doesn't return null
	in some cases
Message-ID: <20130816121739.GM12405@jfranck-desktop.jrpg.bea.com>

Hi

Please review this small fix for a type annotation reflection issue.

The javadoc spec for Class.getAnnotatedSuperclass says: 

 * If this Class represents either the Object class, an interface type, an
 * array type, a primitive type, or void, the return value is null.

The patch fixes this.

Webrev at: http://cr.openjdk.java.net/~jfranck/8022343/webrew.00/

Patch also included it at the end of this mail.

cheers
/Joel



diff -r b07b19182e40 src/share/classes/java/lang/Class.java
--- a/src/share/classes/java/lang/Class.java	Thu Aug 15 15:04:59 2013 +0100
+++ b/src/share/classes/java/lang/Class.java	Fri Aug 16 13:20:31 2013 +0200
@@ -3338,8 +3338,16 @@
      * @since 1.8
      */
     public AnnotatedType getAnnotatedSuperclass() {
-         return TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), getConstantPool(), this);
-}
+        if(this == Object.class ||
+                isInterface() ||
+                isArray() ||
+                isPrimitive() ||
+                this == Void.TYPE) {
+            return null;
+        }
+
+        return TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), getConstantPool(), this);
+    }
 
     /**
      * Returns an array of AnnotatedType objects that represent the use of types to
diff -r b07b19182e40 test/java/lang/annotation/TypeAnnotationReflection.java
--- a/test/java/lang/annotation/TypeAnnotationReflection.java	Thu Aug 15 15:04:59 2013 +0100
+++ b/test/java/lang/annotation/TypeAnnotationReflection.java	Fri Aug 16 13:20:31 2013 +0200
@@ -23,7 +23,7 @@
 
 /*
  * @test
- * @bug 8004698 8007073
+ * @bug 8004698 8007073 8022343
  * @summary Unit test for type annotations
  */
 
@@ -58,7 +58,7 @@
     }
 
     private static void testSuper() throws Exception {
-        check(Object.class.getAnnotatedSuperclass().getAnnotations().length == 0);
+        check(Object.class.getAnnotatedSuperclass() == null);
         check(Class.class.getAnnotatedSuperclass().getAnnotations().length == 0);
 
         AnnotatedType a;
diff -r b07b19182e40 test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java	Fri Aug 16 13:20:31 2013 +0200
@@ -0,0 +1,50 @@
+/*
+ * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+ * or visit www.oracle.com if you need additional information or have any
+ * questions.
+ */
+
+/*
+ * @test
+ * @bug 8022343
+ * @summary make sure Class.getAnnotatedSuperclass() returns null when specified to do so
+ */
+
+import java.util.*;
+import java.lang.annotation.*;
+import java.lang.reflect.*;
+import java.io.Serializable;
+
+public class GetAnnotatedSuperclass {
+    public static void main(String[] args) throws Exception {
+        check(Object.class.getAnnotatedSuperclass() == null);
+        check(If.class.getAnnotatedSuperclass() == null);
+        check(Object[].class.getAnnotatedSuperclass() == null);
+        check(void.class.getAnnotatedSuperclass() == null);
+        check(int.class.getAnnotatedSuperclass() == null);
+    }
+
+    private static void check(boolean b) {
+        if (!b)
+            throw new RuntimeException();
+    }
+    interface If {}
+}
+


From chris.hegarty at oracle.com  Fri Aug 16 12:46:01 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 16 Aug 2013 13:46:01 +0100
Subject: RFR 8023150 java/util/stream tests no longer compiling following
	JDK-8019401
In-Reply-To: <520E00FE.8000005@oracle.com>
References: <35458751-E905-4E43-A922-103EB91F7EAA@oracle.com>
	<520E00FE.8000005@oracle.com>
Message-ID: <520E1F09.4070002@oracle.com>

On 16/08/2013 11:37, Alan Bateman wrote:
> On 16/08/2013 11:27, Paul Sandoz wrote:
>> Hi,
>>
>> This patch fixes a compilation failure in the stream-based tests:
>>
>> diff -r 5649837a4cfa
>> test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java
>>
>> ---
>> a/test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java
>> Mon Aug 12 12:06:50 2013 -0400
>> +++
>> b/test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java
>> Fri Aug 16 12:13:18 2013 +0200
>> @@ -609,7 +609,7 @@
>> @Test(dataProvider = "StreamTestData", dataProviderClass =
>> StreamTestDataProvider.class)
>> public void testComposeFinisher(String name, TestData.OfRef
>> data) throws ReflectiveOperationException {
>> List asList = exerciseTerminalOps(data, s ->
>> s.collect(toList()));
>> - List asImmutableList = exerciseTerminalOps(data, s ->
>> s.collect(collectingAndThen(toList(), Collections::unmodifiableList)));
>> + List asImmutableList = exerciseTerminalOps(data, s ->
>> s.collect(collectingAndThen(toList(),
>> Collections::unmodifiableList)));
>> assertEquals(asList, asImmutableList);
>> try {
>> asImmutableList.add(0);
>>
>>
>> This test is the same (without the above patch applied) in the lambda
>> repo and the code compiles without error. I suspect this is due to
>> differences between javac behaviour in both repos.
>>
>> Paul.
> Looks okay to me, thanks for jumping on this.
+1

-Chris.

>
> -Alan.


From chris.hegarty at oracle.com  Fri Aug 16 12:56:42 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 16 Aug 2013 13:56:42 +0100
Subject: RFR 8022318: Document Spliterator characteristics and binding
	policy of java util concurrent collection impls
In-Reply-To: <6E333CCC-C11A-40D1-AF9B-AF822216ED21@oracle.com>
References: <6E333CCC-C11A-40D1-AF9B-AF822216ED21@oracle.com>
Message-ID: <520E218A.50505@oracle.com>

Looks ok to me.

-Chris.

On 12/08/2013 13:22, Paul Sandoz wrote:
> Hi,
>
> The following patch updates documentation for various spliterators in the j.u.concurrent package:
>
>    http://cr.openjdk.java.net/~psandoz/tl/JDK-8022318-concurrent-split-docs/webrev/
>
> This syncs from the 166 repo and the documentation is just clarifying stuff that was missing.  Many thanks to Martin for helping out with this.
>
> There are a few additional tweaks here and there that are included, the only non-formating/non-documentation tweak is to SynchronousQueue.iterator():
>
> -    @SuppressWarnings("unchecked")
>       public Iterator  iterator() {
> -        return (Iterator) EmptyIterator.EMPTY_ITERATOR;
> -    }
> -
> -    // Replicated from a previous version of Collections
> -    private static class EmptyIterator  implements Iterator  {
> -        static final EmptyIterator  EMPTY_ITERATOR
> -            = new EmptyIterator();
> -
> -        public boolean hasNext() { return false; }
> -        public E next() { throw new NoSuchElementException(); }
> -        public void remove() { throw new IllegalStateException(); }
> +        return Collections.emptyIterator();
>       }
>
> Paul.


From vicente.romero at oracle.com  Fri Aug 16 13:07:44 2013
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Fri, 16 Aug 2013 14:07:44 +0100
Subject: RFR: 8022343: j.l.Class.getAnnotatedSuperclass() doesn't return
	null in some cases
In-Reply-To: <20130816121739.GM12405@jfranck-desktop.jrpg.bea.com>
References: <20130816121739.GM12405@jfranck-desktop.jrpg.bea.com>
Message-ID: <520E2420.3000007@oracle.com>

It looks OK for me,

Vicente

On 16/08/13 13:17, Joel Borggren-Franck wrote:
> Hi
>
> Please review this small fix for a type annotation reflection issue.
>
> The javadoc spec for Class.getAnnotatedSuperclass says:
>
>   * If this Class represents either the Object class, an interface type, an
>   * array type, a primitive type, or void, the return value is null.
>
> The patch fixes this.
>
> Webrev at: http://cr.openjdk.java.net/~jfranck/8022343/webrew.00/
>
> Patch also included it at the end of this mail.
>
> cheers
> /Joel
>
>
>
> diff -r b07b19182e40 src/share/classes/java/lang/Class.java
> --- a/src/share/classes/java/lang/Class.java	Thu Aug 15 15:04:59 2013 +0100
> +++ b/src/share/classes/java/lang/Class.java	Fri Aug 16 13:20:31 2013 +0200
> @@ -3338,8 +3338,16 @@
>        * @since 1.8
>        */
>       public AnnotatedType getAnnotatedSuperclass() {
> -         return TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), getConstantPool(), this);
> -}
> +        if(this == Object.class ||
> +                isInterface() ||
> +                isArray() ||
> +                isPrimitive() ||
> +                this == Void.TYPE) {
> +            return null;
> +        }
> +
> +        return TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), getConstantPool(), this);
> +    }
>   
>       /**
>        * Returns an array of AnnotatedType objects that represent the use of types to
> diff -r b07b19182e40 test/java/lang/annotation/TypeAnnotationReflection.java
> --- a/test/java/lang/annotation/TypeAnnotationReflection.java	Thu Aug 15 15:04:59 2013 +0100
> +++ b/test/java/lang/annotation/TypeAnnotationReflection.java	Fri Aug 16 13:20:31 2013 +0200
> @@ -23,7 +23,7 @@
>   
>   /*
>    * @test
> - * @bug 8004698 8007073
> + * @bug 8004698 8007073 8022343
>    * @summary Unit test for type annotations
>    */
>   
> @@ -58,7 +58,7 @@
>       }
>   
>       private static void testSuper() throws Exception {
> -        check(Object.class.getAnnotatedSuperclass().getAnnotations().length == 0);
> +        check(Object.class.getAnnotatedSuperclass() == null);
>           check(Class.class.getAnnotatedSuperclass().getAnnotations().length == 0);
>   
>           AnnotatedType a;
> diff -r b07b19182e40 test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java	Fri Aug 16 13:20:31 2013 +0200
> @@ -0,0 +1,50 @@
> +/*
> + * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> + *
> + * This code is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 only, as
> + * published by the Free Software Foundation.
> + *
> + * This code is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> + * version 2 for more details (a copy is included in the LICENSE file that
> + * accompanied this code).
> + *
> + * You should have received a copy of the GNU General Public License version
> + * 2 along with this work; if not, write to the Free Software Foundation,
> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> + *
> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
> + * or visit www.oracle.com if you need additional information or have any
> + * questions.
> + */
> +
> +/*
> + * @test
> + * @bug 8022343
> + * @summary make sure Class.getAnnotatedSuperclass() returns null when specified to do so
> + */
> +
> +import java.util.*;
> +import java.lang.annotation.*;
> +import java.lang.reflect.*;
> +import java.io.Serializable;
> +
> +public class GetAnnotatedSuperclass {
> +    public static void main(String[] args) throws Exception {
> +        check(Object.class.getAnnotatedSuperclass() == null);
> +        check(If.class.getAnnotatedSuperclass() == null);
> +        check(Object[].class.getAnnotatedSuperclass() == null);
> +        check(void.class.getAnnotatedSuperclass() == null);
> +        check(int.class.getAnnotatedSuperclass() == null);
> +    }
> +
> +    private static void check(boolean b) {
> +        if (!b)
> +            throw new RuntimeException();
> +    }
> +    interface If {}
> +}
> +



From ivan.gerasimov at oracle.com  Fri Aug 16 13:12:33 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 16 Aug 2013 17:12:33 +0400
Subject: RFR [7129312] BufferedInputStream calculates negative array size
	with large streams and mark
Message-ID: <520E2541.9020505@oracle.com>

Hello everybody!

It was reported that BufferedInputStream#read() method may throw 
NegativeArraySizeException.
This is due to doubling the buffer size in the fill() method without 
checking for a possible overflow.

BUG: http://bugs.sun.com/view_bug.do?bug_id=7129312

Affected versions of jdk are 6, 7 and 8

Would you please help review a fix?
http://cr.openjdk.java.net/~igerasim/7129312/0/webrev/

It uses approach similar to what was suggested for 8020669: The 
maximumBufferSize = (Integer.MAX_INTEGER - 8) constant is introduced and 
we don't make attempts to allocate a bigger array.

Please note, that the sample code as it was originally reported still 
doesn't work. That's because that setting 
buffStream.mark(Integer.MAX_VALUE) actually means that buffStream will 
have to try to allocate an array of that size given a large enough input.

Sincerely yours,
Ivan




From martinrb at google.com  Fri Aug 16 13:45:31 2013
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 16 Aug 2013 06:45:31 -0700
Subject: RFR 8022318: Document Spliterator characteristics and binding
	policy of java util concurrent collection impls
In-Reply-To: <6E333CCC-C11A-40D1-AF9B-AF822216ED21@oracle.com>
References: <6E333CCC-C11A-40D1-AF9B-AF822216ED21@oracle.com>
Message-ID: 

Thanks, Paul.

I made a mistake with the anchor name in package-info.java.
s/WeaklyConsistent/Weakly/
Fix is already in latest jsr166.  Resync package-info.java.
Else looks good.

TODO: all collection class documentation referring to iterators needs to be
examined to check whether it needs to be updated to refer to "iterators and
spliterators".


On Mon, Aug 12, 2013 at 5:22 AM, Paul Sandoz  wrote:

> Hi,
>
> The following patch updates documentation for various spliterators in the
> j.u.concurrent package:
>
>
> http://cr.openjdk.java.net/~psandoz/tl/JDK-8022318-concurrent-split-docs/webrev/
>
> This syncs from the 166 repo and the documentation is just clarifying
> stuff that was missing.  Many thanks to Martin for helping out with this.
>
> There are a few additional tweaks here and there that are included, the
> only non-formating/non-documentation tweak is to
> SynchronousQueue.iterator():
>
> -    @SuppressWarnings("unchecked")
>      public Iterator iterator() {
> -        return (Iterator) EmptyIterator.EMPTY_ITERATOR;
> -    }
> -
> -    // Replicated from a previous version of Collections
> -    private static class EmptyIterator implements Iterator {
> -        static final EmptyIterator EMPTY_ITERATOR
> -            = new EmptyIterator();
> -
> -        public boolean hasNext() { return false; }
> -        public E next() { throw new NoSuchElementException(); }
> -        public void remove() { throw new IllegalStateException(); }
> +        return Collections.emptyIterator();
>      }
>
> Paul.


From erik.joelsson at oracle.com  Fri Aug 16 14:00:31 2013
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 16 Aug 2013 14:00:31 +0000
Subject: hg: jdk8/tl/langtools: 8023146: Sjavac test failes in langtools
	nightly
Message-ID: <20130816140037.E276D48935@hg.openjdk.java.net>

Changeset: 4300c2f5fb1b
Author:    erikj
Date:      2013-08-16 16:00 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4300c2f5fb1b

8023146: Sjavac test failes in langtools nightly
Reviewed-by: mcimadamore, jfranck

! test/tools/sjavac/SJavac.java



From paul.sandoz at oracle.com  Fri Aug 16 14:02:31 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 16 Aug 2013 16:02:31 +0200
Subject: RFR 8022318: Document Spliterator characteristics and binding
	policy of java util concurrent collection impls
In-Reply-To: 
References: <6E333CCC-C11A-40D1-AF9B-AF822216ED21@oracle.com>
	
Message-ID: <4107C7B8-AFB2-4CE3-8C30-F76E1DB86AE5@oracle.com>

On Aug 16, 2013, at 3:45 PM, Martin Buchholz  wrote:
> Thanks, Paul.
> 
> I made a mistake with the anchor name in package-info.java. s/WeaklyConsistent/Weakly/
> Fix is already in latest jsr166.  Resync package-info.java.

Thanks, i caught that one and updated my patch.


> Else looks good.
> 
> TODO: all collection class documentation referring to iterators needs to be examined to check whether it needs to be updated to refer to "iterators and spliterators".
> 

Yes, good point, we need to do another pass over this area.

Paul.

From martinrb at google.com  Fri Aug 16 14:19:45 2013
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 16 Aug 2013 07:19:45 -0700
Subject: Review quest for bug 8022879: sun/nio/cs/MalformedSurrogates.java
	fails intermittently
In-Reply-To: <520DE4E7.2070007@oracle.com>
References: <520DE4E7.2070007@oracle.com>
Message-ID: 

This test remains clearly buggy, at least in theory - the user could have a
default charset named UTFred that does not handle unicode.  I think the
test also depends on the replacement.

The test could be made more robust and also get more coverage by iterating
over all available charsets, (or unconditionally using e.g. US-ASCII)

It's possible to check for encodability using
http://docs.oracle.com/javase/7/docs/api/java/nio/charset/CharsetEncoder.html#canEncode(java.lang.CharSequence)

It's possible to get the replacement byte array using
http://docs.oracle.com/javase/7/docs/api/java/nio/charset/CharsetEncoder.html#replacement()



On Fri, Aug 16, 2013 at 1:37 AM, Eric Wang  wrote:

> Hi,
>
> Please help to review the fix below for bug https://jbs.oracle.com/bugs/**
> browse/JDK-8022879 
>
> http://cr.openjdk.java.net/~**ewang/8022879/webrev.00/
>
> The test has defect as it wouldn't be executed if the file.encoding is
> UTF-8 (lots of test machines in nightly are UTF-8), it also doesn't check
> UTF-16 and UTF-32 which can cause test fail too.
>
> The fix is to check whether the default charset is unicode, if yes, use
> US-ASCII to test instead.
>
> Thanks,
> Eric
>


From martinrb at google.com  Fri Aug 16 14:22:38 2013
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 16 Aug 2013 07:22:38 -0700
Subject: RFR 8022318: Document Spliterator characteristics and binding
	policy of java util concurrent collection impls
In-Reply-To: <4107C7B8-AFB2-4CE3-8C30-F76E1DB86AE5@oracle.com>
References: <6E333CCC-C11A-40D1-AF9B-AF822216ED21@oracle.com>
	
	<4107C7B8-AFB2-4CE3-8C30-F76E1DB86AE5@oracle.com>
Message-ID: 

On Fri, Aug 16, 2013 at 7:02 AM, Paul Sandoz  wrote:

> On Aug 16, 2013, at 3:45 PM, Martin Buchholz  wrote:
> > Thanks, Paul.
> >
> > I made a mistake with the anchor name in package-info.java.
> s/WeaklyConsistent/Weakly/
> > Fix is already in latest jsr166.  Resync package-info.java.
>
> Thanks, i caught that one and updated my patch.
>
>
Do you need to refresh the webrev?


From paul.sandoz at oracle.com  Fri Aug 16 14:27:05 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 16 Aug 2013 16:27:05 +0200
Subject: RFR 8022318: Document Spliterator characteristics and binding
	policy of java util concurrent collection impls
In-Reply-To: 
References: <6E333CCC-C11A-40D1-AF9B-AF822216ED21@oracle.com>
	
	<4107C7B8-AFB2-4CE3-8C30-F76E1DB86AE5@oracle.com>
	
Message-ID: <09004062-861D-4EE1-BA2F-109E095876D5@oracle.com>

On Aug 16, 2013, at 4:22 PM, Martin Buchholz  wrote:
> 
> 
> 
> On Fri, Aug 16, 2013 at 7:02 AM, Paul Sandoz  wrote:
> On Aug 16, 2013, at 3:45 PM, Martin Buchholz  wrote:
> > Thanks, Paul.
> >
> > I made a mistake with the anchor name in package-info.java. s/WeaklyConsistent/Weakly/
> > Fix is already in latest jsr166.  Resync package-info.java.
> 
> Thanks, i caught that one and updated my patch.
> 
> 
> Do you need to refresh the webrev? 

I was not going to bother, since it's just one line of change.

Paul.

From aleksej.efimov at oracle.com  Fri Aug 16 14:51:30 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Fri, 16 Aug 2013 18:51:30 +0400
Subject: RFR 8021820: Number of opened files used in select() is limited
	to 1024 [macosx]
In-Reply-To: <520E006C.8020009@oracle.com>
References: <51F9007D.8090801@oracle.com> <51F9150B.4000008@oracle.com>
	<51F920A7.3000600@oracle.com> <51FF90BD.6070600@oracle.com>
	<52004DD9.4040202@oracle.com> <5202453F.2080409@oracle.com>
	<5202FDFF.1030906@oracle.com> <5209FA51.9060907@oracle.com>
	<520E006C.8020009@oracle.com>
Message-ID: <520E3C72.5090009@oracle.com>

Chris,
Thank you for review and for sponsorship.
  I have prepared hg changeset patches for root and jdk repositories:
root repo patch: http://cr.openjdk.java.net/~aefimov/8021820/jdk8_hg.export
jdk repo patch: 
http://cr.openjdk.java.net/~aefimov/8021820/jdk_jdk8_hg.export
I think if there is no objections - we can do the push.

Thank you
-Aleksej


On 16.08.2013 14:35, Chris Hegarty wrote:
> I see no objections to this, and I think it has been through enough 
> review. I'll sponsor this change for Aleksej.
>
> -Chris.
>
> On 13/08/2013 10:20, Aleksej Efimov wrote:
>> Stuart,
>> Thanks for your comments.
>> New webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.03/
>> 
>> Comments below.
>>
>> Thanks,
>> Aleksej
>>
>> On 08/08/2013 06:10 AM, Stuart Marks wrote:
>>> Hi Aleksej,
>>>
>>> Thanks for the update. The situation is a bit twisted.
>>>
>>> I picked up a couple clues from David Holmes and Jon Gibbons. The
>>> NoClassDefFoundError occurs when the JVM has hit its resource limit
>>> for the number of open files, *and* it is being run in a development
>>> environment with individual class files in a hierarchy, e.g. within
>>>
>>> ROOT/build//jdk/classes
>>>
>>> In this case, since each class is in its own file, it's quite likely
>>> that the loading of an individual class will fail because of lack of
>>> file descriptors. If the JVM itself encounters this, it will generate
>>> a NoClassDefFoundError without a stack trace such as the ones we've 
>>> seen.
>>>
>>> If the test is being run against a fully built JDK image, classes are
>>> loaded from rt.jar. This is usually already open, so quite often
>>> classes can be loaded without having to open additional files. In this
>>> case we get the FileNotFoundException as expected.
>> It was very interesting and enlightening information. Thank you for
>> that, I'll keep it in mind.
>>>
>>> The resource limits seem to vary from system to system, and even from
>>> one Ubuntu version to the next (mine has a default hard limit of 1024
>>> open files). Unfortunately, while it might seem reasonable to have
>>> minimum specifications for systems on which we run tests, in practice
>>> this has proven very difficult. Since the bug being fixed is Mac-only,
>>> and the default open file limit for Mac seems to be unlimited, perhaps
>>> it makes most sense for this to be a Mac-only test.
>>>
>>> From the discussion here [1] which refers to an Apple technote [2] it
>>> seems like the best way to test for being on a Mac is something like
>>> this:
>>>
>>> if (! System.getProperty("os.name").contains("OS X")) {
>>> return;
>>> }
>>>
>>> That is, report success if we're on anything other than a Mac.
>> Agreed, there is no need to run this test on other platforms (the bug
>> states only MacOSX) and as a good addition we don't need to worry about
>> limits on other platforms. The suggested check was added to test. And it
>> was executed on all platforms (without fix): all except MacOSX passes,
>> on MacOSX expected result - "java.net.SocketException: Invalid 
>> argument".
>>>
>>> Once we're sure we're on a Mac, having the test fail if it can't open
>>> enough files seems reasonable.
>>>
>>> I'd suggest putting a comment at the top of the test class saying that
>>> this test *must* be run in othervm mode, to ensure that files are
>>> closed properly. That way, you can take out the cleanupFiles() method
>>> too, as well as avoiding lots of exception handling and related
>>> cleanup code.
>> Comment was added and cleanupFiles() method was removed as suggested.
>>>
>>> Finally, a style point: try/catch statements are conventionally
>>> indented as a single multi-block, not as separate statements. I'd
>>> suggest something like this:
>>>
>>> // The accept() call will throw SocketException if the
>>> // select() has failed due to limitation on fds size,
>>> // indicating test failure. A SocketTimeoutException
>>> // is expected, so it is caught and ignored, and the test
>>> // passes.
>>>
>>> try {
>>> socket.accept();
>>> } catch (SocketTimeoutException e) { }
>> Fixed.
>>>
>>> s'marks
>>>
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-November/005148.html 
>>>
>>>
>>>
>>> [2] 
>>> https://developer.apple.com/library/mac/#technotes/tn2002/tn2110.html
>>>
>>>
>>>
>>> On 8/7/13 6:01 AM, Aleksej Efimov wrote:
>>>> Stuart, thank you for you comments, responses are below.
>>>> New webrev:
>>>> http://cr.openjdk.java.net/~aefimov/8021820/webrev.02/
>>>> 
>>>>
>>>>
>>>> -Aleksej
>>>>
>>>> On 08/06/2013 05:14 AM, Stuart Marks wrote:
>>>>> Hi Aleksej,
>>>>>
>>>>> Thanks for the update. I took a look at the revised test, and there
>>>>> are still
>>>>> some issues. (I didn't look at the build changes.)
>>>>>
>>>>> 1) System-specific resource limits.
>>>>>
>>>>> I think the biggest issue is resource limits on the number of open
>>>>> files per
>>>>> process that might vary from system to system. On my Ubuntu system,
>>>>> the hard
>>>>> limit on the number of open files is 1,024. The test opens 1,023
>>>>> files and
>>>>> then one more for the socket. Unfortunately the JVM and jtreg have
>>>>> several
>>>>> files open already, and the test crashes before the openFiles() 
>>>>> method
>>>>> completes.
>>>>>
>>>>> (Oddly it crashes with a NoClassDefFoundError from the main thread's
>>>>> uncaught
>>>>> exception handler, and then the test reports that it passed! 
>>>>> Placing a
>>>>> try/catch of Throwable in main() or openFiles() doesn't catch this
>>>>> error. I
>>>>> have no explanation for this. When run standalone -- i.e., not from
>>>>> jtreg --
>>>>> the test throws FileNotFoundException (too many open files) from
>>>>> openFiles(),
>>>>> which is expected.)
>>>>>
>>>>> On my Mac (10.7.5) the soft limit is 256 files, but the hard limit is
>>>>> unlimited. The test succeeds in opening all its files but fails
>>>>> because of
>>>>> the select() bug you're fixing. (This is expected; I didn't rebuild
>>>>> my JDK
>>>>> with your patch.) I guess the soft limit doesn't do anything on Mac.
>>>>>
>>>>> Amazingly, the test passed fine on both Windows XP and Windows 8.
>>>>>
>>>>> I'm not entirely sure what to do about resource limits. Since the
>>>>> test is
>>>>> able to open >1024 files on Mac, Windows, and possibly other
>>>>> Linuxes, it
>>>>> seems reasonable to continue with this approach. If it's possible to
>>>>> catch
>>>>> the error that occurs if the test cannot open its initial 1,024 
>>>>> files,
>>>>> perhaps it should do this, log a message indicating what happened, 
>>>>> and
>>>>> consider the test to have passed. I'm mystified by the
>>>>> uncaught/uncatchable
>>>>> NoClassDefFoundError though.
>>>> I wonder if this is a question of test environment required for JTREG
>>>> tests: if
>>>> we'll execute JTREG tests with low value assigned to fd hard limit
>>>> (for example
>>>> 10) we'll see a lot of unrelated test failures. So, I suggest that we
>>>> can
>>>> assume that there is no hard limits set (or at least default ones,
>>>> i.e. default
>>>> fd limit on Ubuntu is 4096) on test machine. But we should consider
>>>> test as
>>>> Failed if test failed to prepare it's environment because of some
>>>> external
>>>> limitations. The JTREG doesn't meet this criteria (log test as PASS
>>>> and prints
>>>> incorrect Exception). To illustrate it I have repeated your
>>>> experiments on
>>>> ubuntu linux: set fd hard limit to 1024 (ulimit -Hn 1024) and got
>>>> this error by
>>>> manual run of test:
>>>> Exception in thread "main" java.io.FileNotFoundException: testfile
>>>> (Too many
>>>> open files)
>>>> at java.io.FileInputStream.open(Native Method)
>>>> at java.io.FileInputStream.(FileInputStream.java:128)
>>>> at SelectFdsLimit.openFiles(SelectFdsLimit.java:63)
>>>> at SelectFdsLimit.main(SelectFdsLimit.java:81)
>>>>
>>>> Seems correct to me.
>>>> An by JTREG (also with hard limit set to 1024):
>>>> ----------messages:(3/123)----------
>>>> command: main SelectFdsLimit
>>>> reason: User specified action: run main/othervm SelectFdsLimit
>>>> elapsed time (seconds): 0.168
>>>> ----------System.out:(0/0)----------
>>>> ----------System.err:(5/250)----------
>>>>
>>>> Exception: java.lang.NoClassDefFoundError thrown from the
>>>> UncaughtExceptionHandler in thread "MainThread"
>>>> STATUS:Passed.
>>>> Exception in thread "main"
>>>> Exception: java.lang.NoClassDefFoundError thrown from the
>>>> UncaughtExceptionHandler in thread "main"
>>>> result: Passed. Execution successful
>>>>
>>>>
>>>> test result: Passed. Execution successful
>>>>
>>>>
>>>> The results are identical to results mentioned by you. It seems to me
>>>> that
>>>> jtreg doesn't correctly processes such test error (at least it
>>>> shouldn't be
>>>> considered as Pass). And I suggest two ways of resolving it:
>>>> 1. If we don't have official limitations (or default) on what
>>>> resources test
>>>> can use then we shouldn't do any modifications to test.
>>>> 2. If there is some limitations that we should honor then we'll need
>>>> to figure
>>>> out what to do with NoClassDefFoundError exception in JTREG.
>>>>
>>>>>
>>>>> 2) Closing files.
>>>>>
>>>>> If an exception is thrown while opening the initial set of files, or
>>>>> sometime
>>>>> during the closing process, the test can still leak files.
>>>>>
>>>>> One approach would be to keep a data structure representing the
>>>>> current set
>>>>> of open files, and close them all in a finally-block around all the
>>>>> test
>>>>> logic, and making sure that exceptions from the close() call are
>>>>> caught and
>>>>> do not prevent the rest of the files from being closed.
>>>>>
>>>>> This seems like a lot of work. Perhaps a more effective approach
>>>>> would be to
>>>>> run the test in "othervm" mode, as follows:
>>>>>
>>>>> @run main/othervm SelectFdsLimit
>>>>>
>>>>> This will cause the test to run in a dedicated JVM, so all files
>>>>> will be
>>>>> closed automatically when it exits. (It would be good to add a 
>>>>> comment
>>>>> explaining the need for othervm, if you do this.)
>>>>>
>>>> main/othervm and comments were added.
>>>>> 3) Port number for sockets.
>>>>>
>>>>> It's fairly common for tests to fail occasionally because they use 
>>>>> some
>>>>> constant port number that sometimes happens to be in use at the same
>>>>> time by
>>>>> another process on the system. I have to say, 8080 is a pretty
>>>>> common port
>>>>> number. :-)
>>>>>
>>>>> For purposes of this test, you can let the system assign a port.
>>>>> Just use:
>>>>>
>>>>> new ServerSocket(0)
>>>>>
>>>> Completely agree that 8080 port - bad port for testing =). Changed 
>>>> to 0.
>>>>> 4) Style.
>>>>>
>>>>> It's probably possible to use the same File object for the test
>>>>> file, instead
>>>>> of creating new File objects repeatedly.
>>>> Agree and corrected.
>>>>>
>>>>> It might be nice to add a comment explaining the logic of the test,
>>>>> that
>>>>> SocketTimeoutException is expected, and that failure will be
>>>>> indicated if the
>>>>> accept() throws SocketException caused by the underlying mishandling
>>>>> of large
>>>>> fds by select().
>>>> Comments were added.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> s'marks
>>>>>
>>>>>
>>>>>
>>>>> On 8/5/13 4:47 AM, Aleksej Efimov wrote:
>>>>>> Alan, Tim,
>>>>>>
>>>>>> I have addressed your comments and as a result - new webrev:
>>>>>> http://cr.openjdk.java.net/~aefimov/8021820/webrev.01
>>>>>>
>>>>>> The list of changes:
>>>>>> 1. The connection to Oracle site is removed (it's not internal, but
>>>>>> anyway it's
>>>>>> better not to rely on availability of external resource in test).
>>>>>> In current
>>>>>> version a server socket is created and accept() method is used 
>>>>>> for bug
>>>>>> disclosure.
>>>>>> 2. The cleanup method is added for closing file streams. The JTREG
>>>>>> successfully
>>>>>> cleaned-up on windows after this modification.
>>>>>> 3. common/autoconf/toolchain.m4 untouched, but 'bash
>>>>>> common/autoconf/autogen.sh' was executed to update
>>>>>> generated-configure.sh.
>>>>>>
>>>>>> Aleksej
>>>>>>
>>>>>>
>>>>>> On 07/31/2013 06:35 PM, Tim Bell wrote:
>>>>>>> Aleksej, Alan
>>>>>>>
>>>>>>> The change in common/autoconf/toolchain.m4 looks correct to me,
>>>>>>> and I think
>>>>>>> that is a good place to have it. Remember to run 'bash
>>>>>>> common/autoconf/autogen.sh' and check in the
>>>>>>> generated-configure.sh files as
>>>>>>> part of the changeset.
>>>>>>>
>>>>>>> I didn't look at the test case, but I think Alan has some good
>>>>>>> points.
>>>>>>>
>>>>>>> Tim
>>>>>>>
>>>>>>> On 07/31/13 06:45 AM, Alan Bateman wrote:
>>>>>>>> On 31/07/2013 05:18, Aleksej Efimov wrote:
>>>>>>>>> Hi,
>>>>>>>>> Can I have a review for the following problem:
>>>>>>>>> The MACOSX JDK (more precisely - the java.net classes) uses the
>>>>>>>>> select()
>>>>>>>>> system call to wait for different events on sockets fds. And the
>>>>>>>>> default
>>>>>>>>> behaviour for select() on Darwin is to fail when fdset contains
>>>>>>>>> the fd with
>>>>>>>>> id greater than FDSET_SIZE(=1024). Test case in webrev
>>>>>>>>> illustrates this
>>>>>>>>> behavior.
>>>>>>>>> There is at least one solution for it: use
>>>>>>>>> -D_DARWIN_UNLIMITED_SELECT
>>>>>>>>> compilation flag for all macosx sources: this won't affect other
>>>>>>>>> parts of
>>>>>>>>> JDK because they are not using select().
>>>>>>>>> Currently, I have added this compilation flag to
>>>>>>>>> common/autoconf/generated-configure.sh and
>>>>>>>>> common/autoconf/generated-configure.sh. I wonder, if there is a
>>>>>>>>> better
>>>>>>>>> place where I can put this flag?
>>>>>>>>>
>>>>>>>>> The webrev: 
>>>>>>>>> http://cr.openjdk.java.net/~aefimov/8021820/webrev.00/
>>>>>>>>> BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021820
>>>>>>>>
>>>>>>>> Thanks for looking into this one. The build changes look okay to
>>>>>>>> me but it's
>>>>>>>> probably best that someone on build-dev agree to those.
>>>>>>>> Michael McMahon can probably explain why the net code is using
>>>>>>>> select for
>>>>>>>> timed read/accept (I have a vague recollection of there being an
>>>>>>>> issue with
>>>>>>>> poll due to the way that it is implemented on kqueue with the
>>>>>>>> result that it
>>>>>>>> had to be changed to use select).
>>>>>>>>
>>>>>>>> I think the test needs re-work. It looks to me that the it
>>>>>>>> attempts to
>>>>>>>> connect to an Oracle internal site so that's not going to work
>>>>>>>> everywhere.
>>>>>>>> In general we don't want the tests to be dependent on hosts that
>>>>>>>> may or may
>>>>>>>> not exist (we had tests that used to this in the past but they
>>>>>>>> caused a lot
>>>>>>>> of grief). It also looks like the test doesn't close the 1023
>>>>>>>> files that it
>>>>>>>> opens at the start and so I assume this test will always fail on
>>>>>>>> Windows
>>>>>>>> when jtreg tries to clean-up.
>>>>>>>>
>>>>>>>> -Alan.
>>>>>>>
>>>>>>
>>>>
>>



From ivan.gerasimov at oracle.com  Fri Aug 16 16:32:30 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 16 Aug 2013 20:32:30 +0400
Subject: RFR [7129312] BufferedInputStream calculates negative array size
	with large streams and mark
In-Reply-To: <520E2541.9020505@oracle.com>
References: <520E2541.9020505@oracle.com>
Message-ID: <520E541E.1060403@oracle.com>

Sorry, the webrev happened to be empty.

Here's the full one: 
http://cr.openjdk.java.net/~igerasim/7129312/1/webrev/ 


Sincerely yours,
Ivan


On 16.08.2013 17:12, Ivan Gerasimov wrote:
> Hello everybody!
>
> It was reported that BufferedInputStream#read() method may throw 
> NegativeArraySizeException.
> This is due to doubling the buffer size in the fill() method without 
> checking for a possible overflow.
>
> BUG: http://bugs.sun.com/view_bug.do?bug_id=7129312
>
> Affected versions of jdk are 6, 7 and 8
>
> Would you please help review a fix?
> http://cr.openjdk.java.net/~igerasim/7129312/0/webrev/
>
> It uses approach similar to what was suggested for 8020669: The 
> maximumBufferSize = (Integer.MAX_INTEGER - 8) constant is introduced 
> and we don't make attempts to allocate a bigger array.
>
> Please note, that the sample code as it was originally reported still 
> doesn't work. That's because that setting 
> buffStream.mark(Integer.MAX_VALUE) actually means that buffStream will 
> have to try to allocate an array of that size given a large enough input.
>
> Sincerely yours,
> Ivan
>
>
>
>



From xueming.shen at oracle.com  Fri Aug 16 17:05:42 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 16 Aug 2013 10:05:42 -0700
Subject: Please review Meiji era tidyup
In-Reply-To: <520BDEFD.9070600@oracle.com>
References: <520BDEFD.9070600@oracle.com>
Message-ID: <520E5BE6.7040608@oracle.com>

Looks good.

-Sherman

On 08/14/2013 12:48 PM, roger riggs wrote:
> The issue 8019185: Inconsistency between JapaneseEra start dates and java.util.JapaneseImperialDate
> Observes a minor discrepancy between the java.util.Calendar Japanese implementation
> and the java.time JapaneseEra.
>
> This fix aligns the start dates of the Meiji Era to avoid the inconsistency.
>
> http://cr.openjdk.java.net/~rriggs/webrev-meiji-start-8019185/
>
> Thanks, Roger
>



From roger.riggs at oracle.com  Fri Aug 16 16:50:21 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Fri, 16 Aug 2013 16:50:21 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130816165100.1B3C04893F@hg.openjdk.java.net>

Changeset: 53819fd0ab61
Author:    rriggs
Date:      2013-08-16 11:28 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/53819fd0ab61

8022770: java/time/tck/java/time/chrono/TCKChronology.java start failing
8022766: java/time/test/java/time/chrono/TestUmmAlQuraChronology.java failed.
Summary: TCKChronology: corrected display name to match update from JDK-8015986
Reviewed-by: alanb

! test/java/time/tck/java/time/chrono/TCKChronology.java
! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java

Changeset: d7fc4e149bb8
Author:    rriggs
Date:      2013-08-16 11:11 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d7fc4e149bb8

8022193: java/time/test/java/util/TestFormatter.java failed in th locale.
Summary: Tests corrected to use fixed locale and not dependent on the environment
Reviewed-by: sherman

! src/share/classes/java/util/Formatter.java
! test/java/time/test/java/util/TestFormatter.java



From roger.riggs at oracle.com  Fri Aug 16 18:00:01 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Fri, 16 Aug 2013 18:00:01 +0000
Subject: hg: jdk8/tl/jdk: 8019185: Inconsistency between JapaneseEra start
	dates and java.util.JapaneseImperialDate
Message-ID: <20130816180013.E79D848946@hg.openjdk.java.net>

Changeset: acaa256e3f7c
Author:    rriggs
Date:      2013-08-16 13:58 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/acaa256e3f7c

8019185: Inconsistency between JapaneseEra start dates and java.util.JapaneseImperialDate
Summary: align Meiji start date with lib/calendar.properties to avoid any confusion
Reviewed-by: sherman

! src/share/classes/java/time/chrono/JapaneseEra.java



From stuart.marks at oracle.com  Fri Aug 16 19:08:10 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 16 Aug 2013 12:08:10 -0700
Subject: RFR 8021820: Number of opened files used in select() is limited
	to 1024 [macosx]
In-Reply-To: <520E3C72.5090009@oracle.com>
References: <51F9007D.8090801@oracle.com> <51F9150B.4000008@oracle.com>
	<51F920A7.3000600@oracle.com> <51FF90BD.6070600@oracle.com>
	<52004DD9.4040202@oracle.com> <5202453F.2080409@oracle.com>
	<5202FDFF.1030906@oracle.com> <5209FA51.9060907@oracle.com>
	<520E006C.8020009@oracle.com> <520E3C72.5090009@oracle.com>
Message-ID: <520E789A.20501@oracle.com>

Hi, Aleksej, thanks for the update. The latest version looks good.

Chris, thanks for sponsoring this change.

s'marks

On 8/16/13 7:51 AM, Aleksej Efimov wrote:
> Chris,
> Thank you for review and for sponsorship.
>   I have prepared hg changeset patches for root and jdk repositories:
> root repo patch: http://cr.openjdk.java.net/~aefimov/8021820/jdk8_hg.export
> jdk repo patch: http://cr.openjdk.java.net/~aefimov/8021820/jdk_jdk8_hg.export
> I think if there is no objections - we can do the push.
>
> Thank you
> -Aleksej
>
>
> On 16.08.2013 14:35, Chris Hegarty wrote:
>> I see no objections to this, and I think it has been through enough review.
>> I'll sponsor this change for Aleksej.
>>
>> -Chris.
>>
>> On 13/08/2013 10:20, Aleksej Efimov wrote:
>>> Stuart,
>>> Thanks for your comments.
>>> New webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.03/
>>> 
>>> Comments below.
>>>
>>> Thanks,
>>> Aleksej
>>>
>>> On 08/08/2013 06:10 AM, Stuart Marks wrote:
>>>> Hi Aleksej,
>>>>
>>>> Thanks for the update. The situation is a bit twisted.
>>>>
>>>> I picked up a couple clues from David Holmes and Jon Gibbons. The
>>>> NoClassDefFoundError occurs when the JVM has hit its resource limit
>>>> for the number of open files, *and* it is being run in a development
>>>> environment with individual class files in a hierarchy, e.g. within
>>>>
>>>> ROOT/build//jdk/classes
>>>>
>>>> In this case, since each class is in its own file, it's quite likely
>>>> that the loading of an individual class will fail because of lack of
>>>> file descriptors. If the JVM itself encounters this, it will generate
>>>> a NoClassDefFoundError without a stack trace such as the ones we've seen.
>>>>
>>>> If the test is being run against a fully built JDK image, classes are
>>>> loaded from rt.jar. This is usually already open, so quite often
>>>> classes can be loaded without having to open additional files. In this
>>>> case we get the FileNotFoundException as expected.
>>> It was very interesting and enlightening information. Thank you for
>>> that, I'll keep it in mind.
>>>>
>>>> The resource limits seem to vary from system to system, and even from
>>>> one Ubuntu version to the next (mine has a default hard limit of 1024
>>>> open files). Unfortunately, while it might seem reasonable to have
>>>> minimum specifications for systems on which we run tests, in practice
>>>> this has proven very difficult. Since the bug being fixed is Mac-only,
>>>> and the default open file limit for Mac seems to be unlimited, perhaps
>>>> it makes most sense for this to be a Mac-only test.
>>>>
>>>> From the discussion here [1] which refers to an Apple technote [2] it
>>>> seems like the best way to test for being on a Mac is something like
>>>> this:
>>>>
>>>> if (! System.getProperty("os.name").contains("OS X")) {
>>>> return;
>>>> }
>>>>
>>>> That is, report success if we're on anything other than a Mac.
>>> Agreed, there is no need to run this test on other platforms (the bug
>>> states only MacOSX) and as a good addition we don't need to worry about
>>> limits on other platforms. The suggested check was added to test. And it
>>> was executed on all platforms (without fix): all except MacOSX passes,
>>> on MacOSX expected result - "java.net.SocketException: Invalid argument".
>>>>
>>>> Once we're sure we're on a Mac, having the test fail if it can't open
>>>> enough files seems reasonable.
>>>>
>>>> I'd suggest putting a comment at the top of the test class saying that
>>>> this test *must* be run in othervm mode, to ensure that files are
>>>> closed properly. That way, you can take out the cleanupFiles() method
>>>> too, as well as avoiding lots of exception handling and related
>>>> cleanup code.
>>> Comment was added and cleanupFiles() method was removed as suggested.
>>>>
>>>> Finally, a style point: try/catch statements are conventionally
>>>> indented as a single multi-block, not as separate statements. I'd
>>>> suggest something like this:
>>>>
>>>> // The accept() call will throw SocketException if the
>>>> // select() has failed due to limitation on fds size,
>>>> // indicating test failure. A SocketTimeoutException
>>>> // is expected, so it is caught and ignored, and the test
>>>> // passes.
>>>>
>>>> try {
>>>> socket.accept();
>>>> } catch (SocketTimeoutException e) { }
>>> Fixed.
>>>>
>>>> s'marks
>>>>
>>>>
>>>> [1]
>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-November/005148.html
>>>>
>>>>
>>>>
>>>> [2] https://developer.apple.com/library/mac/#technotes/tn2002/tn2110.html
>>>>
>>>>
>>>>
>>>> On 8/7/13 6:01 AM, Aleksej Efimov wrote:
>>>>> Stuart, thank you for you comments, responses are below.
>>>>> New webrev:
>>>>> http://cr.openjdk.java.net/~aefimov/8021820/webrev.02/
>>>>> 
>>>>>
>>>>>
>>>>> -Aleksej
>>>>>
>>>>> On 08/06/2013 05:14 AM, Stuart Marks wrote:
>>>>>> Hi Aleksej,
>>>>>>
>>>>>> Thanks for the update. I took a look at the revised test, and there
>>>>>> are still
>>>>>> some issues. (I didn't look at the build changes.)
>>>>>>
>>>>>> 1) System-specific resource limits.
>>>>>>
>>>>>> I think the biggest issue is resource limits on the number of open
>>>>>> files per
>>>>>> process that might vary from system to system. On my Ubuntu system,
>>>>>> the hard
>>>>>> limit on the number of open files is 1,024. The test opens 1,023
>>>>>> files and
>>>>>> then one more for the socket. Unfortunately the JVM and jtreg have
>>>>>> several
>>>>>> files open already, and the test crashes before the openFiles() method
>>>>>> completes.
>>>>>>
>>>>>> (Oddly it crashes with a NoClassDefFoundError from the main thread's
>>>>>> uncaught
>>>>>> exception handler, and then the test reports that it passed! Placing a
>>>>>> try/catch of Throwable in main() or openFiles() doesn't catch this
>>>>>> error. I
>>>>>> have no explanation for this. When run standalone -- i.e., not from
>>>>>> jtreg --
>>>>>> the test throws FileNotFoundException (too many open files) from
>>>>>> openFiles(),
>>>>>> which is expected.)
>>>>>>
>>>>>> On my Mac (10.7.5) the soft limit is 256 files, but the hard limit is
>>>>>> unlimited. The test succeeds in opening all its files but fails
>>>>>> because of
>>>>>> the select() bug you're fixing. (This is expected; I didn't rebuild
>>>>>> my JDK
>>>>>> with your patch.) I guess the soft limit doesn't do anything on Mac.
>>>>>>
>>>>>> Amazingly, the test passed fine on both Windows XP and Windows 8.
>>>>>>
>>>>>> I'm not entirely sure what to do about resource limits. Since the
>>>>>> test is
>>>>>> able to open >1024 files on Mac, Windows, and possibly other
>>>>>> Linuxes, it
>>>>>> seems reasonable to continue with this approach. If it's possible to
>>>>>> catch
>>>>>> the error that occurs if the test cannot open its initial 1,024 files,
>>>>>> perhaps it should do this, log a message indicating what happened, and
>>>>>> consider the test to have passed. I'm mystified by the
>>>>>> uncaught/uncatchable
>>>>>> NoClassDefFoundError though.
>>>>> I wonder if this is a question of test environment required for JTREG
>>>>> tests: if
>>>>> we'll execute JTREG tests with low value assigned to fd hard limit
>>>>> (for example
>>>>> 10) we'll see a lot of unrelated test failures. So, I suggest that we
>>>>> can
>>>>> assume that there is no hard limits set (or at least default ones,
>>>>> i.e. default
>>>>> fd limit on Ubuntu is 4096) on test machine. But we should consider
>>>>> test as
>>>>> Failed if test failed to prepare it's environment because of some
>>>>> external
>>>>> limitations. The JTREG doesn't meet this criteria (log test as PASS
>>>>> and prints
>>>>> incorrect Exception). To illustrate it I have repeated your
>>>>> experiments on
>>>>> ubuntu linux: set fd hard limit to 1024 (ulimit -Hn 1024) and got
>>>>> this error by
>>>>> manual run of test:
>>>>> Exception in thread "main" java.io.FileNotFoundException: testfile
>>>>> (Too many
>>>>> open files)
>>>>> at java.io.FileInputStream.open(Native Method)
>>>>> at java.io.FileInputStream.(FileInputStream.java:128)
>>>>> at SelectFdsLimit.openFiles(SelectFdsLimit.java:63)
>>>>> at SelectFdsLimit.main(SelectFdsLimit.java:81)
>>>>>
>>>>> Seems correct to me.
>>>>> An by JTREG (also with hard limit set to 1024):
>>>>> ----------messages:(3/123)----------
>>>>> command: main SelectFdsLimit
>>>>> reason: User specified action: run main/othervm SelectFdsLimit
>>>>> elapsed time (seconds): 0.168
>>>>> ----------System.out:(0/0)----------
>>>>> ----------System.err:(5/250)----------
>>>>>
>>>>> Exception: java.lang.NoClassDefFoundError thrown from the
>>>>> UncaughtExceptionHandler in thread "MainThread"
>>>>> STATUS:Passed.
>>>>> Exception in thread "main"
>>>>> Exception: java.lang.NoClassDefFoundError thrown from the
>>>>> UncaughtExceptionHandler in thread "main"
>>>>> result: Passed. Execution successful
>>>>>
>>>>>
>>>>> test result: Passed. Execution successful
>>>>>
>>>>>
>>>>> The results are identical to results mentioned by you. It seems to me
>>>>> that
>>>>> jtreg doesn't correctly processes such test error (at least it
>>>>> shouldn't be
>>>>> considered as Pass). And I suggest two ways of resolving it:
>>>>> 1. If we don't have official limitations (or default) on what
>>>>> resources test
>>>>> can use then we shouldn't do any modifications to test.
>>>>> 2. If there is some limitations that we should honor then we'll need
>>>>> to figure
>>>>> out what to do with NoClassDefFoundError exception in JTREG.
>>>>>
>>>>>>
>>>>>> 2) Closing files.
>>>>>>
>>>>>> If an exception is thrown while opening the initial set of files, or
>>>>>> sometime
>>>>>> during the closing process, the test can still leak files.
>>>>>>
>>>>>> One approach would be to keep a data structure representing the
>>>>>> current set
>>>>>> of open files, and close them all in a finally-block around all the
>>>>>> test
>>>>>> logic, and making sure that exceptions from the close() call are
>>>>>> caught and
>>>>>> do not prevent the rest of the files from being closed.
>>>>>>
>>>>>> This seems like a lot of work. Perhaps a more effective approach
>>>>>> would be to
>>>>>> run the test in "othervm" mode, as follows:
>>>>>>
>>>>>> @run main/othervm SelectFdsLimit
>>>>>>
>>>>>> This will cause the test to run in a dedicated JVM, so all files
>>>>>> will be
>>>>>> closed automatically when it exits. (It would be good to add a comment
>>>>>> explaining the need for othervm, if you do this.)
>>>>>>
>>>>> main/othervm and comments were added.
>>>>>> 3) Port number for sockets.
>>>>>>
>>>>>> It's fairly common for tests to fail occasionally because they use some
>>>>>> constant port number that sometimes happens to be in use at the same
>>>>>> time by
>>>>>> another process on the system. I have to say, 8080 is a pretty
>>>>>> common port
>>>>>> number. :-)
>>>>>>
>>>>>> For purposes of this test, you can let the system assign a port.
>>>>>> Just use:
>>>>>>
>>>>>> new ServerSocket(0)
>>>>>>
>>>>> Completely agree that 8080 port - bad port for testing =). Changed to 0.
>>>>>> 4) Style.
>>>>>>
>>>>>> It's probably possible to use the same File object for the test
>>>>>> file, instead
>>>>>> of creating new File objects repeatedly.
>>>>> Agree and corrected.
>>>>>>
>>>>>> It might be nice to add a comment explaining the logic of the test,
>>>>>> that
>>>>>> SocketTimeoutException is expected, and that failure will be
>>>>>> indicated if the
>>>>>> accept() throws SocketException caused by the underlying mishandling
>>>>>> of large
>>>>>> fds by select().
>>>>> Comments were added.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> s'marks
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 8/5/13 4:47 AM, Aleksej Efimov wrote:
>>>>>>> Alan, Tim,
>>>>>>>
>>>>>>> I have addressed your comments and as a result - new webrev:
>>>>>>> http://cr.openjdk.java.net/~aefimov/8021820/webrev.01
>>>>>>>
>>>>>>> The list of changes:
>>>>>>> 1. The connection to Oracle site is removed (it's not internal, but
>>>>>>> anyway it's
>>>>>>> better not to rely on availability of external resource in test).
>>>>>>> In current
>>>>>>> version a server socket is created and accept() method is used for bug
>>>>>>> disclosure.
>>>>>>> 2. The cleanup method is added for closing file streams. The JTREG
>>>>>>> successfully
>>>>>>> cleaned-up on windows after this modification.
>>>>>>> 3. common/autoconf/toolchain.m4 untouched, but 'bash
>>>>>>> common/autoconf/autogen.sh' was executed to update
>>>>>>> generated-configure.sh.
>>>>>>>
>>>>>>> Aleksej
>>>>>>>
>>>>>>>
>>>>>>> On 07/31/2013 06:35 PM, Tim Bell wrote:
>>>>>>>> Aleksej, Alan
>>>>>>>>
>>>>>>>> The change in common/autoconf/toolchain.m4 looks correct to me,
>>>>>>>> and I think
>>>>>>>> that is a good place to have it. Remember to run 'bash
>>>>>>>> common/autoconf/autogen.sh' and check in the
>>>>>>>> generated-configure.sh files as
>>>>>>>> part of the changeset.
>>>>>>>>
>>>>>>>> I didn't look at the test case, but I think Alan has some good
>>>>>>>> points.
>>>>>>>>
>>>>>>>> Tim
>>>>>>>>
>>>>>>>> On 07/31/13 06:45 AM, Alan Bateman wrote:
>>>>>>>>> On 31/07/2013 05:18, Aleksej Efimov wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> Can I have a review for the following problem:
>>>>>>>>>> The MACOSX JDK (more precisely - the java.net classes) uses the
>>>>>>>>>> select()
>>>>>>>>>> system call to wait for different events on sockets fds. And the
>>>>>>>>>> default
>>>>>>>>>> behaviour for select() on Darwin is to fail when fdset contains
>>>>>>>>>> the fd with
>>>>>>>>>> id greater than FDSET_SIZE(=1024). Test case in webrev
>>>>>>>>>> illustrates this
>>>>>>>>>> behavior.
>>>>>>>>>> There is at least one solution for it: use
>>>>>>>>>> -D_DARWIN_UNLIMITED_SELECT
>>>>>>>>>> compilation flag for all macosx sources: this won't affect other
>>>>>>>>>> parts of
>>>>>>>>>> JDK because they are not using select().
>>>>>>>>>> Currently, I have added this compilation flag to
>>>>>>>>>> common/autoconf/generated-configure.sh and
>>>>>>>>>> common/autoconf/generated-configure.sh. I wonder, if there is a
>>>>>>>>>> better
>>>>>>>>>> place where I can put this flag?
>>>>>>>>>>
>>>>>>>>>> The webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.00/
>>>>>>>>>> BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021820
>>>>>>>>>
>>>>>>>>> Thanks for looking into this one. The build changes look okay to
>>>>>>>>> me but it's
>>>>>>>>> probably best that someone on build-dev agree to those.
>>>>>>>>> Michael McMahon can probably explain why the net code is using
>>>>>>>>> select for
>>>>>>>>> timed read/accept (I have a vague recollection of there being an
>>>>>>>>> issue with
>>>>>>>>> poll due to the way that it is implemented on kqueue with the
>>>>>>>>> result that it
>>>>>>>>> had to be changed to use select).
>>>>>>>>>
>>>>>>>>> I think the test needs re-work. It looks to me that the it
>>>>>>>>> attempts to
>>>>>>>>> connect to an Oracle internal site so that's not going to work
>>>>>>>>> everywhere.
>>>>>>>>> In general we don't want the tests to be dependent on hosts that
>>>>>>>>> may or may
>>>>>>>>> not exist (we had tests that used to this in the past but they
>>>>>>>>> caused a lot
>>>>>>>>> of grief). It also looks like the test doesn't close the 1023
>>>>>>>>> files that it
>>>>>>>>> opens at the start and so I assume this test will always fail on
>>>>>>>>> Windows
>>>>>>>>> when jtreg tries to clean-up.
>>>>>>>>>
>>>>>>>>> -Alan.
>>>>>>>>
>>>>>>>
>>>>>
>>>
>


From dan.xu at oracle.com  Fri Aug 16 21:56:19 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Fri, 16 Aug 2013 14:56:19 -0700
Subject: RFR [6883354] File.mkdirs() method doesn't behave well when given
	/../
In-Reply-To: <520E01B3.5090808@oracle.com>
References: <52090717.3040106@oracle.com> <520E01B3.5090808@oracle.com>
Message-ID: <520EA003.4040207@oracle.com>


On 08/16/2013 03:40 AM, Alan Bateman wrote:
> On 12/08/2013 17:02, Ivan Gerasimov wrote:
>> Hello everybody!
>>
>> Would you please help review a small change to File.mkdirs() method?
>>
>> The current implementation of the method, when past an argument 
>> "dir1/../dir2" only tries to create dir2.
>> mkdir -p 'dir1/../dir2' command on Linux creates both dir1 and dir2.
>> java.nio.file.Files.createDirectories() also creates both dir1 and dir2.
>>
>> The proposed fix makes File.mkdirs() method to behave in the same way 
>> on all the platforms except for Windows.
>>
>> The problem with Windows is that it reports 'dir1/..' as existent 
>> even if dir1 does not exist.
>> Because of that Files.createDirectories() doesn't work this way on 
>> Windows either.
>>
>> Proposed fix:
>> - makes File.mkdirs() match the behavior of 'mkdir -p' on Linux, 
>> Solaris and MacOS, and
>> - doesn't change its behavior on Windows.
>>
>> http://cr.openjdk.java.net/~igerasim/6883354/0/webrev/
> This is old code so we have to be cautious about changing it (and 
> understanding why it used the canonical path in the first place). What 
> would you think about adding a few tests to cover more types of file 
> path, Windows drive-relative and directory-relative paths in 
> particular as these are cases where we would need to confident that it 
> doesn't break.
>
> As an aside, Dan Xu and I were chatting recently about just replacing 
> most of the java.io.File implementation to just use java.nio.file. 
> This specific one is a case where it might be easier to just change 
> the method to Files.createDirectories(toPath()).
>
> -Alan.
>
>
Hi Ivan,

As you mentioned, the code behaves differently on Windows platform, so 
you cannot use the same test for all platforms. Your proposed Mkdir.java 
will fail on windows. Thanks!

-Dan


From ivan.gerasimov at oracle.com  Fri Aug 16 22:40:03 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sat, 17 Aug 2013 02:40:03 +0400
Subject: RFR [6883354] File.mkdirs() method doesn't behave well when given
	/../
In-Reply-To: <520EA003.4040207@oracle.com>
References: <52090717.3040106@oracle.com> <520E01B3.5090808@oracle.com>
	<520EA003.4040207@oracle.com>
Message-ID: <520EAA43.3030104@oracle.com>

Thanks Dan!

Yes, the old version of the test somehow crept into the webrev. Sorry 
about that!
Of course if was meant to include the check of  os.name
http://cr.openjdk.java.net/~igerasim/6883354/1/webrev/ 


The idea was to make the behavior of File.mkdirs() match that of 
command-line mkdir -p command on Linux/Solaris/MacOS and leave it as it 
is for Windows.
Files.createDirectories() behaves in exactly the same manner.

Your and Alan's idea of replacing the io implementation with calls to 
its nio counterpart seems to me as the best approach.
So it may be better to defer this fix until this move is done.

Sincerely yours,
Ivan

On 17.08.2013 1:56, Dan Xu wrote:
>
> On 08/16/2013 03:40 AM, Alan Bateman wrote:
>> On 12/08/2013 17:02, Ivan Gerasimov wrote:
>>> Hello everybody!
>>>
>>> Would you please help review a small change to File.mkdirs() method?
>>>
>>> The current implementation of the method, when past an argument 
>>> "dir1/../dir2" only tries to create dir2.
>>> mkdir -p 'dir1/../dir2' command on Linux creates both dir1 and dir2.
>>> java.nio.file.Files.createDirectories() also creates both dir1 and 
>>> dir2.
>>>
>>> The proposed fix makes File.mkdirs() method to behave in the same 
>>> way on all the platforms except for Windows.
>>>
>>> The problem with Windows is that it reports 'dir1/..' as existent 
>>> even if dir1 does not exist.
>>> Because of that Files.createDirectories() doesn't work this way on 
>>> Windows either.
>>>
>>> Proposed fix:
>>> - makes File.mkdirs() match the behavior of 'mkdir -p' on Linux, 
>>> Solaris and MacOS, and
>>> - doesn't change its behavior on Windows.
>>>
>>> http://cr.openjdk.java.net/~igerasim/6883354/0/webrev/
>> This is old code so we have to be cautious about changing it (and 
>> understanding why it used the canonical path in the first place). 
>> What would you think about adding a few tests to cover more types of 
>> file path, Windows drive-relative and directory-relative paths in 
>> particular as these are cases where we would need to confident that 
>> it doesn't break.
>>
>> As an aside, Dan Xu and I were chatting recently about just replacing 
>> most of the java.io.File implementation to just use java.nio.file. 
>> This specific one is a case where it might be easier to just change 
>> the method to Files.createDirectories(toPath()).
>>
>> -Alan.
>>
>>
> Hi Ivan,
>
> As you mentioned, the code behaves differently on Windows platform, so 
> you cannot use the same test for all platforms. Your proposed 
> Mkdir.java will fail on windows. Thanks!
>
> -Dan
>
>



From brent.christian at oracle.com  Fri Aug 16 22:48:30 2013
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 16 Aug 2013 15:48:30 -0700
Subject: Possible HashMap update
In-Reply-To: 
References: <51D4ABDA.7010801@cs.oswego.edu> <51DAD99F.9030705@cs.oswego.edu>
	<9F896672-012F-40A7-B7A3-AF9823CF7BB9@oracle.com>
	<520A8F0C.2070503@cs.oswego.edu> <520AA2B1.1030507@oracle.com>
	<520B5968.2050302@oracle.com>
	
Message-ID: <520EAC3E.3060001@oracle.com>

On 8/14/13 3:34 AM, Paul Sandoz wrote:
>
> If no one else volunteers i can try and sort this out and sync up
> stuff from the current HashMap/LinkedHashMap (e.g. forEachRem. as
> reported by Remi) and the lint warnings in one go, and submit for
> review.
>

That would be great, Paul.

One thing on my mind to watch out for is keeping EMPTY_TABLE for the 
empty HashMap optimization (instead of using null - see the relevant 
comments in 7143928/8003586).

Thanks,
-Brent


From pbenedict at apache.org  Sat Aug 17 04:30:25 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Fri, 16 Aug 2013 23:30:25 -0500
Subject: Enum.valueOf(String)
Message-ID: 

I noticed this method is not listed in the Javadocs for 5/6/7/8 but it's
part of every enum. Is this an oversight or is there a good reason why it's
not documented?

-- 
Cheers,
Paul


From nicholas+openjdk at nicholaswilliams.net  Sat Aug 17 04:54:36 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Fri, 16 Aug 2013 23:54:36 -0500
Subject: Enum.valueOf(String)
In-Reply-To: 
References: 
Message-ID: <7AE76BDE-06C8-4438-90F4-765B9726C80F@nicholaswilliams.net>

That method doesn't exist in the actual java.lang.Enum base class. It gets generated automatically when the enum is compiled and is part of the compiled enum class, not part of the Enum base class.

With that said, I don't disagree that it could use some documentation. I've often wondered why java.lang.Enum didn't have the following method definition:

public abstract E valueOf(String name);

That is essentially the method that all compiled enums implement, it's just not actually specified as an abstract method on the base class. If it were, then there could be JavaDoc for it.

Nick

On Aug 16, 2013, at 11:30 PM, Paul Benedict wrote:

> I noticed this method is not listed in the Javadocs for 5/6/7/8 but it's
> part of every enum. Is this an oversight or is there a good reason why it's
> not documented?
> 
> -- 
> Cheers,
> Paul



From eamonn at mcmanus.net  Sat Aug 17 05:28:42 2013
From: eamonn at mcmanus.net (Eamonn McManus)
Date: Fri, 16 Aug 2013 22:28:42 -0700
Subject: Enum.valueOf(String)
In-Reply-To: <7AE76BDE-06C8-4438-90F4-765B9726C80F@nicholaswilliams.net>
References: 
	<7AE76BDE-06C8-4438-90F4-765B9726C80F@nicholaswilliams.net>
Message-ID: 

The valueOf method in Enum subclasses is static, so Enum itself can't
usefully declare it. But the description of the Enum class could say
in text what the generated methods are, rather than referring the
reader to the JLS without even a link. If you forget what the methods
are you can always look in any enum, such as Thread.State
,
but you shouldn't have to.

?amonn


2013/8/16 Nick Williams :
> That method doesn't exist in the actual java.lang.Enum base class. It gets generated automatically when the enum is compiled and is part of the compiled enum class, not part of the Enum base class.
>
> With that said, I don't disagree that it could use some documentation. I've often wondered why java.lang.Enum didn't have the following method definition:
>
> public abstract E valueOf(String name);
>
> That is essentially the method that all compiled enums implement, it's just not actually specified as an abstract method on the base class. If it were, then there could be JavaDoc for it.
>
> Nick
>
> On Aug 16, 2013, at 11:30 PM, Paul Benedict wrote:
>
>> I noticed this method is not listed in the Javadocs for 5/6/7/8 but it's
>> part of every enum. Is this an oversight or is there a good reason why it's
>> not documented?
>>
>> --
>> Cheers,
>> Paul
>


From nicholas+openjdk at nicholaswilliams.net  Sat Aug 17 05:32:11 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Sat, 17 Aug 2013 00:32:11 -0500
Subject: Enum.valueOf(String)
In-Reply-To: 
References: 
	<7AE76BDE-06C8-4438-90F4-765B9726C80F@nicholaswilliams.net>
	
Message-ID: <013E5DBB-9D96-4D7A-AE1B-29D56D0B5729@nicholaswilliams.net>

Oh, yea. Duh. I completely forgot about it being static, which of course it would HAVE to be to be useful. Silly me.

Maybe there's a new language feature in there somewhere. Abstract static methods? ;-)

Still, yes. I would recommend that the JavaDoc for the Enum class list the signature and usage of any/all generated methods.

Nick

On Aug 17, 2013, at 12:28 AM, Eamonn McManus wrote:

> The valueOf method in Enum subclasses is static, so Enum itself can't
> usefully declare it. But the description of the Enum class could say
> in text what the generated methods are, rather than referring the
> reader to the JLS without even a link. If you forget what the methods
> are you can always look in any enum, such as Thread.State
> ,
> but you shouldn't have to.
> 
> ?amonn
> 
> 
> 2013/8/16 Nick Williams :
>> That method doesn't exist in the actual java.lang.Enum base class. It gets generated automatically when the enum is compiled and is part of the compiled enum class, not part of the Enum base class.
>> 
>> With that said, I don't disagree that it could use some documentation. I've often wondered why java.lang.Enum didn't have the following method definition:
>> 
>> public abstract E valueOf(String name);
>> 
>> That is essentially the method that all compiled enums implement, it's just not actually specified as an abstract method on the base class. If it were, then there could be JavaDoc for it.
>> 
>> Nick
>> 
>> On Aug 16, 2013, at 11:30 PM, Paul Benedict wrote:
>> 
>>> I noticed this method is not listed in the Javadocs for 5/6/7/8 but it's
>>> part of every enum. Is this an oversight or is there a good reason why it's
>>> not documented?
>>> 
>>> --
>>> Cheers,
>>> Paul
>> 



From peter.levart at gmail.com  Sat Aug 17 13:06:58 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 17 Aug 2013 15:06:58 +0200
Subject: RFR JDK-8022721 : AnnotationTypeDeadlockTest.java throws
	java.lang.IllegalStateException: unexpected condition
Message-ID: 

Hi,

Please review the fix for a test that tries to provoke a deadlock when
parsing annotations:

  http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/fix1/webrev.01/

The test was failing on slow machines when run with -Xcomp due to a short
time out (5s). The fix makes the test only fail when the dead-lock
situation is detected - never times out. I also re-worked the dead-lock
detection so that it is more correct now (using ThreadMXBean). When run on
an old build of JDK8 (the dead-lock bug not fixed yet), it produces the
following failure:

Exception in thread "main" java.lang.IllegalStateException: deadlock
detected:

"AnnB" Id=10 BLOCKED on java.lang.Class at 5fbd8c6e owned by "AnnA" Id=9
    at
sun.reflect.annotation.AnnotationType.getInstance(AnnotationType.java:81)
    -  blocked on java.lang.Class at 5fbd8c6e
    at
sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:91)
    at
sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:70)
    at java.lang.Class.initAnnotationsIfNecessary(Class.java:3093)
    at java.lang.Class.getDeclaredAnnotations(Class.java:3081)
    at
AnnotationTypeDeadlockTest$Task.run(AnnotationTypeDeadlockTest.java:68)

"AnnA" Id=9 BLOCKED on java.lang.Class at 514ae5cd owned by "AnnB" Id=10
    at java.lang.Class.initAnnotationsIfNecessary(Class.java:3090)
    -  blocked on java.lang.Class at 514ae5cd
    at java.lang.Class.getAnnotation(Class.java:3052)
    at sun.reflect.annotation.AnnotationType.(AnnotationType.java:131)
    at
sun.reflect.annotation.AnnotationType.getInstance(AnnotationType.java:84)
    at
sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:222)
    at
sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:88)
    at
sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:70)
    at java.lang.Class.initAnnotationsIfNecessary(Class.java:3093)
    ...


When run on new build of JDK8, it succeeds (also tried with -Xcomp).


Regards, Peter


From Alan.Bateman at oracle.com  Sat Aug 17 20:44:31 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 17 Aug 2013 21:44:31 +0100
Subject: RFR JDK-8022721 : AnnotationTypeDeadlockTest.java throws
	java.lang.IllegalStateException: unexpected condition
In-Reply-To: 
References: 
Message-ID: <520FE0AF.40908@oracle.com>

On 17/08/2013 14:06, Peter Levart wrote:
> Hi,
>
> Please review the fix for a test that tries to provoke a deadlock when
> parsing annotations:
>
>    http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/fix1/webrev.01/
>
> The test was failing on slow machines when run with -Xcomp due to a short
> time out (5s). The fix makes the test only fail when the dead-lock
> situation is detected - never times out. I also re-worked the dead-lock
> detection so that it is more correct now (using ThreadMXBean).
I remember an early version of the test used 500ms and I suggested you 
bump it to 5000ms on the assumption that it would be sufficient. It just 
demonstrates again that timeouts almost always bite back. I've looked at 
the webrev and it looks good to me, thanks again for picking this one up.

-Alan


From pbenedict at apache.org  Sun Aug 18 04:07:50 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Sat, 17 Aug 2013 23:07:50 -0500
Subject: Enum.valueOf(String)
In-Reply-To: <013E5DBB-9D96-4D7A-AE1B-29D56D0B5729@nicholaswilliams.net>
References: 
	<7AE76BDE-06C8-4438-90F4-765B9726C80F@nicholaswilliams.net>
	
	<013E5DBB-9D96-4D7A-AE1B-29D56D0B5729@nicholaswilliams.net>
Message-ID: 

I think the generated method needs to be listed in the class javadoc at
least. I presume it throws an exception too (like the other valueOf) if the
String can't be resolved to a constant, but no user is going to discover
this fact through the documentation.


On Sat, Aug 17, 2013 at 12:32 AM, Nick Williams <
nicholas+openjdk at nicholaswilliams.net> wrote:

> Oh, yea. Duh. I completely forgot about it being static, which of course
> it would HAVE to be to be useful. Silly me.
>
> Maybe there's a new language feature in there somewhere. Abstract static
> methods? ;-)
>
> Still, yes. I would recommend that the JavaDoc for the Enum class list the
> signature and usage of any/all generated methods.
>
> Nick
>
> On Aug 17, 2013, at 12:28 AM, Eamonn McManus wrote:
>
> > The valueOf method in Enum subclasses is static, so Enum itself can't
> > usefully declare it. But the description of the Enum class could say
> > in text what the generated methods are, rather than referring the
> > reader to the JLS without even a link. If you forget what the methods
> > are you can always look in any enum, such as Thread.State
> > ,
> > but you shouldn't have to.
> >
> > ?amonn
> >
> >
> > 2013/8/16 Nick Williams :
> >> That method doesn't exist in the actual java.lang.Enum base class. It
> gets generated automatically when the enum is compiled and is part of the
> compiled enum class, not part of the Enum base class.
> >>
> >> With that said, I don't disagree that it could use some documentation.
> I've often wondered why java.lang.Enum didn't have the following method
> definition:
> >>
> >> public abstract E valueOf(String name);
> >>
> >> That is essentially the method that all compiled enums implement, it's
> just not actually specified as an abstract method on the base class. If it
> were, then there could be JavaDoc for it.
> >>
> >> Nick
> >>
> >> On Aug 16, 2013, at 11:30 PM, Paul Benedict wrote:
> >>
> >>> I noticed this method is not listed in the Javadocs for 5/6/7/8 but
> it's
> >>> part of every enum. Is this an oversight or is there a good reason why
> it's
> >>> not documented?
> >>>
> >>> --
> >>> Cheers,
> >>> Paul
> >>
>
>


-- 
Cheers,
Paul


From dan.xu at oracle.com  Mon Aug 19 00:44:42 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Sun, 18 Aug 2013 17:44:42 -0700
Subject: RFR: JDK-8023203 - Wrap RandomAccessFile.seek native method into
	a Java helper method
Message-ID: <52116A7A.4050104@oracle.com>

HiAll,

Please review the simple change for JDK-8023203 - Wrap 
RandomAccessFile.seek native method into a Java helper method. Itadds a 
helper java method and makes it the only place that can invoke the 
native method directly. Thanks!

Webrev: http://cr.openjdk.java.net/~dxu/8023203/webrev/
Bug: http://bugs.sun.com/view_bug.do?bug_id=8023203

-Dan


From Alan.Bateman at oracle.com  Mon Aug 19 08:32:56 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 19 Aug 2013 09:32:56 +0100
Subject: Enum.valueOf(String)
In-Reply-To: 
References: 
	<7AE76BDE-06C8-4438-90F4-765B9726C80F@nicholaswilliams.net>
	
	<013E5DBB-9D96-4D7A-AE1B-29D56D0B5729@nicholaswilliams.net>
	
Message-ID: <5211D838.5070408@oracle.com>

On 18/08/2013 05:07, Paul Benedict wrote:
> I think the generated method needs to be listed in the class javadoc at
> least. I presume it throws an exception too (like the other valueOf) if the
> String can't be resolved to a constant, but no user is going to discover
> this fact through the documentation.
>
Have you checked the generated avadoc for your enum? The valueOf(String) 
should be there and specified to throw IAE or NPE.

-Alan




From paul.sandoz at oracle.com  Mon Aug 19 08:34:44 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 19 Aug 2013 10:34:44 +0200
Subject: RFR: 8022343: j.l.Class.getAnnotatedSuperclass() doesn't return
	null in some cases
In-Reply-To: <20130816121739.GM12405@jfranck-desktop.jrpg.bea.com>
References: <20130816121739.GM12405@jfranck-desktop.jrpg.bea.com>
Message-ID: 

Hi Joel,

The fix looks OK.

Not suggesting you do the following, unless you really want to, but the test is an example of where TestNG data providers are useful, since all cases will be tested and reported for pass or failure, rather than in this case the first failure will cause other checks (if any) not to be tested and in addition will not report which check failed (one needs to look at the stack trace).

Not tested:

  @DataProvider(name = "class")
  private static Object[][] getClasses() {
      // Using the stream API because i can :-)
      // Arguably simpler in this case to use new Object[][] { {} }
      return Stream.of(
                                Object.class,
                                If.class,
                                Object[].class,
                                void.class,
                                int.class).
              map(e -> new Object[] { e }).
              toArray(Object[][]::new);
  }

  @Test(dataProvider = "class")
  public void testAnnotatedSuperClassIsNull(Class c) {
      assertNull(c.getAnnotatedSuperclass())
  }

Paul.

On Aug 16, 2013, at 2:17 PM, Joel Borggren-Franck  wrote:

> Hi
> 
> Please review this small fix for a type annotation reflection issue.
> 
> The javadoc spec for Class.getAnnotatedSuperclass says: 
> 
> * If this Class represents either the Object class, an interface type, an
> * array type, a primitive type, or void, the return value is null.
> 
> The patch fixes this.
> 
> Webrev at: http://cr.openjdk.java.net/~jfranck/8022343/webrew.00/
> 
> Patch also included it at the end of this mail.
> 
> cheers
> /Joel
> 
> 
> 
> diff -r b07b19182e40 src/share/classes/java/lang/Class.java
> --- a/src/share/classes/java/lang/Class.java	Thu Aug 15 15:04:59 2013 +0100
> +++ b/src/share/classes/java/lang/Class.java	Fri Aug 16 13:20:31 2013 +0200
> @@ -3338,8 +3338,16 @@
>      * @since 1.8
>      */
>     public AnnotatedType getAnnotatedSuperclass() {
> -         return TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), getConstantPool(), this);
> -}
> +        if(this == Object.class ||
> +                isInterface() ||
> +                isArray() ||
> +                isPrimitive() ||
> +                this == Void.TYPE) {
> +            return null;
> +        }
> +
> +        return TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), getConstantPool(), this);
> +    }
> 
>     /**
>      * Returns an array of AnnotatedType objects that represent the use of types to
> diff -r b07b19182e40 test/java/lang/annotation/TypeAnnotationReflection.java
> --- a/test/java/lang/annotation/TypeAnnotationReflection.java	Thu Aug 15 15:04:59 2013 +0100
> +++ b/test/java/lang/annotation/TypeAnnotationReflection.java	Fri Aug 16 13:20:31 2013 +0200
> @@ -23,7 +23,7 @@
> 
> /*
>  * @test
> - * @bug 8004698 8007073
> + * @bug 8004698 8007073 8022343
>  * @summary Unit test for type annotations
>  */
> 
> @@ -58,7 +58,7 @@
>     }
> 
>     private static void testSuper() throws Exception {
> -        check(Object.class.getAnnotatedSuperclass().getAnnotations().length == 0);
> +        check(Object.class.getAnnotatedSuperclass() == null);
>         check(Class.class.getAnnotatedSuperclass().getAnnotations().length == 0);
> 
>         AnnotatedType a;
> diff -r b07b19182e40 test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java	Fri Aug 16 13:20:31 2013 +0200
> @@ -0,0 +1,50 @@
> +/*
> + * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> + *
> + * This code is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 only, as
> + * published by the Free Software Foundation.
> + *
> + * This code is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> + * version 2 for more details (a copy is included in the LICENSE file that
> + * accompanied this code).
> + *
> + * You should have received a copy of the GNU General Public License version
> + * 2 along with this work; if not, write to the Free Software Foundation,
> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> + *
> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
> + * or visit www.oracle.com if you need additional information or have any
> + * questions.
> + */
> +
> +/*
> + * @test
> + * @bug 8022343
> + * @summary make sure Class.getAnnotatedSuperclass() returns null when specified to do so
> + */
> +
> +import java.util.*;
> +import java.lang.annotation.*;
> +import java.lang.reflect.*;
> +import java.io.Serializable;
> +
> +public class GetAnnotatedSuperclass {
> +    public static void main(String[] args) throws Exception {
> +        check(Object.class.getAnnotatedSuperclass() == null);
> +        check(If.class.getAnnotatedSuperclass() == null);
> +        check(Object[].class.getAnnotatedSuperclass() == null);
> +        check(void.class.getAnnotatedSuperclass() == null);
> +        check(int.class.getAnnotatedSuperclass() == null);
> +    }
> +
> +    private static void check(boolean b) {
> +        if (!b)
> +            throw new RuntimeException();
> +    }
> +    interface If {}
> +}
> +



From Alan.Bateman at oracle.com  Mon Aug 19 08:35:02 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 19 Aug 2013 09:35:02 +0100
Subject: RFR: JDK-8023203 - Wrap RandomAccessFile.seek native method into
	a Java helper method
In-Reply-To: <52116A7A.4050104@oracle.com>
References: <52116A7A.4050104@oracle.com>
Message-ID: <5211D8B6.2050107@oracle.com>

On 19/08/2013 01:44, Dan Xu wrote:
> HiAll,
>
> Please review the simple change for JDK-8023203 - Wrap 
> RandomAccessFile.seek native method into a Java helper method. Itadds 
> a helper java method and makes it the only place that can invoke the 
> native method directly. Thanks!
>
> Webrev: http://cr.openjdk.java.net/~dxu/8023203/webrev/
> Bug: http://bugs.sun.com/view_bug.do?bug_id=8023203
I don't think we have a bug here but as a defensive change then it's 
okay (the duplicate check isn't a concern as a lseek is relatively 
expensive).

-Alan


From chris.hegarty at oracle.com  Mon Aug 19 08:58:16 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 19 Aug 2013 09:58:16 +0100
Subject: RFR: JDK-8023203 - Wrap RandomAccessFile.seek native method into
	a Java helper method
In-Reply-To: <5211D8B6.2050107@oracle.com>
References: <52116A7A.4050104@oracle.com> <5211D8B6.2050107@oracle.com>
Message-ID: <5211DE28.4000702@oracle.com>

On 19/08/2013 09:35, Alan Bateman wrote:
> On 19/08/2013 01:44, Dan Xu wrote:
>> HiAll,
>>
>> Please review the simple change for JDK-8023203 - Wrap
>> RandomAccessFile.seek native method into a Java helper method. Itadds
>> a helper java method and makes it the only place that can invoke the
>> native method directly. Thanks!
>>
>> Webrev: http://cr.openjdk.java.net/~dxu/8023203/webrev/
>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8023203
> I don't think we have a bug here but as a defensive change then it's
 > okay
+1

> (the duplicate check isn't a concern as a lseek is relatively
> expensive).

Trivially, I'd remove the extra native check, but I can understand why 
you may want to keep it.

-Chris.

>
> -Alan


From jaroslav.bachorik at oracle.com  Mon Aug 19 09:05:55 2013
From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com)
Date: Mon, 19 Aug 2013 09:05:55 +0000
Subject: hg: jdk8/tl/jdk: 4 new changesets
Message-ID: <20130819090651.373E34898A@hg.openjdk.java.net>

Changeset: 8e098a29ecd8
Author:    egahlin
Date:      2013-08-16 17:02 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8e098a29ecd8

6417702: Graph in Memory tab is not redrawn immediately if changed via 'Chart' combo box
Reviewed-by: alanb, jbachorik, sjiang

! src/share/classes/sun/tools/jconsole/MemoryTab.java

Changeset: c67cb9d4d51a
Author:    egahlin
Date:      2013-08-16 17:11 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c67cb9d4d51a

6721425: jconsole Makefile clean rule is missing rm of generated Version.java
Reviewed-by: alanb, jbachorik

! make/sun/jconsole/Makefile

Changeset: 89ef4bcf7b0e
Author:    egahlin
Date:      2013-08-16 16:53 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89ef4bcf7b0e

7015157: String "Tabular Navigation" should be rephrased for avoiding mistranslation
Reviewed-by: alanb, jbachorik, sjiang

! src/share/classes/sun/tools/jconsole/resources/messages.properties

Changeset: 71bad9540825
Author:    egahlin
Date:      2013-08-16 18:58 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71bad9540825

6696970: Jconsole becomes unusable if a plugin throws an exception
Reviewed-by: mchung, jbachorik

+ src/share/classes/sun/tools/jconsole/ExceptionSafePlugin.java
! src/share/classes/sun/tools/jconsole/Messages.java
! src/share/classes/sun/tools/jconsole/VMPanel.java
! src/share/classes/sun/tools/jconsole/resources/messages.properties



From Alan.Bateman at oracle.com  Mon Aug 19 09:14:45 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 19 Aug 2013 10:14:45 +0100
Subject: 8023215: test/java/util/Comparator/TypeTest.java not running (failing
	but reported as passing)
Message-ID: <5211E205.70202@oracle.com>


I just refreshed my clone of code-tools/jtreg to pick up a few changes, 
including a number of fixes to the TestNG support.

With the updated jtreg then test/java/util/Comparator/TypeTest.java fails:

[TestNG] Running:
   java/util/Comparator/TypeTest.java

test public static void TypeTest.main(java.lang.String[]): skip
org.testng.TestNGException:
Method main requires 1 parameters but 0 were supplied in the @Test 
annotation.

It turns out this has been failing (and so this test has not been 
running) since it was initially pushed, it's just that jtreg has been 
reporting it as passing.

Looking at the test now then it seems incomplete (although it matches 
the version in the lambda forest). For now I'd like to "enable it" via 
the attached patch so that it's not failing when running the java.util 
tests.

-Alan

diff --git a/test/java/util/Comparator/TypeTest.java 
b/test/java/util/Comparator/TypeTest.java
--- a/test/java/util/Comparator/TypeTest.java
+++ b/test/java/util/Comparator/TypeTest.java
@@ -75,7 +75,7 @@
          }
      }

-    public static void main(String[] args) {
+    public void testOrder() {
          Manager m1 = new Manager("Manager", 2, 2000);
          Manager m2 = new Manager("Manager", 4, 1300);


From joel.franck at oracle.com  Mon Aug 19 09:14:26 2013
From: joel.franck at oracle.com (Joel Borggren-Franck)
Date: Mon, 19 Aug 2013 11:14:26 +0200
Subject: RFR JDK-8022721 : AnnotationTypeDeadlockTest.java throws
	java.lang.IllegalStateException: unexpected condition
In-Reply-To: <520FE0AF.40908@oracle.com>
References: 
	<520FE0AF.40908@oracle.com>
Message-ID: <20130819091426.GB31919@jfranck-desktop.jrpg.bea.com>

Hi Peter,

Looks good to me too.

cheers
/Joel

On 2013-08-17, Alan Bateman wrote:
> On 17/08/2013 14:06, Peter Levart wrote:
> >Hi,
> >
> >Please review the fix for a test that tries to provoke a deadlock when
> >parsing annotations:
> >
> >   http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/fix1/webrev.01/
> >
> >The test was failing on slow machines when run with -Xcomp due to a short
> >time out (5s). The fix makes the test only fail when the dead-lock
> >situation is detected - never times out. I also re-worked the dead-lock
> >detection so that it is more correct now (using ThreadMXBean).
> I remember an early version of the test used 500ms and I suggested
> you bump it to 5000ms on the assumption that it would be sufficient.
> It just demonstrates again that timeouts almost always bite back.
> I've looked at the webrev and it looks good to me, thanks again for
> picking this one up.
> 
> -Alan


From paul.sandoz at oracle.com  Mon Aug 19 08:54:44 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 19 Aug 2013 08:54:44 +0000
Subject: hg: jdk8/tl/jdk: 8022318: Document Spliterator characteristics and
	binding policy of java util concurrent collection impls
Message-ID: <20130819085531.8707F48988@hg.openjdk.java.net>

Changeset: 9e9f5713b26d
Author:    psandoz
Date:      2013-08-06 14:26 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e9f5713b26d

8022318: Document Spliterator characteristics and binding policy of java util concurrent collection impls
Reviewed-by: chegar
Contributed-by: Martin Buchholz , Paul Sandoz 

! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
! src/share/classes/java/util/concurrent/DelayQueue.java
! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java
! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java
! src/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/share/classes/java/util/concurrent/SynchronousQueue.java
! src/share/classes/java/util/concurrent/package-info.java



From paul.sandoz at oracle.com  Mon Aug 19 09:40:08 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 19 Aug 2013 11:40:08 +0200
Subject: 8023215: test/java/util/Comparator/TypeTest.java not running
	(failing but reported as passing)
In-Reply-To: <5211E205.70202@oracle.com>
References: <5211E205.70202@oracle.com>
Message-ID: <6646ADF7-D22A-4787-9744-7281E0D0DCC3@oracle.com>

Looks good, i will commit the same to the lambda repo.

Did you build jtreg yourself or did you download it?

Paul.

On Aug 19, 2013, at 11:14 AM, Alan Bateman  wrote:

> 
> I just refreshed my clone of code-tools/jtreg to pick up a few changes, including a number of fixes to the TestNG support.
> 
> With the updated jtreg then test/java/util/Comparator/TypeTest.java fails:
> 
> [TestNG] Running:
>  java/util/Comparator/TypeTest.java
> 
> test public static void TypeTest.main(java.lang.String[]): skip
> org.testng.TestNGException:
> Method main requires 1 parameters but 0 were supplied in the @Test annotation.
> 
> It turns out this has been failing (and so this test has not been running) since it was initially pushed, it's just that jtreg has been reporting it as passing.
> 
> Looking at the test now then it seems incomplete (although it matches the version in the lambda forest). For now I'd like to "enable it" via the attached patch so that it's not failing when running the java.util tests.
> 
> -Alan
> 
> diff --git a/test/java/util/Comparator/TypeTest.java b/test/java/util/Comparator/TypeTest.java
> --- a/test/java/util/Comparator/TypeTest.java
> +++ b/test/java/util/Comparator/TypeTest.java
> @@ -75,7 +75,7 @@
>         }
>     }
> 
> -    public static void main(String[] args) {
> +    public void testOrder() {
>         Manager m1 = new Manager("Manager", 2, 2000);
>         Manager m2 = new Manager("Manager", 4, 1300);



From chris.hegarty at oracle.com  Mon Aug 19 09:45:33 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 19 Aug 2013 09:45:33 +0000
Subject: hg: jdk8/tl: 8021820: Number of opened files used in select() is
	limited to 1024 [macosx]
Message-ID: <20130819094534.30D3F4898B@hg.openjdk.java.net>

Changeset: 00dcfaa6bc01
Author:    aefimov
Date:      2013-08-16 18:40 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/00dcfaa6bc01

8021820: Number of opened files used in select() is limited to 1024 [macosx]
Reviewed-by: alanb, chegar, tbell, smarks

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4



From Alan.Bateman at oracle.com  Mon Aug 19 09:47:36 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 19 Aug 2013 10:47:36 +0100
Subject: 8023215: test/java/util/Comparator/TypeTest.java not running
	(failing but reported as passing)
In-Reply-To: <6646ADF7-D22A-4787-9744-7281E0D0DCC3@oracle.com>
References: <5211E205.70202@oracle.com>
	<6646ADF7-D22A-4787-9744-7281E0D0DCC3@oracle.com>
Message-ID: <5211E9B8.4060407@oracle.com>

On 19/08/2013 10:40, Paul Sandoz wrote:
> Looks good, i will commit the same to the lambda repo.
>
> Did you build jtreg yourself or did you download it?
>
Thanks. I build jtreg myself which is how I ran into this.

-Alan.


From chris.hegarty at oracle.com  Mon Aug 19 09:47:17 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 19 Aug 2013 09:47:17 +0000
Subject: hg: jdk8/tl/jdk: 8021820: Number of opened files used in select() is
	limited to 1024 [macosx]
Message-ID: <20130819094817.B3DE94898E@hg.openjdk.java.net>

Changeset: 11ccaabdb2a8
Author:    aefimov
Date:      2013-08-16 18:41 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11ccaabdb2a8

8021820: Number of opened files used in select() is limited to 1024 [macosx]
Reviewed-by: alanb, chegar, tbell, smarks

+ test/java/net/ServerSocket/SelectFdsLimit.java



From alan.bateman at oracle.com  Mon Aug 19 10:07:04 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 19 Aug 2013 10:07:04 +0000
Subject: hg: jdk8/tl/jdk: 8023215: test/java/util/Comparator/TypeTest.java not
	running (failing but reported as passing)
Message-ID: <20130819100719.3AF2648991@hg.openjdk.java.net>

Changeset: f580728b08b4
Author:    alanb
Date:      2013-08-19 11:04 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f580728b08b4

8023215: test/java/util/Comparator/TypeTest.java not running (failing but reported as passing)
Reviewed-by: psandoz

! test/java/util/Comparator/TypeTest.java



From chris.hegarty at oracle.com  Mon Aug 19 10:12:38 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 19 Aug 2013 11:12:38 +0100
Subject: Take 2 Re: RFR 8014824: Document Spliterator characteristics
	and binding policy of java util collection impls
In-Reply-To: 
References: <1C62EB3E-11FF-484B-BC00-2DED97C33A8F@oracle.com>
	
Message-ID: <5211EF96.5000109@oracle.com>

Looks good to me Paul.

Trivially, typo in Spliterator.java
   'structural interface' -> 'structural interference'

-Chris.

On 12/08/2013 13:12, Paul Sandoz wrote:
> Hi,
>
> I have updated this webrev to remove documenting empty/singleton collections (that will be tackled as a separate issue):
>
>    http://cr.openjdk.java.net/~psandoz/tl/JDK-8014824-split-docs/webrev/
>
> Paul.
>
> On Aug 8, 2013, at 11:00 AM, Paul Sandoz  wrote:
>
>> Hi,
>>
>> The following patch updates documentation for various spliterators:
>>
>>   http://cr.openjdk.java.net/~psandoz/tl/JDK-8014824-split-docs/webrev/
>>
>> Mostly this is just clarifying stuff that was missing, but there are a few cases of a spec change to Collections (CCC will be created):
>>
>>   http://cr.openjdk.java.net/~psandoz/tl/JDK-8014824-split-docs/specdiff/overview-summary.html
>>
>> This is for the Collection.empty/singleton/nCopies relaxing the reporting of characteristics for spliterators containing 0 or 1 elements. It's more efficient to share code for empty and singleton spliterator implementations (and instance for the former) rather than attempting to conform the required characteristics of the collection, which will anyway have little or no benefit in terms of the client trying to optimize based on those characteristics.
>>
>> Paul.
>


From Alan.Bateman at oracle.com  Mon Aug 19 10:38:09 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 19 Aug 2013 11:38:09 +0100
Subject: RFR [7129312] BufferedInputStream calculates negative array size
	with large streams and mark
In-Reply-To: <520E541E.1060403@oracle.com>
References: <520E2541.9020505@oracle.com> <520E541E.1060403@oracle.com>
Message-ID: <5211F591.6010504@oracle.com>

On 16/08/2013 17:32, Ivan Gerasimov wrote:
> Sorry, the webrev happened to be empty.
>
> Here's the full one: 
> http://cr.openjdk.java.net/~igerasim/7129312/1/webrev/ 
> 
>
> Sincerely yours,
> Ivan
Thanks for taking this one.

The update to BufferedInputStream looks okay to me. I guess we don't 
actually need to check the size in the constructor, OOME will be thrown 
anyway. Usually constants are in uppercase and maybe we should just do 
this while we are here (so this means rename defaultBufferSize too).

I'm in two minds about the test as reserving 4GB of heap is going to be 
a problem on some systems (32-bit mostly).

-Alan.




From Alan.Bateman at oracle.com  Mon Aug 19 10:43:10 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 19 Aug 2013 11:43:10 +0100
Subject: RFR [6883354] File.mkdirs() method doesn't behave well when given
	/../
In-Reply-To: <520EAA43.3030104@oracle.com>
References: <52090717.3040106@oracle.com> <520E01B3.5090808@oracle.com>
	<520EA003.4040207@oracle.com> <520EAA43.3030104@oracle.com>
Message-ID: <5211F6BE.5020702@oracle.com>

On 16/08/2013 23:40, Ivan Gerasimov wrote:
> :
>
> Your and Alan's idea of replacing the io implementation with calls to 
> its nio counterpart seems to me as the best approach.
> So it may be better to defer this fix until this move is done.
>
I think it should be okay to just change this one method to use 
Files.createDirectories if you feel inclined. The main thing with 
changing all of java.io to use java.nio.file is that there are a number 
of subtle compatibility issues to trash through (Windows in particular 
where java.io has a long of long standing issues/bugs, fixing those bugs 
would result in subtle behavior changes that would need to be 
understood). If you want to go ahead with this then the main thing is 
that there is cover test coverage to catch any issues.

-Alan.



From paul.sandoz at oracle.com  Mon Aug 19 11:06:33 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 19 Aug 2013 13:06:33 +0200
Subject: 8020292: j.u.SplittableRandom
Message-ID: <9F153157-0FC5-4385-B1BC-4FE2D43006F4@oracle.com>

Hi,

This is the patch for SplittableRandom:

  http://cr.openjdk.java.net/~psandoz/tl/JDK-8020292-SplittableRandom/webrev/

The algorithm remains the same as reported by Doug on the 9th August:

  http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019768.html

Paul.

From paul.sandoz at oracle.com  Mon Aug 19 11:07:03 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 19 Aug 2013 13:07:03 +0200
Subject: RFR 8023155: Ensure functional consistency across Random,
	ThreadLocalRandom, SplittableRandom
Message-ID: 

Hi,

This patch updates Random and ThreadLocalRandom to have functional consistency (for the most part) across Random, ThreadLocalRandom and SplittableRandom:

  http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/webrev/

  http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/specdiff/overview-summary.html


The PRNG of ThreadLocalRandom has been updated by Doug:

     * Even though this class subclasses java.util.Random, it uses the
     * same basic algorithm as java.util.SplittableRandom.  (See its
     * internal documentation for explanations, which are not repeated
     * here.)  Because ThreadLocalRandoms are not splittable
     * though, we use only a single 64bit gamma.


The stream-returning method gaussians() is removed from Random and TLR. Doug's explanation as to why SplittableRandom does not have nextGaussian is applicable to why it's not worth having sized and effectively infinite stream-returning gaussians() methods:

"There are many algorithms to choose from, that are all
independent of the underlying uniform RNG algorithm.
Plus, there are many more probability distributions
out there. Singling out a particular algorithm/method
for Gaussian stands mostly as an accident of history
in java.util.Random."


The nextFloat functionality has been left unmodified. Such un/bounded nextFloat methods do not exist on SplittableRandom, i don't think they carry their weight given the nextDouble functionality.


I have yet to define a common interface e.g. RandomGenerator that Random, ThreadLocalRandom and SplittableRandom could implement, but it would be very easy to do so. Any thoughts on doing this?

--

A JPRT run reported no corresponding failures.

Paul.

From paul.sandoz at oracle.com  Mon Aug 19 11:59:53 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 19 Aug 2013 13:59:53 +0200
Subject: Take 2 Re: RFR 8014824: Document Spliterator characteristics and
	binding policy of java util collection impls
In-Reply-To: <5211EF96.5000109@oracle.com>
References: <1C62EB3E-11FF-484B-BC00-2DED97C33A8F@oracle.com>
	
	<5211EF96.5000109@oracle.com>
Message-ID: <6C2E07D2-B65D-4A4A-A73E-9143EA1FD2FC@oracle.com>


On Aug 19, 2013, at 12:12 PM, Chris Hegarty  wrote:

> Looks good to me Paul.
> 
> Trivially, typo in Spliterator.java
>  'structural interface' -> 'structural interference'
> 

Thanks!, i updated my patch.

Paul.


From peter.levart at gmail.com  Mon Aug 19 12:26:51 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 19 Aug 2013 14:26:51 +0200
Subject: RFR 8023155: Ensure functional consistency across Random,
	ThreadLocalRandom, SplittableRandom
In-Reply-To: 
References: 
Message-ID: <52120F0B.10107@gmail.com>


On 08/19/2013 01:07 PM, Paul Sandoz wrote:
> Hi,
>
> This patch updates Random and ThreadLocalRandom to have functional consistency (for the most part) across Random, ThreadLocalRandom and SplittableRandom:
>
>    http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/webrev/
>
>    http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/specdiff/overview-summary.html
>
>
> The PRNG of ThreadLocalRandom has been updated by Doug:
>
>       * Even though this class subclasses java.util.Random, it uses the
>       * same basic algorithm as java.util.SplittableRandom.  (See its
>       * internal documentation for explanations, which are not repeated
>       * here.)  Because ThreadLocalRandoms are not splittable
>       * though, we use only a single 64bit gamma.
>
>
> The stream-returning method gaussians() is removed from Random and TLR. Doug's explanation as to why SplittableRandom does not have nextGaussian is applicable to why it's not worth having sized and effectively infinite stream-returning gaussians() methods:
>
> "There are many algorithms to choose from, that are all
> independent of the underlying uniform RNG algorithm.
> Plus, there are many more probability distributions
> out there. Singling out a particular algorithm/method
> for Gaussian stands mostly as an accident of history
> in java.util.Random."
>
>
> The nextFloat functionality has been left unmodified. Such un/bounded nextFloat methods do not exist on SplittableRandom, i don't think they carry their weight given the nextDouble functionality.
>
>
> I have yet to define a common interface e.g. RandomGenerator that Random, ThreadLocalRandom and SplittableRandom could implement, but it would be very easy to do so. Any thoughts on doing this?

Hi Paul,

Yes, a common interface is something that I missed sometimes. But now 
that we have lambdas and method references, it's not difficult to just 
adapt someRandom::nextLong to a LongSupplier or someRandom::nextDouble 
to a DoubleSupplier, so it somehow looses the importance. Anyway, a 
special interface might be a better fit for APIs taking random 
generators as parameters from self-documenting perspective. The consumer 
of such interface can also have more methods to choose from - it's not 
just a functional interface. So I'm for such interface.

Regards, Peter

> --
>
> A JPRT run reported no corresponding failures.
>
> Paul.



From paul.sandoz at oracle.com  Mon Aug 19 12:40:49 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 19 Aug 2013 14:40:49 +0200
Subject: RFR 8023155: Ensure functional consistency across Random,
	ThreadLocalRandom, SplittableRandom
In-Reply-To: <52120F0B.10107@gmail.com>
References: 
	<52120F0B.10107@gmail.com>
Message-ID: <0312052A-52B6-4944-BD1D-1059DFC5D623@oracle.com>

On Aug 19, 2013, at 2:26 PM, Peter Levart  wrote:
>> I have yet to define a common interface e.g. RandomGenerator that Random, ThreadLocalRandom and SplittableRandom could implement, but it would be very easy to do so. Any thoughts on doing this?
> 
> Hi Paul,
> 
> Yes, a common interface is something that I missed sometimes. But now that we have lambdas and method references, it's not difficult to just adapt someRandom::nextLong to a LongSupplier or someRandom::nextDouble to a DoubleSupplier, so it somehow looses the importance. Anyway, a special interface might be a better fit for APIs taking random generators as parameters from self-documenting perspective. The consumer of such interface can also have more methods to choose from - it's not just a functional interface. So I'm for such interface.
> 

Yes.

Perhaps it would also allow us to deprecate Random in a future JDK?

Perhaps there could be factory methods to obtain a PRNG based on generator properties rather than picking a specific class. Although there probably needs to two i/faces for that e.g. RandomGenerator and SplittableRandomGenerator (that extends for the former).

Paul.



From miroslav.kos at oracle.com  Mon Aug 19 12:56:35 2013
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Mon, 19 Aug 2013 14:56:35 +0200
Subject: Update jdk8/tl/jaxws to v2.2.9-b14140 ready for review
In-Reply-To: <520E0259.6070206@oracle.com>
References: <520DFBC1.3020207@oracle.com> <520E0259.6070206@oracle.com>
Message-ID: <52121603.1010401@oracle.com>

Hi Alan,
yes, this is true for rngom library - we downgraded it to the version 
which has been approved to be used as a 3rd party library. Licences are 
unchanged from the ones in the library; is there somebody who could 
approve these are ok?

Thanks
Miran



On 08/16/2013 12:43 PM, Alan Bateman wrote:
> On 16/08/2013 11:15, Miroslav Kos wrote:
>> There is an update syncing JAX-WS sources in jdk8/tl/jaxws to most 
>> recent development version.
>>
>> It is quite big changeset (13k+ LOC changed) and includes several bug 
>> fixes:
>>
>> http://java.net/jira/browse/JAX_WS-1114 problem sending XML primitive 
>> type gMonth (the request ends up null on server)
>> http://java.net/jira/browse/JAX_WS-723 Provide target 2.1 option to 
>> generate classes as per JAX-WS 2.1
>> http://java.net/jira/browse/JAX_WS-653 Erroneous Class-Path ref. in 
>> Manifest of several jar files
>>
>> http://java.net/jira/browse/JAXB-937 Nested unmarshalling can lead to 
>> NullPointerException
>> http://java.net/jira/browse/JAXB-643 Cannot use gMonth on jdk/jre 6
>>
>> Please, see weberev here: 
>> http://cr.openjdk.java.net/~mkos/8022885/webrev.00/
>>
>> Thanks
>> Miran
> I can't really comment on the changes as I don't know the JAX-WS code 
> but you might need to double-check some of the copyrights. I see for 
> example that the patch removes (rather than replaces) the copyright 
> header on org/relaxng/datatype classes. I don't know if that is 
> intended or not.
>
> -Alan.



From weijun.wang at oracle.com  Mon Aug 19 13:11:18 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 19 Aug 2013 21:11:18 +0800
Subject: RFR 8022761: SQE test regression on wrongly signed indexed jar file
In-Reply-To: <520861FA.4090605@oracle.com>
References: <520861FA.4090605@oracle.com>
Message-ID: <52121976.60708@oracle.com>

Hi Sherman

I try out "jar i" after signing and it puts INDEX.LIST at the very 
beginning of the file. Does this mean INDEX.LIST was actually an 
exception? Or it's just a bug?

Anyway, I think I should update the fix for 8021788 and here is the webrev:

   http://cr.openjdk.java.net/~weijun/8022761/webrev.00/

Now it also skips INDEX.LIST, i.e. update line 142 to

   if (uname.equals(JarFile.MANIFEST_NAME) ||
           uname.equals(JarIndex.INDEX_NAME) ) {

After this change, if INDEX.LIST appears before the MANIFEST and 
signature-related files, it will not be treated as signed. This should 
usually be true because it only happens when you call "jar i" after 
signing a jar which means INDEX.LIST *is* unsigned.

Thanks
Max

On 8/12/13 12:18 PM, Weijun Wang wrote:
> Hi Sherman
>
> SQE observes a regression in their test suite and
> the reason is my recent fix for 8021788 at
>
>    http://hg.openjdk.java.net/jdk8/tl/jdk/rev/758e3117899c
>
> The jar file mentioned contains
>
>      66 Mon Jun 04 15:42:18 CST 2007 META-INF/INDEX.LIST
>     323 Sat Apr 01 15:47:28 CST 2000 META-INF/MANIFEST.MF
>     376 Mon Jun 04 15:41:00 CST 2007 META-INF/MYKEY.SF
>     972 Sat Apr 01 15:47:38 CST 2000 META-INF/MYKEY.DSA
>       0 Sat Apr 01 15:46:58 CST 2000 META-INF/
>       0 Sat Apr 01 15:45:16 CST 2000 test/
>      21 Sat Apr 01 15:46:24 CST 2000 test/test0
>      21 Sat Apr 01 15:46:18 CST 2000 test/test1
>      21 Sat Apr 01 15:46:04 CST 2000 test/test2
>      21 Sat Apr 01 15:46:10 CST 2000 test/test3
>
> After JDK-8021788, the file is regarded as an unsigned jar because the
> updated JarVerifier goes thru all signature-related files and treats all
> others not. Here the first one is not signature-related so none is.
>
> Is fix for JDK-8021788 wrong? Inside JarVerifier.java, we have
>
>    * Assumptions:
>    * 1. The manifest should be the first entry in the META-INF directory.
>    * 2. The .SF/.DSA/.EC files follow the manifest, before any normal
> entries
>
> Is this INDEX.LIST an exception?
>
> Thanks
> Max


From pbenedict at apache.org  Mon Aug 19 14:23:57 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Mon, 19 Aug 2013 09:23:57 -0500
Subject: Enum.valueOf(String)
In-Reply-To: <5211D838.5070408@oracle.com>
References: 
	<7AE76BDE-06C8-4438-90F4-765B9726C80F@nicholaswilliams.net>
	
	<013E5DBB-9D96-4D7A-AE1B-29D56D0B5729@nicholaswilliams.net>
	
	<5211D838.5070408@oracle.com>
Message-ID: 

I have been working with classes that don't have javadoc attachments. The
problem was I couldn't find the method in the source nor was the method
part of the Enum class. So where did it materialize from? Now I know the
answer: the compiler generates it.

I really think this knowledge should be added to the Enum javadoc class. I
had to go on quite a goose hunt to find this fact.

Paul


On Mon, Aug 19, 2013 at 3:32 AM, Alan Bateman wrote:

> On 18/08/2013 05:07, Paul Benedict wrote:
>
>> I think the generated method needs to be listed in the class javadoc at
>> least. I presume it throws an exception too (like the other valueOf) if
>> the
>> String can't be resolved to a constant, but no user is going to discover
>> this fact through the documentation.
>>
>>  Have you checked the generated avadoc for your enum? The valueOf(String)
> should be there and specified to throw IAE or NPE.
>
> -Alan
>
>
>


-- 
Cheers,
Paul


From paul.sandoz at oracle.com  Mon Aug 19 14:15:56 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 19 Aug 2013 14:15:56 +0000
Subject: hg: jdk8/tl/jdk: 8014824: Document Spliterator characteristics and
	binding policy of java util collection impls
Message-ID: <20130819141634.3910A4899C@hg.openjdk.java.net>

Changeset: 3647aab7b1d5
Author:    psandoz
Date:      2013-08-06 14:26 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3647aab7b1d5

8014824: Document Spliterator characteristics and binding policy of java util collection impls
Reviewed-by: chegar

! src/share/classes/java/util/ArrayDeque.java
! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/HashSet.java
! src/share/classes/java/util/LinkedHashMap.java
! src/share/classes/java/util/LinkedHashSet.java
! src/share/classes/java/util/LinkedList.java
! src/share/classes/java/util/List.java
! src/share/classes/java/util/PriorityQueue.java
! src/share/classes/java/util/Set.java
! src/share/classes/java/util/SortedSet.java
! src/share/classes/java/util/Spliterator.java
! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/TreeSet.java
! src/share/classes/java/util/Vector.java



From sundararajan.athijegannathan at oracle.com  Mon Aug 19 14:48:58 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Mon, 19 Aug 2013 14:48:58 +0000
Subject: hg: jdk8/tl/nashorn: 7 new changesets
Message-ID: <20130819144905.7CC544899E@hg.openjdk.java.net>

Changeset: bbc4e9d37315
Author:    jlaskey
Date:      2013-08-12 18:00 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/bbc4e9d37315

8022676: Confusing error message checking instanceof non-class
Reviewed-by: jlaskey, sundar
Contributed-by: michael.horowitz at oracle.com

! src/jdk/nashorn/internal/runtime/resources/Messages.properties

Changeset: ba507ac08719
Author:    sundar
Date:      2013-08-14 20:51 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ba507ac08719

8023026: Array.prototype iterator functions like forEach, reduce should work for Java arrays, lists
Reviewed-by: jlaskey, lagergren

- src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/JavaArrayIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/JavaListIterator.java
- src/jdk/nashorn/internal/runtime/arrays/MapIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ReverseJavaArrayIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ReverseJavaListIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ReverseScriptArrayIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ReverseScriptObjectIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ScriptArrayIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ScriptObjectIterator.java
+ test/script/basic/JDK-8023026.js
+ test/script/basic/JDK-8023026.js.EXPECTED

Changeset: 09c99b58b81e
Author:    sundar
Date:      2013-08-16 15:04 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/09c99b58b81e

8020355: bind on built-in constructors don't use bound argument values
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java
+ test/script/basic/JDK-8020355.js

Changeset: 1d29d2e27590
Author:    hannesw
Date:      2013-08-16 13:42 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1d29d2e27590

8019985: Date.parse("2000-01-01T00:00:00.Z") should return NaN
Reviewed-by: sundar, jlaskey

! src/jdk/nashorn/internal/parser/DateParser.java
+ test/script/basic/JDK-8019985.js

Changeset: 36fb36217e1d
Author:    lagergren
Date:      2013-08-16 18:51 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/36fb36217e1d

8023017: SUB missing for widest op == number for BinaryNode
Reviewed-by: sundar, jlaskey

! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java
! src/jdk/nashorn/internal/codegen/ObjectCreator.java
! src/jdk/nashorn/internal/ir/BinaryNode.java
! src/jdk/nashorn/internal/ir/BreakableNode.java
! src/jdk/nashorn/internal/ir/IdentNode.java
! src/jdk/nashorn/internal/ir/LexicalContextNode.java
! src/jdk/nashorn/internal/objects/NativeArguments.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/parser/Parser.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java
! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java
! src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethod.java
! src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethodLinker.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java

Changeset: bd0174b1a42f
Author:    sundar
Date:      2013-08-19 17:16 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/bd0174b1a42f

8023210: jjs tools should support a mode where it will load few command line scripts and then entering into interactive shell
Reviewed-by: hannesw, attila, lagergren, jlaskey

! src/jdk/nashorn/internal/runtime/options/Options.java
! src/jdk/nashorn/tools/Shell.java

Changeset: e628aefac504
Author:    sundar
Date:      2013-08-19 19:37 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e628aefac504

Merge

- src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/MapIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java



From aleksey.shipilev at oracle.com  Mon Aug 19 14:50:57 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 19 Aug 2013 18:50:57 +0400
Subject: RFR (M) CR 8023234: StampedLock serializes readers on writer unlock
Message-ID: <521230D1.9070803@oracle.com>

Hi,

This is the review for the issue originally found by Dr. Heinz Kabutz
and Victor Grazi. The issue is consequently diagnosed and fixed by Doug
Lea in JSR 166 CVS.

The webrev which brings in the fix and the regression tests in JDK 8:
   http://cr.openjdk.java.net/~shade/8023234/webrev.00/

Testing:
  - builds on Linux x86_64/release
  - targeted regression test failure/pass before/after the fix
  - java/util/concurrent/locks/StampedLock basic tests

Thanks,
-Aleksey.


From henry.jen at oracle.com  Mon Aug 19 14:57:45 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 19 Aug 2013 07:57:45 -0700
Subject: 8023215: test/java/util/Comparator/TypeTest.java not running
	(failing but reported as passing)
In-Reply-To: <5211E205.70202@oracle.com>
References: <5211E205.70202@oracle.com>
Message-ID: <80892FA2-9E73-4F8B-90FE-65CD73A64BCA@oracle.com>

Uh, this one was wrote to be a regular jtreg test running with main, not a testNG test.

Thanks for looking into this.

Also I am wondering if this one still add any value, it was added to test the API when we had it like

 Comparator thenComparing(Comparator cmp)

Cheers,
Henry

On Aug 19, 2013, at 2:14 AM, Alan Bateman  wrote:

> 
> I just refreshed my clone of code-tools/jtreg to pick up a few changes, including a number of fixes to the TestNG support.
> 
> With the updated jtreg then test/java/util/Comparator/TypeTest.java fails:
> 
> [TestNG] Running:
>  java/util/Comparator/TypeTest.java
> 
> test public static void TypeTest.main(java.lang.String[]): skip
> org.testng.TestNGException:
> Method main requires 1 parameters but 0 were supplied in the @Test annotation.
> 
> It turns out this has been failing (and so this test has not been running) since it was initially pushed, it's just that jtreg has been reporting it as passing.
> 
> Looking at the test now then it seems incomplete (although it matches the version in the lambda forest). For now I'd like to "enable it" via the attached patch so that it's not failing when running the java.util tests.
> 
> -Alan
> 
> diff --git a/test/java/util/Comparator/TypeTest.java b/test/java/util/Comparator/TypeTest.java
> --- a/test/java/util/Comparator/TypeTest.java
> +++ b/test/java/util/Comparator/TypeTest.java
> @@ -75,7 +75,7 @@
>         }
>     }
> 
> -    public static void main(String[] args) {
> +    public void testOrder() {
>         Manager m1 = new Manager("Manager", 2, 2000);
>         Manager m2 = new Manager("Manager", 4, 1300);



From Alan.Bateman at oracle.com  Mon Aug 19 15:33:48 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 19 Aug 2013 16:33:48 +0100
Subject: Update jdk8/tl/jaxws to v2.2.9-b14140 ready for review
In-Reply-To: <52121603.1010401@oracle.com>
References: <520DFBC1.3020207@oracle.com> <520E0259.6070206@oracle.com>
	<52121603.1010401@oracle.com>
Message-ID: <52123ADC.1050306@oracle.com>

On 19/08/2013 13:56, Miroslav Kos wrote:
> Hi Alan,
> yes, this is true for rngom library - we downgraded it to the version 
> which has been approved to be used as a 3rd party library. Licences 
> are unchanged from the ones in the library; is there somebody who 
> could approve these are ok?
IANAL and without some understanding or legal help then it's impossible 
to approve changes that remove copyright headers from what seems to be 
3rd party code. All I can suggest is to get this checked.

-Alan.


From kumar.x.srinivasan at oracle.com  Mon Aug 19 16:42:45 2013
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Mon, 19 Aug 2013 16:42:45 +0000
Subject: hg: jdk8/tl/langtools: 7071377: Exception when javac -processor is
	given a class name with invalid postfix
Message-ID: <20130819164255.72E15489A4@hg.openjdk.java.net>

Changeset: 389eaf6ed973
Author:    ksrini
Date:      2013-08-19 07:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/389eaf6ed973

7071377: Exception when javac -processor is given a class name with invalid postfix
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/processing/errors/TestClassNames.java



From mike.duigou at oracle.com  Mon Aug 19 19:04:35 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 19 Aug 2013 12:04:35 -0700
Subject: 8020292: j.u.SplittableRandom
In-Reply-To: <9F153157-0FC5-4385-B1BC-4FE2D43006F4@oracle.com>
References: <9F153157-0FC5-4385-B1BC-4FE2D43006F4@oracle.com>
Message-ID: 

Looks pretty good. Two points concern me:

- Every source of non-crypto quality randoms should explicitly document that it should not be used for generating keys or other crypto purposes. There is mention that the seeding is insecure in the implementation docs but more explicit mention in the public docs is needed. (And some fool somewhere will *still* use it for crypto...)

- Additional seed material might be desirable for "seeder". I worry about how many of the actual bits are random. If no local host address is available the seed might be fairly predictable. In the murmur3 implementation I included also System.identityHashCode(String.class), System.identityHashCode(System.class), System.identityHashCode(Thread.currentThread()), Thread.currentThread().getId() and Runtime.getRuntime().freeMemory(). Mixing multiply with XOR operations also helps to spread the random bits out. Perhaps just call mix64 on each component and XOR against previous?

Mike

On Aug 19 2013, at 04:06 , Paul Sandoz wrote:

> Hi,
> 
> This is the patch for SplittableRandom:
> 
>  http://cr.openjdk.java.net/~psandoz/tl/JDK-8020292-SplittableRandom/webrev/
> 
> The algorithm remains the same as reported by Doug on the 9th August:
> 
>  http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019768.html
> 
> Paul.



From mike.duigou at oracle.com  Mon Aug 19 19:17:47 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 19 Aug 2013 12:17:47 -0700
Subject: RFR 8023155: Ensure functional consistency across Random,
	ThreadLocalRandom, SplittableRandom
In-Reply-To: 
References: 
Message-ID: 

- documentation of "bound" should mention that it is exclusive rather than relying on the return documentation.

- I find disallowing the zero bounds and empty ranges slightly annoying. It requires me to externally special case for situations such as:

Random ran = new Random();
String[] users = {"Fred"}; 

someUser = users[mine.nextInt(users.length - 1)];

This is a frequently used idiom. Yes, forcing the random number generator to return zero is silly but for symmetry it is convenient. An empty range isn't an obvious error (though the "String[] users = {};" case is obviously an error).

On Aug 19 2013, at 04:07 , Paul Sandoz wrote:

> Hi,
> 
> This patch updates Random and ThreadLocalRandom to have functional consistency (for the most part) across Random, ThreadLocalRandom and SplittableRandom:
> 
>  http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/webrev/
> 
>  http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/specdiff/overview-summary.html
> 
> I have yet to define a common interface e.g. RandomGenerator that Random, ThreadLocalRandom and SplittableRandom could implement, but it would be very easy to do so. Any thoughts on doing this?

Seems worthwhile. 

Mike

From henry.jen at oracle.com  Mon Aug 19 19:18:19 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 19 Aug 2013 12:18:19 -0700
Subject: RFR: 8023275: Wrapping collections should override default methods
Message-ID: <52126F7B.60602@oracle.com>

Hi,

Please review the webrev at
http://cr.openjdk.java.net/~henryjen/tl/8023275/0/webrev/

The patch adds override on default methods for a couple wrapping classed
and delegate those to underlying class.

There is a minor revise on synchronizedCollection javadoc to cover Stream.

A sanity check on wrapper classes to ensure default methods are override.

Those changes has been in lambda repo since long ago.

Cheers,
Henry




From sean.mullan at oracle.com  Mon Aug 19 19:13:44 2013
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Mon, 19 Aug 2013 19:13:44 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130819191422.3915D489A7@hg.openjdk.java.net>

Changeset: bce5205dbe84
Author:    ascarpino
Date:      2013-08-14 10:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bce5205dbe84

8022669: OAEPParameterSpec does not work if MGF1ParameterSpec is set to SHA2 algorithms
Reviewed-by: mullan

! src/share/classes/sun/security/rsa/RSAPadding.java
! test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java

Changeset: b40d246d4d81
Author:    ascarpino
Date:      2013-08-16 12:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b40d246d4d81

8022896: test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java fails
Reviewed-by: mullan

! test/ProblemList.txt



From mike.duigou at oracle.com  Mon Aug 19 20:01:17 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 19 Aug 2013 13:01:17 -0700
Subject: RFR: 8023275: Wrapping collections should override default methods
In-Reply-To: <52126F7B.60602@oracle.com>
References: <52126F7B.60602@oracle.com>
Message-ID: 

- @SuppressWarnings("unchecked") would appear to be in some of the cases.

- Replace:

@summary Unit tests for wrapping classes should delegate to default methods

with

@summary Ensure Collections wrapping classes provide non-default implementations

- ArrayList list -> List list

- TestNG DataProviders can return Iterator which means you can return cases.iterator() rather than converting to an array.



On Aug 19 2013, at 12:18 , Henry Jen wrote:

> Hi,
> 
> Please review the webrev at
> http://cr.openjdk.java.net/~henryjen/tl/8023275/0/webrev/
> 
> The patch adds override on default methods for a couple wrapping classed
> and delegate those to underlying class.
> 
> There is a minor revise on synchronizedCollection javadoc to cover Stream.
> 
> A sanity check on wrapper classes to ensure default methods are override.
> 
> Those changes has been in lambda repo since long ago.
> 
> Cheers,
> Henry
> 
> 



From guy.steele at oracle.com  Mon Aug 19 20:12:36 2013
From: guy.steele at oracle.com (Guy Steele)
Date: Mon, 19 Aug 2013 16:12:36 -0400
Subject: RFR 8023155: Ensure functional consistency across Random,
	ThreadLocalRandom, SplittableRandom
In-Reply-To: 
References: 
	
Message-ID: <87CA253C-0142-467F-85DF-96BB1C88F4D9@oracle.com>


On Aug 19, 2013, at 3:17 PM, Mike Duigou  wrote:

> - documentation of "bound" should mention that it is exclusive rather than relying on the return documentation.

Agreed.

> - I find disallowing the zero bounds and empty ranges slightly annoying. It requires me to externally special case for situations such as:
> 
> Random ran = new Random();
> String[] users = {"Fred"}; 
> 
> someUser = users[mine.nextInt(users.length - 1)];
> 
> This is a frequently used idiom. Yes, forcing the random number generator to return zero is silly but for symmetry it is convenient. An empty range isn't an obvious error (though the "String[] users = {};" case is obviously an error).

But I am puzzled here.  Is it really a frequently used idiom to want to set "someUser" to any element of the array "users" EXCEPT the last one?  Because that is what is asked for by

   someUser = users[mine.nextInt(users.length - 1)];

If you want a free choice among ALL elements in the (non-empty) array, then

   someUser = users[mine.nextInt(users.length)];

is what you want; and if the array is empty, then you'll get an exception from the nextInt method rather than the array indexing step, but that amounts to the same thing: an inability to pick an element from an empty array.

--Guy



From mike.duigou at oracle.com  Mon Aug 19 20:20:14 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 19 Aug 2013 13:20:14 -0700
Subject: RFR 8023155: Ensure functional consistency across Random,
	ThreadLocalRandom, SplittableRandom
In-Reply-To: <87CA253C-0142-467F-85DF-96BB1C88F4D9@oracle.com>
References: 
	
	<87CA253C-0142-467F-85DF-96BB1C88F4D9@oracle.com>
Message-ID: <253931C2-74E1-4017-9E53-72B9F1D1AA5B@oracle.com>


On Aug 19 2013, at 13:12 , Guy Steele wrote:

> 
> On Aug 19, 2013, at 3:17 PM, Mike Duigou  wrote:
> 
>> - I find disallowing the zero bounds and empty ranges slightly annoying. It requires me to externally special case for situations such as:
>> 
>> Random ran = new Random();
>> String[] users = {"Fred"}; 
>> 
>> someUser = users[mine.nextInt(users.length - 1)];
>> 
>> This is a frequently used idiom. Yes, forcing the random number generator to return zero is silly but for symmetry it is convenient. An empty range isn't an obvious error (though the "String[] users = {};" case is obviously an error).

> If you want a free choice among ALL elements in the (non-empty) array, then
> 
>   someUser = users[mine.nextInt(users.length)];
> 
> is what you want; and if the array is empty, then you'll get an exception from the nextInt method rather than the array indexing step, but that amounts to the same thing: an inability to pick an element from an empty array.

Doh, yes. I knew it was important to document that bounds was exclusive--I managed to confuse myself....

Mike

From guy.steele at oracle.com  Mon Aug 19 20:21:48 2013
From: guy.steele at oracle.com (Guy Steele)
Date: Mon, 19 Aug 2013 16:21:48 -0400
Subject: RFR 8023155: Ensure functional consistency across Random,
	ThreadLocalRandom, SplittableRandom
In-Reply-To: <253931C2-74E1-4017-9E53-72B9F1D1AA5B@oracle.com>
References: 
	
	<87CA253C-0142-467F-85DF-96BB1C88F4D9@oracle.com>
	<253931C2-74E1-4017-9E53-72B9F1D1AA5B@oracle.com>
Message-ID: <4AA1DBA0-6F11-4C4B-8A26-F834223E9C5F@oracle.com>


On Aug 19, 2013, at 4:20 PM, Mike Duigou  wrote:

> 
> On Aug 19 2013, at 13:12 , Guy Steele wrote:
> 
>> 
>> On Aug 19, 2013, at 3:17 PM, Mike Duigou  wrote:
>> 
>>> - I find disallowing the zero bounds and empty ranges slightly annoying. It requires me to externally special case for situations such as:
>>> 
>>> Random ran = new Random();
>>> String[] users = {"Fred"}; 
>>> 
>>> someUser = users[mine.nextInt(users.length - 1)];
>>> 
>>> This is a frequently used idiom. Yes, forcing the random number generator to return zero is silly but for symmetry it is convenient. An empty range isn't an obvious error (though the "String[] users = {};" case is obviously an error).
> 
>> If you want a free choice among ALL elements in the (non-empty) array, then
>> 
>>  someUser = users[mine.nextInt(users.length)];
>> 
>> is what you want; and if the array is empty, then you'll get an exception from the nextInt method rather than the array indexing step, but that amounts to the same thing: an inability to pick an element from an empty array.
> 
> Doh, yes. I knew it was important to document that bounds was exclusive--I managed to confuse myself?.

That happens to all of us.  :-)

--Guy



From dan.xu at oracle.com  Mon Aug 19 19:39:13 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Mon, 19 Aug 2013 19:39:13 +0000
Subject: hg: jdk8/tl/jdk: 8023203: Wrap RandomAccessFile.seek native method
	into a Java helper method
Message-ID: <20130819193934.17B0D489B2@hg.openjdk.java.net>

Changeset: 2fd841fccb2e
Author:    dxu
Date:      2013-08-19 12:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2fd841fccb2e

8023203: Wrap RandomAccessFile.seek native method into a Java helper method
Reviewed-by: alanb, chegar

! make/java/java/mapfile-vers
! makefiles/mapfiles/libjava/mapfile-vers
! src/share/classes/java/io/RandomAccessFile.java
! src/share/native/java/io/RandomAccessFile.c



From sean.mullan at oracle.com  Mon Aug 19 21:19:17 2013
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Mon, 19 Aug 2013 21:19:17 +0000
Subject: hg: jdk8/tl/jdk: 8016850: JCK javax.security.auth.Policy tests fail
	when run in Profiles mode
Message-ID: <20130819211951.B52AD489C1@hg.openjdk.java.net>

Changeset: f120e2c4b4b1
Author:    mullan
Date:      2013-08-19 17:17 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f120e2c4b4b1

8016850: JCK javax.security.auth.Policy tests fail when run in Profiles mode
Summary: Move default javax.security.auth.Policy implementation to compact1 profile
Reviewed-by: vinnie

! src/share/classes/com/sun/security/auth/PolicyFile.java
- src/share/classes/com/sun/security/auth/PolicyParser.java
- src/share/classes/com/sun/security/auth/SubjectCodeSource.java
! src/share/classes/javax/security/auth/Policy.java
+ src/share/classes/sun/security/provider/AuthPolicyFile.java
+ src/share/classes/sun/security/provider/SubjectCodeSource.java



From martinrb at google.com  Mon Aug 19 21:28:35 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 19 Aug 2013 14:28:35 -0700
Subject: RFR 8023155: Ensure functional consistency across Random,
	ThreadLocalRandom, SplittableRandom
In-Reply-To: 
References: 
Message-ID: 

I haven't had the time I would have liked to review recent changes to our
prng's, but I am very happy with the direction of this change (and others).
 Especially the use of a better prng with ThreadLocalRandom.  Adding an
interface for all these classes to implement also seems good.  Thanks!

(and there's always more work to do... full support for a variety of
generators and distributions is a career path)


On Mon, Aug 19, 2013 at 4:07 AM, Paul Sandoz  wrote:

> Hi,
>
> This patch updates Random and ThreadLocalRandom to have functional
> consistency (for the most part) across Random, ThreadLocalRandom and
> SplittableRandom:
>
>
> http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/webrev/
>
>
> http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/specdiff/overview-summary.html
>
>
> The PRNG of ThreadLocalRandom has been updated by Doug:
>
>      * Even though this class subclasses java.util.Random, it uses the
>      * same basic algorithm as java.util.SplittableRandom.  (See its
>      * internal documentation for explanations, which are not repeated
>      * here.)  Because ThreadLocalRandoms are not splittable
>      * though, we use only a single 64bit gamma.
>
>
> The stream-returning method gaussians() is removed from Random and TLR.
> Doug's explanation as to why SplittableRandom does not have nextGaussian is
> applicable to why it's not worth having sized and effectively infinite
> stream-returning gaussians() methods:
>
> "There are many algorithms to choose from, that are all
> independent of the underlying uniform RNG algorithm.
> Plus, there are many more probability distributions
> out there. Singling out a particular algorithm/method
> for Gaussian stands mostly as an accident of history
> in java.util.Random."
>
>
> The nextFloat functionality has been left unmodified. Such un/bounded
> nextFloat methods do not exist on SplittableRandom, i don't think they
> carry their weight given the nextDouble functionality.
>
>
> I have yet to define a common interface e.g. RandomGenerator that Random,
> ThreadLocalRandom and SplittableRandom could implement, but it would be
> very easy to do so. Any thoughts on doing this?
>
> --
>
> A JPRT run reported no corresponding failures.
>
> Paul.


From martinrb at google.com  Mon Aug 19 21:44:48 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 19 Aug 2013 14:44:48 -0700
Subject: 8020292: j.u.SplittableRandom
In-Reply-To: <9F153157-0FC5-4385-B1BC-4FE2D43006F4@oracle.com>
References: <9F153157-0FC5-4385-B1BC-4FE2D43006F4@oracle.com>
Message-ID: 

I've done some review on SplittableRandom earlier, and am happy to see this
go into openjdk8.

I'm not sure it's worth maintaining a TestNG version of the tck
test SplittableRandomTest.java.  Doug's tck tests are expected to
eventually become part of tck 8, so they should be run regularly that way.
 I also strongly encourage Oracle's QA process to run these tck tests
against vanilla openjdk8, thereby not losing any test coverage.  We could
add an ant target to jsr166 CVS to make that happen.


On Mon, Aug 19, 2013 at 4:06 AM, Paul Sandoz  wrote:

> Hi,
>
> This is the patch for SplittableRandom:
>
>
> http://cr.openjdk.java.net/~psandoz/tl/JDK-8020292-SplittableRandom/webrev/
>
> The algorithm remains the same as reported by Doug on the 9th August:
>
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019768.html
>
> Paul.


From mike.duigou at oracle.com  Mon Aug 19 22:15:12 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 19 Aug 2013 15:15:12 -0700
Subject: RFR: 8021591 : (s) Additional explicit null checks
In-Reply-To: <51FA8584.1000702@oracle.com>
References: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com>
	<51FA8584.1000702@oracle.com>
Message-ID: <31FFC5F9-2950-44DA-B846-D1A8E8AA9E18@oracle.com>


On Aug 1 2013, at 08:57 , Alan Bateman wrote:

> On 26/07/2013 16:31, Mike Duigou wrote:
>> Hello all;
>> 
>> This patch adds some missing checks for null that, according to interface contract, should be throwing NPE. It also improves the existing tests to check for these cases.
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8021591/0/webrev/
>> 
>> The changes to src/share/classes/java/util/concurrent/ConcurrentHashMap.java will be synchronized separately with the jsr166 workspace. They are part of this review to avoid test failures.
>> 
>> Mike
> As retainAll and removeAll are long standing methods, are there are cases where we might now throw NPE when we didn't previously?

Yes.

retainAll(null) and removeAll(null) will more consistently throw NPE. Previously the NPE was not thrown by some collections when the collection they were empty.

> I'm just wondering if any of these need to be looked at more closely, minimally to get into release/compatibility notes.

I will definitely tag this issue for release notes mention.

> -Alan



From martinrb at google.com  Mon Aug 19 22:35:54 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 19 Aug 2013 15:35:54 -0700
Subject: RFR: 8021591 : (s) Additional explicit null checks
In-Reply-To: <31FFC5F9-2950-44DA-B846-D1A8E8AA9E18@oracle.com>
References: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com>
	<51FA8584.1000702@oracle.com>
	<31FFC5F9-2950-44DA-B846-D1A8E8AA9E18@oracle.com>
Message-ID: 

My feeling is that the JDK specs have been creeping in the direction of
excessive pedantry and doc lawyerism.  I think it's overall a benefit of
Java that its documentation is more readable (at the cost of being a little
less precise) than the typical ISO spec.

So we usually say "returns true if the foo got frozzled" instead of the
more precise "returns true if and only if the foo got frozzled".
It's "obvious" that an NPE is thrown on an attempt to derefence a null arg,
which might not happen in some corner case.  I think it's overall a
detriment if either extra null checks are inserted or the spec is made more
precise but less readable.

Consider the Throws spec for
http://download.java.net/jdk8/docs/api/java/util/TreeMap.html#containsKey(java.lang.Object)

ClassCastException - if the specified key cannot be compared with the keys
currently in the map

That's incomplete and imprecise, but don't pessimize by adding code to
compare the arg with every key in the map!  (which is the equivalent of
what is happening here)

A vote from me for maintaining the already high level of pedantry we have,
but not raising it any further.



On Mon, Aug 19, 2013 at 3:15 PM, Mike Duigou  wrote:

>
> On Aug 1 2013, at 08:57 , Alan Bateman wrote:
>
> > On 26/07/2013 16:31, Mike Duigou wrote:
> >> Hello all;
> >>
> >> This patch adds some missing checks for null that, according to
> interface contract, should be throwing NPE. It also improves the existing
> tests to check for these cases.
> >>
> >> http://cr.openjdk.java.net/~mduigou/JDK-8021591/0/webrev/
> >>
> >> The changes to
> src/share/classes/java/util/concurrent/ConcurrentHashMap.java will be
> synchronized separately with the jsr166 workspace. They are part of this
> review to avoid test failures.
> >>
> >> Mike
> > As retainAll and removeAll are long standing methods, are there are
> cases where we might now throw NPE when we didn't previously?
>
> Yes.
>
> retainAll(null) and removeAll(null) will more consistently throw NPE.
> Previously the NPE was not thrown by some collections when the collection
> they were empty.
>
> > I'm just wondering if any of these need to be looked at more closely,
> minimally to get into release/compatibility notes.
>
> I will definitely tag this issue for release notes mention.
>
> > -Alan
>
>


From martinrb at google.com  Mon Aug 19 23:06:55 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 19 Aug 2013 16:06:55 -0700
Subject: RFR (M) CR 8023234: StampedLock serializes readers on writer
	unlock
In-Reply-To: <521230D1.9070803@oracle.com>
References: <521230D1.9070803@oracle.com>
Message-ID: 

Thanks.  Looks good.

Style suggestions for the test:

+            while(!isDone && !isInterrupted()) {
SPC after keywords.

I think it's more readable to use CountDownLatch instead of CyclicBarrier
for writerHasLock, because of asymmetric API.
Doers call countDown(), waiters call await().



On Mon, Aug 19, 2013 at 7:50 AM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> Hi,
>
> This is the review for the issue originally found by Dr. Heinz Kabutz
> and Victor Grazi. The issue is consequently diagnosed and fixed by Doug
> Lea in JSR 166 CVS.
>
> The webrev which brings in the fix and the regression tests in JDK 8:
>    http://cr.openjdk.java.net/~shade/8023234/webrev.00/
>
> Testing:
>   - builds on Linux x86_64/release
>   - targeted regression test failure/pass before/after the fix
>   - java/util/concurrent/locks/StampedLock basic tests
>
> Thanks,
> -Aleksey.
>


From david.holmes at oracle.com  Mon Aug 19 23:33:48 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Aug 2013 09:33:48 +1000
Subject: Simple RFR: 8203311 Clean up profile-includes.txt
Message-ID: <5212AB5C.6080804@oracle.com>

http://cr.openjdk.java.net/~dholmes/8023311/webrev/

Patch inlined below

This is a trivial cleanup following on from an earlier change under 
8017570. JFR was moved from profile compact3 to the full JRE but not all 
the variables in profile-includes.txt were updated as needed. jfr.jar 
needed to removed from the profile3 jar list and added to the jre jar list.

This has no impact on the actual build artifacts - JFR was, and remains, 
in the full JRE only.

Thanks,
David

--- old/makefiles/profile-includes.txt	2013-08-19 19:10:17.554355677 -0400
+++ new/makefiles/profile-includes.txt	2013-08-19 19:10:14.586187808 -0400
@@ -102,6 +102,7 @@
      security/US_export_policy.jar \
      security/local_policy.jar

+
  PROFILE_2_JRE_BIN_FILES := \
      rmid$(EXE_SUFFIX) \
      rmiregistry$(EXE_SUFFIX)
@@ -140,7 +141,6 @@
  PROFILE_3_JRE_OTHER_FILES :=

  PROFILE_3_JRE_JAR_FILES := \
-    jfr.jar \
      management-agent.jar


@@ -253,6 +253,6 @@
      ext/cldrdata.jar \
      ext/dnsns.jar \
      ext/nashorn.jar \
-    ext/zipfs.jar
-
+    ext/zipfs.jar \
+    jfr.jar



From henry.jen at oracle.com  Tue Aug 20 00:09:37 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 19 Aug 2013 17:09:37 -0700
Subject: RFR: 8023275: Wrapping collections should override default methods
In-Reply-To: 
References: <52126F7B.60602@oracle.com>
	
Message-ID: <5212B3C1.7040406@oracle.com>

On 08/19/2013 01:01 PM, Mike Duigou wrote:
> - @SuppressWarnings("unchecked") would appear to be in some of the cases.
> 

Added.

> - Replace:
> 
> @summary Unit tests for wrapping classes should delegate to default methods
> 
> with
> 
> @summary Ensure Collections wrapping classes provide non-default implementations
> 
> - ArrayList list -> List list
> 

Updated.

> - TestNG DataProviders can return Iterator which means you can return cases.iterator() rather than converting to an array.
> 
>

Thanks for the tip, testng javadoc doesn't mention it, but in document.
Since it's one time construction and not lazily, I didn't change it.

http://cr.openjdk.java.net/~henryjen/tl/8023275/1/webrev/

Cheers,
Henry


From xuelei.fan at oracle.com  Tue Aug 20 00:43:43 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Tue, 20 Aug 2013 00:43:43 +0000
Subject: hg: jdk8/tl/jdk: 8020842: IDN do not throw IAE when hostname ends
	with a trailing dot
Message-ID: <20130820004420.A5A84489CB@hg.openjdk.java.net>

Changeset: 096e7c665857
Author:    xuelei
Date:      2013-08-19 17:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/096e7c665857

8020842: IDN do not throw IAE when hostname ends with a trailing dot
Reviewed-by: weijun, michaelm

! src/share/classes/java/net/IDN.java
+ test/java/net/IDN/IllegalArg.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java



From joe.darcy at oracle.com  Tue Aug 20 01:24:02 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 19 Aug 2013 18:24:02 -0700
Subject: RFR: 8022343: j.l.Class.getAnnotatedSuperclass() doesn't return
	null in some cases
In-Reply-To: 
References: <20130816121739.GM12405@jfranck-desktop.jrpg.bea.com>
	
Message-ID: <5212C532.8030905@oracle.com>

Hi Joel,

I agree the code looks fine.

However, I concur with the general sentiment of Paul test advice without 
advocating using testng for this task.

A loop over a Class[] initialized with the kinds of values of 
interest would seem to be better structured to me and allow for better 
exception handing, etc.

-Joe

On 08/19/2013 01:34 AM, Paul Sandoz wrote:
> Hi Joel,
>
> The fix looks OK.
>
> Not suggesting you do the following, unless you really want to, but the test is an example of where TestNG data providers are useful, since all cases will be tested and reported for pass or failure, rather than in this case the first failure will cause other checks (if any) not to be tested and in addition will not report which check failed (one needs to look at the stack trace).
>
> Not tested:
>
>    @DataProvider(name = "class")
>    private static Object[][] getClasses() {
>        // Using the stream API because i can :-)
>        // Arguably simpler in this case to use new Object[][] { {} }
>        return Stream.of(
>                                  Object.class,
>                                  If.class,
>                                  Object[].class,
>                                  void.class,
>                                  int.class).
>                map(e -> new Object[] { e }).
>                toArray(Object[][]::new);
>    }
>
>    @Test(dataProvider = "class")
>    public void testAnnotatedSuperClassIsNull(Class c) {
>        assertNull(c.getAnnotatedSuperclass())
>    }
>
> Paul.
>
> On Aug 16, 2013, at 2:17 PM, Joel Borggren-Franck  wrote:
>
>> Hi
>>
>> Please review this small fix for a type annotation reflection issue.
>>
>> The javadoc spec for Class.getAnnotatedSuperclass says:
>>
>> * If this Class represents either the Object class, an interface type, an
>> * array type, a primitive type, or void, the return value is null.
>>
>> The patch fixes this.
>>
>> Webrev at: http://cr.openjdk.java.net/~jfranck/8022343/webrew.00/
>>
>> Patch also included it at the end of this mail.
>>
>> cheers
>> /Joel
>>
>>
>>
>> diff -r b07b19182e40 src/share/classes/java/lang/Class.java
>> --- a/src/share/classes/java/lang/Class.java	Thu Aug 15 15:04:59 2013 +0100
>> +++ b/src/share/classes/java/lang/Class.java	Fri Aug 16 13:20:31 2013 +0200
>> @@ -3338,8 +3338,16 @@
>>       * @since 1.8
>>       */
>>      public AnnotatedType getAnnotatedSuperclass() {
>> -         return TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), getConstantPool(), this);
>> -}
>> +        if(this == Object.class ||
>> +                isInterface() ||
>> +                isArray() ||
>> +                isPrimitive() ||
>> +                this == Void.TYPE) {
>> +            return null;
>> +        }
>> +
>> +        return TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), getConstantPool(), this);
>> +    }
>>
>>      /**
>>       * Returns an array of AnnotatedType objects that represent the use of types to
>> diff -r b07b19182e40 test/java/lang/annotation/TypeAnnotationReflection.java
>> --- a/test/java/lang/annotation/TypeAnnotationReflection.java	Thu Aug 15 15:04:59 2013 +0100
>> +++ b/test/java/lang/annotation/TypeAnnotationReflection.java	Fri Aug 16 13:20:31 2013 +0200
>> @@ -23,7 +23,7 @@
>>
>> /*
>>   * @test
>> - * @bug 8004698 8007073
>> + * @bug 8004698 8007073 8022343
>>   * @summary Unit test for type annotations
>>   */
>>
>> @@ -58,7 +58,7 @@
>>      }
>>
>>      private static void testSuper() throws Exception {
>> -        check(Object.class.getAnnotatedSuperclass().getAnnotations().length == 0);
>> +        check(Object.class.getAnnotatedSuperclass() == null);
>>          check(Class.class.getAnnotatedSuperclass().getAnnotations().length == 0);
>>
>>          AnnotatedType a;
>> diff -r b07b19182e40 test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java
>> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
>> +++ b/test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java	Fri Aug 16 13:20:31 2013 +0200
>> @@ -0,0 +1,50 @@
>> +/*
>> + * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
>> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> + *
>> + * This code is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 only, as
>> + * published by the Free Software Foundation.
>> + *
>> + * This code is distributed in the hope that it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>> + * version 2 for more details (a copy is included in the LICENSE file that
>> + * accompanied this code).
>> + *
>> + * You should have received a copy of the GNU General Public License version
>> + * 2 along with this work; if not, write to the Free Software Foundation,
>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>> + *
>> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>> + * or visit www.oracle.com if you need additional information or have any
>> + * questions.
>> + */
>> +
>> +/*
>> + * @test
>> + * @bug 8022343
>> + * @summary make sure Class.getAnnotatedSuperclass() returns null when specified to do so
>> + */
>> +
>> +import java.util.*;
>> +import java.lang.annotation.*;
>> +import java.lang.reflect.*;
>> +import java.io.Serializable;
>> +
>> +public class GetAnnotatedSuperclass {
>> +    public static void main(String[] args) throws Exception {
>> +        check(Object.class.getAnnotatedSuperclass() == null);
>> +        check(If.class.getAnnotatedSuperclass() == null);
>> +        check(Object[].class.getAnnotatedSuperclass() == null);
>> +        check(void.class.getAnnotatedSuperclass() == null);
>> +        check(int.class.getAnnotatedSuperclass() == null);
>> +    }
>> +
>> +    private static void check(boolean b) {
>> +        if (!b)
>> +            throw new RuntimeException();
>> +    }
>> +    interface If {}
>> +}
>> +



From xuelei.fan at oracle.com  Tue Aug 20 01:51:26 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Tue, 20 Aug 2013 01:51:26 +0000
Subject: hg: jdk8/tl/jdk: 8023230: The impl of KerberosClientKeyExchange maybe
	not exist
Message-ID: <20130820015148.C0D5F489CE@hg.openjdk.java.net>

Changeset: 21a25911f7f7
Author:    xuelei
Date:      2013-08-19 18:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/21a25911f7f7

8023230: The impl of KerberosClientKeyExchange maybe not exist
Reviewed-by: weijun

! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java



From jonathan.gibbons at oracle.com  Tue Aug 20 02:23:19 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 19 Aug 2013 19:23:19 -0700
Subject: Enum.valueOf(String)
Message-ID: <5212D317.4030905@oracle.com>

> ------------------------------------------------------------------------
> I noticed this method is not listed in the Javadocs for 5/6/7/8 but it's
> part of every enum. Is this an oversight or is there a good reason why it's
> not documented?
>
> -- 
> Cheers,
> Paul

Paul,

Can you give more details?

On a sample size of one, I see the method descriptions being generated 
correctly

http://docs.oracle.com/javase/7/docs/api/javax/lang/model/SourceVersion.html

http://docs.oracle.com/javase/7/docs/api/javax/lang/model/SourceVersion.html#valueOf%28java.lang.String%29
http://docs.oracle.com/javase/7/docs/api/javax/lang/model/SourceVersion.html#values%28%29

-- Jon


From miroslav.kos at oracle.com  Tue Aug 20 06:23:30 2013
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Tue, 20 Aug 2013 08:23:30 +0200
Subject: Update jdk8/tl/jaxws to v2.2.9-b14140 ready for review
In-Reply-To: <52123ADC.1050306@oracle.com>
References: <520DFBC1.3020207@oracle.com> <520E0259.6070206@oracle.com>
	<52121603.1010401@oracle.com> <52123ADC.1050306@oracle.com>
Message-ID: <52130B62.3010902@oracle.com>

Hi everybody,

I prepared a new changeset containing no copyright changes so we can get 
further: http://cr.openjdk.java.net/~mkos/8022885/webrev.01/

We will discuss rngom changes separately and if necessary, it will be 
updated with a new integration.

Miran



On 08/19/2013 05:33 PM, Alan Bateman wrote:
> On 19/08/2013 13:56, Miroslav Kos wrote:
>> Hi Alan,
>> yes, this is true for rngom library - we downgraded it to the version 
>> which has been approved to be used as a 3rd party library. Licences 
>> are unchanged from the ones in the library; is there somebody who 
>> could approve these are ok?
> IANAL and without some understanding or legal help then it's 
> impossible to approve changes that remove copyright headers from what 
> seems to be 3rd party code. All I can suggest is to get this checked.
>
> -Alan.



From staffan.larsen at oracle.com  Tue Aug 20 06:59:36 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Tue, 20 Aug 2013 06:59:36 +0000
Subject: hg: jdk8/tl/jdk: 8022071: Some vm/jvmti tests fail because cannot
	attach to the Java virtual machine
Message-ID: <20130820070010.F0E36489D2@hg.openjdk.java.net>

Changeset: 53ea4b5cef9b
Author:    sla
Date:      2013-08-20 08:59 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/53ea4b5cef9b

8022071: Some vm/jvmti tests fail because cannot attach to the Java virtual machine
Reviewed-by: erikj, sspitsyn

! makefiles/CompileNativeLibraries.gmk
+ makefiles/mapfiles/libattach/reorder-windows-x86
+ makefiles/mapfiles/libattach/reorder-windows-x86_64
! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c



From Alan.Bateman at oracle.com  Tue Aug 20 07:02:16 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 20 Aug 2013 08:02:16 +0100
Subject: Simple RFR: 8203311 Clean up profile-includes.txt
In-Reply-To: <5212AB5C.6080804@oracle.com>
References: <5212AB5C.6080804@oracle.com>
Message-ID: <52131478.1050908@oracle.com>

On 20/08/2013 00:33, David Holmes wrote:
> http://cr.openjdk.java.net/~dholmes/8023311/webrev/
>
> Patch inlined below
>
> This is a trivial cleanup following on from an earlier change under 
> 8017570. JFR was moved from profile compact3 to the full JRE but not 
> all the variables in profile-includes.txt were updated as needed. 
> jfr.jar needed to removed from the profile3 jar list and added to the 
> jre jar list.
>
> This has no impact on the actual build artifacts - JFR was, and 
> remains, in the full JRE only.
This looks okay to me, I can't quite tell why this wasn't done as part 
of JDK- 8017570 as it's not hard to miss.

-Alan.



From david.holmes at oracle.com  Tue Aug 20 07:12:58 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Aug 2013 17:12:58 +1000
Subject: Simple RFR: 8203311 Clean up profile-includes.txt
In-Reply-To: <52131478.1050908@oracle.com>
References: <5212AB5C.6080804@oracle.com> <52131478.1050908@oracle.com>
Message-ID: <521316FA.1040405@oracle.com>

On 20/08/2013 5:02 PM, Alan Bateman wrote:
> On 20/08/2013 00:33, David Holmes wrote:
>> http://cr.openjdk.java.net/~dholmes/8023311/webrev/
>>
>> Patch inlined below
>>
>> This is a trivial cleanup following on from an earlier change under
>> 8017570. JFR was moved from profile compact3 to the full JRE but not
>> all the variables in profile-includes.txt were updated as needed.
>> jfr.jar needed to removed from the profile3 jar list and added to the
>> jre jar list.
>>
>> This has no impact on the actual build artifacts - JFR was, and
>> remains, in the full JRE only.
> This looks okay to me, I can't quite tell why this wasn't done as part
> of JDK- 8017570 as it's not hard to miss.

Thanks Alan. I can't recall why I didn't review it either. :)

David

> -Alan.
>


From david.holmes at oracle.com  Tue Aug 20 07:19:32 2013
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Tue, 20 Aug 2013 07:19:32 +0000
Subject: hg: jdk8/tl/jdk: 8023311: Clean up profile-includes.txt
Message-ID: <20130820071955.810B7489D5@hg.openjdk.java.net>

Changeset: e17da8b09f5e
Author:    dholmes
Date:      2013-08-20 03:18 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e17da8b09f5e

8023311: Clean up profile-includes.txt
Reviewed-by: alanb

! makefiles/profile-includes.txt



From Alan.Bateman at oracle.com  Tue Aug 20 10:04:21 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 20 Aug 2013 11:04:21 +0100
Subject: Update jdk8/tl/jaxws to v2.2.9-b14140 ready for review
In-Reply-To: <52130B62.3010902@oracle.com>
References: <520DFBC1.3020207@oracle.com> <520E0259.6070206@oracle.com>
	<52121603.1010401@oracle.com> <52123ADC.1050306@oracle.com>
	<52130B62.3010902@oracle.com>
Message-ID: <52133F25.3010201@oracle.com>

On 20/08/2013 07:23, Miroslav Kos wrote:
> Hi everybody,
>
> I prepared a new changeset containing no copyright changes so we can 
> get further: http://cr.openjdk.java.net/~mkos/8022885/webrev.01/
>
> We will discuss rngom changes separately and if necessary, it will be 
> updated with a new integration.
>
> Miran
Thanks for the dropping this, that make things easier. There are still a 
bunch updates to copyright dates in files that don't have other changes, 
they seem harmless and I only assume they have crept in with whatever is 
used to create the source bundle to push to OpenJDK.

Chris - are you going to sponsor this?

-Alan


From dl at cs.oswego.edu  Tue Aug 20 11:46:37 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Tue, 20 Aug 2013 07:46:37 -0400
Subject: RFR 8023155: Ensure functional consistency across Random,
	ThreadLocalRandom, SplittableRandom
In-Reply-To: 
References: 
Message-ID: <5213571D.4000007@cs.oswego.edu>

On 08/19/2013 07:07 AM, Paul Sandoz wrote:
> Hi,
>
> This patch updates Random and ThreadLocalRandom to have functional consistency (for the most part) across Random, ThreadLocalRandom and SplittableRandom:
>
>    http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/webrev/
>

A couple of extra @since's crept in. See below.


>
> I have yet to define a common interface e.g. RandomGenerator

After scrapping this idea twice now already for JDK8 time frame, I
think leave it for JDK9.

...

diff ThreadLocalRandom.java~ ThreadLocalRandom.java
316d315
<      * @since 1.8
331d329
<      * @since 1.8
370d367
<      * @since 1.8
425d421
<      * @since 1.8
470d465
<      * @since 1.8
482d476
<      * @since 1.8



From Alan.Bateman at oracle.com  Tue Aug 20 12:13:38 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 20 Aug 2013 13:13:38 +0100
Subject: 8023351: Add TEST.groups in preparation to simplify rules in
	jdk/test/Makefile
Message-ID: <52135D72.2020205@oracle.com>


For some time now we have been chipping away at the make files that are 
used to run the jdk tests. Mike has his wielded his axe on several 
occasions recently to remove logic and rules that are no longer needed. 
One of the next steps needs to be to remove the definitions of the test 
targets from the make file as it can't currently be shared between the 
Makefile and direct jtreg usage.

To that end, I'd like to push a TEST.groups file to define the 
corresponding jtreg groups. For the most part the proposal is to start 
up with a mostly 1-1 mapping for the existing test targets. In addition 
to groups for the normal test target then I also propose to add higher 
level groups that partition the entire test suite into three groups 
named "core", "svc" and "desktop". This makes it really easy to run 
selections of the test suite, for example "jtreg  :core :svc" 
will run all the core area and serviceability tests.

One other thing to mention is that David Holmes will arrive soon with 
additional groups to add selection of tests that are appropriate for the 
compact Profiles, maybe JRE vs. JDK too.

The webrev with the proposed changes is here, it's very simple:

http://cr.openjdk.java.net/~alanb/8023351/webrev/

A few things to note (as there are a few small changes from the normal 
test targets):

1. I've moved the management and java.lang.instrument tests out of the 
jdk_lang group. Once the make file targets are updated then these can be 
re-included if needed but logically they should be separated.

2. I have not moved the JSR-292 tests or stream tests, they remain in 
jdk_lang and jdk_util for now. They can easily be changed if there is 
good reason.

3. I've kept security1, security2 and security3 for now but these are 
unbalanced in execution time and ideally should all be in one group. 
Once we get to the point that concurrency is dialed up by default then 
that might be the right time to do that.

4. To my knowledge, the client teams do not use the make files and I 
don't know anyone that used the jdk_awt, etc. make targets. For now, 
I've just re-worked those targets (eliminating the beans1, beans2, 
beans3 that have not been needed since we moved the execution mode out 
of the make file). I'm sure someone in the AWT or 2D area could come up 
with cleaner definitions but as they aren't used then it shouldn't 
matter for now.

-Alan




From paul.sandoz at oracle.com  Tue Aug 20 13:11:04 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 20 Aug 2013 15:11:04 +0200
Subject: Please ignore: TEST without signing using OpenPGP (signed messages
	appear to be blocked)
Message-ID: <8A1DDCCE-EBB6-4022-B117-AFD7601CEC9E@oracle.com>

Paul.


From paul.sandoz at oracle.com  Tue Aug 20 09:21:03 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 20 Aug 2013 11:21:03 +0200
Subject: RFR: 8023275: Wrapping collections should override default methods
In-Reply-To: <52126F7B.60602@oracle.com>
References: <52126F7B.60602@oracle.com>
Message-ID: <03DB347B-7A9A-4150-8251-0C36FE317806@oracle.com>

[resending unsigned, sorry if a dup arrives later on]

On Aug 19, 2013, at 9:18 PM, Henry Jen  wrote:

> Hi,
> 
> Please review the webrev at
> http://cr.openjdk.java.net/~henryjen/tl/8023275/0/webrev/
> 
> The patch adds override on default methods for a couple wrapping classed
> and delegate those to underlying class.
> 
> There is a minor revise on synchronizedCollection javadoc to cover Stream.
> 

Looks good.


> A sanity check on wrapper classes to ensure default methods are override.
> 

You might want to additionally use an ArrayList instance for unmodifiableList/synchronizedList/checkedList, so as to check both unmod list impls:

   public static  List unmodifiableList(List list) {
       return (list instanceof RandomAccess ?
               new UnmodifiableRandomAccessList<>(list) :
               new UnmodifiableList<>(list));
   }

Paul.


From paul.sandoz at oracle.com  Tue Aug 20 11:57:56 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 20 Aug 2013 13:57:56 +0200
Subject: 8020292: j.u.SplittableRandom
In-Reply-To: 
References: <9F153157-0FC5-4385-B1BC-4FE2D43006F4@oracle.com>
	
Message-ID: 

[resending unsigned, sorry if a dup arrives later on]

On Aug 19, 2013, at 9:04 PM, Mike Duigou  wrote:

> Looks pretty good. Two points concern me:
> 
> - Every source of non-crypto quality randoms should explicitly document that it should not be used for generating keys or other crypto purposes. There is mention that the seeding is insecure in the implementation docs but more explicit mention in the public docs is needed. (And some fool somewhere will *still* use it for crypto...)
> 

Good point.


> - Additional seed material might be desirable for "seeder". I worry about how many of the actual bits are random. If no local host address is available the seed might be fairly predictable. In the murmur3 implementation I included also System.identityHashCode(String.class), System.identityHashCode(System.class), System.identityHashCode(Thread.currentThread()), Thread.currentThread().getId() and Runtime.getRuntime().freeMemory(). Mixing multiply with XOR operations also helps to spread the random bits out. Perhaps just call mix64 on each component and XOR against previous?
> 

Are you concerned that the values passed to mix64 may be of low entropy? i.e. that small differences in input (such as counting numbers) do not result in large enough differences in the output. I suppose it might be possible to switch from MurmurHash3 to using Stafford's "Mix13" constants or a combination to avoid any potential correlations. However, given that there is further mixing going on for the values and gamma generation perhaps it is not so important?

Paul.



From paul.sandoz at oracle.com  Tue Aug 20 12:16:08 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 20 Aug 2013 14:16:08 +0200
Subject: RFR 8023155: Ensure functional consistency across Random,
	ThreadLocalRandom, SplittableRandom
In-Reply-To: <5213571D.4000007@cs.oswego.edu>
References: 
	<5213571D.4000007@cs.oswego.edu>
Message-ID: 

[resending unsigned, sorry if a dup arrives later on]

On Aug 20, 2013, at 1:46 PM, Doug Lea 
 wrote:

> On 08/19/2013 07:07 AM, Paul Sandoz wrote:
>> Hi,
>> 
>> This patch updates Random and ThreadLocalRandom to have functional consistency (for the most part) across Random, ThreadLocalRandom and SplittableRandom:
>> 
>>   http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/webrev/
>> 
> 
> A couple of extra @since's crept in. See below.
> 

According to the spec diff new overriding methods are added to TLR:

  http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/specdiff/java/util/concurrent/ThreadLocalRandom.html

  http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/specdiff/java/util/Random.html

Is that sufficient motivation to add @since to such methods on TLR?


> 
>> 
>> I have yet to define a common interface e.g. RandomGenerator
> 
> After scrapping this idea twice now already for JDK8 time frame, I
> think leave it for JDK9.
> 

OK. I like the idea of an interface but i am concerned we don't have enough time to flesh out the contract. Personally i would prefer to manage this webrev minus an interface, otherwise i fear we will never get the patch in!

Paul.

From paul.sandoz at oracle.com  Tue Aug 20 12:53:36 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 20 Aug 2013 14:53:36 +0200
Subject: RFR 8023155: Ensure functional consistency across Random,
	ThreadLocalRandom, SplittableRandom
In-Reply-To: 
References: 
	
Message-ID: <2F2B4DE7-93F4-42C5-96B3-591C52CF24F8@oracle.com>

[resending unsigned, sorry if a dup arrives later on]

On Aug 19, 2013, at 9:17 PM, Mike Duigou  wrote:

> - documentation of "bound" should mention that it is exclusive rather than relying on the return documentation.
> 

I have updated both webrevs and the spec diff to be consistent when referring to ranges:

 http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/webrev/

 http://cr.openjdk.java.net/~psandoz/tl/JDK-8020292-SplittableRandom/webrev/

 http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/specdiff/overview-summary.html


(SplittableRandom is also updated to include some blurb on not being cryptographically secure.)

Paul.


From pbenedict at apache.org  Tue Aug 20 13:27:11 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Tue, 20 Aug 2013 08:27:11 -0500
Subject: Enum.valueOf(String)
In-Reply-To: 
References: 
	<7AE76BDE-06C8-4438-90F4-765B9726C80F@nicholaswilliams.net>
	
	<013E5DBB-9D96-4D7A-AE1B-29D56D0B5729@nicholaswilliams.net>
	
	<5211D838.5070408@oracle.com>
	
Message-ID: 

Jon, it's not a problem with the method docs, per se. The issue is about
how the generation isn't documented. My questioning started because I was
using several enums without javadoc available, but I did have the source
available, and couldn't figure out how the method came to be. Since I've
asked, everyone knew (but me!) it was a generated method, but I couldn't
divine that knowledge.

My recommendation is to add an @implNote on Enum.valueOf(Class, String) so
that people know each subclass will get a generated method that behaves
similarly. What do you think?


On Mon, Aug 19, 2013 at 9:23 AM, Paul Benedict  wrote:

> I have been working with classes that don't have javadoc attachments. The
> problem was I couldn't find the method in the source nor was the method
> part of the Enum class. So where did it materialize from? Now I know the
> answer: the compiler generates it.
>
> I really think this knowledge should be added to the Enum javadoc class. I
> had to go on quite a goose hunt to find this fact.
>
> Paul
>
>
> On Mon, Aug 19, 2013 at 3:32 AM, Alan Bateman wrote:
>
>> On 18/08/2013 05:07, Paul Benedict wrote:
>>
>>> I think the generated method needs to be listed in the class javadoc at
>>> least. I presume it throws an exception too (like the other valueOf) if
>>> the
>>> String can't be resolved to a constant, but no user is going to discover
>>> this fact through the documentation.
>>>
>>>  Have you checked the generated avadoc for your enum? The
>> valueOf(String) should be there and specified to throw IAE or NPE.
>>
>> -Alan
>>
>>
>>
>
>
> --
> Cheers,
> Paul
>



-- 
Cheers,
Paul


From alexander.zuev at oracle.com  Tue Aug 20 13:36:52 2013
From: alexander.zuev at oracle.com (alexander.zuev at oracle.com)
Date: Tue, 20 Aug 2013 13:36:52 +0000
Subject: hg: jdk8/tl/langtools: 7182350: Regression in wording of unchecked
	warning message
Message-ID: <20130820133656.57107489E0@hg.openjdk.java.net>

Changeset: 55da6b3a6940
Author:    kizune
Date:      2013-08-20 17:34 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/55da6b3a6940

7182350: Regression in wording of unchecked warning message
Reviewed-by: mcimadamore, jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! test/tools/javac/6758789/T6758789b.out
+ test/tools/javac/7182350/T7182350.java
+ test/tools/javac/7182350/T7182350.out
! test/tools/javac/generics/7015430/T7015430_1.out
! test/tools/javac/generics/7015430/T7015430_2.out
! test/tools/javac/generics/7151802/T7151802.out
! test/tools/javac/generics/inference/6718364/T6718364.out
! test/tools/javac/generics/inference/7177306/T7177306a.out



From jonathan.gibbons at oracle.com  Tue Aug 20 13:48:16 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 20 Aug 2013 06:48:16 -0700
Subject: Enum.valueOf(String)
In-Reply-To: 
References: 
	<7AE76BDE-06C8-4438-90F4-765B9726C80F@nicholaswilliams.net>
	
	<013E5DBB-9D96-4D7A-AE1B-29D56D0B5729@nicholaswilliams.net>
	
	<5211D838.5070408@oracle.com>
	
	
Message-ID: <521373A0.2050101@oracle.com>

Paul,

Enums are well covered in JLS 7, section 8.9. In particular, see 8.9.2, 
Enum Body Declarations, beginning at the line

"In addition, if E is the name of an enum type, then that type has the 
following implicitly declared static methods:"

-- Jon

On 08/20/2013 06:27 AM, Paul Benedict wrote:
> Jon, it's not a problem with the method docs, per se. The issue is 
> about how the generation isn't documented. My questioning started 
> because I was using several enums without javadoc available, but I did 
> have the source available, and couldn't figure out how the method came 
> to be. Since I've asked, everyone knew (but me!) it was a generated 
> method, but I couldn't divine that knowledge.
>
> My recommendation is to add an @implNote on Enum.valueOf(Class, 
> String) so that people know each subclass will get a generated method 
> that behaves similarly. What do you think?
>
>
> On Mon, Aug 19, 2013 at 9:23 AM, Paul Benedict  > wrote:
>
>     I have been working with classes that don't have javadoc
>     attachments. The problem was I couldn't find the method in the
>     source nor was the method part of the Enum class. So where did it
>     materialize from? Now I know the answer: the compiler generates it.
>
>     I really think this knowledge should be added to the Enum javadoc
>     class. I had to go on quite a goose hunt to find this fact.
>
>     Paul
>
>
>     On Mon, Aug 19, 2013 at 3:32 AM, Alan Bateman
>     > wrote:
>
>         On 18/08/2013 05:07, Paul Benedict wrote:
>
>             I think the generated method needs to be listed in the
>             class javadoc at
>             least. I presume it throws an exception too (like the
>             other valueOf) if the
>             String can't be resolved to a constant, but no user is
>             going to discover
>             this fact through the documentation.
>
>         Have you checked the generated avadoc for your enum? The
>         valueOf(String) should be there and specified to throw IAE or NPE.
>
>         -Alan
>
>
>
>
>
>     -- 
>     Cheers,
>     Paul
>
>
>
>
> -- 
> Cheers,
> Paul



From pbenedict at apache.org  Tue Aug 20 14:29:38 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Tue, 20 Aug 2013 09:29:38 -0500
Subject: Enum.valueOf(String)
In-Reply-To: <521373A0.2050101@oracle.com>
References: 
	<7AE76BDE-06C8-4438-90F4-765B9726C80F@nicholaswilliams.net>
	
	<013E5DBB-9D96-4D7A-AE1B-29D56D0B5729@nicholaswilliams.net>
	
	<5211D838.5070408@oracle.com>
	
	
	<521373A0.2050101@oracle.com>
Message-ID: 

So are you recommending not to alter the Javadoc of Enum to mention this
fact? Going to the JLS is great for compiler developers, but it's not the
first place for the end user.


On Tue, Aug 20, 2013 at 8:48 AM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

>  Paul,
>
> Enums are well covered in JLS 7, section 8.9. In particular, see 8.9.2,
> Enum Body Declarations, beginning at the line
>
> "In addition, if E is the name of an enum type, then that type has the
> following implicitly declared static methods:"
>
> -- Jon
>
>
> On 08/20/2013 06:27 AM, Paul Benedict wrote:
>
>  Jon, it's not a problem with the method docs, per se. The issue is about
> how the generation isn't documented. My questioning started because I was
> using several enums without javadoc available, but I did have the source
> available, and couldn't figure out how the method came to be. Since I've
> asked, everyone knew (but me!) it was a generated method, but I couldn't
> divine that knowledge.
>
> My recommendation is to add an @implNote on Enum.valueOf(Class, String) so
> that people know each subclass will get a generated method that behaves
> similarly. What do you think?
>
>
> On Mon, Aug 19, 2013 at 9:23 AM, Paul Benedict wrote:
>
>> I have been working with classes that don't have javadoc attachments. The
>> problem was I couldn't find the method in the source nor was the method
>> part of the Enum class. So where did it materialize from? Now I know the
>> answer: the compiler generates it.
>>
>> I really think this knowledge should be added to the Enum javadoc class.
>> I had to go on quite a goose hunt to find this fact.
>>
>> Paul
>>
>>
>>  On Mon, Aug 19, 2013 at 3:32 AM, Alan Bateman wrote:
>>
>>> On 18/08/2013 05:07, Paul Benedict wrote:
>>>
>>>> I think the generated method needs to be listed in the class javadoc at
>>>> least. I presume it throws an exception too (like the other valueOf) if
>>>> the
>>>> String can't be resolved to a constant, but no user is going to discover
>>>> this fact through the documentation.
>>>>
>>>>  Have you checked the generated avadoc for your enum? The
>>> valueOf(String) should be there and specified to throw IAE or NPE.
>>>
>>> -Alan
>>>
>>>
>>>
>>
>>
>>  --
>> Cheers,
>> Paul
>>
>
>
>
> --
> Cheers,
> Paul
>
>
>


-- 
Cheers,
Paul


From aleksey.shipilev at oracle.com  Tue Aug 20 14:55:47 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 20 Aug 2013 18:55:47 +0400
Subject: RFR (M) CR 8023234: StampedLock serializes readers on writer
	unlock
In-Reply-To: 
References: <521230D1.9070803@oracle.com>
	
Message-ID: <52138373.8090903@oracle.com>

Thanks Martin!

New webrev:
 http://cr.openjdk.java.net/~shade/8023234/webrev.01/

On 08/20/2013 03:06 AM, Martin Buchholz wrote:
> Thanks.  Looks good.
> 
> Style suggestions for the test:
> 
> +            while(!isDone && !isInterrupted()) {
> SPC after keywords.

Fixed.

> I think it's more readable to use CountDownLatch instead of
> CyclicBarrier for writerHasLock, because of asymmetric API.
> Doers call countDown(), waiters call await().

Nope, we need: a) *reusable* primitive, CDL is one-shot, unfortunately;
b) we need symmetric block, writer should also block on barrier until
both readers arrive; this makes test much more reliable.

-Aleksey.



From jonathan.gibbons at oracle.com  Tue Aug 20 14:56:46 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 20 Aug 2013 07:56:46 -0700
Subject: Enum.valueOf(String)
In-Reply-To: 
References: 
	<7AE76BDE-06C8-4438-90F4-765B9726C80F@nicholaswilliams.net>
	
	<013E5DBB-9D96-4D7A-AE1B-29D56D0B5729@nicholaswilliams.net>
	
	<5211D838.5070408@oracle.com>
	
	
	<521373A0.2050101@oracle.com>
	
Message-ID: <521383AE.8040206@oracle.com>

Well, I presume other learning materials for Java (tutorials, ... for 
dummies, etc) will explain the existence of these methods as part of the 
language feature that is "enum"s.

Quite where the bytecodes for the methods comes from is implementation 
detail that should not need to be documented in end-user docs.

Interestingly, though, is that the javadoc for Enum.valueOf *does* have 
something close to the text you want:

http://docs.oracle.com/javase/7/docs/api/java/lang/Enum.html#valueOf(java.lang.Class,%20java.lang.String)

> Note that for a particular enum type T, the implicitly declared public 
> static T valueOf(String) method on that enum may be used instead of 
> this method to map from a name to the corresponding enum constant. All 
> the constants of an enum type can be obtained by calling the implicit 
> public static T[] values() method of that type.

-- Jon


On 08/20/2013 07:29 AM, Paul Benedict wrote:
> So are you recommending not to alter the Javadoc of Enum to mention 
> this fact? Going to the JLS is great for compiler developers, but it's 
> not the first place for the end user.
>
>
> On Tue, Aug 20, 2013 at 8:48 AM, Jonathan Gibbons 
> > wrote:
>
>     Paul,
>
>     Enums are well covered in JLS 7, section 8.9. In particular, see
>     8.9.2, Enum Body Declarations, beginning at the line
>
>     "In addition, if E is the name of an enum type, then that type has
>     the following implicitly declared static methods:"
>
>     -- Jon
>
>
>     On 08/20/2013 06:27 AM, Paul Benedict wrote:
>>     Jon, it's not a problem with the method docs, per se. The issue
>>     is about how the generation isn't documented. My questioning
>>     started because I was using several enums without javadoc
>>     available, but I did have the source available, and couldn't
>>     figure out how the method came to be. Since I've asked, everyone
>>     knew (but me!) it was a generated method, but I couldn't divine
>>     that knowledge.
>>
>>     My recommendation is to add an @implNote on Enum.valueOf(Class,
>>     String) so that people know each subclass will get a generated
>>     method that behaves similarly. What do you think?
>>
>>
>>     On Mon, Aug 19, 2013 at 9:23 AM, Paul Benedict
>>     > wrote:
>>
>>         I have been working with classes that don't have javadoc
>>         attachments. The problem was I couldn't find the method in
>>         the source nor was the method part of the Enum class. So
>>         where did it materialize from? Now I know the answer: the
>>         compiler generates it.
>>
>>         I really think this knowledge should be added to the Enum
>>         javadoc class. I had to go on quite a goose hunt to find this
>>         fact.
>>
>>         Paul
>>
>>
>>         On Mon, Aug 19, 2013 at 3:32 AM, Alan Bateman
>>         > wrote:
>>
>>             On 18/08/2013 05:07, Paul Benedict wrote:
>>
>>                 I think the generated method needs to be listed in
>>                 the class javadoc at
>>                 least. I presume it throws an exception too (like the
>>                 other valueOf) if the
>>                 String can't be resolved to a constant, but no user
>>                 is going to discover
>>                 this fact through the documentation.
>>
>>             Have you checked the generated avadoc for your enum? The
>>             valueOf(String) should be there and specified to throw
>>             IAE or NPE.
>>
>>             -Alan
>>
>>
>>
>>
>>
>>         -- 
>>         Cheers,
>>         Paul
>>
>>
>>
>>
>>     -- 
>>     Cheers,
>>     Paul
>
>
>
>
> -- 
> Cheers,
> Paul



From staffan.larsen at oracle.com  Tue Aug 20 14:56:12 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Tue, 20 Aug 2013 14:56:12 +0000
Subject: hg: jdk8/tl/jdk: 8016727:
	test/com/sun/jdi/sde/TemperatureTableTest.java failing intermittently
Message-ID: <20130820145635.5C28E489E3@hg.openjdk.java.net>

Changeset: 961cdea684b5
Author:    sla
Date:      2013-08-20 16:53 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/961cdea684b5

8016727: test/com/sun/jdi/sde/TemperatureTableTest.java failing intermittently
Reviewed-by: alanb

! test/com/sun/jdi/sde/TemperatureTableTest.java



From joel.franck at oracle.com  Tue Aug 20 15:27:15 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Tue, 20 Aug 2013 15:27:15 +0000
Subject: hg: jdk8/tl/langtools: 8019243: AnnotationTypeMismatchException
	instead of MirroredTypeException
Message-ID: <20130820152718.E9171489E6@hg.openjdk.java.net>

Changeset: e811fb09a1dc
Author:    jfranck
Date:      2013-08-20 17:21 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e811fb09a1dc

8019243: AnnotationTypeMismatchException instead of MirroredTypeException
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Attribute.java
! src/share/classes/com/sun/tools/javac/comp/Annotate.java
! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java
+ test/tools/javac/processing/errors/EnsureMirroredTypeException/Processor.java
+ test/tools/javac/processing/errors/EnsureMirroredTypeException/Source.java
+ test/tools/javac/processing/errors/EnsureMirroredTypeException/Source.out



From paul.sandoz at oracle.com  Tue Aug 20 15:39:25 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 20 Aug 2013 17:39:25 +0200
Subject: RFR 8023367 Collections.emptyList().sort((Comparator)null) throws NPE
Message-ID: <5E4A0C2D-9EDC-4324-9D7D-3B8F22CAA4CD@oracle.com>

Hi,

Please see below for a simple fix to stop throwing an NPE on Collections.emptyList().sort(null);

Paul.

http://hg.openjdk.java.net/lambda/lambda/jdk/rev/67e00b862126

diff -r 3647aab7b1d5 src/share/classes/java/util/Collections.java
--- a/src/share/classes/java/util/Collections.java	Tue Aug 06 14:26:34 2013 +0100
+++ b/src/share/classes/java/util/Collections.java	Tue Aug 20 17:38:16 2013 +0200
@@ -4508,7 +4508,6 @@
         }
         @Override
         public void sort(Comparator c) {
-            Objects.requireNonNull(c);
         }
 
         // Override default methods in Collection
diff -r 3647aab7b1d5 test/java/util/Collection/ListDefaults.java
--- a/test/java/util/Collection/ListDefaults.java	Tue Aug 06 14:26:34 2013 +0100
+++ b/test/java/util/Collection/ListDefaults.java	Tue Aug 20 17:38:16 2013 +0200
@@ -49,6 +49,7 @@
 
 /**
  * @test
+ * @bug 8023367
  * @library testlibrary
  * @build CollectionAsserts CollectionSupplier
  * @run testng ListDefaults
@@ -100,6 +101,7 @@
     @DataProvider(name="listProvider", parallel=true)
     public static Object[][] listCases() {
         final List cases = new LinkedList<>();
+        cases.add(new Object[] { Collections.emptyList() });
         cases.add(new Object[] { new ArrayList<>() });
         cases.add(new Object[] { new LinkedList<>() });
         cases.add(new Object[] { new Vector<>() });
@@ -128,6 +130,11 @@
             list.removeIf(null);
             fail("expected NPE not thrown");
         } catch (NullPointerException npe) {}
+        try {
+            list.sort(null);
+        } catch (Throwable t) {
+            fail("Exception not expected: " + t);
+        }
     }
 
     @Test

From Alan.Bateman at oracle.com  Tue Aug 20 15:59:59 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 20 Aug 2013 16:59:59 +0100
Subject: RFR 8023367 Collections.emptyList().sort((Comparator)null) throws
	NPE
In-Reply-To: <5E4A0C2D-9EDC-4324-9D7D-3B8F22CAA4CD@oracle.com>
References: <5E4A0C2D-9EDC-4324-9D7D-3B8F22CAA4CD@oracle.com>
Message-ID: <5213927F.8030700@oracle.com>

On 20/08/2013 16:39, Paul Sandoz wrote:
> Hi,
>
> Please see below for a simple fix to stop throwing an NPE on Collections.emptyList().sort(null);
>
> Paul.
>
Looks okay to me.

-Alan


From ivan.gerasimov at oracle.com  Tue Aug 20 16:01:36 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 20 Aug 2013 20:01:36 +0400
Subject: RFR [7129312] BufferedInputStream calculates negative array size
	with large streams and mark
In-Reply-To: <5211F591.6010504@oracle.com>
References: <520E2541.9020505@oracle.com> <520E541E.1060403@oracle.com>
	<5211F591.6010504@oracle.com>
Message-ID: <521392E0.20604@oracle.com>

Thank you Alan!

> The update to BufferedInputStream looks okay to me. I guess we don't 
> actually need to check the size in the constructor, OOME will be 
> thrown anyway. Usually constants are in uppercase and maybe we should 
> just do this while we are here (so this means rename defaultBufferSize 
> too).
>
Removed the unnecessary check and renamed the constants.

> I'm in two minds about the test as reserving 4GB of heap is going to 
> be a problem on some systems (32-bit mostly).
>
Yes, you're right!
I've updated the test to be a shell script + Java application.
If java reported 'Invalid maximum heap size', the test is skipped.

Just check with JPRT, the test passes on both 64 and 32 bit platforms.

Would you please review the updated webrev?
http://cr.openjdk.java.net/~igerasim/7129312/2/webrev/ 


Sincerely yours,
Ivan


> -Alan.
>
>
>
>



From mike.duigou at oracle.com  Tue Aug 20 16:27:32 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 20 Aug 2013 09:27:32 -0700
Subject: RFR 8023367 Collections.emptyList().sort((Comparator)null) throws
	NPE
In-Reply-To: <5E4A0C2D-9EDC-4324-9D7D-3B8F22CAA4CD@oracle.com>
References: <5E4A0C2D-9EDC-4324-9D7D-3B8F22CAA4CD@oracle.com>
Message-ID: <3B7A9709-92F3-4A44-9D11-E832CBF78687@oracle.com>

Looks OK to me.

On Aug 20 2013, at 08:39 , Paul Sandoz wrote:

> Hi,
> 
> Please see below for a simple fix to stop throwing an NPE on Collections.emptyList().sort(null);
> 
> Paul.
> 
> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/67e00b862126
> 
> diff -r 3647aab7b1d5 src/share/classes/java/util/Collections.java
> --- a/src/share/classes/java/util/Collections.java	Tue Aug 06 14:26:34 2013 +0100
> +++ b/src/share/classes/java/util/Collections.java	Tue Aug 20 17:38:16 2013 +0200
> @@ -4508,7 +4508,6 @@
>         }
>         @Override
>         public void sort(Comparator c) {
> -            Objects.requireNonNull(c);
>         }
> 
>         // Override default methods in Collection
> diff -r 3647aab7b1d5 test/java/util/Collection/ListDefaults.java
> --- a/test/java/util/Collection/ListDefaults.java	Tue Aug 06 14:26:34 2013 +0100
> +++ b/test/java/util/Collection/ListDefaults.java	Tue Aug 20 17:38:16 2013 +0200
> @@ -49,6 +49,7 @@
> 
> /**
>  * @test
> + * @bug 8023367
>  * @library testlibrary
>  * @build CollectionAsserts CollectionSupplier
>  * @run testng ListDefaults
> @@ -100,6 +101,7 @@
>     @DataProvider(name="listProvider", parallel=true)
>     public static Object[][] listCases() {
>         final List cases = new LinkedList<>();
> +        cases.add(new Object[] { Collections.emptyList() });
>         cases.add(new Object[] { new ArrayList<>() });
>         cases.add(new Object[] { new LinkedList<>() });
>         cases.add(new Object[] { new Vector<>() });
> @@ -128,6 +130,11 @@
>             list.removeIf(null);
>             fail("expected NPE not thrown");
>         } catch (NullPointerException npe) {}
> +        try {
> +            list.sort(null);
> +        } catch (Throwable t) {
> +            fail("Exception not expected: " + t);
> +        }
>     }
> 
>     @Test



From Lance.Andersen at oracle.com  Tue Aug 20 16:27:37 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Tue, 20 Aug 2013 12:27:37 -0400
Subject: 8023351: Add TEST.groups in preparation to simplify rules in
	jdk/test/Makefile
In-Reply-To: <52135D72.2020205@oracle.com>
References: <52135D72.2020205@oracle.com>
Message-ID: <5A4D11E8-08C9-48D3-9A2B-393F11326EA8@oracle.com>

I think this look OK Alan

Best
Lance
On Aug 20, 2013, at 8:13 AM, Alan Bateman wrote:

> 
> For some time now we have been chipping away at the make files that are used to run the jdk tests. Mike has his wielded his axe on several occasions recently to remove logic and rules that are no longer needed. One of the next steps needs to be to remove the definitions of the test targets from the make file as it can't currently be shared between the Makefile and direct jtreg usage.
> 
> To that end, I'd like to push a TEST.groups file to define the corresponding jtreg groups. For the most part the proposal is to start up with a mostly 1-1 mapping for the existing test targets. In addition to groups for the normal test target then I also propose to add higher level groups that partition the entire test suite into three groups named "core", "svc" and "desktop". This makes it really easy to run selections of the test suite, for example "jtreg  :core :svc" will run all the core area and serviceability tests.
> 
> One other thing to mention is that David Holmes will arrive soon with additional groups to add selection of tests that are appropriate for the compact Profiles, maybe JRE vs. JDK too.
> 
> The webrev with the proposed changes is here, it's very simple:
> 
> http://cr.openjdk.java.net/~alanb/8023351/webrev/
> 
> A few things to note (as there are a few small changes from the normal test targets):
> 
> 1. I've moved the management and java.lang.instrument tests out of the jdk_lang group. Once the make file targets are updated then these can be re-included if needed but logically they should be separated.
> 
> 2. I have not moved the JSR-292 tests or stream tests, they remain in jdk_lang and jdk_util for now. They can easily be changed if there is good reason.
> 
> 3. I've kept security1, security2 and security3 for now but these are unbalanced in execution time and ideally should all be in one group. Once we get to the point that concurrency is dialed up by default then that might be the right time to do that.
> 
> 4. To my knowledge, the client teams do not use the make files and I don't know anyone that used the jdk_awt, etc. make targets. For now, I've just re-worked those targets (eliminating the beans1, beans2, beans3 that have not been needed since we moved the execution mode out of the make file). I'm sure someone in the AWT or 2D area could come up with cleaner definitions but as they aren't used then it shouldn't matter for now.
> 
> -Alan
> 
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From paul.sandoz at oracle.com  Tue Aug 20 16:47:20 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Tue, 20 Aug 2013 16:47:20 +0000
Subject: hg: jdk8/tl/jdk: 8023367:
	Collections.emptyList().sort((Comparator)null) throws NPE
Message-ID: <20130820164747.1CD50489ED@hg.openjdk.java.net>

Changeset: c17d6543b30f
Author:    psandoz
Date:      2013-08-20 17:36 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c17d6543b30f

8023367: Collections.emptyList().sort((Comparator)null) throws NPE
Reviewed-by: alanb, mduigou

! src/share/classes/java/util/Collections.java
! test/java/util/Collection/ListDefaults.java



From artkoshelev at gmail.com  Sat Aug 17 12:34:20 2013
From: artkoshelev at gmail.com (Artem Koshelev)
Date: Sat, 17 Aug 2013 16:34:20 +0400
Subject: Test for java.sql.DriverManager
Message-ID: 

Hi,

not sure about mailing group, but here is a test i wrote
https://gist.github.com/artkoshelev/6256684.
Review please and add it to testbase.

Artem


From staffan.larsen at oracle.com  Tue Aug 20 17:07:41 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Tue, 20 Aug 2013 17:07:41 +0000
Subject: hg: jdk8/tl/jdk: 8023250: Update JavaScript code in JDK for changes
	in iteration over Java arrays
Message-ID: <20130820170753.D7C43489F1@hg.openjdk.java.net>

Changeset: 1ccc7bbee0bb
Author:    attila
Date:      2013-08-20 11:15 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ccc7bbee0bb

8023250: Update JavaScript code in JDK for changes in iteration over Java arrays
Reviewed-by: sundar, sla

! src/share/classes/com/sun/tools/hat/resources/hat.js



From mike.duigou at oracle.com  Tue Aug 20 17:26:15 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 20 Aug 2013 10:26:15 -0700
Subject: 8023351: Add TEST.groups in preparation to simplify rules in
	jdk/test/Makefile
In-Reply-To: <52135D72.2020205@oracle.com>
References: <52135D72.2020205@oracle.com>
Message-ID: <0E1B4A8F-ACAF-46A6-8981-CB360082F3EC@oracle.com>

Looks very good!

On Aug 20 2013, at 05:13 , Alan Bateman wrote:

> 
> For some time now we have been chipping away at the make files that are used to run the jdk tests. Mike has his wielded his axe on several occasions recently to remove logic and rules that are no longer needed. One of the next steps needs to be to remove the definitions of the test targets from the make file as it can't currently be shared between the Makefile and direct jtreg usage.

I'm eager to wield the axe again once this is change is integrated to remove the directory specifications from the test/Makefile (and hopefully soon from jprt.properties as well). :-)

> To that end, I'd like to push a TEST.groups file to define the corresponding jtreg groups. For the most part the proposal is to start up with a mostly 1-1 mapping for the existing test targets.

Once we have A/B runs that show the same tests are run we can consider refactoring the organization. (For example, I would like to see at least a portion of sun/misc move from jdk_lang to jdk_util).

> In addition to groups for the normal test target then I also propose to add higher level groups that partition the entire test suite into three groups named "core", "svc" and "desktop". This makes it really easy to run selections of the test suite, for example "jtreg  :core :svc" will run all the core area and serviceability tests.
> 
> One other thing to mention is that David Holmes will arrive soon with additional groups to add selection of tests that are appropriate for the compact Profiles, maybe JRE vs. JDK too.
> 
> The webrev with the proposed changes is here, it's very simple:
> 
> http://cr.openjdk.java.net/~alanb/8023351/webrev/
> 
> A few things to note (as there are a few small changes from the normal test targets):
> 
> 1. I've moved the management and java.lang.instrument tests out of the jdk_lang group. Once the make file targets are updated then these can be re-included if needed but logically they should be separated.
> 
> 2. I have not moved the JSR-292 tests or stream tests, they remain in jdk_lang and jdk_util for now. They can easily be changed if there is good reason.

Probably they will get their own sub-groups but may or may not remain in the super-groups.

> 3. I've kept security1, security2 and security3 for now but these are unbalanced in execution time and ideally should all be in one group. Once we get to the point that concurrency is dialed up by default then that might be the right time to do that.

I am glad to see you defined the jdk_security super-group. This allows us to abstract these details. 

> 4. To my knowledge, the client teams do not use the make files and I don't know anyone that used the jdk_awt, etc. make targets. For now, I've just re-worked those targets (eliminating the beans1, beans2, beans3 that have not been needed since we moved the execution mode out of the make file). I'm sure someone in the AWT or 2D area could come up with cleaner definitions but as they aren't used then it shouldn't matter for now.
> 
> -Alan
> 
> 



From eamonn at mcmanus.net  Tue Aug 20 18:00:33 2013
From: eamonn at mcmanus.net (Eamonn McManus)
Date: Tue, 20 Aug 2013 11:00:33 -0700
Subject: Enum.valueOf(String)
In-Reply-To: <521373A0.2050101@oracle.com>
References: 
	<7AE76BDE-06C8-4438-90F4-765B9726C80F@nicholaswilliams.net>
	
	<013E5DBB-9D96-4D7A-AE1B-29D56D0B5729@nicholaswilliams.net>
	
	<5211D838.5070408@oracle.com>
	
	
	<521373A0.2050101@oracle.com>
Message-ID: 

As I mentioned earlier in the thread, it's kind of user-hostile for
the Enum javadoc to send the user to the JLS instead of just saying,
even briefly, what the methods are. Even more so since it doesn't
actually link to the relevant section of the JLS or in fact to the JLS
at all. This is not a complaint that the information isn't documented,
just that it is too hard to find. Imagine how much work I have to do
if I can't remember the name of the method to convert from a string to
an enum constant in a new enum I'm writing, and it doesn't occur to me
to pick some other random enum and look at its javadoc.

?amonn


2013/8/20 Jonathan Gibbons :
> Paul,
>
> Enums are well covered in JLS 7, section 8.9. In particular, see 8.9.2, Enum
> Body Declarations, beginning at the line
>
> "In addition, if E is the name of an enum type, then that type has the
> following implicitly declared static methods:"
>
> -- Jon
>
>
> On 08/20/2013 06:27 AM, Paul Benedict wrote:
>>
>> Jon, it's not a problem with the method docs, per se. The issue is about
>> how the generation isn't documented. My questioning started because I was
>> using several enums without javadoc available, but I did have the source
>> available, and couldn't figure out how the method came to be. Since I've
>> asked, everyone knew (but me!) it was a generated method, but I couldn't
>> divine that knowledge.
>>
>> My recommendation is to add an @implNote on Enum.valueOf(Class, String) so
>> that people know each subclass will get a generated method that behaves
>> similarly. What do you think?
>>
>>
>> On Mon, Aug 19, 2013 at 9:23 AM, Paul Benedict > > wrote:
>>
>>     I have been working with classes that don't have javadoc
>>     attachments. The problem was I couldn't find the method in the
>>     source nor was the method part of the Enum class. So where did it
>>     materialize from? Now I know the answer: the compiler generates it.
>>
>>     I really think this knowledge should be added to the Enum javadoc
>>     class. I had to go on quite a goose hunt to find this fact.
>>
>>     Paul
>>
>>
>>     On Mon, Aug 19, 2013 at 3:32 AM, Alan Bateman
>>     > wrote:
>>
>>         On 18/08/2013 05:07, Paul Benedict wrote:
>>
>>             I think the generated method needs to be listed in the
>>             class javadoc at
>>             least. I presume it throws an exception too (like the
>>             other valueOf) if the
>>             String can't be resolved to a constant, but no user is
>>             going to discover
>>             this fact through the documentation.
>>
>>         Have you checked the generated avadoc for your enum? The
>>         valueOf(String) should be there and specified to throw IAE or NPE.
>>
>>         -Alan
>>
>>
>>
>>
>>
>>     --     Cheers,
>>     Paul
>>
>>
>>
>>
>> --
>> Cheers,
>> Paul
>
>


From Mike.Duigou at oracle.COM  Tue Aug 20 18:07:13 2013
From: Mike.Duigou at oracle.COM (Mike Duigou)
Date: Tue, 20 Aug 2013 11:07:13 -0700
Subject: RFR : 8023395 : (xs) Deprecate sun.misc.Sort and sun.misc.Compare
Message-ID: <3CE2D646-4978-42B2-9AC4-BF41D5DC3D6A@oracle.COM>

Hello all;

This is a proposal to deprecate (Any votes for outright removal?) two classes in the private sun.misc package. These are ancient vestigial classes who's usage has long been eliminated in the JDK in favour of java.util.Arrays.sort(T[], Comparator) and java.util.Arrays.sort(T[], int start, int end, Comparator).


http://cr.openjdk.java.net/~mduigou/JDK-8023395/0/webrev/

Mike




From Mike.Duigou at oracle.COM  Tue Aug 20 18:11:36 2013
From: Mike.Duigou at oracle.COM (Mike Duigou)
Date: Tue, 20 Aug 2013 11:11:36 -0700
Subject: RFR: 8023306 : (xs) Add replace() implementations to TreeMap
Message-ID: 

Hello all;

This is a small changeset I have split out from the mostly unrelated JDK-8021591. This changeset adds Map.replace(key,value) and Map.replace(key,oldValue,newValue) implementations to TreeMap that are more efficient that that provided by the defaults in Map.

webrev: http://cr.openjdk.java.net/~mduigou/JDK-8023306/0/webrev/

Cheers,

Mike




From brian.burkhalter at oracle.com  Tue Aug 20 18:27:40 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 20 Aug 2013 11:27:40 -0700
Subject: RFR : 8023395 : (xs) Deprecate sun.misc.Sort and sun.misc.Compare
In-Reply-To: <3CE2D646-4978-42B2-9AC4-BF41D5DC3D6A@oracle.COM>
References: <3CE2D646-4978-42B2-9AC4-BF41D5DC3D6A@oracle.COM>
Message-ID: 

+1

On Aug 20, 2013, at 11:07 AM, Mike Duigou wrote:

> Any votes for outright removal?



From joe.darcy at oracle.com  Tue Aug 20 18:27:50 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 20 Aug 2013 11:27:50 -0700
Subject: RFR : 8023395 : (xs) Deprecate sun.misc.Sort and sun.misc.Compare
In-Reply-To: <3CE2D646-4978-42B2-9AC4-BF41D5DC3D6A@oracle.COM>
References: <3CE2D646-4978-42B2-9AC4-BF41D5DC3D6A@oracle.COM>
Message-ID: <5213B526.7040700@oracle.com>

On 08/20/2013 11:07 AM, Mike Duigou wrote:
> Hello all;
>
> This is a proposal to deprecate (Any votes for outright removal?)

Yes; take them out!

-Joe



From brian.burkhalter at oracle.com  Tue Aug 20 18:32:06 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 20 Aug 2013 11:32:06 -0700
Subject: RFR: 8023306 : (xs) Add replace() implementations to TreeMap
In-Reply-To: 
References: 
Message-ID: <406DE62F-6F46-4087-A2C4-C7EA7F4B4E07@oracle.com>

+1

On Aug 20, 2013, at 11:11 AM, Mike Duigou wrote:

> This is a small changeset I have split out from the mostly unrelated JDK-8021591. This changeset adds Map.replace(key,value) and Map.replace(key,oldValue,newValue) implementations to TreeMap that are more efficient that that provided by the defaults in Map.
> 
> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8023306/0/webrev/



From mike.duigou at oracle.com  Tue Aug 20 18:54:57 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 20 Aug 2013 11:54:57 -0700
Subject: RFR: 8023306 : (xs) Add replace() implementations to TreeMap
In-Reply-To: 
References: 
Message-ID: <55C85296-289A-4DB1-8BE8-7CF33D97DDB6@oracle.com>

Paul Sandoz pointed out (again) that I let synchronized slip back into the split out patch. 

http://cr.openjdk.java.net/~mduigou/JDK-8023306/1/webrev/

Corrects this error.

Mike

On Aug 20 2013, at 11:11 , Mike Duigou wrote:

> Hello all;
> 
> This is a small changeset I have split out from the mostly unrelated JDK-8021591. This changeset adds Map.replace(key,value) and Map.replace(key,oldValue,newValue) implementations to TreeMap that are more efficient that that provided by the defaults in Map.
> 
> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8023306/0/webrev/
> 
> Cheers,
> 
> Mike
> 
> 



From chris.hegarty at oracle.com  Tue Aug 20 18:58:53 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 20 Aug 2013 19:58:53 +0100
Subject: RFR: 8023306 : (xs) Add replace() implementations to TreeMap
In-Reply-To: <55C85296-289A-4DB1-8BE8-7CF33D97DDB6@oracle.com>
References: 
	<55C85296-289A-4DB1-8BE8-7CF33D97DDB6@oracle.com>
Message-ID: <5213BC6D.4070103@oracle.com>

On 08/20/2013 07:54 PM, Mike Duigou wrote:
> Paul Sandoz pointed out (again) that I let synchronized slip back into the split out patch.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8023306/1/webrev/

Yes, the sycn free versions look better.

-Chris.

>
> Corrects this error.
>
> Mike
>
> On Aug 20 2013, at 11:11 , Mike Duigou wrote:
>
>> Hello all;
>>
>> This is a small changeset I have split out from the mostly unrelated JDK-8021591. This changeset adds Map.replace(key,value) and Map.replace(key,oldValue,newValue) implementations to TreeMap that are more efficient that that provided by the defaults in Map.
>>
>> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8023306/0/webrev/
>>
>> Cheers,
>>
>> Mike
>>
>>
>


From Alan.Bateman at oracle.com  Tue Aug 20 19:24:52 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 20 Aug 2013 20:24:52 +0100
Subject: RFR: 8023306 : (xs) Add replace() implementations to TreeMap
In-Reply-To: <55C85296-289A-4DB1-8BE8-7CF33D97DDB6@oracle.com>
References: 
	<55C85296-289A-4DB1-8BE8-7CF33D97DDB6@oracle.com>
Message-ID: <5213C284.5060204@oracle.com>

On 20/08/2013 19:54, Mike Duigou wrote:
> Paul Sandoz pointed out (again) that I let synchronized slip back into the split out patch.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8023306/1/webrev/
>
> Corrects this error.
>
> Mike
>
Looks okay to me, I guess I would Entry e rather than p but that's just 
a personal preference.

-Alan


From Alan.Bateman at oracle.com  Tue Aug 20 19:33:16 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 20 Aug 2013 20:33:16 +0100
Subject: RFR : 8023395 : (xs) Deprecate sun.misc.Sort and sun.misc.Compare
In-Reply-To: <3CE2D646-4978-42B2-9AC4-BF41D5DC3D6A@oracle.COM>
References: <3CE2D646-4978-42B2-9AC4-BF41D5DC3D6A@oracle.COM>
Message-ID: <5213C47C.3080301@oracle.com>

On 20/08/2013 19:07, Mike Duigou wrote:
> Hello all;
>
> This is a proposal to deprecate (Any votes for outright removal?)
No objection to deprecating it but I assume anyone compiling against it 
is seeing a warning already (because it's a JDK internal class).

We've historically being cautious about removing classes from sun.misc 
(as we know there is code that ignores the warnings). So I would at 
least do a quick check to see if there is anything obvious using it. One 
other thing is that this isn't the only orphan in sun.misc. Some time 
ago I created JDK-6852936 with a list of classes that aren't used. I 
wasn't brave enough at the time to try to remove them.

-Alan


> two classes in the private sun.misc package. These are ancient vestigial classes who's usage has long been eliminated in the JDK in favour of java.util.Arrays.sort(T[], Comparator) and java.util.Arrays.sort(T[], int start, int end, Comparator).
>
>
> http://cr.openjdk.java.net/~mduigou/JDK-8023395/0/webrev/
>



From jonathan.gibbons at oracle.com  Tue Aug 20 19:46:18 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 20 Aug 2013 12:46:18 -0700
Subject: Enum.valueOf(String)
In-Reply-To: 
References: 
	<7AE76BDE-06C8-4438-90F4-765B9726C80F@nicholaswilliams.net>
	
	<013E5DBB-9D96-4D7A-AE1B-29D56D0B5729@nicholaswilliams.net>
	
	<5211D838.5070408@oracle.com>
	
	
	<521373A0.2050101@oracle.com>
	
Message-ID: <5213C78A.4000406@oracle.com>

Eamonn,

See 
http://docs.oracle.com/javase/7/docs/api/java/lang/Enum.html#valueOf(java.lang.Class,%20java.lang.String)

> Note that for a particular enum type T, the implicitly declared public 
> static T valueOf(String) method on that enum may be used instead of 
> this method to map from a name to the corresponding enum constant. All 
> the constants of an enum type can be obtained by calling the implicit 
> public static T[] values() method of that type.

-- Jon

On 08/20/2013 11:00 AM, Eamonn McManus wrote:
> As I mentioned earlier in the thread, it's kind of user-hostile for
> the Enum javadoc to send the user to the JLS instead of just saying,
> even briefly, what the methods are. Even more so since it doesn't
> actually link to the relevant section of the JLS or in fact to the JLS
> at all. This is not a complaint that the information isn't documented,
> just that it is too hard to find. Imagine how much work I have to do
> if I can't remember the name of the method to convert from a string to
> an enum constant in a new enum I'm writing, and it doesn't occur to me
> to pick some other random enum and look at its javadoc.
>
> ?amonn
>
>
> 2013/8/20 Jonathan Gibbons :
>> Paul,
>>
>> Enums are well covered in JLS 7, section 8.9. In particular, see 8.9.2, Enum
>> Body Declarations, beginning at the line
>>
>> "In addition, if E is the name of an enum type, then that type has the
>> following implicitly declared static methods:"
>>
>> -- Jon
>>
>>
>> On 08/20/2013 06:27 AM, Paul Benedict wrote:
>>> Jon, it's not a problem with the method docs, per se. The issue is about
>>> how the generation isn't documented. My questioning started because I was
>>> using several enums without javadoc available, but I did have the source
>>> available, and couldn't figure out how the method came to be. Since I've
>>> asked, everyone knew (but me!) it was a generated method, but I couldn't
>>> divine that knowledge.
>>>
>>> My recommendation is to add an @implNote on Enum.valueOf(Class, String) so
>>> that people know each subclass will get a generated method that behaves
>>> similarly. What do you think?
>>>
>>>
>>> On Mon, Aug 19, 2013 at 9:23 AM, Paul Benedict >> > wrote:
>>>
>>>      I have been working with classes that don't have javadoc
>>>      attachments. The problem was I couldn't find the method in the
>>>      source nor was the method part of the Enum class. So where did it
>>>      materialize from? Now I know the answer: the compiler generates it.
>>>
>>>      I really think this knowledge should be added to the Enum javadoc
>>>      class. I had to go on quite a goose hunt to find this fact.
>>>
>>>      Paul
>>>
>>>
>>>      On Mon, Aug 19, 2013 at 3:32 AM, Alan Bateman
>>>      > wrote:
>>>
>>>          On 18/08/2013 05:07, Paul Benedict wrote:
>>>
>>>              I think the generated method needs to be listed in the
>>>              class javadoc at
>>>              least. I presume it throws an exception too (like the
>>>              other valueOf) if the
>>>              String can't be resolved to a constant, but no user is
>>>              going to discover
>>>              this fact through the documentation.
>>>
>>>          Have you checked the generated avadoc for your enum? The
>>>          valueOf(String) should be there and specified to throw IAE or NPE.
>>>
>>>          -Alan
>>>
>>>
>>>
>>>
>>>
>>>      --     Cheers,
>>>      Paul
>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Paul
>>



From henry.jen at oracle.com  Tue Aug 20 19:48:51 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 20 Aug 2013 12:48:51 -0700
Subject: RFR: 8016846: Pattern.splitAsStream tests required
In-Reply-To: <51EFFD82.50307@oracle.com>
References: <51E5998E.8040409@oracle.com> <51EFFD82.50307@oracle.com>
Message-ID: <5213C823.3020105@oracle.com>

On 07/24/2013 09:14 AM, Alan Bateman wrote:
> On 16/07/2013 12:05, Henry Jen wrote:
>> Hi,
>>
>> Please review the webrev at,
>>
>> http://cr.openjdk.java.net/~henryjen/tl/8016846/0/webrev/
>>
>> The test is mostly contributed by Ben Evans.
>>
>> Cheers,
>> Henry
>>
> It looks okay to me, just a concern that the tests for the regex API are
> normally in test/java/util/regex.
> 

We are using stream test framework on this to verify all style of stream
works, with that we will need to have library on bootclasspath, and that
current prevent us from put it in test/java/util/regex because of jtreg
limitation.

If no object, I'll push this at its current location. We can revisit
this when jtreg support is available.

The other alternative is that we refactor the test to test only split,
and leave out the various style of stream checking. While we lose the
sanity check, but I don't think we lose much as the form of iterator
converted into stream and operated should have been covered in other
stream tests.

Let me know if we think it's important enough to refactor the test.

Cheers,
Henry


From eamonn at mcmanus.net  Tue Aug 20 20:09:00 2013
From: eamonn at mcmanus.net (Eamonn McManus)
Date: Tue, 20 Aug 2013 13:09:00 -0700
Subject: Enum.valueOf(String)
In-Reply-To: <5213C78A.4000406@oracle.com>
References: 
	<7AE76BDE-06C8-4438-90F4-765B9726C80F@nicholaswilliams.net>
	
	<013E5DBB-9D96-4D7A-AE1B-29D56D0B5729@nicholaswilliams.net>
	
	<5211D838.5070408@oracle.com>
	
	
	<521373A0.2050101@oracle.com>
	
	<5213C78A.4000406@oracle.com>
Message-ID: 

It might occur to me to look at valueOf(Class, String) if I was
looking for a method to convert a string to an enum constant, but I
don't think it would occur to me to look there if I was looking for a
method to get all the values of an enum. I'm sure plenty of people end
up using MyEnum.class.getEnumConstants() because that *is* linked to
from the class javadoc. Perhaps a {@link} from the class javadoc to
the valueOf(Class, String) method would be sufficient, like this:

* More information about enums, including descriptions of the
* implicitly declared methods synthesized by the compiler, can be
* found in section 8.9 of
* The Java™ Language Specification. See also
* the description in {@link #valueOf valueOf}.

Additionally, Class.getEnumConstants() could mention the simpler
alternative if the class is known at compile time.

?amonn


2013/8/20 Jonathan Gibbons :
> Eamonn,
>
> See
> http://docs.oracle.com/javase/7/docs/api/java/lang/Enum.html#valueOf(java.lang.Class,%20java.lang.String)
>
>
>> Note that for a particular enum type T, the implicitly declared public
>> static T valueOf(String) method on that enum may be used instead of this
>> method to map from a name to the corresponding enum constant. All the
>> constants of an enum type can be obtained by calling the implicit public
>> static T[] values() method of that type.
>
>
> -- Jon
>
> On 08/20/2013 11:00 AM, Eamonn McManus wrote:
>>
>> As I mentioned earlier in the thread, it's kind of user-hostile for
>> the Enum javadoc to send the user to the JLS instead of just saying,
>> even briefly, what the methods are. Even more so since it doesn't
>> actually link to the relevant section of the JLS or in fact to the JLS
>> at all. This is not a complaint that the information isn't documented,
>> just that it is too hard to find. Imagine how much work I have to do
>> if I can't remember the name of the method to convert from a string to
>> an enum constant in a new enum I'm writing, and it doesn't occur to me
>> to pick some other random enum and look at its javadoc.
>>
>> ?amonn
>>
>>
>> 2013/8/20 Jonathan Gibbons :
>>>
>>> Paul,
>>>
>>> Enums are well covered in JLS 7, section 8.9. In particular, see 8.9.2,
>>> Enum
>>> Body Declarations, beginning at the line
>>>
>>> "In addition, if E is the name of an enum type, then that type has the
>>> following implicitly declared static methods:"
>>>
>>> -- Jon
>>>
>>>
>>> On 08/20/2013 06:27 AM, Paul Benedict wrote:
>>>>
>>>> Jon, it's not a problem with the method docs, per se. The issue is about
>>>> how the generation isn't documented. My questioning started because I
>>>> was
>>>> using several enums without javadoc available, but I did have the source
>>>> available, and couldn't figure out how the method came to be. Since I've
>>>> asked, everyone knew (but me!) it was a generated method, but I couldn't
>>>> divine that knowledge.
>>>>
>>>> My recommendation is to add an @implNote on Enum.valueOf(Class, String)
>>>> so
>>>> that people know each subclass will get a generated method that behaves
>>>> similarly. What do you think?
>>>>
>>>>
>>>> On Mon, Aug 19, 2013 at 9:23 AM, Paul Benedict >>> > wrote:
>>>>
>>>>      I have been working with classes that don't have javadoc
>>>>      attachments. The problem was I couldn't find the method in the
>>>>      source nor was the method part of the Enum class. So where did it
>>>>      materialize from? Now I know the answer: the compiler generates it.
>>>>
>>>>      I really think this knowledge should be added to the Enum javadoc
>>>>      class. I had to go on quite a goose hunt to find this fact.
>>>>
>>>>      Paul
>>>>
>>>>
>>>>      On Mon, Aug 19, 2013 at 3:32 AM, Alan Bateman
>>>>      > wrote:
>>>>
>>>>          On 18/08/2013 05:07, Paul Benedict wrote:
>>>>
>>>>              I think the generated method needs to be listed in the
>>>>              class javadoc at
>>>>              least. I presume it throws an exception too (like the
>>>>              other valueOf) if the
>>>>              String can't be resolved to a constant, but no user is
>>>>              going to discover
>>>>              this fact through the documentation.
>>>>
>>>>          Have you checked the generated avadoc for your enum? The
>>>>          valueOf(String) should be there and specified to throw IAE or
>>>> NPE.
>>>>
>>>>          -Alan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>      --     Cheers,
>>>>      Paul
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Paul
>>>
>>>
>


From joe.darcy at oracle.com  Tue Aug 20 19:16:27 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 20 Aug 2013 19:16:27 +0000
Subject: hg: jdk8/tl/langtools: 8011043: Warn about use of 1.5 and earlier
	source and target values
Message-ID: <20130820191632.B7F59489F6@hg.openjdk.java.net>

Changeset: 58da1296c6b3
Author:    darcy
Date:      2013-08-20 12:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/58da1296c6b3

8011043: Warn about use of 1.5 and earlier source and target values
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javadoc/Start.java
+ test/tools/javac/diags/examples/ObsoleteSourceAndTarget.java



From omajid at redhat.com  Tue Aug 20 20:38:31 2013
From: omajid at redhat.com (Omair Majid)
Date: Tue, 20 Aug 2013 16:38:31 -0400
Subject: Enum.valueOf(String)
In-Reply-To: 
References: 
	<7AE76BDE-06C8-4438-90F4-765B9726C80F@nicholaswilliams.net>
	
	<013E5DBB-9D96-4D7A-AE1B-29D56D0B5729@nicholaswilliams.net>
	
	<5211D838.5070408@oracle.com>
	
	
	<521373A0.2050101@oracle.com>
	
	<5213C78A.4000406@oracle.com>
	
Message-ID: <5213D3C7.4030607@redhat.com>

On 08/20/2013 04:09 PM, Eamonn McManus wrote:
> It might occur to me to look at valueOf(Class, String) if I was
> looking for a method to convert a string to an enum constant, but I
> don't think it would occur to me to look there if I was looking for a
> method to get all the values of an enum. I'm sure plenty of people end
> up using MyEnum.class.getEnumConstants() because that *is* linked to
> from the class javadoc.

As a counter-argument, using an IDE's auto-complete makes it really
really easy to discover the values() method.

In fact, it never even occurred to me that there is an
MyEnum.class.getEnumConstants() method that would do the same.

Cheers,
Omair


From mandy.chung at oracle.com  Tue Aug 20 20:38:28 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 20 Aug 2013 13:38:28 -0700
Subject: RFR : 8023395 : (xs) Deprecate sun.misc.Sort and sun.misc.Compare
In-Reply-To: <5213C47C.3080301@oracle.com>
References: <3CE2D646-4978-42B2-9AC4-BF41D5DC3D6A@oracle.COM>
	<5213C47C.3080301@oracle.com>
Message-ID: <5213D3C4.40801@oracle.com>

FWIW.  From the maven artifacts I looked at last year (essentially ran 
jdeps), there is only one reference to these 2 sun.misc classes:

http://grepcode.com/file/repo1.maven.org/maven2/net.sf.ingenias/iaf/1.3/ingenias/jade/EventPanelLogger.java

Mandy

On 8/20/2013 12:33 PM, Alan Bateman wrote:
> On 20/08/2013 19:07, Mike Duigou wrote:
>> Hello all;
>>
>> This is a proposal to deprecate (Any votes for outright removal?)
> No objection to deprecating it but I assume anyone compiling against 
> it is seeing a warning already (because it's a JDK internal class).
>
> We've historically being cautious about removing classes from sun.misc 
> (as we know there is code that ignores the warnings). So I would at 
> least do a quick check to see if there is anything obvious using it. 
> One other thing is that this isn't the only orphan in sun.misc. Some 
> time ago I created JDK-6852936 with a list of classes that aren't 
> used. I wasn't brave enough at the time to try to remove them.
>
> -Alan
>
>
>> two classes in the private sun.misc package. These are ancient 
>> vestigial classes who's usage has long been eliminated in the JDK in 
>> favour of java.util.Arrays.sort(T[], Comparator) and 
>> java.util.Arrays.sort(T[], int start, int end, Comparator).
>>
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-8023395/0/webrev/
>>
>



From ivan.gerasimov at oracle.com  Tue Aug 20 20:40:48 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 21 Aug 2013 00:40:48 +0400
Subject: RFR [7129312] BufferedInputStream calculates negative array size
	with large streams and mark
In-Reply-To: <521392E0.20604@oracle.com>
References: <520E2541.9020505@oracle.com> <520E541E.1060403@oracle.com>
	<5211F591.6010504@oracle.com> <521392E0.20604@oracle.com>
Message-ID: <5213D450.9050404@oracle.com>


> Just check with JPRT, the test passes on both 64 and 32 bit platforms.

Was meant: I've just checked with JPRT, and the test passes on both 64 
and 32 bit platforms.

Sincerely yours,
Ivan



From henry.jen at oracle.com  Tue Aug 20 21:32:43 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 20 Aug 2013 14:32:43 -0700
Subject: RFR: 8016846: Pattern.splitAsStream tests required
In-Reply-To: <5213CA48.6060406@oracle.com>
References: <51E5998E.8040409@oracle.com> <51EFFD82.50307@oracle.com>
	<5213C823.3020105@oracle.com> <5213CA48.6060406@oracle.com>
Message-ID: <5213E07B.1060506@oracle.com>

On 08/20/2013 12:58 PM, Jonathan Gibbons wrote:
> Henry,
> 
> I think you should sort out the issues you are having with jtreg.
> It is not yet clear to me that this is a jtreg issue as much as a test 
> or library issue.
> 

Thanks Jon for the help on jtreg issue, the test can be easily fixed by
adding an extra @build tag.

The new webrev is at
http://cr.openjdk.java.net/~henryjen/tl/8016846/1/webrev

Cheers,
Henry

> -- Jon
> 
> On 08/20/2013 12:48 PM, Henry Jen wrote:
>> On 07/24/2013 09:14 AM, Alan Bateman wrote:
>>> On 16/07/2013 12:05, Henry Jen wrote:
>>>> Hi,
>>>>
>>>> Please review the webrev at,
>>>>
>>>> http://cr.openjdk.java.net/~henryjen/tl/8016846/0/webrev/
>>>>
>>>> The test is mostly contributed by Ben Evans.
>>>>
>>>> Cheers,
>>>> Henry
>>>>
>>> It looks okay to me, just a concern that the tests for the regex API are
>>> normally in test/java/util/regex.
>>>
>> We are using stream test framework on this to verify all style of stream
>> works, with that we will need to have library on bootclasspath, and that
>> current prevent us from put it in test/java/util/regex because of jtreg
>> limitation.
>>
>> If no object, I'll push this at its current location. We can revisit
>> this when jtreg support is available.
>>
>> The other alternative is that we refactor the test to test only split,
>> and leave out the various style of stream checking. While we lose the
>> sanity check, but I don't think we lose much as the form of iterator
>> converted into stream and operated should have been covered in other
>> stream tests.
>>
>> Let me know if we think it's important enough to refactor the test.
>>
>> Cheers,
>> Henry
>>
> 
> 



From jonathan.gibbons at oracle.com  Tue Aug 20 21:48:34 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 20 Aug 2013 21:48:34 +0000
Subject: hg: jdk8/tl/langtools: 8020663: Restructure some properties to
	facilitate better translation
Message-ID: <20130820214837.9671E48A07@hg.openjdk.java.net>

Changeset: a76dc1b4c299
Author:    jjg
Date:      2013-08-20 14:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a76dc1b4c299

8020663: Restructure some properties to facilitate better translation
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java



From kumar.x.srinivasan at oracle.com  Tue Aug 20 21:18:34 2013
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Tue, 20 Aug 2013 21:18:34 +0000
Subject: hg: jdk8/tl/langtools: 7179455:
	tools/javac/processing/model/testgetallmembers/Main.java fails
	against JDK 7 and JDK 8
Message-ID: <20130820211839.BB48A48A01@hg.openjdk.java.net>

Changeset: 0f88e3d3d250
Author:    ksrini
Date:      2013-08-20 14:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0f88e3d3d250

7179455: tools/javac/processing/model/testgetallmembers/Main.java fails against JDK 7 and JDK 8
Reviewed-by: jjg

! test/tools/javac/processing/model/testgetallmembers/Main.java



From mike.duigou at oracle.com  Tue Aug 20 21:50:15 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 20 Aug 2013 14:50:15 -0700
Subject: 8020292: j.u.SplittableRandom
In-Reply-To: 
References: <9F153157-0FC5-4385-B1BC-4FE2D43006F4@oracle.com>
	
	
Message-ID: 


On Aug 20 2013, at 04:57 , Paul Sandoz wrote:

> [resending unsigned, sorry if a dup arrives later on]
> 
> On Aug 19, 2013, at 9:04 PM, Mike Duigou  wrote:
> 
>> Looks pretty good. Two points concern me:
>> 
>> - Every source of non-crypto quality randoms should explicitly document that it should not be used for generating keys or other crypto purposes. There is mention that the seeding is insecure in the implementation docs but more explicit mention in the public docs is needed. (And some fool somewhere will *still* use it for crypto...)
>> 
> 
> Good point.
> 
> 
>> - Additional seed material might be desirable for "seeder". I worry about how many of the actual bits are random. If no local host address is available the seed might be fairly predictable. In the murmur3 implementation I included also System.identityHashCode(String.class), System.identityHashCode(System.class), System.identityHashCode(Thread.currentThread()), Thread.currentThread().getId() and Runtime.getRuntime().freeMemory(). Mixing multiply with XOR operations also helps to spread the random bits out. Perhaps just call mix64 on each component and XOR against previous?
>> 
> 
> Are you concerned that the values passed to mix64 may be of low entropy? i.e. that small differences in input (such as counting numbers) do not result in large enough differences in the output. I suppose it might be possible to switch from MurmurHash3 to using Stafford's "Mix13" constants or a combination to avoid any potential correlations. However, given that there is further mixing going on for the values and gamma generation perhaps it is not so important?

It was more that "seeder" is initialized with a potentially predictable value. currentTimeMillis probably has only a couple of bits of entropy (and on a webserver it is probably observable), maybe a dozen bits for nanoTime. Those random bits are likely in the same range of bits (around bits 5-15). If getLocalHostAddress() returns a loopback address then we've seeded the shared state with only a few bits of randomness. (Also, since the local host address is directly visible it could be reversed out by an attacker). The suggestion of using mix64 was mostly to take best advantage of the entropy available. 

Plus, more bits would be better. Imagine an attack where the attacker looked for newly launched instances of a clustered webserver. It would not be too hard to reduce the search space for the initial value of it's SplittableRandom seeder to less than 2^16 possibilities. Whether this is useful would depend upon the application being run on that webserver but it seems insufficient to me though.

Mike

From jonathan.gibbons at oracle.com  Tue Aug 20 21:55:32 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 20 Aug 2013 21:55:32 +0000
Subject: hg: jdk8/tl/langtools: 8022080: javadoc generates invalid HTML in
	Turkish locale
Message-ID: <20130820215535.36BC748A08@hg.openjdk.java.net>

Changeset: 79e341614c50
Author:    jjg
Date:      2013-08-20 14:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/79e341614c50

8022080: javadoc generates invalid HTML in Turkish locale
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java
! src/share/classes/com/sun/tools/doclint/HtmlTag.java



From jonathan.gibbons at oracle.com  Tue Aug 20 22:13:02 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 20 Aug 2013 22:13:02 +0000
Subject: hg: jdk8/tl/langtools: 8013887: In class use,
	some tables are randomly unsorted
Message-ID: <20130820221305.33B1448A09@hg.openjdk.java.net>

Changeset: 720992953d43
Author:    jjg
Date:      2013-08-20 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/720992953d43

8013887: In class use, some tables are randomly unsorted
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java



From dan.xu at oracle.com  Wed Aug 21 00:04:38 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Tue, 20 Aug 2013 17:04:38 -0700
Subject: RFR: JDK-8023430 - Replace File.mkdirs with Files.createDirectories
	to get MaxPathLength.java failure details
Message-ID: <52140416.1060309@oracle.com>

Hi,

MaxPathLength.java testcase failed intermittently. And File.mkdirs() 
does not throw any exceptions when it fails, which makes it even harder 
for the diagnosis. As Alan suggested, I'd like to change it to 
Files.createDirectories to get detailed exceptions once a failure 
happens. Thanks!

webrev: http://cr.openjdk.java.net/~dxu/8023430/webrev/
bug: http://bugs.sun.com/view_bug.do?bug_id=8023430

-Dan


From mike.duigou at oracle.com  Wed Aug 21 00:04:47 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 20 Aug 2013 17:04:47 -0700
Subject: 8023351: Add TEST.groups in preparation to simplify rules in
	jdk/test/Makefile
In-Reply-To: <52135D72.2020205@oracle.com>
References: <52135D72.2020205@oracle.com>
Message-ID: 


On Aug 20 2013, at 05:13 , Alan Bateman wrote:

> 
> For some time now we have been chipping away at the make files that are used to run the jdk tests. Mike has his wielded his axe on several occasions recently to remove logic and rules that are no longer needed.

I've started to sharpen my axe preparing the follow-on changes to Makefiles

>  In addition to groups for the normal test target then I also propose to add higher level groups that partition the entire test suite into three groups named "core", "svc" and "desktop". This makes it really easy to run selections of the test suite, for example "jtreg  :core :svc" will run all the core area and serviceability tests.

The root repo test targets currently trigger off the repo name in order to know which /test/Makefile to run. ie. jdk_util triggers running the jdk/test/Makefile. Would it be possible to retain the repo prefix for the meta group names? ie. jdk_core jdk_svc and jdk_desktop?

The other possibility is to move the TEST.ROOT and TEST.groups files for all tests to the root repo. This would have the advantage that we could define groups like "smoketest" that would span repos.

Mike

From mike.duigou at oracle.com  Wed Aug 21 00:51:30 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 21 Aug 2013 00:51:30 +0000
Subject: hg: jdk8/tl: 8023433: Improve 'make help'
Message-ID: <20130821005130.7CC5C48A18@hg.openjdk.java.net>

Changeset: c8da1b6a9762
Author:    mduigou
Date:      2013-08-20 17:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/c8da1b6a9762

8023433: Improve 'make help'
Reviewed-by: tbell

! NewMakefile.gmk



From martinrb at google.com  Wed Aug 21 02:28:35 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 20 Aug 2013 19:28:35 -0700
Subject: RFR (M) CR 8023234: StampedLock serializes readers on writer
	unlock
In-Reply-To: <52138373.8090903@oracle.com>
References: <521230D1.9070803@oracle.com>
	
	<52138373.8090903@oracle.com>
Message-ID: 

If a Reader throws, the test might still pass, since only throwing from the
main thread matters.  See infrastructure in JSR166TestCase, e.g.
threadUnexpectedException.

OTOH, there seems no value in converting exceptions in the main thread to
ISE.  Just declare main to throw Exception or whatever.


On Tue, Aug 20, 2013 at 7:55 AM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

>
> > I think it's more readable to use CountDownLatch instead of
> > CyclicBarrier for writerHasLock, because of asymmetric API.
> > Doers call countDown(), waiters call await().
>
> Nope, we need: a) *reusable* primitive, CDL is one-shot, unfortunately;
> b) we need symmetric block, writer should also block on barrier until
> both readers arrive; this makes test much more reliable.
>

You're right that here you need something reusable.  I try to avoid
reusable synchronization constructs, but don't have any obvious suggestion
for how to do that here.


From Alan.Bateman at oracle.com  Wed Aug 21 06:16:20 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 21 Aug 2013 07:16:20 +0100
Subject: 8023351: Add TEST.groups in preparation to simplify rules in
	jdk/test/Makefile
In-Reply-To: 
References: <52135D72.2020205@oracle.com>
	
Message-ID: <52145B34.80509@oracle.com>

On 21/08/2013 01:04, Mike Duigou wrote:
> :
> The root repo test targets currently trigger off the repo name in order to know which/test/Makefile to run. ie. jdk_util triggers running the jdk/test/Makefile. Would it be possible to retain the repo prefix for the meta group names? ie. jdk_core jdk_svc and jdk_desktop?
>
> The other possibility is to move the TEST.ROOT and TEST.groups files for all tests to the root repo. This would have the advantage that we could define groups like "smoketest" that would span repos.
>
It makes sense to use jdk_ for the meta groups so I'll rename those 3 
before pushing this.

I see your where you are going on a top-level root but I think that has 
several implications that would need to be considered. It's almost like 
you need to link the test directories in each of the repositories.

-Alan


From Alan.Bateman at oracle.com  Wed Aug 21 06:18:28 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 21 Aug 2013 07:18:28 +0100
Subject: RFR: JDK-8023430 - Replace File.mkdirs with
	Files.createDirectories to get MaxPathLength.java failure details
In-Reply-To: <52140416.1060309@oracle.com>
References: <52140416.1060309@oracle.com>
Message-ID: <52145BB4.3080202@oracle.com>

On 21/08/2013 01:04, Dan Xu wrote:
> Hi,
>
> MaxPathLength.java testcase failed intermittently. And File.mkdirs() 
> does not throw any exceptions when it fails, which makes it even 
> harder for the diagnosis. As Alan suggested, I'd like to change it to 
> Files.createDirectories to get detailed exceptions once a failure 
> happens. Thanks!
>
> webrev: http://cr.openjdk.java.net/~dxu/8023430/webrev/
> bug: http://bugs.sun.com/view_bug.do?bug_id=8023430
I think this is the right thing to do to find out what is going on. With 
the patch then you can remove couldMakeTestDirectory as the exists check 
and throwing the exception is no longer needed.

-Alan.


From rieberandreas at gmail.com  Wed Aug 21 06:44:28 2013
From: rieberandreas at gmail.com (Andreas Rieber)
Date: Wed, 21 Aug 2013 08:44:28 +0200
Subject: Simple RFR: 8203311 Clean up profile-includes.txt
In-Reply-To: <5212AB5C.6080804@oracle.com>
References: <5212AB5C.6080804@oracle.com>
Message-ID: <521461CC.2050402@gmail.com>

Hi David,

your change causes build problems with ubuntu 12.04. Result is:

make[2]: Entering directory `/usr/local/src/jdk8tl/jdk/makefiles'
make[2]: *** No rule to make target 
`/usr/local/src/jdk8tl/build/linux-x86-normal-server-release/images/lib/jfr.jar', 
needed by `all'.  Stop.
make[2]: Leaving directory `/usr/local/src/jdk8tl/jdk/makefiles'
make[1]: *** [images] Error 2
make[1]: Leaving directory `/usr/local/src/jdk8tl/jdk/makefiles'
make: *** [images-only] Error 2

I tried several make clean, configure and so on but only when i rollback 
your change i can compile.

Andreas


On 20.08.13 01:33, David Holmes wrote:
> http://cr.openjdk.java.net/~dholmes/8023311/webrev/
>
> Patch inlined below
>
> This is a trivial cleanup following on from an earlier change under
> 8017570. JFR was moved from profile compact3 to the full JRE but not all
> the variables in profile-includes.txt were updated as needed. jfr.jar
> needed to removed from the profile3 jar list and added to the jre jar list.
>
> This has no impact on the actual build artifacts - JFR was, and remains,
> in the full JRE only.
>
> Thanks,
> David
>
> --- old/makefiles/profile-includes.txt    2013-08-19 19:10:17.554355677
> -0400
> +++ new/makefiles/profile-includes.txt    2013-08-19 19:10:14.586187808
> -0400
> @@ -102,6 +102,7 @@
>       security/US_export_policy.jar \
>       security/local_policy.jar
>
> +
>   PROFILE_2_JRE_BIN_FILES := \
>       rmid$(EXE_SUFFIX) \
>       rmiregistry$(EXE_SUFFIX)
> @@ -140,7 +141,6 @@
>   PROFILE_3_JRE_OTHER_FILES :=
>
>   PROFILE_3_JRE_JAR_FILES := \
> -    jfr.jar \
>       management-agent.jar
>
>
> @@ -253,6 +253,6 @@
>       ext/cldrdata.jar \
>       ext/dnsns.jar \
>       ext/nashorn.jar \
> -    ext/zipfs.jar
> -
> +    ext/zipfs.jar \
> +    jfr.jar
>



From david.holmes at oracle.com  Wed Aug 21 07:53:02 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Aug 2013 17:53:02 +1000
Subject: Simple RFR: 8203311 Clean up profile-includes.txt
In-Reply-To: <521461CC.2050402@gmail.com>
References: <5212AB5C.6080804@oracle.com> <521461CC.2050402@gmail.com>
Message-ID: <521471DE.3050905@oracle.com>

Hi Andreas,

On 21/08/2013 4:44 PM, Andreas Rieber wrote:
> Hi David,
>
> your change causes build problems with ubuntu 12.04. Result is:
>
> make[2]: Entering directory `/usr/local/src/jdk8tl/jdk/makefiles'
> make[2]: *** No rule to make target
> `/usr/local/src/jdk8tl/build/linux-x86-normal-server-release/images/lib/jfr.jar',
> needed by `all'.  Stop.
> make[2]: Leaving directory `/usr/local/src/jdk8tl/jdk/makefiles'
> make[1]: *** [images] Error 2
> make[1]: Leaving directory `/usr/local/src/jdk8tl/jdk/makefiles'
> make: *** [images-only] Error 2
>
> I tried several make clean, configure and so on but only when i rollback
> your change i can compile.

I presume this is an OpenJDK build?

That is quite puzzling .... I will investigate.

Thanks,
David

> Andreas
>
>
> On 20.08.13 01:33, David Holmes wrote:
>> http://cr.openjdk.java.net/~dholmes/8023311/webrev/
>>
>> Patch inlined below
>>
>> This is a trivial cleanup following on from an earlier change under
>> 8017570. JFR was moved from profile compact3 to the full JRE but not all
>> the variables in profile-includes.txt were updated as needed. jfr.jar
>> needed to removed from the profile3 jar list and added to the jre jar
>> list.
>>
>> This has no impact on the actual build artifacts - JFR was, and remains,
>> in the full JRE only.
>>
>> Thanks,
>> David
>>
>> --- old/makefiles/profile-includes.txt    2013-08-19 19:10:17.554355677
>> -0400
>> +++ new/makefiles/profile-includes.txt    2013-08-19 19:10:14.586187808
>> -0400
>> @@ -102,6 +102,7 @@
>>       security/US_export_policy.jar \
>>       security/local_policy.jar
>>
>> +
>>   PROFILE_2_JRE_BIN_FILES := \
>>       rmid$(EXE_SUFFIX) \
>>       rmiregistry$(EXE_SUFFIX)
>> @@ -140,7 +141,6 @@
>>   PROFILE_3_JRE_OTHER_FILES :=
>>
>>   PROFILE_3_JRE_JAR_FILES := \
>> -    jfr.jar \
>>       management-agent.jar
>>
>>
>> @@ -253,6 +253,6 @@
>>       ext/cldrdata.jar \
>>       ext/dnsns.jar \
>>       ext/nashorn.jar \
>> -    ext/zipfs.jar
>> -
>> +    ext/zipfs.jar \
>> +    jfr.jar
>>
>


From rieberandreas at gmail.com  Wed Aug 21 08:31:50 2013
From: rieberandreas at gmail.com (Andreas Rieber)
Date: Wed, 21 Aug 2013 10:31:50 +0200
Subject: Simple RFR: 8203311 Clean up profile-includes.txt
In-Reply-To: <521471DE.3050905@oracle.com>
References: <5212AB5C.6080804@oracle.com> <521461CC.2050402@gmail.com>
	<521471DE.3050905@oracle.com>
Message-ID: <52147AF6.9050401@gmail.com>

Hi David,

On 21.08.13 09:53, David Holmes wrote:
> Hi Andreas,
>
> On 21/08/2013 4:44 PM, Andreas Rieber wrote:
>> Hi David,
>>
>> your change causes build problems with ubuntu 12.04. Result is:
>>
>> make[2]: Entering directory `/usr/local/src/jdk8tl/jdk/makefiles'
>> make[2]: *** No rule to make target
>> `/usr/local/src/jdk8tl/build/linux-x86-normal-server-release/images/lib/jfr.jar',
>>
>> needed by `all'.  Stop.
>> make[2]: Leaving directory `/usr/local/src/jdk8tl/jdk/makefiles'
>> make[1]: *** [images] Error 2
>> make[1]: Leaving directory `/usr/local/src/jdk8tl/jdk/makefiles'
>> make: *** [images-only] Error 2
>>
>> I tried several make clean, configure and so on but only when i rollback
>> your change i can compile.
>
> I presume this is an OpenJDK build?

Yes, openJDK build. Just tried clean fresh build on ubuntu 13.04 with 
jdk8tl, same result:

## Starting images
Creating images/lib/charsets.jar
make[2]: *** No rule to make target 
`/usr/local/src/jdk8tl/build/linux-x86_64-normal-server-release/images/lib/jfr.jar', 
needed by `all'.  Stop.
make[2]: *** Waiting for unfinished jobs....
Creating images/lib/ext/dnsns.jar
Creating images/lib/ext/cldrdata.jar
make[1]: *** [images] Error 2
make: *** [images-only] Error 2

>
> That is quite puzzling .... I will investigate.

thanks for puzzling
Andreas

>
> Thanks,
> David
>
>> Andreas
>>
>>
>> On 20.08.13 01:33, David Holmes wrote:
>>> http://cr.openjdk.java.net/~dholmes/8023311/webrev/
>>>
>>> Patch inlined below
>>>
>>> This is a trivial cleanup following on from an earlier change under
>>> 8017570. JFR was moved from profile compact3 to the full JRE but not all
>>> the variables in profile-includes.txt were updated as needed. jfr.jar
>>> needed to removed from the profile3 jar list and added to the jre jar
>>> list.
>>>
>>> This has no impact on the actual build artifacts - JFR was, and remains,
>>> in the full JRE only.
>>>
>>> Thanks,
>>> David
>>>
>>> --- old/makefiles/profile-includes.txt    2013-08-19 19:10:17.554355677
>>> -0400
>>> +++ new/makefiles/profile-includes.txt    2013-08-19 19:10:14.586187808
>>> -0400
>>> @@ -102,6 +102,7 @@
>>>       security/US_export_policy.jar \
>>>       security/local_policy.jar
>>>
>>> +
>>>   PROFILE_2_JRE_BIN_FILES := \
>>>       rmid$(EXE_SUFFIX) \
>>>       rmiregistry$(EXE_SUFFIX)
>>> @@ -140,7 +141,6 @@
>>>   PROFILE_3_JRE_OTHER_FILES :=
>>>
>>>   PROFILE_3_JRE_JAR_FILES := \
>>> -    jfr.jar \
>>>       management-agent.jar
>>>
>>>
>>> @@ -253,6 +253,6 @@
>>>       ext/cldrdata.jar \
>>>       ext/dnsns.jar \
>>>       ext/nashorn.jar \
>>> -    ext/zipfs.jar
>>> -
>>> +    ext/zipfs.jar \
>>> +    jfr.jar
>>>
>>



From david.holmes at oracle.com  Wed Aug 21 08:55:57 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Aug 2013 18:55:57 +1000
Subject: Simple RFR: 8203311 Clean up profile-includes.txt
In-Reply-To: <52147AF6.9050401@gmail.com>
References: <5212AB5C.6080804@oracle.com> <521461CC.2050402@gmail.com>
	<521471DE.3050905@oracle.com> <52147AF6.9050401@gmail.com>
Message-ID: <5214809D.6040300@oracle.com>

Fix on the way. This exposed another piece that was missing from the 
original change. But mea culpa for not doing an OPENJDK build. Sorry 
about that.

Thanks,
David

On 21/08/2013 6:31 PM, Andreas Rieber wrote:
> Hi David,
>
> On 21.08.13 09:53, David Holmes wrote:
>> Hi Andreas,
>>
>> On 21/08/2013 4:44 PM, Andreas Rieber wrote:
>>> Hi David,
>>>
>>> your change causes build problems with ubuntu 12.04. Result is:
>>>
>>> make[2]: Entering directory `/usr/local/src/jdk8tl/jdk/makefiles'
>>> make[2]: *** No rule to make target
>>> `/usr/local/src/jdk8tl/build/linux-x86-normal-server-release/images/lib/jfr.jar',
>>>
>>>
>>> needed by `all'.  Stop.
>>> make[2]: Leaving directory `/usr/local/src/jdk8tl/jdk/makefiles'
>>> make[1]: *** [images] Error 2
>>> make[1]: Leaving directory `/usr/local/src/jdk8tl/jdk/makefiles'
>>> make: *** [images-only] Error 2
>>>
>>> I tried several make clean, configure and so on but only when i rollback
>>> your change i can compile.
>>
>> I presume this is an OpenJDK build?
>
> Yes, openJDK build. Just tried clean fresh build on ubuntu 13.04 with
> jdk8tl, same result:
>
> ## Starting images
> Creating images/lib/charsets.jar
> make[2]: *** No rule to make target
> `/usr/local/src/jdk8tl/build/linux-x86_64-normal-server-release/images/lib/jfr.jar',
> needed by `all'.  Stop.
> make[2]: *** Waiting for unfinished jobs....
> Creating images/lib/ext/dnsns.jar
> Creating images/lib/ext/cldrdata.jar
> make[1]: *** [images] Error 2
> make: *** [images-only] Error 2
>
>>
>> That is quite puzzling .... I will investigate.
>
> thanks for puzzling
> Andreas
>
>>
>> Thanks,
>> David
>>
>>> Andreas
>>>
>>>
>>> On 20.08.13 01:33, David Holmes wrote:
>>>> http://cr.openjdk.java.net/~dholmes/8023311/webrev/
>>>>
>>>> Patch inlined below
>>>>
>>>> This is a trivial cleanup following on from an earlier change under
>>>> 8017570. JFR was moved from profile compact3 to the full JRE but not
>>>> all
>>>> the variables in profile-includes.txt were updated as needed. jfr.jar
>>>> needed to removed from the profile3 jar list and added to the jre jar
>>>> list.
>>>>
>>>> This has no impact on the actual build artifacts - JFR was, and
>>>> remains,
>>>> in the full JRE only.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> --- old/makefiles/profile-includes.txt    2013-08-19 19:10:17.554355677
>>>> -0400
>>>> +++ new/makefiles/profile-includes.txt    2013-08-19 19:10:14.586187808
>>>> -0400
>>>> @@ -102,6 +102,7 @@
>>>>       security/US_export_policy.jar \
>>>>       security/local_policy.jar
>>>>
>>>> +
>>>>   PROFILE_2_JRE_BIN_FILES := \
>>>>       rmid$(EXE_SUFFIX) \
>>>>       rmiregistry$(EXE_SUFFIX)
>>>> @@ -140,7 +141,6 @@
>>>>   PROFILE_3_JRE_OTHER_FILES :=
>>>>
>>>>   PROFILE_3_JRE_JAR_FILES := \
>>>> -    jfr.jar \
>>>>       management-agent.jar
>>>>
>>>>
>>>> @@ -253,6 +253,6 @@
>>>>       ext/cldrdata.jar \
>>>>       ext/dnsns.jar \
>>>>       ext/nashorn.jar \
>>>> -    ext/zipfs.jar
>>>> -
>>>> +    ext/zipfs.jar \
>>>> +    jfr.jar
>>>>
>>>
>


From alan.bateman at oracle.com  Wed Aug 21 09:02:07 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 21 Aug 2013 09:02:07 +0000
Subject: hg: jdk8/tl/jdk: 8023351: Add TEST.groups in preparation to simplify
	rules in jdk/test/Makefile
Message-ID: <20130821090221.72AF148A34@hg.openjdk.java.net>

Changeset: eb18a483e772
Author:    alanb
Date:      2013-08-21 09:59 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb18a483e772

8023351: Add TEST.groups in preparation to simplify rules in jdk/test/Makefile
Reviewed-by: lancea, mduigou

! test/TEST.ROOT
+ test/TEST.groups



From david.holmes at oracle.com  Wed Aug 21 09:13:27 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Aug 2013 19:13:27 +1000
Subject: RFR: 8023460 OPENJDK build fails due to missing jfr.jar
Message-ID: <521484B7.9000205@oracle.com>

The fix for 8023311 has exposed a second omission in the original fix 
for 817570. In Profiles.gmk we filter out jfr.jar when JFR is not 
enabled but that is currently applied to the profile3 jar list and needs 
to be moved to the full JRE jar list.

webrev:

http://cr.openjdk.java.net/~dholmes/8023460/webrev/

Thanks - and apologies again for the build problem for OpenJDK.

David


From Alan.Bateman at oracle.com  Wed Aug 21 09:22:27 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 21 Aug 2013 10:22:27 +0100
Subject: RFR: 8023460 OPENJDK build fails due to missing jfr.jar
In-Reply-To: <521484B7.9000205@oracle.com>
References: <521484B7.9000205@oracle.com>
Message-ID: <521486D3.8000000@oracle.com>

On 21/08/2013 10:13, David Holmes wrote:
> :
>
> webrev:
>
> http://cr.openjdk.java.net/~dholmes/8023460/webrev/
>
> Thanks - and apologies again for the build problem for OpenJDK.
It's good to get to bottom of the original issue. In general the 
profiles build is somewhat complicated and easy for issues to creep in, 
especially when alternative ways to build it. The change looks okay to me.

-Alan


From Alan.Bateman at oracle.com  Wed Aug 21 09:28:48 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 21 Aug 2013 10:28:48 +0100
Subject: RFR [7129312] BufferedInputStream calculates negative array size
	with large streams and mark
In-Reply-To: <521392E0.20604@oracle.com>
References: <520E2541.9020505@oracle.com> <520E541E.1060403@oracle.com>
	<5211F591.6010504@oracle.com> <521392E0.20604@oracle.com>
Message-ID: <52148850.6090401@oracle.com>

On 20/08/2013 17:01, Ivan Gerasimov wrote:
> Yes, you're right!
>
> I've updated the test to be a shell script + Java application.
> If java reported 'Invalid maximum heap size', the test is skipped.
>
> Just check with JPRT, the test passes on both 64 and 32 bit platforms.
>
> Would you please review the updated webrev?
> http://cr.openjdk.java.net/~igerasim/7129312/2/webrev/ 
> 
The updated change to BufferedInputStream looks good.

On the test then I agree with the approach to skip on 32-bit but I think 
we should avoid introduce more shell tests. Have you looked at 
jdk.testlibrary.ProcessTools to launch the test after checking that we 
are 64-bit?

-Alan.



From paul.sandoz at oracle.com  Wed Aug 21 09:43:37 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 21 Aug 2013 11:43:37 +0200
Subject: 8020292: j.u.SplittableRandom
In-Reply-To: 
References: <9F153157-0FC5-4385-B1BC-4FE2D43006F4@oracle.com>
	
	
	
Message-ID: 

On Aug 20, 2013, at 11:50 PM, Mike Duigou  wrote:
>>> - Additional seed material might be desirable for "seeder". I worry about how many of the actual bits are random. If no local host address is available the seed might be fairly predictable. In the murmur3 implementation I included also System.identityHashCode(String.class), System.identityHashCode(System.class), System.identityHashCode(Thread.currentThread()), Thread.currentThread().getId() and Runtime.getRuntime().freeMemory(). Mixing multiply with XOR operations also helps to spread the random bits out. Perhaps just call mix64 on each component and XOR against previous?
>>> 
>> 
>> Are you concerned that the values passed to mix64 may be of low entropy? i.e. that small differences in input (such as counting numbers) do not result in large enough differences in the output. I suppose it might be possible to switch from MurmurHash3 to using Stafford's "Mix13" constants or a combination to avoid any potential correlations. However, given that there is further mixing going on for the values and gamma generation perhaps it is not so important?
> 
> It was more that "seeder" is initialized with a potentially predictable value. currentTimeMillis probably has only a couple of bits of entropy (and on a webserver it is probably observable), maybe a dozen bits for nanoTime. Those random bits are likely in the same range of bits (around bits 5-15). If getLocalHostAddress() returns a loopback address then we've seeded the shared state with only a few bits of randomness. (Also, since the local host address is directly visible it could be reversed out by an attacker). The suggestion of using mix64 was mostly to take best advantage of the entropy available. 
> 
> Plus, more bits would be better. Imagine an attack where the attacker looked for newly launched instances of a clustered webserver. It would not be too hard to reduce the search space for the initial value of it's SplittableRandom seeder to less than 2^16 possibilities. Whether this is useful would depend upon the application being run on that webserver but it seems insufficient to me though.
> 

OK. So it's predictability of the initial seed that is a concern, not the fact that different instances (created within a small period of time) don't produce seeds that are sufficiently different.

IMHO using a non-secure PRNG in combination with data (e.g. as a seed for hashing keys in maps) exposed to non-trusted parties is probably the wrong thing to be doing.

Does using System.identityHashCode on common classes really help, given that those classes are likely to be initialized in a known order? 

Perhaps it is really System.identityHashCode(Thread.currentThread()), Thread.currentThread().getId() and Runtime.getRuntime().freeMemory() that are more likely to offer some variance that is harder to predict, and even those are likely to be predictable for multiple runs of the same program.

How about this:

    /**
     * The seed generator for default constructors.
     */
    private static final AtomicLong seeder = getSeeder();

    private static AtomicLong getSeeder() {
        long seed = mix64((((long) hashedHostAddress()) << 32) ^
                          System.currentTimeMillis()) ^
                    mix64(System.nanoTime()) ^
                    mix64(Runtime.getRuntime().freeMemory()) ^
                    mix64(Thread.currentThread().getId()) ^
                    mix64((((long) System.identityHashCode(SplittableRandom.class)) << 32) |
                          System.identityHashCode(Thread.currentThread()));
        return new AtomicLong(seed);
    }

Although i must admit it feels a little over the top.

I did ponder whether it is worthwhile defining a boolean system property that if declared and true then SecureRandom is used.

Paul.

From staffan.larsen at oracle.com  Wed Aug 21 09:43:40 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Wed, 21 Aug 2013 09:43:40 +0000
Subject: hg: jdk8/tl/jdk: 4 new changesets
Message-ID: <20130821094503.9A16C48A37@hg.openjdk.java.net>

Changeset: 68be998c2596
Author:    egahlin
Date:      2013-08-19 12:57 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68be998c2596

6358357: Division by zero in Threads tab when shrinking jconsole window
Reviewed-by: mchung, leifs, jbachorik

! src/share/classes/sun/tools/jconsole/Plotter.java

Changeset: bddf55211ed8
Author:    egahlin
Date:      2013-08-19 16:21 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bddf55211ed8

6417721: Thread list should not allow multiple selection
Reviewed-by: alanb, jbachorik, sjiang

! src/share/classes/sun/tools/jconsole/ThreadTab.java

Changeset: 2636d337a1ed
Author:    egahlin
Date:      2013-08-19 16:41 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2636d337a1ed

6800801: NPE in JConsole when using Nimbus L&F
Reviewed-by: alanb, sjiang

! src/share/classes/sun/tools/jconsole/ConnectDialog.java
! src/share/classes/sun/tools/jconsole/VMPanel.java

Changeset: ba943fc47fc8
Author:    egahlin
Date:      2013-08-19 13:11 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ba943fc47fc8

7042707: Un-needed mnemonic in JConsole resource file
Reviewed-by: mfang, jbachorik

! src/share/classes/sun/tools/jconsole/Messages.java
! src/share/classes/sun/tools/jconsole/resources/messages.properties
! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties
! src/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties



From david.holmes at oracle.com  Wed Aug 21 09:51:47 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Aug 2013 19:51:47 +1000
Subject: RFR: 8023460 OPENJDK build fails due to missing jfr.jar
In-Reply-To: <521486D3.8000000@oracle.com>
References: <521484B7.9000205@oracle.com> <521486D3.8000000@oracle.com>
Message-ID: <52148DB3.5030809@oracle.com>

On 21/08/2013 7:22 PM, Alan Bateman wrote:
> On 21/08/2013 10:13, David Holmes wrote:
>> :
>>
>> webrev:
>>
>> http://cr.openjdk.java.net/~dholmes/8023460/webrev/
>>
>> Thanks - and apologies again for the build problem for OpenJDK.
> It's good to get to bottom of the original issue. In general the
> profiles build is somewhat complicated and easy for issues to creep in,
> especially when alternative ways to build it. The change looks okay to me.

Thanks Alan.

Also a good example of how you can get the right results for the wrong 
reason :)

Cheers,
David

> -Alan


From paul.sandoz at oracle.com  Wed Aug 21 09:52:05 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 21 Aug 2013 11:52:05 +0200
Subject: RFR: 8016846: Pattern.splitAsStream tests required
In-Reply-To: <5213E07B.1060506@oracle.com>
References: <51E5998E.8040409@oracle.com> <51EFFD82.50307@oracle.com>
	<5213C823.3020105@oracle.com> <5213CA48.6060406@oracle.com>
	<5213E07B.1060506@oracle.com>
Message-ID: <60CBC066-F0F6-49DA-976F-A8CF89731785@oracle.com>


On Aug 20, 2013, at 11:32 PM, Henry Jen  wrote:

> On 08/20/2013 12:58 PM, Jonathan Gibbons wrote:
>> Henry,
>> 
>> I think you should sort out the issues you are having with jtreg.
>> It is not yet clear to me that this is a jtreg issue as much as a test 
>> or library issue.
>> 
> 
> Thanks Jon for the help on jtreg issue, the test can be easily fixed by
> adding an extra @build tag.
> 
> The new webrev is at
> http://cr.openjdk.java.net/~henryjen/tl/8016846/1/webrev
> 

Looks good, it's useful to know that jtreg can do this.

Paul.

From david.holmes at oracle.com  Wed Aug 21 09:57:16 2013
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Wed, 21 Aug 2013 09:57:16 +0000
Subject: hg: jdk8/tl/jdk: 8023460: OPENJDK build fails due to missing jfr.jar
Message-ID: <20130821095728.7866948A38@hg.openjdk.java.net>

Changeset: 3b8fed46b2a8
Author:    dholmes
Date:      2013-08-21 05:56 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b8fed46b2a8

8023460: OPENJDK build fails due to missing jfr.jar
Reviewed-by: alanb

! makefiles/Profiles.gmk



From dl at cs.oswego.edu  Wed Aug 21 10:19:43 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 21 Aug 2013 06:19:43 -0400
Subject: 8020292: j.u.SplittableRandom
In-Reply-To: 
References: <9F153157-0FC5-4385-B1BC-4FE2D43006F4@oracle.com>
	
	
	
	
Message-ID: <5214943F.5080609@cs.oswego.edu>

On 08/21/2013 05:43 AM, Paul Sandoz wrote:
> On Aug 20, 2013, at 11:50 PM, Mike Duigou  wrote:
>>>> - Additional seed material might be desirable for "seeder". I worry
>>>> about how many of the actual bits are random.

Backing up a bit: I tried using a SecureRandom seed.
But then discovered that on some systems, this led to
serious start-up stalls (up to 10 seconds or so) because
/dev/random can delay while collecting entropy. For a non-secure
RNG, this is unacceptable. On most Unix/linux systems,
this is a known issue, and there is a workaround to instead
use /dev/urandom. But using /dev/urandom is tantamount to
just collecting some local information, so the default
seeder does so itself which leads to faster startup.
Note that the two main ingredients, absolute time (currentTimeMillis)
and non-absolute time (nanoTime) are in general uncorrelated
(they normally use different timers, with different precisions,
on current JVMs). The hostname hash is a barely-useful tie-breaker
in case they are.

I can't get myself to believe that adding information from
various identityHashCodes would improve this, since they are
dependent on the identityHashCode mechanics themselves
doing better than this, which I don't think they do.

>
> I did ponder whether it is worthwhile defining a boolean system property that
> if declared and true then SecureRandom is used.
>

Given the alternative of slowing down startup for all
usages, this now strikes me as an OK CYA move.

-Doug


From joel.franck at oracle.com  Wed Aug 21 12:04:05 2013
From: joel.franck at oracle.com (Joel =?utf-8?Q?Borggr=C3=A9n-Franck?=)
Date: Wed, 21 Aug 2013 14:04:05 +0200
Subject: RFR: 8022343: j.l.Class.getAnnotatedSuperclass() doesn't return
	null in some cases
In-Reply-To: <5212C532.8030905@oracle.com>
References: <20130816121739.GM12405@jfranck-desktop.jrpg.bea.com>
	
	<5212C532.8030905@oracle.com>
Message-ID: <20130821120405.GE22953@jfranck-desktop.jrpg.bea.com>

Hi Joe, Paul

I rewrote the test in Paul's style without using testNG.

http://cr.openjdk.java.net/~jfranck/8022343/webrev.01/

Please review.

cheers
/Joel

On 2013-08-19, Joe Darcy wrote:
> Hi Joel,
> 
> I agree the code looks fine.
> 
> However, I concur with the general sentiment of Paul test advice
> without advocating using testng for this task.
> 
> A loop over a Class[] initialized with the kinds of values of
> interest would seem to be better structured to me and allow for
> better exception handing, etc.
> 
> -Joe
> 
> On 08/19/2013 01:34 AM, Paul Sandoz wrote:
> >Hi Joel,
> >
> >The fix looks OK.
> >
> >Not suggesting you do the following, unless you really want to, but the test is an example of where TestNG data providers are useful, since all cases will be tested and reported for pass or failure, rather than in this case the first failure will cause other checks (if any) not to be tested and in addition will not report which check failed (one needs to look at the stack trace).
> >
> >Not tested:
> >
> >   @DataProvider(name = "class")
> >   private static Object[][] getClasses() {
> >       // Using the stream API because i can :-)
> >       // Arguably simpler in this case to use new Object[][] { {} }
> >       return Stream.of(
> >                                 Object.class,
> >                                 If.class,
> >                                 Object[].class,
> >                                 void.class,
> >                                 int.class).
> >               map(e -> new Object[] { e }).
> >               toArray(Object[][]::new);
> >   }
> >
> >   @Test(dataProvider = "class")
> >   public void testAnnotatedSuperClassIsNull(Class c) {
> >       assertNull(c.getAnnotatedSuperclass())
> >   }
> >
> >Paul.
> >
> >On Aug 16, 2013, at 2:17 PM, Joel Borggren-Franck  wrote:
> >
> >>Hi
> >>
> >>Please review this small fix for a type annotation reflection issue.
> >>
> >>The javadoc spec for Class.getAnnotatedSuperclass says:
> >>
> >>* If this Class represents either the Object class, an interface type, an
> >>* array type, a primitive type, or void, the return value is null.
> >>
> >>The patch fixes this.
> >>
> >>Webrev at: http://cr.openjdk.java.net/~jfranck/8022343/webrew.00/
> >>
> >>Patch also included it at the end of this mail.
> >>
> >>cheers
> >>/Joel
> >>
> >>
> >>
> >>diff -r b07b19182e40 src/share/classes/java/lang/Class.java
> >>--- a/src/share/classes/java/lang/Class.java	Thu Aug 15 15:04:59 2013 +0100
> >>+++ b/src/share/classes/java/lang/Class.java	Fri Aug 16 13:20:31 2013 +0200
> >>@@ -3338,8 +3338,16 @@
> >>      * @since 1.8
> >>      */
> >>     public AnnotatedType getAnnotatedSuperclass() {
> >>-         return TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), getConstantPool(), this);
> >>-}
> >>+        if(this == Object.class ||
> >>+                isInterface() ||
> >>+                isArray() ||
> >>+                isPrimitive() ||
> >>+                this == Void.TYPE) {
> >>+            return null;
> >>+        }
> >>+
> >>+        return TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), getConstantPool(), this);
> >>+    }
> >>
> >>     /**
> >>      * Returns an array of AnnotatedType objects that represent the use of types to
> >>diff -r b07b19182e40 test/java/lang/annotation/TypeAnnotationReflection.java
> >>--- a/test/java/lang/annotation/TypeAnnotationReflection.java	Thu Aug 15 15:04:59 2013 +0100
> >>+++ b/test/java/lang/annotation/TypeAnnotationReflection.java	Fri Aug 16 13:20:31 2013 +0200
> >>@@ -23,7 +23,7 @@
> >>
> >>/*
> >>  * @test
> >>- * @bug 8004698 8007073
> >>+ * @bug 8004698 8007073 8022343
> >>  * @summary Unit test for type annotations
> >>  */
> >>
> >>@@ -58,7 +58,7 @@
> >>     }
> >>
> >>     private static void testSuper() throws Exception {
> >>-        check(Object.class.getAnnotatedSuperclass().getAnnotations().length == 0);
> >>+        check(Object.class.getAnnotatedSuperclass() == null);
> >>         check(Class.class.getAnnotatedSuperclass().getAnnotations().length == 0);
> >>
> >>         AnnotatedType a;
> >>diff -r b07b19182e40 test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java
> >>--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> >>+++ b/test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java	Fri Aug 16 13:20:31 2013 +0200
> >>@@ -0,0 +1,50 @@
> >>+/*
> >>+ * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
> >>+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> >>+ *
> >>+ * This code is free software; you can redistribute it and/or modify it
> >>+ * under the terms of the GNU General Public License version 2 only, as
> >>+ * published by the Free Software Foundation.
> >>+ *
> >>+ * This code is distributed in the hope that it will be useful, but WITHOUT
> >>+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> >>+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> >>+ * version 2 for more details (a copy is included in the LICENSE file that
> >>+ * accompanied this code).
> >>+ *
> >>+ * You should have received a copy of the GNU General Public License version
> >>+ * 2 along with this work; if not, write to the Free Software Foundation,
> >>+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> >>+ *
> >>+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
> >>+ * or visit www.oracle.com if you need additional information or have any
> >>+ * questions.
> >>+ */
> >>+
> >>+/*
> >>+ * @test
> >>+ * @bug 8022343
> >>+ * @summary make sure Class.getAnnotatedSuperclass() returns null when specified to do so
> >>+ */
> >>+
> >>+import java.util.*;
> >>+import java.lang.annotation.*;
> >>+import java.lang.reflect.*;
> >>+import java.io.Serializable;
> >>+
> >>+public class GetAnnotatedSuperclass {
> >>+    public static void main(String[] args) throws Exception {
> >>+        check(Object.class.getAnnotatedSuperclass() == null);
> >>+        check(If.class.getAnnotatedSuperclass() == null);
> >>+        check(Object[].class.getAnnotatedSuperclass() == null);
> >>+        check(void.class.getAnnotatedSuperclass() == null);
> >>+        check(int.class.getAnnotatedSuperclass() == null);
> >>+    }
> >>+
> >>+    private static void check(boolean b) {
> >>+        if (!b)
> >>+            throw new RuntimeException();
> >>+    }
> >>+    interface If {}
> >>+}
> >>+
> 


From paul.sandoz at oracle.com  Wed Aug 21 12:25:37 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 21 Aug 2013 14:25:37 +0200
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets or
	trees (red/black)
Message-ID: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>

Hi,

Here are Doug's Linked/HashMap changes, discussed in a previous thread, as a webrev:

  http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/

I also added some tests related to characteristics associated with fixing another bug.

Looking at the diffs will be tricky given there are so many changes.


I fixed unchecked warnings in LinkedHashMap, but have not done so for HashMap, where there are many more casts from Node to TreeNode. One way to solve that is with a static method:

    @SuppressWarnings("unchecked")
    static  TreeNode asTreeNode(Node n) {
        return (TreeNode) n;
    }

but i dunno what the performance implications are. Perhaps it's best to simply stuff @SuppressWarnings on methods of TreeNode rather than trying to modify code just for the sake of reducing the scope.


A JPRT job has been kicked off.

I recommend when this code goes in we look closely at code coverage results to see if we are missing areas testing tree functionality and update/add new tests accordingly.

Paul.


From paul.sandoz at oracle.com  Wed Aug 21 14:00:25 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 21 Aug 2013 16:00:25 +0200
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets
	or trees (red/black)
In-Reply-To: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
Message-ID: 

I updated the webrev to adjust some tests that a JPRT run reporting as failing:

FAILED: java/util/Map/CheckRandomHashSeed.java
FAILED: java/util/Map/TreeBinSplitBackToEntries.java

The test TreeBinSplitBackToEntries needs to be revamped as the conditions under which bins are converted to trees and vice versa are no longer hold.

Conversion from a bin to a tree will not happen unless the table size is >= 64 (MIN_TREEIFY_CAPACITY) and the number of entries in a bin before adding is >= 7 (TREEIFY_THRESHOLD - 1). 

Conversion back from a tree to a bin occurs if the number of entries in a tree is <= 6 (UNTREEIFY_THRESHOLD), which AFAICT can occur when the table is resized, but can also occur under remove when the tree size is somewhere between 2 and 6. So we should try and create some tests to trigger this conversion too.

Plus tests for traversal when it is known the table contains trees (it is tempting, for convenience, to add instances to Spliterator traversing tests but that is probably overkill)

Paul.

On Aug 21, 2013, at 2:25 PM, Paul Sandoz  wrote:

> Hi,
> 
> Here are Doug's Linked/HashMap changes, discussed in a previous thread, as a webrev:
> 
>  http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/
> 
> I also added some tests related to characteristics associated with fixing another bug.
> 
> Looking at the diffs will be tricky given there are so many changes.
> 
> 
> I fixed unchecked warnings in LinkedHashMap, but have not done so for HashMap, where there are many more casts from Node to TreeNode. One way to solve that is with a static method:
> 
>    @SuppressWarnings("unchecked")
>    static  TreeNode asTreeNode(Node n) {
>        return (TreeNode) n;
>    }
> 
> but i dunno what the performance implications are. Perhaps it's best to simply stuff @SuppressWarnings on methods of TreeNode rather than trying to modify code just for the sake of reducing the scope.
> 
> 
> A JPRT job has been kicked off.
> 
> I recommend when this code goes in we look closely at code coverage results to see if we are missing areas testing tree functionality and update/add new tests accordingly.
> 
> Paul.
> 


From paul.sandoz at oracle.com  Wed Aug 21 14:04:34 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 21 Aug 2013 16:04:34 +0200
Subject: 8020292: j.u.SplittableRandom
In-Reply-To: <5214943F.5080609@cs.oswego.edu>
References: <9F153157-0FC5-4385-B1BC-4FE2D43006F4@oracle.com>
	
	
	
	
	<5214943F.5080609@cs.oswego.edu>
Message-ID: <647F7963-8C04-49B4-9434-EB5631C49CA3@oracle.com>

On Aug 21, 2013, at 12:19 PM, Doug Lea 
 wrote:
> On 08/21/2013 05:43 AM, Paul Sandoz wrote:
>> On Aug 20, 2013, at 11:50 PM, Mike Duigou  wrote:
>>>>> - Additional seed material might be desirable for "seeder". I worry
>>>>> about how many of the actual bits are random.
> 
> Backing up a bit: I tried using a SecureRandom seed.
> But then discovered that on some systems, this led to
> serious start-up stalls (up to 10 seconds or so) because
> /dev/random can delay while collecting entropy. For a non-secure
> RNG, this is unacceptable. On most Unix/linux systems,
> this is a known issue, and there is a workaround to instead
> use /dev/urandom. But using /dev/urandom is tantamount to
> just collecting some local information, so the default
> seeder does so itself which leads to faster startup.
> Note that the two main ingredients, absolute time (currentTimeMillis)
> and non-absolute time (nanoTime) are in general uncorrelated
> (they normally use different timers, with different precisions,
> on current JVMs). The hostname hash is a barely-useful tie-breaker
> in case they are.
> 
> I can't get myself to believe that adding information from
> various identityHashCodes would improve this, since they are
> dependent on the identityHashCode mechanics themselves
> doing better than this, which I don't think they do.
> 
>> 
>> I did ponder whether it is worthwhile defining a boolean system property that
>> if declared and true then SecureRandom is used.
>> 
> 
> Given the alternative of slowing down startup for all
> usages, this now strikes me as an OK CYA move.
> 

OK. Unless there are strong objections i will do this.

Paul.

From Alan.Bateman at oracle.com  Wed Aug 21 14:11:12 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 21 Aug 2013 15:11:12 +0100
Subject: RFR: 8016846: Pattern.splitAsStream tests required
In-Reply-To: <5213C823.3020105@oracle.com>
References: <51E5998E.8040409@oracle.com> <51EFFD82.50307@oracle.com>
	<5213C823.3020105@oracle.com>
Message-ID: <5214CA80.4010905@oracle.com>

On 20/08/2013 20:48, Henry Jen wrote:
> :
> We are using stream test framework on this to verify all style of stream
> works, with that we will need to have library on bootclasspath, and that
> current prevent us from put it in test/java/util/regex because of jtreg
> limitation.
>
> If no object, I'll push this at its current location. We can revisit
> this when jtreg support is available.
>
> The other alternative is that we refactor the test to test only split,
> and leave out the various style of stream checking. While we lose the
> sanity check, but I don't think we lose much as the form of iterator
> converted into stream and operated should have been covered in other
> stream tests.
>
> Let me know if we think it's important enough to refactor the test.
>
I saw the mails on jtreg-use so thanks for following up on that. I 
looked at the latest webrev and it looks fine to me.

-Alan.


From Alan.Bateman at oracle.com  Wed Aug 21 14:13:22 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 21 Aug 2013 15:13:22 +0100
Subject: 8023215: test/java/util/Comparator/TypeTest.java not running
	(failing but reported as passing)
In-Reply-To: <80892FA2-9E73-4F8B-90FE-65CD73A64BCA@oracle.com>
References: <5211E205.70202@oracle.com>
	<80892FA2-9E73-4F8B-90FE-65CD73A64BCA@oracle.com>
Message-ID: <5214CB02.1070508@oracle.com>

On 19/08/2013 15:57, Henry Jen wrote:
> Uh, this one was wrote to be a regular jtreg test running with main, not a testNG test.
>
> Thanks for looking into this.
>
> Also I am wondering if this one still add any value, it was added to test the API when we had it like
>
>   Comparator  thenComparing(Comparator  cmp)
>
I was wonder about that as looked a bit incomplete. If there isn't any 
value then it should be fine to just delete it, assuming there is good 
coverage in other tests (which I suspect there is).

-Alan


From staffan.larsen at oracle.com  Wed Aug 21 14:20:55 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 21 Aug 2013 16:20:55 +0200
Subject: RFR: Remove tests from ProblemList.txt
Message-ID: <8A0D2A91-6ABB-4CC3-BABA-EFE8ACDFC3BA@oracle.com>

I've had a look at these two old bugs:
  http://bugs.sun.com/view_bug.do?bug_id=7020857
  http://bugs.sun.com/view_bug.do?bug_id=6909804

They are both listed in ProblemList.txt and reported as intermittent failures in 2011 and 2009 respectively.

I've been searching our test history for instances of these failures, but cannot find anything for the last year (didn't look further back). I can see that the tests have been running and I can see other failures in the tests (environment issues mostly) but not the failures reported in the bugs.

I have been doing reruns on linux x86-64 and window x86-64. 1000 iterations did not reproduce the problems. 

I would thus like to close the bugs and remove the tests from ProblemList.txt. Below is the proposed diff.

Thanks,
/Staffan



diff --git a/test/ProblemList.txt b/test/ProblemList.txt
--- a/test/ProblemList.txt
+++ b/test/ProblemList.txt
@@ -336,12 +336,6 @@
 # Filed 6653793
 com/sun/jdi/RedefineCrossEvent.java                             generic-all

-# Filed 6987312
-com/sun/jdi/DoubleAgentTest.java                                generic-all
-
-# Filed 7020857
-com/sun/jdi/FieldWatchpoints.java                               generic-all
-
 # Filed 6402201
 com/sun/jdi/ProcessAttachTest.sh                                generic-all



From chris.hegarty at oracle.com  Wed Aug 21 14:57:41 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 21 Aug 2013 15:57:41 +0100
Subject: RFR: Remove tests from ProblemList.txt
In-Reply-To: <544b4597-517d-4328-ac4e-eecdf7b2a375@default>
References: <8A0D2A91-6ABB-4CC3-BABA-EFE8ACDFC3BA@oracle.com>
	<544b4597-517d-4328-ac4e-eecdf7b2a375@default>
Message-ID: 

Looks good to me.

-Chris

On 21 Aug 2013, at 15:31, Markus Gr?nlund  wrote:

> Thanks for taking a look at these old bugs Staffan.
> 
> Looks good (not a Reviewer).
> 
> /Markus
> 
> 
> 
> -----Original Message-----
> From: Staffan Larsen 
> Sent: den 21 augusti 2013 16:21
> To: core-libs-dev at openjdk.java.net; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net
> Subject: RFR: Remove tests from ProblemList.txt
> 
> I've had a look at these two old bugs:
>  http://bugs.sun.com/view_bug.do?bug_id=7020857
>  http://bugs.sun.com/view_bug.do?bug_id=6909804
> 
> They are both listed in ProblemList.txt and reported as intermittent failures in 2011 and 2009 respectively.
> 
> I've been searching our test history for instances of these failures, but cannot find anything for the last year (didn't look further back). I can see that the tests have been running and I can see other failures in the tests (environment issues mostly) but not the failures reported in the bugs.
> 
> I have been doing reruns on linux x86-64 and window x86-64. 1000 iterations did not reproduce the problems. 
> 
> I would thus like to close the bugs and remove the tests from ProblemList.txt. Below is the proposed diff.
> 
> Thanks,
> /Staffan
> 
> 
> 
> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
> --- a/test/ProblemList.txt
> +++ b/test/ProblemList.txt
> @@ -336,12 +336,6 @@
> # Filed 6653793
> com/sun/jdi/RedefineCrossEvent.java                             generic-all
> 
> -# Filed 6987312
> -com/sun/jdi/DoubleAgentTest.java                                generic-all
> -
> -# Filed 7020857
> -com/sun/jdi/FieldWatchpoints.java                               generic-all
> -
> # Filed 6402201
> com/sun/jdi/ProcessAttachTest.sh                                generic-all
> 


From staffan.larsen at oracle.com  Wed Aug 21 15:21:34 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 21 Aug 2013 17:21:34 +0200
Subject: RFR: Remove tests from ProblemList.txt
In-Reply-To: 
References: <8A0D2A91-6ABB-4CC3-BABA-EFE8ACDFC3BA@oracle.com>
	<544b4597-517d-4328-ac4e-eecdf7b2a375@default>
	
Message-ID: <7DE061E1-2546-4DDA-90FE-74564A5074A3@oracle.com>

Thanks Chris and Markus.

/Staffan

On 21 aug 2013, at 16:57, Chris Hegarty  wrote:

> Looks good to me.
> 
> -Chris
> 
> On 21 Aug 2013, at 15:31, Markus Gr?nlund  wrote:
> 
>> Thanks for taking a look at these old bugs Staffan.
>> 
>> Looks good (not a Reviewer).
>> 
>> /Markus
>> 
>> 
>> 
>> -----Original Message-----
>> From: Staffan Larsen 
>> Sent: den 21 augusti 2013 16:21
>> To: core-libs-dev at openjdk.java.net; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net
>> Subject: RFR: Remove tests from ProblemList.txt
>> 
>> I've had a look at these two old bugs:
>> http://bugs.sun.com/view_bug.do?bug_id=7020857
>> http://bugs.sun.com/view_bug.do?bug_id=6909804
>> 
>> They are both listed in ProblemList.txt and reported as intermittent failures in 2011 and 2009 respectively.
>> 
>> I've been searching our test history for instances of these failures, but cannot find anything for the last year (didn't look further back). I can see that the tests have been running and I can see other failures in the tests (environment issues mostly) but not the failures reported in the bugs.
>> 
>> I have been doing reruns on linux x86-64 and window x86-64. 1000 iterations did not reproduce the problems. 
>> 
>> I would thus like to close the bugs and remove the tests from ProblemList.txt. Below is the proposed diff.
>> 
>> Thanks,
>> /Staffan
>> 
>> 
>> 
>> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
>> --- a/test/ProblemList.txt
>> +++ b/test/ProblemList.txt
>> @@ -336,12 +336,6 @@
>> # Filed 6653793
>> com/sun/jdi/RedefineCrossEvent.java                             generic-all
>> 
>> -# Filed 6987312
>> -com/sun/jdi/DoubleAgentTest.java                                generic-all
>> -
>> -# Filed 7020857
>> -com/sun/jdi/FieldWatchpoints.java                               generic-all
>> -
>> # Filed 6402201
>> com/sun/jdi/ProcessAttachTest.sh                                generic-all
>> 



From staffan.larsen at oracle.com  Wed Aug 21 15:33:42 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Wed, 21 Aug 2013 15:33:42 +0000
Subject: hg: jdk8/tl/jdk: 8023485: Remove com/sun/jdi/DoubleAgentTest.java and
	com/sun/jdi/FieldWatchpoints.java from ProblemList.txt
Message-ID: <20130821153409.DC15048A46@hg.openjdk.java.net>

Changeset: 8996f47f738d
Author:    sla
Date:      2013-08-21 17:19 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8996f47f738d

8023485: Remove com/sun/jdi/DoubleAgentTest.java and com/sun/jdi/FieldWatchpoints.java from ProblemList.txt
Reviewed-by: chegar, mgronlun

! test/ProblemList.txt



From paul.sandoz at oracle.com  Wed Aug 21 16:47:08 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 21 Aug 2013 18:47:08 +0200
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets
	or trees (red/black)
In-Reply-To: 
References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
	
Message-ID: 

I updated the webrev and replaced TreeBinSplitBackToEntries.java with:

  http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/test/java/util/Map/MapBinToFromTreeTest.java.html

Paul.

On Aug 21, 2013, at 4:00 PM, Paul Sandoz  wrote:

> I updated the webrev to adjust some tests that a JPRT run reporting as failing:
> 
> FAILED: java/util/Map/CheckRandomHashSeed.java
> FAILED: java/util/Map/TreeBinSplitBackToEntries.java
> 
> The test TreeBinSplitBackToEntries needs to be revamped as the conditions under which bins are converted to trees and vice versa are no longer hold.
> 
> Conversion from a bin to a tree will not happen unless the table size is >= 64 (MIN_TREEIFY_CAPACITY) and the number of entries in a bin before adding is >= 7 (TREEIFY_THRESHOLD - 1). 
> 
> Conversion back from a tree to a bin occurs if the number of entries in a tree is <= 6 (UNTREEIFY_THRESHOLD), which AFAICT can occur when the table is resized, but can also occur under remove when the tree size is somewhere between 2 and 6. So we should try and create some tests to trigger this conversion too.
> 
> Plus tests for traversal when it is known the table contains trees (it is tempting, for convenience, to add instances to Spliterator traversing tests but that is probably overkill)
> 
> Paul.
> 
> On Aug 21, 2013, at 2:25 PM, Paul Sandoz  wrote:
> 
>> Hi,
>> 
>> Here are Doug's Linked/HashMap changes, discussed in a previous thread, as a webrev:
>> 
>> http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/
>> 
>> I also added some tests related to characteristics associated with fixing another bug.
>> 
>> Looking at the diffs will be tricky given there are so many changes.
>> 
>> 
>> I fixed unchecked warnings in LinkedHashMap, but have not done so for HashMap, where there are many more casts from Node to TreeNode. One way to solve that is with a static method:
>> 
>>   @SuppressWarnings("unchecked")
>>   static  TreeNode asTreeNode(Node n) {
>>       return (TreeNode) n;
>>   }
>> 
>> but i dunno what the performance implications are. Perhaps it's best to simply stuff @SuppressWarnings on methods of TreeNode rather than trying to modify code just for the sake of reducing the scope.
>> 
>> 
>> A JPRT job has been kicked off.
>> 
>> I recommend when this code goes in we look closely at code coverage results to see if we are missing areas testing tree functionality and update/add new tests accordingly.
>> 
>> Paul.
>> 
> 


From markus.gronlund at oracle.com  Wed Aug 21 14:31:37 2013
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Wed, 21 Aug 2013 07:31:37 -0700 (PDT)
Subject: RFR: Remove tests from ProblemList.txt
In-Reply-To: <8A0D2A91-6ABB-4CC3-BABA-EFE8ACDFC3BA@oracle.com>
References: <8A0D2A91-6ABB-4CC3-BABA-EFE8ACDFC3BA@oracle.com>
Message-ID: <544b4597-517d-4328-ac4e-eecdf7b2a375@default>

Thanks for taking a look at these old bugs Staffan.

Looks good (not a Reviewer).

/Markus



-----Original Message-----
From: Staffan Larsen 
Sent: den 21 augusti 2013 16:21
To: core-libs-dev at openjdk.java.net; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net
Subject: RFR: Remove tests from ProblemList.txt

I've had a look at these two old bugs:
  http://bugs.sun.com/view_bug.do?bug_id=7020857
  http://bugs.sun.com/view_bug.do?bug_id=6909804

They are both listed in ProblemList.txt and reported as intermittent failures in 2011 and 2009 respectively.

I've been searching our test history for instances of these failures, but cannot find anything for the last year (didn't look further back). I can see that the tests have been running and I can see other failures in the tests (environment issues mostly) but not the failures reported in the bugs.

I have been doing reruns on linux x86-64 and window x86-64. 1000 iterations did not reproduce the problems. 

I would thus like to close the bugs and remove the tests from ProblemList.txt. Below is the proposed diff.

Thanks,
/Staffan



diff --git a/test/ProblemList.txt b/test/ProblemList.txt
--- a/test/ProblemList.txt
+++ b/test/ProblemList.txt
@@ -336,12 +336,6 @@
 # Filed 6653793
 com/sun/jdi/RedefineCrossEvent.java                             generic-all

-# Filed 6987312
-com/sun/jdi/DoubleAgentTest.java                                generic-all
-
-# Filed 7020857
-com/sun/jdi/FieldWatchpoints.java                               generic-all
-
 # Filed 6402201
 com/sun/jdi/ProcessAttachTest.sh                                generic-all



From aleksey.shipilev at oracle.com  Wed Aug 21 17:46:12 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 21 Aug 2013 21:46:12 +0400
Subject: RFR (M) CR 8023234: StampedLock serializes readers on writer
	unlock
In-Reply-To: 
References: <521230D1.9070803@oracle.com>
	
	<52138373.8090903@oracle.com>
	
Message-ID: <5214FCE4.9030507@oracle.com>

Hi Martin,

On 08/21/2013 06:28 AM, Martin Buchholz wrote:
> If a Reader throws, the test might still pass, since only throwing from
> the main thread matters.  See infrastructure in JSR166TestCase, e.g.
> threadUnexpectedException.

Yes. I still don't think there is a value in catching the exceptions in
the threads for this concrete regression test. Should the reader die
with the exception, the test will fail anyway, since enough readers are
not available.

> OTOH, there seems no value in converting exceptions in the main thread
> to ISE.  Just declare main to throw Exception or whatever.

This seems to be the stylistic nit. ;) There is the symmetry against
readers code, which wraps the exceptions into the ISE. For my taste, it
looks better to retain that symmetry.

I can still make the changes to the test, if you insist.

-Aleksey.



From stuart.marks at oracle.com  Wed Aug 21 18:10:02 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 21 Aug 2013 11:10:02 -0700
Subject: RFR : 8023395 : (xs) Deprecate sun.misc.Sort and sun.misc.Compare
In-Reply-To: <5213B526.7040700@oracle.com>
References: <3CE2D646-4978-42B2-9AC4-BF41D5DC3D6A@oracle.COM>
	<5213B526.7040700@oracle.com>
Message-ID: <5215027A.4050000@oracle.com>

On 8/20/13 11:27 AM, Joe Darcy wrote:
> On 08/20/2013 11:07 AM, Mike Duigou wrote:
>> Hello all;
>>
>> This is a proposal to deprecate (Any votes for outright removal?)
>
> Yes; take them out!

Me too! Just take 'em out. Unlike some other sun.misc APIs :-/ there are 
already suitable public alternatives for these.

s'marks



From Mike.Duigou at oracle.com  Wed Aug 21 18:33:52 2013
From: Mike.Duigou at oracle.com (Mike Duigou)
Date: Wed, 21 Aug 2013 11:33:52 -0700
Subject: RFR : 8023395 : (xs) Remove sun.misc.Sort and sun.misc.Compare
In-Reply-To: <5215027A.4050000@oracle.com>
References: <3CE2D646-4978-42B2-9AC4-BF41D5DC3D6A@oracle.COM>
	<5213B526.7040700@oracle.com> <5215027A.4050000@oracle.com>
Message-ID: <1F836204-C47F-4970-ABE8-5F5EC3E4B9B6@oracle.com>

Hearing significant consensus to remove rather than deprecate these two classes I am revising this proposal remove rather than deprecate. The revised webrev (which removes the classes) is here:

http://cr.openjdk.java.net/~mduigou/JDK-8023395/1/webrev/

I have verified that they are unused within the JDK. Mandy provided one external example that uses these classes rather than java.util.Arrays for unknown reasons. I will attempt to contact the project and advise them to switch.

Mike


On Aug 21 2013, at 11:10 , Stuart Marks wrote:

> On 8/20/13 11:27 AM, Joe Darcy wrote:
>> On 08/20/2013 11:07 AM, Mike Duigou wrote:
>>> Hello all;
>>> 
>>> This is a proposal to deprecate (Any votes for outright removal?)
>> 
>> Yes; take them out!
> 
> Me too! Just take 'em out. Unlike some other sun.misc APIs :-/ there are already suitable public alternatives for these.
> 
> s'marks
> 



From joe.darcy at oracle.com  Wed Aug 21 18:36:31 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 21 Aug 2013 11:36:31 -0700
Subject: RFR : 8023395 : (xs) Remove sun.misc.Sort and sun.misc.Compare
In-Reply-To: <1F836204-C47F-4970-ABE8-5F5EC3E4B9B6@oracle.com>
References: <3CE2D646-4978-42B2-9AC4-BF41D5DC3D6A@oracle.COM>
	<5213B526.7040700@oracle.com> <5215027A.4050000@oracle.com>
	<1F836204-C47F-4970-ABE8-5F5EC3E4B9B6@oracle.com>
Message-ID: <521508AF.2080602@oracle.com>

Looks good.

-Joe

On 08/21/2013 11:33 AM, Mike Duigou wrote:
> Hearing significant consensus to remove rather than deprecate these two classes I am revising this proposal remove rather than deprecate. The revised webrev (which removes the classes) is here:
>
> http://cr.openjdk.java.net/~mduigou/JDK-8023395/1/webrev/
>
> I have verified that they are unused within the JDK. Mandy provided one external example that uses these classes rather than java.util.Arrays for unknown reasons. I will attempt to contact the project and advise them to switch.
>
> Mike
>
>
> On Aug 21 2013, at 11:10 , Stuart Marks wrote:
>
>> On 8/20/13 11:27 AM, Joe Darcy wrote:
>>> On 08/20/2013 11:07 AM, Mike Duigou wrote:
>>>> Hello all;
>>>>
>>>> This is a proposal to deprecate (Any votes for outright removal?)
>>> Yes; take them out!
>> Me too! Just take 'em out. Unlike some other sun.misc APIs :-/ there are already suitable public alternatives for these.
>>
>> s'marks
>>



From martinrb at google.com  Wed Aug 21 18:53:09 2013
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 21 Aug 2013 11:53:09 -0700
Subject: RFR (M) CR 8023234: StampedLock serializes readers on writer
	unlock
In-Reply-To: <5214FCE4.9030507@oracle.com>
References: <521230D1.9070803@oracle.com>
	
	<52138373.8090903@oracle.com>
	
	<5214FCE4.9030507@oracle.com>
Message-ID: 

OK, approved!

I would do things differently, and there is the deeper problem that openjdk
provides no test infrastructure for multi-threaded tests, which we are
suffering from here.  Now that testng is being used, it's a good time for
someone to import test infrastructure from JSR166TestCase


On Wed, Aug 21, 2013 at 10:46 AM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> Hi Martin,
>
> On 08/21/2013 06:28 AM, Martin Buchholz wrote:
> > If a Reader throws, the test might still pass, since only throwing from
> > the main thread matters.  See infrastructure in JSR166TestCase, e.g.
> > threadUnexpectedException.
>
> Yes. I still don't think there is a value in catching the exceptions in
> the threads for this concrete regression test. Should the reader die
> with the exception, the test will fail anyway, since enough readers are
> not available.
>
> > OTOH, there seems no value in converting exceptions in the main thread
> > to ISE.  Just declare main to throw Exception or whatever.
>
> This seems to be the stylistic nit. ;) There is the symmetry against
> readers code, which wraps the exceptions into the ISE. For my taste, it
> looks better to retain that symmetry.
>
> I can still make the changes to the test, if you insist.
>
> -Aleksey.
>
>


From aleksey.shipilev at oracle.com  Wed Aug 21 19:05:38 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 21 Aug 2013 23:05:38 +0400
Subject: RFR (M) CR 8023234: StampedLock serializes readers on writer
	unlock
In-Reply-To: 
References: <521230D1.9070803@oracle.com>
	
	<52138373.8090903@oracle.com>
	
	<5214FCE4.9030507@oracle.com>
	
Message-ID: <52150F82.1090600@oracle.com>

Thanks Martin!

I need a sponsor to push this.

-Aleksey.

P.S. The support for multi-threaded tests in jtreg/library is one of the
things I'm eager to have.

On 08/21/2013 10:53 PM, Martin Buchholz wrote:
> OK, approved!
> 
> I would do things differently, and there is the deeper problem that
> openjdk provides no test infrastructure for multi-threaded tests, which
> we are suffering from here.  Now that testng is being used, it's a good
> time for someone to import test infrastructure from JSR166TestCase
> 
> 
> On Wed, Aug 21, 2013 at 10:46 AM, Aleksey Shipilev
> > wrote:
> 
>     Hi Martin,
> 
>     On 08/21/2013 06:28 AM, Martin Buchholz wrote:
>     > If a Reader throws, the test might still pass, since only throwing
>     from
>     > the main thread matters.  See infrastructure in JSR166TestCase, e.g.
>     > threadUnexpectedException.
> 
>     Yes. I still don't think there is a value in catching the exceptions in
>     the threads for this concrete regression test. Should the reader die
>     with the exception, the test will fail anyway, since enough readers are
>     not available.
> 
>     > OTOH, there seems no value in converting exceptions in the main thread
>     > to ISE.  Just declare main to throw Exception or whatever.
> 
>     This seems to be the stylistic nit. ;) There is the symmetry against
>     readers code, which wraps the exceptions into the ISE. For my taste, it
>     looks better to retain that symmetry.
> 
>     I can still make the changes to the test, if you insist.
> 
>     -Aleksey.
> 
> 



From mark.reinhold at oracle.com  Wed Aug 21 19:16:05 2013
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 21 Aug 2013 12:16:05 -0700
Subject: RFR : 8023395 : (xs) Remove sun.misc.Sort and sun.misc.Compare
In-Reply-To: <1F836204-C47F-4970-ABE8-5F5EC3E4B9B6@oracle.com>
References: <3CE2D646-4978-42B2-9AC4-BF41D5DC3D6A@oracle.COM>,
	<5213B526.7040700@oracle.com>, <5215027A.4050000@oracle.com>,
	<1F836204-C47F-4970-ABE8-5F5EC3E4B9B6@oracle.com>
Message-ID: <20130821121605.108375@eggemoggin.niobe.net>

2013/8/21 4:33 -0700, mike.duigou at oracle.com:
> Hearing significant consensus to remove rather than deprecate these
> two classes I am revising this proposal remove rather than
> deprecate. The revised webrev (which removes the classes) is here:
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8023395/1/webrev/

Looks good to me!

- Mark


From henry.jen at oracle.com  Wed Aug 21 20:14:41 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Wed, 21 Aug 2013 20:14:41 +0000
Subject: hg: jdk8/tl/jdk: 8016846: Pattern.splitAsStream tests required
Message-ID: <20130821201454.58B7848A5E@hg.openjdk.java.net>

Changeset: 60891d90327f
Author:    henryjen
Date:      2013-08-20 14:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60891d90327f

8016846: Pattern.splitAsStream tests required
Reviewed-by: alanb, psandoz
Contributed-by: Ben Evans 

+ test/java/util/regex/PatternTest.java



From mike.duigou at oracle.com  Wed Aug 21 19:49:20 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 21 Aug 2013 19:49:20 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130821194944.A99FD48A5B@hg.openjdk.java.net>

Changeset: fad3b6673159
Author:    mduigou
Date:      2013-08-21 12:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fad3b6673159

8023306: Add replace() implementations to TreeMap
Reviewed-by: psandoz, alanb, chegar, bpb

! src/share/classes/java/util/TreeMap.java

Changeset: 91a31c77be5b
Author:    mduigou
Date:      2013-08-21 12:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/91a31c77be5b

8023395: Remove sun.misc.Sort and sun.misc.Compare
Reviewed-by: alanb, smarks, darcy, mr

- src/share/classes/sun/misc/Compare.java
- src/share/classes/sun/misc/Sort.java



From dan.xu at oracle.com  Wed Aug 21 21:06:14 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Wed, 21 Aug 2013 14:06:14 -0700
Subject: RFR: JDK-8023430 - Replace File.mkdirs with
	Files.createDirectories to get MaxPathLength.java failure details
In-Reply-To: <52145BB4.3080202@oracle.com>
References: <52140416.1060309@oracle.com> <52145BB4.3080202@oracle.com>
Message-ID: <52152BC6.8020609@oracle.com>


On 08/20/2013 11:18 PM, Alan Bateman wrote:
> On 21/08/2013 01:04, Dan Xu wrote:
>> Hi,
>>
>> MaxPathLength.java testcase failed intermittently. And File.mkdirs() 
>> does not throw any exceptions when it fails, which makes it even 
>> harder for the diagnosis. As Alan suggested, I'd like to change it to 
>> Files.createDirectories to get detailed exceptions once a failure 
>> happens. Thanks!
>>
>> webrev: http://cr.openjdk.java.net/~dxu/8023430/webrev/
>> bug: http://bugs.sun.com/view_bug.do?bug_id=8023430
> I think this is the right thing to do to find out what is going on. 
> With the patch then you can remove couldMakeTestDirectory as the 
> exists check and throwing the exception is no longer needed.
>
> -Alan.

Thanks, Alan. I have updated my webrev at, 
http://cr.openjdk.java.net/~dxu/8023430/webrev.01/. Please take a look!

-Dan


From jonathan.gibbons at oracle.com  Wed Aug 21 23:14:14 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 21 Aug 2013 23:14:14 +0000
Subject: hg: jdk8/tl/langtools: 8023515: import type-annotations updates
Message-ID: <20130821231417.A145A48A61@hg.openjdk.java.net>

Changeset: 7de231613e4a
Author:    jjg
Date:      2013-08-21 16:13 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7de231613e4a

8023515: import type-annotations updates
Reviewed-by: jjg
Contributed-by: wdietl at gmail.com

! src/share/classes/com/sun/source/tree/MethodTree.java
! src/share/classes/com/sun/source/tree/TypeParameterTree.java
! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java
+ test/tools/javac/annotations/typeAnnotations/failures/DummyProcessor.java
+ test/tools/javac/annotations/typeAnnotations/failures/T8020715.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java
+ test/tools/javac/tree/TypeAnnotationsPretty.java



From henry.jen at oracle.com  Wed Aug 21 23:19:11 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 21 Aug 2013 16:19:11 -0700
Subject: RFR(2nd): 8023275: Wrapping collections should override default
	methods
In-Reply-To: <03DB347B-7A9A-4150-8251-0C36FE317806@oracle.com>
References: <52126F7B.60602@oracle.com>
	<03DB347B-7A9A-4150-8251-0C36FE317806@oracle.com>
Message-ID: <52154AEF.3040507@oracle.com>

On 08/20/2013 02:21 AM, Paul Sandoz wrote:
> [resending unsigned, sorry if a dup arrives later on]
> 
> On Aug 19, 2013, at 9:18 PM, Henry Jen  wrote:
> 
>> Hi,
>>
>> Please review the webrev at
>> http://cr.openjdk.java.net/~henryjen/tl/8023275/0/webrev/
>>
>> The patch adds override on default methods for a couple wrapping classed
>> and delegate those to underlying class.
>>
>> There is a minor revise on synchronizedCollection javadoc to cover Stream.
>>
> 
> Looks good.
> 
> 
>> A sanity check on wrapper classes to ensure default methods are override.
>>
> 
> You might want to additionally use an ArrayList instance for unmodifiableList/synchronizedList/checkedList, so as to check both unmod list impls:
> 
>    public static  List unmodifiableList(List list) {
>        return (list instanceof RandomAccess ?
>                new UnmodifiableRandomAccessList<>(list) :
>                new UnmodifiableList<>(list));
>    }
> 

Good point, I also added Navigable into the test.

http://cr.openjdk.java.net/~henryjen/tl/8023275/2/webrev/

Cheers,
Henry





From brian.burkhalter at oracle.com  Wed Aug 21 23:37:52 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 21 Aug 2013 16:37:52 -0700
Subject: JDK 8 RFC 6470700: Math.random() / Math.initRNG() uses "double
	checked locking"
Message-ID: <022F8725-278E-44AF-B26A-779E089E33CC@oracle.com>

With respect to this issue

http://bugs.sun.com/view_bug.do?bug_id=6470700

the code of concern from java.lang.Math is

701    private static Random randomNumberGenerator;
702
703    private static synchronized Random initRNG() {
704        Random rnd = randomNumberGenerator;
705        return (rnd == null) ? (randomNumberGenerator = new Random()) : rnd;
706     }

731    public static double random() {
732        Random rnd = randomNumberGenerator;
733        if (rnd == null) rnd = initRNG();
734        return rnd.nextDouble();
735    }

where the class variable "randomNumberGenerator" is not used anywhere else in the class. The complaint is that this is an instance of the broken double-checked locking pattern. While at first glance this might appear to be the case, it does not seem so to me. It looks more like an attempt to avoid calling a synchronized method if "randomNumberGenerator" has already been initialized.

A more typical pattern would be

    private static Random randomNumberGenerator;

    private static synchronized Random getRNG() {
        if (randomNumberGenerator == null) {
            randomNumberGenerator = new Random();
        }
        return randomNumberGenerator;
    }

    public static double random() {
        return getRNG().nextDouble();
    }

Comments, please.

Thanks,

Brian

From david.lloyd at redhat.com  Thu Aug 22 00:01:27 2013
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 21 Aug 2013 18:01:27 -0600
Subject: JDK 8 RFC 6470700: Math.random() / Math.initRNG() uses "double
	checked locking"
In-Reply-To: <022F8725-278E-44AF-B26A-779E089E33CC@oracle.com>
References: <022F8725-278E-44AF-B26A-779E089E33CC@oracle.com>
Message-ID: <521554D7.5090200@redhat.com>

On 8/21/13 5:37 PM, Brian Burkhalter wrote:
> With respect to this issue
>
> http://bugs.sun.com/view_bug.do?bug_id=6470700
>
> the code of concern from java.lang.Math is
>
> 701    private static Random randomNumberGenerator;
> 702
> 703    private static synchronized Random initRNG() {
> 704        Random rnd = randomNumberGenerator;
> 705        return (rnd == null) ? (randomNumberGenerator = new Random()) : rnd;
> 706     }
>
> 731    public static double random() {
> 732        Random rnd = randomNumberGenerator;
> 733        if (rnd == null) rnd = initRNG();
> 734        return rnd.nextDouble();
> 735    }
>
> where the class variable "randomNumberGenerator" is not used anywhere else in the class. The complaint is that this is an instance of the broken double-checked locking pattern. While at first glance this might appear to be the case, it does not seem so to me. It looks more like an attempt to avoid calling a synchronized method if "randomNumberGenerator" has already been initialized.
>
> A more typical pattern would be
>
>      private static Random randomNumberGenerator;
>
>      private static synchronized Random getRNG() {
>          if (randomNumberGenerator == null) {
>              randomNumberGenerator = new Random();
>          }
>          return randomNumberGenerator;
>      }
>
>      public static double random() {
>          return getRNG().nextDouble();
>      }
>
> Comments, please.

I don't think you'd want to introduce the overhead of synchronization 
here.  It may be better in this case to use this kind of lazy init pattern:

     static final class Holder {
         static final Random RNG = new Random();
     }

     public static double random() {
         return Holder.RNG.nextDouble();
     }

-- 
- DML


From brian.burkhalter at oracle.com  Thu Aug 22 00:24:38 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 21 Aug 2013 17:24:38 -0700
Subject: JDK 8 RFC 6470700: Math.random() / Math.initRNG() uses "double
	checked locking"
In-Reply-To: <521554D7.5090200@redhat.com>
References: <022F8725-278E-44AF-B26A-779E089E33CC@oracle.com>
	<521554D7.5090200@redhat.com>
Message-ID: <40241882-FA33-4178-B477-1C863BD4DBD0@oracle.com>

On Aug 21, 2013, at 5:01 PM, David M. Lloyd wrote:

> I don't think you'd want to introduce the overhead of synchronization here.

No, I don't. My example code was just that.

> It may be better in this case to use this kind of lazy init pattern:
> 
>    static final class Holder {
>        static final Random RNG = new Random();
>    }
> 
>    public static double random() {
>        return Holder.RNG.nextDouble();
>    }

Thanks for the cleaner suggestion.

Brian

From eric.mccorkle at oracle.com  Thu Aug 22 00:24:04 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Thu, 22 Aug 2013 00:24:04 +0000
Subject: hg: jdk8/tl/langtools: 7118412: Shadowing of type-variables vs.
	member types; ...
Message-ID: <20130822002407.9A65248A64@hg.openjdk.java.net>

Changeset: 2068190f8ac2
Author:    emc
Date:      2013-08-21 20:23 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2068190f8ac2

7118412: Shadowing of type-variables vs. member types
4987840: What is the scope of an annotation?
Summary: Fixed issue with shadowing of type names.
Reviewed-by: jjg, abuckley, mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Resolve.java



From jonathan.gibbons at oracle.com  Thu Aug 22 00:29:36 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 22 Aug 2013 00:29:36 +0000
Subject: hg: jdk8/tl/langtools: 8022287: javac.sym.Profiles uses a static Map
	when it should not
Message-ID: <20130822002939.8336848A65@hg.openjdk.java.net>

Changeset: 57e1266527dd
Author:    jjg
Date:      2013-08-21 17:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/57e1266527dd

8022287: javac.sym.Profiles uses a static Map when it should not
Reviewed-by: ksrini

! src/share/classes/com/sun/tools/javac/sym/Profiles.java
+ test/tools/javac/profiles/ProfileTest.java



From stevenschlansker at gmail.com  Thu Aug 22 00:35:51 2013
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Wed, 21 Aug 2013 17:35:51 -0700
Subject: JDK 8 RFC 6470700: Math.random() / Math.initRNG() uses "double
	checked locking"
In-Reply-To: <022F8725-278E-44AF-B26A-779E089E33CC@oracle.com>
References: <022F8725-278E-44AF-B26A-779E089E33CC@oracle.com>
Message-ID: <5BD48E3E-16ED-4761-9282-053E970195C7@gmail.com>


On Aug 21, 2013, at 4:37 PM, Brian Burkhalter  wrote:

> With respect to this issue
> 
> http://bugs.sun.com/view_bug.do?bug_id=6470700
> 
> the code of concern from java.lang.Math is
> 
> 701    private static Random randomNumberGenerator;
> 702
> 703    private static synchronized Random initRNG() {
> 704        Random rnd = randomNumberGenerator;
> 705        return (rnd == null) ? (randomNumberGenerator = new Random()) : rnd;
> 706     }
> 
> 731    public static double random() {
> 732        Random rnd = randomNumberGenerator;
> 733        if (rnd == null) rnd = initRNG();
> 734        return rnd.nextDouble();
> 735    }
> 
> where the class variable "randomNumberGenerator" is not used anywhere else in the class. The complaint is that this is an instance of the broken double-checked locking pattern. While at first glance this might appear to be the case, it does not seem so to me. It looks more like an attempt to avoid calling a synchronized method if "randomNumberGenerator" has already been initialized.


This looks very much like the "Broken multithreaded version" from
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

// Broken multithreaded version
// "Double-Checked Locking" idiom
class Foo { 
  private Helper helper = null;
  public Helper getHelper() {
    if (helper == null) 
      synchronized(this) {
        if (helper == null) 
          helper = new Helper();
      }    
    return helper;
    }
  // other functions and members...
  }


"Unfortunately, that code just does not work in the presence of either optimizing compilers or shared memory multiprocessors."



From eric.mccorkle at oracle.com  Thu Aug 22 00:43:27 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Thu, 22 Aug 2013 00:43:27 +0000
Subject: hg: jdk8/tl/langtools: 8023520: Add missing test for JDK-7118412
Message-ID: <20130822004330.6C49548A66@hg.openjdk.java.net>

Changeset: eebb29618f50
Author:    emc
Date:      2013-08-21 20:41 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/eebb29618f50

8023520: Add missing test for JDK-7118412
Summary: The test for JDK-7118412 was dropped from the changeset in a merging accident.
Reviewed-by: jjg

+ test/tools/javac/7118412/ShadowingTest.java



From vitalyd at gmail.com  Thu Aug 22 00:46:37 2013
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 21 Aug 2013 20:46:37 -0400
Subject: JDK 8 RFC 6470700: Math.random() / Math.initRNG() uses "double
	checked locking"
In-Reply-To: <5BD48E3E-16ED-4761-9282-053E970195C7@gmail.com>
References: <022F8725-278E-44AF-B26A-779E089E33CC@oracle.com>
	<5BD48E3E-16ED-4761-9282-053E970195C7@gmail.com>
Message-ID: 

There's a significant difference here: Random reads the field into a local
and then operates only on the local.  Looking at the code, I only see one
possible (bizarre) circumstance where you can hit NPE.  If code was
transformed to:

static double random() {
      Random rnd = randomNumberGenerator; // assume null is read
      if (randomNumberGenerator == null) ... // note the field is re-read
instead of local, and assume it's not null now
     return rnd.nextDouble(); // NPE
}

I don't see a case where any sane compiler would do this but I think it's
legal transformation given that the field is non-volatile and single
threaded execution would not detect difference.  Unless phantom reads
cannot be introduced even for plain fields, in which case I don't see how
NPE can occur.

Having said that, David's suggestion is cleaner anyway.

Sent from my phone
On Aug 21, 2013 8:36 PM, "Steven Schlansker" 
wrote:

>
> On Aug 21, 2013, at 4:37 PM, Brian Burkhalter 
> wrote:
>
> > With respect to this issue
> >
> > http://bugs.sun.com/view_bug.do?bug_id=6470700
> >
> > the code of concern from java.lang.Math is
> >
> > 701    private static Random randomNumberGenerator;
> > 702
> > 703    private static synchronized Random initRNG() {
> > 704        Random rnd = randomNumberGenerator;
> > 705        return (rnd == null) ? (randomNumberGenerator = new Random())
> : rnd;
> > 706     }
> >
> > 731    public static double random() {
> > 732        Random rnd = randomNumberGenerator;
> > 733        if (rnd == null) rnd = initRNG();
> > 734        return rnd.nextDouble();
> > 735    }
> >
> > where the class variable "randomNumberGenerator" is not used anywhere
> else in the class. The complaint is that this is an instance of the broken
> double-checked locking pattern. While at first glance this might appear to
> be the case, it does not seem so to me. It looks more like an attempt to
> avoid calling a synchronized method if "randomNumberGenerator" has already
> been initialized.
>
>
> This looks very much like the "Broken multithreaded version" from
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
>
> // Broken multithreaded version
> // "Double-Checked Locking" idiom
> class Foo {
>   private Helper helper = null;
>   public Helper getHelper() {
>     if (helper == null)
>       synchronized(this) {
>         if (helper == null)
>           helper = new Helper();
>       }
>     return helper;
>     }
>   // other functions and members...
>   }
>
>
> "Unfortunately, that code just does not work in the presence of either
> optimizing compilers or shared memory multiprocessors."
>
>


From stuart.marks at oracle.com  Thu Aug 22 00:58:31 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 21 Aug 2013 17:58:31 -0700
Subject: RFR: 8022445: fix RMISocketFactory example to avoid using localhost
Message-ID: <52156237.5070605@oracle.com>

Hi all,

Please review this small documentation change to the example I added to 
RMISocketFactory a couple weeks ago [1]. This change fixes a problem 
that Bernd Eckenfels pointed out [2] where the interface returned by 
getLoopbackAddress() might not match the interface that "localhost" 
resolves to.

Patch appended below.

Thanks,

s'marks

[1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31759750ff63

[2] 
http://mail.openjdk.java.net/pipermail/security-dev/2013-August/008346.html



# HG changeset patch
# User smarks
# Date 1377131500 25200
# Node ID fac7907d8c0b4358b9994b04562b722f533db3ac
# Parent  1ccc7bbee0bb4d4d0f472374f2cc544cb07d1336
8022445: fix RMISocketFactory example to avoid using localhost
Reviewed-by: XXX

diff -r 1ccc7bbee0bb -r fac7907d8c0b 
src/share/classes/java/rmi/server/RMISocketFactory.java
--- a/src/share/classes/java/rmi/server/RMISocketFactory.java	Tue Aug 20 
11:15:08 2013 +0200
+++ b/src/share/classes/java/rmi/server/RMISocketFactory.java	Wed Aug 21 
17:31:40 2013 -0700
@@ -50,13 +50,13 @@
   * @implNote
   * 
You can use the {@code RMISocketFactory} class to create a 
server socket that
   * is bound to a specific address, restricting the origin of requests. 
For example,
- * the following code implements a socket factory that binds server 
sockets to the
+ * the following code implements a socket factory that binds server 
sockets to the IPv6
   * loopback address. This restricts RMI to processing requests only 
from the local host.
   *
   * 
{@code
   *     class LoopbackSocketFactory extends RMISocketFactory {
   *         public ServerSocket createServerSocket(int port) throws 
IOException {
- *             return new ServerSocket(port, 5, 
InetAddress.getLoopbackAddress());
+ *             return new ServerSocket(port, 5, 
InetAddress.getByName("::1"));
   *         }
   *
   *         public Socket createSocket(String host, int port) throws 
IOException {
@@ -72,8 +72,8 @@
   * }

   *
   * Set the {@code java.rmi.server.hostname} system property
- * to a host name (typically {@code localhost}) that resolves to the 
loopback
- * interface to ensure that the generated stubs use the right network 
interface.
+ * to {@code ::1} to ensure that the generated stubs connect to the right
+ * network interface.
   *
   * @author  Ann Wollrath
   * @author  Peter Jones


From mike.duigou at oracle.com  Thu Aug 22 02:23:17 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 21 Aug 2013 19:23:17 -0700
Subject: JDK 8 RFC 6470700: Math.random() / Math.initRNG() uses "double
	checked locking"
In-Reply-To: <521554D7.5090200@redhat.com>
References: <022F8725-278E-44AF-B26A-779E089E33CC@oracle.com>
	<521554D7.5090200@redhat.com>
Message-ID: <65BC83F4-F020-4001-A288-26C09958999B@oracle.com>

On Aug 21 2013, at 17:01 , David M. Lloyd wrote:

> On 8/21/13 5:37 PM, Brian Burkhalter wrote:
>> With respect to this issue
>> 
>> http://bugs.sun.com/view_bug.do?bug_id=6470700
>> 
>> the code of concern from java.lang.Math is
>> 
>> 701    private static Random randomNumberGenerator;
>> 702
>> 703    private static synchronized Random initRNG() {
>> 704        Random rnd = randomNumberGenerator;
>> 705        return (rnd == null) ? (randomNumberGenerator = new Random()) : rnd;
>> 706     }
>> 
>> 731    public static double random() {
>> 732        Random rnd = randomNumberGenerator;
>> 733        if (rnd == null) rnd = initRNG();
>> 734        return rnd.nextDouble();
>> 735    }
>> 
>> where the class variable "randomNumberGenerator" is not used anywhere else in the class. The complaint is that this is an instance of the broken double-checked locking pattern. While at first glance this might appear to be the case, it does not seem so to me. It looks more like an attempt to avoid calling a synchronized method if "randomNumberGenerator" has already been initialized.
>> 
>> A more typical pattern would be
>> 
>>     private static Random randomNumberGenerator;
>> 
>>     private static synchronized Random getRNG() {
>>         if (randomNumberGenerator == null) {
>>             randomNumberGenerator = new Random();
>>         }
>>         return randomNumberGenerator;
>>     }
>> 
>>     public static double random() {
>>         return getRNG().nextDouble();
>>     }
>> 
>> Comments, please.
> 
> I don't think you'd want to introduce the overhead of synchronization here.  It may be better in this case to use this kind of lazy init pattern:
> 
>    static final class Holder {
>        static final Random RNG = new Random();
>    }
> 
>    public static double random() {
>        return Holder.RNG.nextDouble();
>    }
> 
> -- 
> - DML


David's suggestion seems very reasonable.


Mike

From xuelei.fan at oracle.com  Thu Aug 22 02:46:51 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Thu, 22 Aug 2013 02:46:51 +0000
Subject: hg: jdk8/tl/jdk: 8022228: Intermittent test failures in
	sun/security/ssl/javax/net/ssl/NewAPIs
Message-ID: <20130822024717.B922548A76@hg.openjdk.java.net>

Changeset: ec827a62070a
Author:    xuelei
Date:      2013-08-21 19:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ec827a62070a

8022228: Intermittent test failures in sun/security/ssl/javax/net/ssl/NewAPIs
Reviewed-by: weijun

! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java
! test/sun/security/ssl/templates/SSLSocketTemplate.java



From staffan.larsen at oracle.com  Thu Aug 22 06:29:14 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Thu, 22 Aug 2013 06:29:14 +0000
Subject: hg: jdk8/tl/jdk: 8023101:
	java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails
Message-ID: <20130822062937.A47CB48A7B@hg.openjdk.java.net>

Changeset: a0896634ab46
Author:    sla
Date:      2013-08-22 08:28 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a0896634ab46

8023101: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails
Reviewed-by: ysr

! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java



From Alan.Bateman at oracle.com  Thu Aug 22 07:13:50 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 22 Aug 2013 08:13:50 +0100
Subject: RFR: JDK-8023430 - Replace File.mkdirs with
	Files.createDirectories to get MaxPathLength.java failure details
In-Reply-To: <52152BC6.8020609@oracle.com>
References: <52140416.1060309@oracle.com> <52145BB4.3080202@oracle.com>
	<52152BC6.8020609@oracle.com>
Message-ID: <5215BA2E.7040103@oracle.com>

On 21/08/2013 22:06, Dan Xu wrote:
> :
>
> Thanks, Alan. I have updated my webrev at, 
> http://cr.openjdk.java.net/~dxu/8023430/webrev.01/. Please take a look!
This looks okay now.

-Alan


From chris.hegarty at oracle.com  Thu Aug 22 08:41:40 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 22 Aug 2013 09:41:40 +0100
Subject: RFR: 8022445: fix RMISocketFactory example to avoid using
	localhost
In-Reply-To: <52156237.5070605@oracle.com>
References: <52156237.5070605@oracle.com>
Message-ID: <5215CEC4.2060107@oracle.com>

Stuart,

I think I would have picked the more common IPv4 loopback address, 
127.0.0.1, but what you have is fine.

-Chris.

On 08/22/2013 01:58 AM, Stuart Marks wrote:
> Hi all,
>
> Please review this small documentation change to the example I added to
> RMISocketFactory a couple weeks ago [1]. This change fixes a problem
> that Bernd Eckenfels pointed out [2] where the interface returned by
> getLoopbackAddress() might not match the interface that "localhost"
> resolves to.
>
> Patch appended below.
>
> Thanks,
>
> s'marks
>
> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31759750ff63
>
> [2]
> http://mail.openjdk.java.net/pipermail/security-dev/2013-August/008346.html
>
>
>
> # HG changeset patch
> # User smarks
> # Date 1377131500 25200
> # Node ID fac7907d8c0b4358b9994b04562b722f533db3ac
> # Parent  1ccc7bbee0bb4d4d0f472374f2cc544cb07d1336
> 8022445: fix RMISocketFactory example to avoid using localhost
> Reviewed-by: XXX
>
> diff -r 1ccc7bbee0bb -r fac7907d8c0b
> src/share/classes/java/rmi/server/RMISocketFactory.java
> --- a/src/share/classes/java/rmi/server/RMISocketFactory.java    Tue Aug
> 20 11:15:08 2013 +0200
> +++ b/src/share/classes/java/rmi/server/RMISocketFactory.java    Wed Aug
> 21 17:31:40 2013 -0700
> @@ -50,13 +50,13 @@
>    * @implNote
>    * 
You can use the {@code RMISocketFactory} class to create a
> server socket that
>    * is bound to a specific address, restricting the origin of requests.
> For example,
> - * the following code implements a socket factory that binds server
> sockets to the
> + * the following code implements a socket factory that binds server
> sockets to the IPv6
>    * loopback address. This restricts RMI to processing requests only
> from the local host.
>    *
>    * 
{@code
>    *     class LoopbackSocketFactory extends RMISocketFactory {
>    *         public ServerSocket createServerSocket(int port) throws
> IOException {
> - *             return new ServerSocket(port, 5,
> InetAddress.getLoopbackAddress());
> + *             return new ServerSocket(port, 5,
> InetAddress.getByName("::1"));
>    *         }
>    *
>    *         public Socket createSocket(String host, int port) throws
> IOException {
> @@ -72,8 +72,8 @@
>    * }

>    *
>    * Set the {@code java.rmi.server.hostname} system property
> - * to a host name (typically {@code localhost}) that resolves to the
> loopback
> - * interface to ensure that the generated stubs use the right network
> interface.
> + * to {@code ::1} to ensure that the generated stubs connect to the right
> + * network interface.
>    *
>    * @author  Ann Wollrath
>    * @author  Peter Jones


From Alan.Bateman at oracle.com  Thu Aug 22 08:54:29 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 22 Aug 2013 09:54:29 +0100
Subject: RFR: 8022445: fix RMISocketFactory example to avoid using
	localhost
In-Reply-To: <52156237.5070605@oracle.com>
References: <52156237.5070605@oracle.com>
Message-ID: <5215D1C5.6000906@oracle.com>

On 22/08/2013 01:58, Stuart Marks wrote:
> Hi all,
>
> Please review this small documentation change to the example I added 
> to RMISocketFactory a couple weeks ago [1]. This change fixes a 
> problem that Bernd Eckenfels pointed out [2] where the interface 
> returned by getLoopbackAddress() might not match the interface that 
> "localhost" resolves to.
We don't have support for IPv4-only or IPv6-only listeners (at least not 
with stream oriented sockets, there is support for protocol specific 
datagram sockets but that doesn't apply here). So I'm curious about the 
original comments and whether there are configurations or loopback 
address plumbing where getLoopbackAddress doesn't do the right thing?

-Alan


From vicente.romero at oracle.com  Thu Aug 22 09:23:48 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Thu, 22 Aug 2013 09:23:48 +0000
Subject: hg: jdk8/tl/langtools: 8022316: Generic throws,
	overriding and method reference
Message-ID: <20130822092359.E724B48A80@hg.openjdk.java.net>

Changeset: 7a4717f3ea7b
Author:    vromero
Date:      2013-08-22 10:22 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7a4717f3ea7b

8022316: Generic throws, overriding and method reference
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/T8022316/CompilerErrorGenericThrowPlusMethodRefTest.java
+ test/tools/javac/T8022316/CompilerErrorGenericThrowPlusMethodRefTest.out



From david.holmes at oracle.com  Thu Aug 22 11:32:24 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 22 Aug 2013 21:32:24 +1000
Subject: RFR: Remove tests from ProblemList.txt
In-Reply-To: <8A0D2A91-6ABB-4CC3-BABA-EFE8ACDFC3BA@oracle.com>
References: <8A0D2A91-6ABB-4CC3-BABA-EFE8ACDFC3BA@oracle.com>
Message-ID: <5215F6C8.6080809@oracle.com>

On 22/08/2013 12:20 AM, Staffan Larsen wrote:
> I've had a look at these two old bugs:
>    http://bugs.sun.com/view_bug.do?bug_id=7020857
>    http://bugs.sun.com/view_bug.do?bug_id=6909804
>
> They are both listed in ProblemList.txt and reported as intermittent failures in 2011 and 2009 respectively.
>
> I've been searching our test history for instances of these failures, but cannot find anything for the last year (didn't look further back). I can see that the tests have been running and I can see other failures in the tests (environment issues mostly) but not the failures reported in the bugs.

How have they been running if they are in the ProblemList ???

David

> I have been doing reruns on linux x86-64 and window x86-64. 1000 iterations did not reproduce the problems.
>
> I would thus like to close the bugs and remove the tests from ProblemList.txt. Below is the proposed diff.
>
> Thanks,
> /Staffan
>
>
>
> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
> --- a/test/ProblemList.txt
> +++ b/test/ProblemList.txt
> @@ -336,12 +336,6 @@
>   # Filed 6653793
>   com/sun/jdi/RedefineCrossEvent.java                             generic-all
>
> -# Filed 6987312
> -com/sun/jdi/DoubleAgentTest.java                                generic-all
> -
> -# Filed 7020857
> -com/sun/jdi/FieldWatchpoints.java                               generic-all
> -
>   # Filed 6402201
>   com/sun/jdi/ProcessAttachTest.sh                                generic-all
>


From staffan.larsen at oracle.com  Thu Aug 22 11:47:10 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 22 Aug 2013 13:47:10 +0200
Subject: RFR: Remove tests from ProblemList.txt
In-Reply-To: <5215F6C8.6080809@oracle.com>
References: <8A0D2A91-6ABB-4CC3-BABA-EFE8ACDFC3BA@oracle.com>
	<5215F6C8.6080809@oracle.com>
Message-ID: <71B35F5F-E9BB-4C4D-988E-63916C097DC9@oracle.com>


On 22 aug 2013, at 13:32, David Holmes  wrote:

> On 22/08/2013 12:20 AM, Staffan Larsen wrote:
>> I've had a look at these two old bugs:
>>   http://bugs.sun.com/view_bug.do?bug_id=7020857
>>   http://bugs.sun.com/view_bug.do?bug_id=6909804
>> 
>> They are both listed in ProblemList.txt and reported as intermittent failures in 2011 and 2009 respectively.
>> 
>> I've been searching our test history for instances of these failures, but cannot find anything for the last year (didn't look further back). I can see that the tests have been running and I can see other failures in the tests (environment issues mostly) but not the failures reported in the bugs.
> 
> How have they been running if they are in the ProblemList ???

Good question and I wish I understood. From aurora history it looks like some promotion testing runs still included the tests.

/Staffan



From paul.sandoz at oracle.com  Thu Aug 22 12:01:21 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 22 Aug 2013 14:01:21 +0200
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets
	or trees (red/black)
In-Reply-To: 
References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
	
	
Message-ID: 

On Aug 21, 2013, at 6:47 PM, Paul Sandoz  wrote:
> I updated the webrev and replaced TreeBinSplitBackToEntries.java with:
> 
>  http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/test/java/util/Map/MapBinToFromTreeTest.java.html
> 

Another tweak to ensure untreeify is tested on resize (use the same URL above). I think at this point the tests are in reasonable shape and are on a par with previous tests.

Paul.


From vicente.romero at oracle.com  Thu Aug 22 12:13:31 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Thu, 22 Aug 2013 12:13:31 +0000
Subject: hg: jdk8/tl/langtools: 8023112: javac should not use lazy constant
	evaluation approach for method references
Message-ID: <20130822121336.74ABE48A86@hg.openjdk.java.net>

Changeset: 25aaff78d754
Author:    vromero
Date:      2013-08-22 13:12 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/25aaff78d754

8023112: javac should not use lazy constant evaluation approach for method references
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
+ test/tools/javac/T8023112/SkipLazyConstantCreationForMethodRefTest.java



From daniel.daugherty at oracle.com  Thu Aug 22 13:02:19 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 22 Aug 2013 07:02:19 -0600
Subject: RFR: Remove tests from ProblemList.txt
In-Reply-To: <5215F6C8.6080809@oracle.com>
References: <8A0D2A91-6ABB-4CC3-BABA-EFE8ACDFC3BA@oracle.com>
	<5215F6C8.6080809@oracle.com>
Message-ID: <52160BDB.2080205@oracle.com>


On 8/22/13 5:32 AM, David Holmes wrote:
> On 22/08/2013 12:20 AM, Staffan Larsen wrote:
>> I've had a look at these two old bugs:
>>    http://bugs.sun.com/view_bug.do?bug_id=7020857
>>    http://bugs.sun.com/view_bug.do?bug_id=6909804
>>
>> They are both listed in ProblemList.txt and reported as intermittent 
>> failures in 2011 and 2009 respectively.
>>
>> I've been searching our test history for instances of these failures, 
>> but cannot find anything for the last year (didn't look further 
>> back). I can see that the tests have been running and I can see other 
>> failures in the tests (environment issues mostly) but not the 
>> failures reported in the bugs.
>
> How have they been running if they are in the ProblemList ???

VM/SQE nightly doesn't use the ProblemList.

Dan


>
> David
>
>> I have been doing reruns on linux x86-64 and window x86-64. 1000 
>> iterations did not reproduce the problems.
>>
>> I would thus like to close the bugs and remove the tests from 
>> ProblemList.txt. Below is the proposed diff.
>>
>> Thanks,
>> /Staffan
>>
>>
>>
>> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
>> --- a/test/ProblemList.txt
>> +++ b/test/ProblemList.txt
>> @@ -336,12 +336,6 @@
>>   # Filed 6653793
>> com/sun/jdi/RedefineCrossEvent.java generic-all
>>
>> -# Filed 6987312
>> -com/sun/jdi/DoubleAgentTest.java generic-all
>> -
>> -# Filed 7020857
>> -com/sun/jdi/FieldWatchpoints.java generic-all
>> -
>>   # Filed 6402201
>> com/sun/jdi/ProcessAttachTest.sh generic-all
>>



From Alan.Bateman at oracle.com  Thu Aug 22 13:32:31 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 22 Aug 2013 14:32:31 +0100
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets
	or trees (red/black)
In-Reply-To: 
References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
	
	
	
Message-ID: <521612EF.7070200@oracle.com>

On 22/08/2013 13:01, Paul Sandoz wrote:
> On Aug 21, 2013, at 6:47 PM, Paul Sandoz  wrote:
>> I updated the webrev and replaced TreeBinSplitBackToEntries.java with:
>>
>>   http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/test/java/util/Map/MapBinToFromTreeTest.java.html
>>
> Another tweak to ensure untreeify is tested on resize (use the same URL above). I think at this point the tests are in reasonable shape and are on a par with previous tests.
>
I skimmed over the test updates and they looks good to me (and more 
checks that the original MapBinToFromTreeTest).

-Alan.




From Alan.Bateman at oracle.com  Thu Aug 22 13:48:29 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 22 Aug 2013 14:48:29 +0100
Subject: RFR: 8022445: fix RMISocketFactory example to avoid using
	localhost
In-Reply-To: <56F5142A-BEFB-481E-8757-731F1DF60613@eckenfels.net>
References: <52156237.5070605@oracle.com> <5215D1C5.6000906@oracle.com>
	<56F5142A-BEFB-481E-8757-731F1DF60613@eckenfels.net>
Message-ID: <521616AD.7070103@oracle.com>

On 22/08/2013 13:48, Bernd Eckenfels wrote:
> getLoopbackAddress is either ::1 or 127.0.0.1 (depending on the stack preferemces) and InetAddress.getByName("localhost") is also one of both (but not necesarily the same, unfortunately). This happened to me in the past, so I wanted to make sure that asumption does not show up in sample code of JavaDocs. Thanks for improving this!
>
You're right, this method is returning a specific address. In that case, 
I think Chris's point about using the familiar (IPv4) is probably the 
way to go when changing this.

-Alan.


From ivan.gerasimov at oracle.com  Thu Aug 22 13:52:30 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 22 Aug 2013 17:52:30 +0400
Subject: RFR [7129312] BufferedInputStream calculates negative array size
	with large streams and mark
In-Reply-To: <52148850.6090401@oracle.com>
References: <520E2541.9020505@oracle.com> <520E541E.1060403@oracle.com>
	<5211F591.6010504@oracle.com> <521392E0.20604@oracle.com>
	<52148850.6090401@oracle.com>
Message-ID: <5216179E.5060708@oracle.com>

Thank you Alan!

Would you please review the updated webrev?
http://cr.openjdk.java.net/~igerasim/7129312/3/webrev/ 


On 21.08.2013 13:28, Alan Bateman wrote:
> On 20/08/2013 17:01, Ivan Gerasimov wrote:
>> Yes, you're right!
>>
>> I've updated the test to be a shell script + Java application.
>> If java reported 'Invalid maximum heap size', the test is skipped.
>>
>> Just check with JPRT, the test passes on both 64 and 32 bit platforms.
>>
>> Would you please review the updated webrev?
>> http://cr.openjdk.java.net/~igerasim/7129312/2/webrev/ 
>> 
> The updated change to BufferedInputStream looks good.
>
> On the test then I agree with the approach to skip on 32-bit but I 
> think we should avoid introduce more shell tests. Have you looked at 
> jdk.testlibrary.ProcessTools to launch the test after checking that we 
> are 64-bit?
>
That's a good alternative to shell scripting, I like it.

Sincerely yours,
Ivan

> -Alan.
>



From chris.hegarty at oracle.com  Thu Aug 22 14:11:42 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 22 Aug 2013 15:11:42 +0100
Subject: Update jdk8/tl/jaxws to v2.2.9-b14140 ready for review
In-Reply-To: <52133F25.3010201@oracle.com>
References: <520DFBC1.3020207@oracle.com> <520E0259.6070206@oracle.com>
	<52121603.1010401@oracle.com> <52123ADC.1050306@oracle.com>
	<52130B62.3010902@oracle.com> <52133F25.3010201@oracle.com>
Message-ID: <52161C1E.50109@oracle.com>

On 08/20/2013 11:04 AM, Alan Bateman wrote:
> On 20/08/2013 07:23, Miroslav Kos wrote:
>> Hi everybody,
>>
>> I prepared a new changeset containing no copyright changes so we can
>> get further: http://cr.openjdk.java.net/~mkos/8022885/webrev.01/
>>
>> We will discuss rngom changes separately and if necessary, it will be
>> updated with a new integration.
>>
>> Miran
> Thanks for the dropping this, that make things easier. There are still a
> bunch updates to copyright dates in files that don't have other changes,
> they seem harmless and I only assume they have crept in with whatever is
> used to create the source bundle to push to OpenJDK.
>
> Chris - are you going to sponsor this?

Yes, I can sponsor this.

-Chris.

>
> -Alan


From roger.riggs at oracle.com  Thu Aug 22 14:25:13 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 22 Aug 2013 10:25:13 -0400
Subject: Please review fix for 8011944 : Sort fails with
	ArrayIndexOutOfBoundsException
Message-ID: <52161F49.3030001@oracle.com>

Please review the fix for:

   JDK-8011944[1] : Sort fails with ArrayIndexOutOfBoundsException

The pending run stack size is estimated based on the input size.
The worst case sequence of inputs exceeds the current allocation and an 
exception occurs.
Increasing the allocation of the pending run stack addresses the issue.
This was present in the original contribution of Timsort and 
ComparableTimSort.

Webrev[2]:
   http://cr.openjdk.java.net/~rriggs/webrev-timsort-8011944/

Thanks, Roger

[1] http://bugs.sun.com/view_bug.do?bug_id=8011944
[2] http://cr.openjdk.java.net/~rriggs/webrev-timsort-8011944/


From martinrb at google.com  Thu Aug 22 15:10:34 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 22 Aug 2013 08:10:34 -0700
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets
	or trees (red/black)
In-Reply-To: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
Message-ID: 

On Wed, Aug 21, 2013 at 5:25 AM, Paul Sandoz  wrote:

>
> I fixed unchecked warnings in LinkedHashMap, but have not done so for
> HashMap, where there are many more casts from Node to TreeNode. One way to
> solve that is with a static method:
>
>     @SuppressWarnings("unchecked")
>     static  TreeNode asTreeNode(Node n) {
>         return (TreeNode) n;
>     }
>

We've waffled about doing this kind of thing in j.u.c.  Our current jsr166
practice is not to have such helper methods if the number of required
@SuppressWarnings is not too oppressive.  We're willing to pay the
readability cost for core classes.


From martinrb at google.com  Thu Aug 22 15:33:16 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 22 Aug 2013 08:33:16 -0700
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets
	or trees (red/black)
In-Reply-To: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
Message-ID: 

I support the treeification of all the HashMaps.

On Wed, Aug 21, 2013 at 5:25 AM, Paul Sandoz  wrote:

>
> I recommend when this code goes in we look closely at code coverage
> results to see if we are missing areas testing tree functionality and
> update/add new tests accordingly.
>

Testing is indeed a problem. Treeification is only triggered when hash
codes collide AND there are sufficient elements in the map.  All existing
tests for hash collections could be examined to check whether they can be
adapted to additionally test such maps.  But that would be a lot of work.

See test classes containing
        public int hashCode() { return 42; }
in
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/ConcurrentHashMapTest.java?view=co


From joe.darcy at oracle.com  Thu Aug 22 16:41:33 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Thu, 22 Aug 2013 16:41:33 +0000
Subject: hg: jdk8/tl/jdk: 8023587: Fix lone remaining doclint issue in
	java.util.regex
Message-ID: <20130822164212.2D00B48AA0@hg.openjdk.java.net>

Changeset: b7c4094be729
Author:    darcy
Date:      2013-08-22 09:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b7c4094be729

8023587: Fix lone remaining doclint issue in java.util.regex
Reviewed-by: jjg

! src/share/classes/java/util/regex/Pattern.java



From eric.mccorkle at oracle.com  Thu Aug 22 16:49:15 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Thu, 22 Aug 2013 16:49:15 +0000
Subject: hg: jdk8/tl/langtools: 8020745: Suspicious MethodParameters attribute
	generated for local classes capturing local variables
Message-ID: <20130822164921.71E4548AA1@hg.openjdk.java.net>

Changeset: 1ab22e60a738
Author:    emc
Date:      2013-08-22 12:47 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1ab22e60a738

8020745: Suspicious MethodParameters attribute generated for local classes capturing local variables
Summary: Corrected an error in a previous patch that caused captured locals to be added to the beginning, not the end of a parameter list.
Reviewed-by: jjg, mcimadamore, ksrini, abuckley

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
- test/tools/javac/8015701/AnonymousParameters.java
+ test/tools/javac/MethodParameters/CaptureTest.java



From dan.xu at oracle.com  Thu Aug 22 18:43:40 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Thu, 22 Aug 2013 18:43:40 +0000
Subject: hg: jdk8/tl/jdk: 8023430: Replace File.mkdirs with
	Files.createDirectories to get MaxPathLength.java failure details
Message-ID: <20130822184414.54EE348ACC@hg.openjdk.java.net>

Changeset: 8a7d9cc2f41c
Author:    dxu
Date:      2013-08-22 11:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a7d9cc2f41c

8023430: Replace File.mkdirs with Files.createDirectories to get MaxPathLength.java failure details
Reviewed-by: alanb

! test/ProblemList.txt
! test/java/io/File/MaxPathLength.java



From brian.burkhalter at oracle.com  Thu Aug 22 19:41:32 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 22 Aug 2013 12:41:32 -0700
Subject: JDK 8 RFR 6470700: Math.random() / Math.initRNG() uses "double
	checked locking"
In-Reply-To: <65BC83F4-F020-4001-A288-26C09958999B@oracle.com>
References: <022F8725-278E-44AF-B26A-779E089E33CC@oracle.com>
	<521554D7.5090200@redhat.com>
	<65BC83F4-F020-4001-A288-26C09958999B@oracle.com>
Message-ID: <1EC3BE90-2F7D-4B6C-B725-6F3BAC9DE34E@oracle.com>

JDK 8 Reviewers:

The proposed patch is here:

http://cr.openjdk.java.net/~bpb/6470700/

JTREG tests pass and JMH benchmarking shows a very slight performance improvement versus the extant code.

Thanks,

Brian

On Aug 21, 2013, at 7:23 PM, Mike Duigou wrote:

> On Aug 21 2013, at 17:01 , David M. Lloyd wrote:
> 
>> On 8/21/13 5:37 PM, Brian Burkhalter wrote:
>>> With respect to this issue
>>> 
>>> http://bugs.sun.com/view_bug.do?bug_id=6470700
>>> 
>>> the code of concern from java.lang.Math is
>>> 
>>> 701    private static Random randomNumberGenerator;
>>> 702
>>> 703    private static synchronized Random initRNG() {
>>> 704        Random rnd = randomNumberGenerator;
>>> 705        return (rnd == null) ? (randomNumberGenerator = new Random()) : rnd;
>>> 706     }
>>> 
>>> 731    public static double random() {
>>> 732        Random rnd = randomNumberGenerator;
>>> 733        if (rnd == null) rnd = initRNG();
>>> 734        return rnd.nextDouble();
>>> 735    }
>>> 
>>> where the class variable "randomNumberGenerator" is not used anywhere else in the class. The complaint is that this is an instance of the broken double-checked locking pattern. While at first glance this might appear to be the case, it does not seem so to me. It looks more like an attempt to avoid calling a synchronized method if "randomNumberGenerator" has already been initialized.
>>> 
>>> A more typical pattern would be
>>> 
>>>    private static Random randomNumberGenerator;
>>> 
>>>    private static synchronized Random getRNG() {
>>>        if (randomNumberGenerator == null) {
>>>            randomNumberGenerator = new Random();
>>>        }
>>>        return randomNumberGenerator;
>>>    }
>>> 
>>>    public static double random() {
>>>        return getRNG().nextDouble();
>>>    }
>>> 
>>> Comments, please.
>> 
>> I don't think you'd want to introduce the overhead of synchronization here.  It may be better in this case to use this kind of lazy init pattern:
>> 
>>   static final class Holder {
>>       static final Random RNG = new Random();
>>   }
>> 
>>   public static double random() {
>>       return Holder.RNG.nextDouble();
>>   }
>> 
>> -- 
>> - DML
> 
> 
> David's suggestion seems very reasonable.
> 
> 
> Mike



From Alan.Bateman at oracle.com  Thu Aug 22 19:46:38 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 22 Aug 2013 20:46:38 +0100
Subject: JDK 8 RFR 6470700: Math.random() / Math.initRNG() uses "double
	checked locking"
In-Reply-To: <1EC3BE90-2F7D-4B6C-B725-6F3BAC9DE34E@oracle.com>
References: <022F8725-278E-44AF-B26A-779E089E33CC@oracle.com>
	<521554D7.5090200@redhat.com>
	<65BC83F4-F020-4001-A288-26C09958999B@oracle.com>
	<1EC3BE90-2F7D-4B6C-B725-6F3BAC9DE34E@oracle.com>
Message-ID: <52166A9E.3010703@oracle.com>

On 22/08/2013 20:41, Brian Burkhalter wrote:
> JDK 8 Reviewers:
>
> The proposed patch is here:
>
> http://cr.openjdk.java.net/~bpb/6470700/
>
> JTREG tests pass and JMH benchmarking shows a very slight performance improvement versus the extant code.
>
It looks okay to me although the downside of this idiom is yet another 
class (which I assume can private btw).

-Alan


From brian.burkhalter at oracle.com  Thu Aug 22 19:47:51 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 22 Aug 2013 12:47:51 -0700
Subject: JDK 8 RFR 6470700: Math.random() / Math.initRNG() uses "double
	checked locking"
In-Reply-To: <52166A9E.3010703@oracle.com>
References: <022F8725-278E-44AF-B26A-779E089E33CC@oracle.com>
	<521554D7.5090200@redhat.com>
	<65BC83F4-F020-4001-A288-26C09958999B@oracle.com>
	<1EC3BE90-2F7D-4B6C-B725-6F3BAC9DE34E@oracle.com>
	<52166A9E.3010703@oracle.com>
Message-ID: <741E37CE-1BFC-48EC-8E79-8DFBACE66ADF@oracle.com>

You are correct: it should be private - I'll fix that.

Thanks,

Brian

On Aug 22, 2013, at 12:46 PM, Alan Bateman wrote:

> It looks okay to me although the downside of this idiom is yet another class (which I assume can private btw).



From jonathan.gibbons at oracle.com  Thu Aug 22 19:53:39 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 22 Aug 2013 19:53:39 +0000
Subject: hg: jdk8/tl/langtools: 8022173: Relax some warnings in doclint
Message-ID: <20130822195344.ABB5648AD2@hg.openjdk.java.net>

Changeset: b77381d99056
Author:    jjg
Date:      2013-08-22 12:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b77381d99056

8022173: Relax some warnings in doclint
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclint/HtmlTag.java
! test/tools/doclint/html/ListTagsTest.java
! test/tools/doclint/html/OtherTagsTest.java
! test/tools/doclint/html/OtherTagsTest.out
! test/tools/doclint/html/TableTagsTest.java



From chris.hegarty at oracle.com  Thu Aug 22 20:22:10 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 22 Aug 2013 21:22:10 +0100
Subject: JDK 8 RFR 6470700: Math.random() / Math.initRNG() uses "double
	checked locking"
In-Reply-To: <52166A9E.3010703@oracle.com>
References: <022F8725-278E-44AF-B26A-779E089E33CC@oracle.com>
	<521554D7.5090200@redhat.com>
	<65BC83F4-F020-4001-A288-26C09958999B@oracle.com>
	<1EC3BE90-2F7D-4B6C-B725-6F3BAC9DE34E@oracle.com>
	<52166A9E.3010703@oracle.com>
Message-ID: <521672F2.5080008@oracle.com>

On 08/22/2013 08:46 PM, Alan Bateman wrote:
> On 22/08/2013 20:41, Brian Burkhalter wrote:
>> JDK 8 Reviewers:
>>
>> The proposed patch is here:
>>
>> http://cr.openjdk.java.net/~bpb/6470700/
>>
>> JTREG tests pass and JMH benchmarking shows a very slight performance
>> improvement versus the extant code.
>>
> It looks okay to me although the downside of this idiom is yet another
> class (which I assume can private btw).
+1

-Chris.

>
> -Alan


From peter.levart at gmail.com  Thu Aug 22 22:10:50 2013
From: peter.levart at gmail.com (peter.levart at gmail.com)
Date: Thu, 22 Aug 2013 22:10:50 +0000
Subject: hg: jdk8/tl/jdk: 8022721: AnnotationTypeDeadlockTest.java throws
	java.lang.IllegalStateException: unexpected condition
Message-ID: <20130822221116.9EE9548ADC@hg.openjdk.java.net>

Changeset: 2281a7f79738
Author:    plevart
Date:      2013-08-20 14:13 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2281a7f79738

8022721: AnnotationTypeDeadlockTest.java throws java.lang.IllegalStateException: unexpected condition
Reviewed-by: alanb, jfranck

! test/java/lang/annotation/AnnotationType/AnnotationTypeDeadlockTest.java



From stuart.marks at oracle.com  Thu Aug 22 22:51:43 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 22 Aug 2013 15:51:43 -0700
Subject: RFR: 8022445: fix RMISocketFactory example to avoid using
	localhost
In-Reply-To: <521616AD.7070103@oracle.com>
References: <52156237.5070605@oracle.com> <5215D1C5.6000906@oracle.com>
	<56F5142A-BEFB-481E-8757-731F1DF60613@eckenfels.net>
	<521616AD.7070103@oracle.com>
Message-ID: <521695FF.1070908@oracle.com>

On 8/22/13 6:48 AM, Alan Bateman wrote:
> On 22/08/2013 13:48, Bernd Eckenfels wrote:
>> getLoopbackAddress is either ::1 or 127.0.0.1 (depending on the stack
>> preferemces) and InetAddress.getByName("localhost") is also one of
>> both (but not necesarily the same, unfortunately). This happened to me
>> in the past, so I wanted to make sure that asumption does not show up
>> in sample code of JavaDocs. Thanks for improving this!
>>
> You're right, this method is returning a specific address. In that case,
> I think Chris's point about using the familiar (IPv4) is probably the
> way to go when changing this.

Thanks for looking at this.

I had initially used the IPv6 address since it's more forward-looking, 
but after reading the comments and after further reflection I'll change 
it to use an IPv4 loopback address.

s'marks


From stuart.marks at oracle.com  Thu Aug 22 22:53:20 2013
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Thu, 22 Aug 2013 22:53:20 +0000
Subject: hg: jdk8/tl/jdk: 8022445: fix RMISocketFactory example to avoid using
	localhost
Message-ID: <20130822225333.EBC9548ADD@hg.openjdk.java.net>

Changeset: 7496ec8bab76
Author:    smarks
Date:      2013-08-22 15:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7496ec8bab76

8022445: fix RMISocketFactory example to avoid using localhost
Reviewed-by: chegar, alanb

! src/share/classes/java/rmi/server/RMISocketFactory.java



From joe.darcy at oracle.com  Fri Aug 23 00:34:25 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Thu, 22 Aug 2013 17:34:25 -0700
Subject: RFR: 8022343: j.l.Class.getAnnotatedSuperclass() doesn't return
	null in some cases
In-Reply-To: <20130821120405.GE22953@jfranck-desktop.jrpg.bea.com>
References: <20130816121739.GM12405@jfranck-desktop.jrpg.bea.com>
	
	<5212C532.8030905@oracle.com>
	<20130821120405.GE22953@jfranck-desktop.jrpg.bea.com>
Message-ID: <5216AE11.8090705@oracle.com>

Hi Joel,

The new version is better, but for the testing in question I would 
prefer to see something even simpler like:

     public static void main(String[] args) throws Exception {
         int failed = 0;
         Class[] testData = {/* list of class literals*/}
         for (Class toTest: testData) {
             Object res = toTest.getAnnotatedSuperclass();

             if (res != null) {
                 failed++;
                 System.out.println(toTest + ".getAnnotatedSuperclass() 
returns: "
                         + res + ", was non-null");
             }
         }

         if (failed != 0)
             throw new RuntimeException("Test failed, check log for 
details");
     }


-Joe

On 8/21/2013 5:04 AM, Joel Borggr?n-Franck wrote:
> Hi Joe, Paul
>
> I rewrote the test in Paul's style without using testNG.
>
> http://cr.openjdk.java.net/~jfranck/8022343/webrev.01/
>
> Please review.
>
> cheers
> /Joel
>
> On 2013-08-19, Joe Darcy wrote:
>> Hi Joel,
>>
>> I agree the code looks fine.
>>
>> However, I concur with the general sentiment of Paul test advice
>> without advocating using testng for this task.
>>
>> A loop over a Class[] initialized with the kinds of values of
>> interest would seem to be better structured to me and allow for
>> better exception handing, etc.
>>
>> -Joe
>>
>> On 08/19/2013 01:34 AM, Paul Sandoz wrote:
>>> Hi Joel,
>>>
>>> The fix looks OK.
>>>
>>> Not suggesting you do the following, unless you really want to, but the test is an example of where TestNG data providers are useful, since all cases will be tested and reported for pass or failure, rather than in this case the first failure will cause other checks (if any) not to be tested and in addition will not report which check failed (one needs to look at the stack trace).
>>>
>>> Not tested:
>>>
>>>    @DataProvider(name = "class")
>>>    private static Object[][] getClasses() {
>>>        // Using the stream API because i can :-)
>>>        // Arguably simpler in this case to use new Object[][] { {} }
>>>        return Stream.of(
>>>                                  Object.class,
>>>                                  If.class,
>>>                                  Object[].class,
>>>                                  void.class,
>>>                                  int.class).
>>>                map(e -> new Object[] { e }).
>>>                toArray(Object[][]::new);
>>>    }
>>>
>>>    @Test(dataProvider = "class")
>>>    public void testAnnotatedSuperClassIsNull(Class c) {
>>>        assertNull(c.getAnnotatedSuperclass())
>>>    }
>>>
>>> Paul.
>>>
>>> On Aug 16, 2013, at 2:17 PM, Joel Borggren-Franck  wrote:
>>>
>>>> Hi
>>>>
>>>> Please review this small fix for a type annotation reflection issue.
>>>>
>>>> The javadoc spec for Class.getAnnotatedSuperclass says:
>>>>
>>>> * If this Class represents either the Object class, an interface type, an
>>>> * array type, a primitive type, or void, the return value is null.
>>>>
>>>> The patch fixes this.
>>>>
>>>> Webrev at: http://cr.openjdk.java.net/~jfranck/8022343/webrew.00/
>>>>
>>>> Patch also included it at the end of this mail.
>>>>
>>>> cheers
>>>> /Joel
>>>>
>>>>
>>>>
>>>> diff -r b07b19182e40 src/share/classes/java/lang/Class.java
>>>> --- a/src/share/classes/java/lang/Class.java	Thu Aug 15 15:04:59 2013 +0100
>>>> +++ b/src/share/classes/java/lang/Class.java	Fri Aug 16 13:20:31 2013 +0200
>>>> @@ -3338,8 +3338,16 @@
>>>>       * @since 1.8
>>>>       */
>>>>      public AnnotatedType getAnnotatedSuperclass() {
>>>> -         return TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), getConstantPool(), this);
>>>> -}
>>>> +        if(this == Object.class ||
>>>> +                isInterface() ||
>>>> +                isArray() ||
>>>> +                isPrimitive() ||
>>>> +                this == Void.TYPE) {
>>>> +            return null;
>>>> +        }
>>>> +
>>>> +        return TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), getConstantPool(), this);
>>>> +    }
>>>>
>>>>      /**
>>>>       * Returns an array of AnnotatedType objects that represent the use of types to
>>>> diff -r b07b19182e40 test/java/lang/annotation/TypeAnnotationReflection.java
>>>> --- a/test/java/lang/annotation/TypeAnnotationReflection.java	Thu Aug 15 15:04:59 2013 +0100
>>>> +++ b/test/java/lang/annotation/TypeAnnotationReflection.java	Fri Aug 16 13:20:31 2013 +0200
>>>> @@ -23,7 +23,7 @@
>>>>
>>>> /*
>>>>   * @test
>>>> - * @bug 8004698 8007073
>>>> + * @bug 8004698 8007073 8022343
>>>>   * @summary Unit test for type annotations
>>>>   */
>>>>
>>>> @@ -58,7 +58,7 @@
>>>>      }
>>>>
>>>>      private static void testSuper() throws Exception {
>>>> -        check(Object.class.getAnnotatedSuperclass().getAnnotations().length == 0);
>>>> +        check(Object.class.getAnnotatedSuperclass() == null);
>>>>          check(Class.class.getAnnotatedSuperclass().getAnnotations().length == 0);
>>>>
>>>>          AnnotatedType a;
>>>> diff -r b07b19182e40 test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java
>>>> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
>>>> +++ b/test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java	Fri Aug 16 13:20:31 2013 +0200
>>>> @@ -0,0 +1,50 @@
>>>> +/*
>>>> + * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
>>>> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>> + *
>>>> + * This code is free software; you can redistribute it and/or modify it
>>>> + * under the terms of the GNU General Public License version 2 only, as
>>>> + * published by the Free Software Foundation.
>>>> + *
>>>> + * This code is distributed in the hope that it will be useful, but WITHOUT
>>>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>>> + * version 2 for more details (a copy is included in the LICENSE file that
>>>> + * accompanied this code).
>>>> + *
>>>> + * You should have received a copy of the GNU General Public License version
>>>> + * 2 along with this work; if not, write to the Free Software Foundation,
>>>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>> + *
>>>> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>>> + * or visit www.oracle.com if you need additional information or have any
>>>> + * questions.
>>>> + */
>>>> +
>>>> +/*
>>>> + * @test
>>>> + * @bug 8022343
>>>> + * @summary make sure Class.getAnnotatedSuperclass() returns null when specified to do so
>>>> + */
>>>> +
>>>> +import java.util.*;
>>>> +import java.lang.annotation.*;
>>>> +import java.lang.reflect.*;
>>>> +import java.io.Serializable;
>>>> +
>>>> +public class GetAnnotatedSuperclass {
>>>> +    public static void main(String[] args) throws Exception {
>>>> +        check(Object.class.getAnnotatedSuperclass() == null);
>>>> +        check(If.class.getAnnotatedSuperclass() == null);
>>>> +        check(Object[].class.getAnnotatedSuperclass() == null);
>>>> +        check(void.class.getAnnotatedSuperclass() == null);
>>>> +        check(int.class.getAnnotatedSuperclass() == null);
>>>> +    }
>>>> +
>>>> +    private static void check(boolean b) {
>>>> +        if (!b)
>>>> +            throw new RuntimeException();
>>>> +    }
>>>> +    interface If {}
>>>> +}
>>>> +



From ivan.gerasimov at oracle.com  Fri Aug 23 03:07:18 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 23 Aug 2013 07:07:18 +0400
Subject: RFR [8023130] (process) ProcessBuilder#inheritIO does not work on
	Windows
Message-ID: <5216D1E6.2090304@oracle.com>

Hello everybody!

The method ProcessBuilder#inheritIO() is reported to not have any effect 
on Windows platform.
The same story is with redirectOutput/Input/Error(Redirect.INHERIT) methods.
As the result, standard in/out/err aren't inherited.

It turn out that the culprit is the CREATE_NO_WINDOW flag passed to 
CreateProcessW().
MS doc says about this flag: "The process is a console application that 
is being run without a console window."

CREATE_NO_WINDOW flag was added with the fix for 
http://bugs.sun.com/view_bug.do?bug_id=4244515 to suppress a console 
window on a newly created process, when it is created from a program 
launched with javaw.exe.
Thus, I left this flag only for cases when the program doesn't have a 
console associated with it.

Would you please help review a fix for this problem?

BUGURL: http://bugs.sun.com/view_bug.do?bug_id=8023130
WEBREV: http://cr.openjdk.java.net/~igerasim/8023130/0/webrev/

Sincerely yours,
Ivan Gerasimov


From henry.jen at oracle.com  Fri Aug 23 03:21:21 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 22 Aug 2013 20:21:21 -0700
Subject: RFR: 8023528: Rename Comparator combinators to disambiguate
	overloading methods
Message-ID: <5216D531.5060900@oracle.com>

Hi,

Please review a relative simple webrev[1] that basically simply renaming
Comparator methods. The reason behind the renaming can be found at this
email thread[2]. The specdiff is also available here[3].

Cheers,
Henry

[1] http://cr.openjdk.java.net/~henryjen/ccc/8023528/0/webrev/
[2]
http://mail.openjdk.java.net/pipermail/lambda-libs-spec-expert/2013-August/002206.html
[3]
http://cr.openjdk.java.net/~henryjen/ccc/8023528/0/specdiff/overview-summary.html


From stuart.marks at oracle.com  Fri Aug 23 06:00:21 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 22 Aug 2013 23:00:21 -0700
Subject: RFR: 8023528: Rename Comparator combinators to disambiguate
	overloading methods
In-Reply-To: <5216D531.5060900@oracle.com>
References: <5216D531.5060900@oracle.com>
Message-ID: <5216FA75.6040002@oracle.com>

Hi Henry,

Changes look good. It's also good to see some now-extra casts and type 
witnesses removed. It somewhat makes up for the longer, non-overloaded 
method names.

Note, corrected email thread[2] link:

http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-August/002206.html

s'marks

On 8/22/13 8:21 PM, Henry Jen wrote:
> Hi,
>
> Please review a relative simple webrev[1] that basically simply renaming
> Comparator methods. The reason behind the renaming can be found at this
> email thread[2]. The specdiff is also available here[3].
>
> Cheers,
> Henry
>
> [1] http://cr.openjdk.java.net/~henryjen/ccc/8023528/0/webrev/
> [2]
> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-expert/2013-August/002206.html
> [3]
> http://cr.openjdk.java.net/~henryjen/ccc/8023528/0/specdiff/overview-summary.html
>


From staffan.larsen at oracle.com  Fri Aug 23 05:55:36 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Fri, 23 Aug 2013 05:55:36 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130823055615.9B27648AE6@hg.openjdk.java.net>

Changeset: 7b6211cd8d76
Author:    egahlin
Date:      2013-08-21 17:15 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b6211cd8d76

6417649: -interval=0 is accepted and jconsole doesn't update window content at all
Reviewed-by: alanb, jbachorik

! src/share/classes/sun/tools/jconsole/JConsole.java

Changeset: 77a32e5df365
Author:    egahlin
Date:      2013-08-21 17:17 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77a32e5df365

6359971: Threads tab: Simple text to explain that one can click on a thread to get stack trace
Reviewed-by: alanb, jbachorik

! src/share/classes/sun/tools/jconsole/Messages.java
! src/share/classes/sun/tools/jconsole/ThreadTab.java
! src/share/classes/sun/tools/jconsole/resources/messages.properties



From chris.hegarty at oracle.com  Fri Aug 23 09:03:01 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Fri, 23 Aug 2013 09:03:01 +0000
Subject: hg: jdk8/tl/jdk: 6470700: Math.random() / Math.initRNG() uses "double
	checked locking"
Message-ID: <20130823090333.C8F7F48AF2@hg.openjdk.java.net>

Changeset: 223be1d3494f
Author:    bpb
Date:      2013-08-22 13:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/223be1d3494f

6470700: Math.random() / Math.initRNG() uses "double checked locking"
Summary: Replace class Random variable with a static final holder class
Reviewed-by: alanb, mduigou, chegar
Contributed-by: Brian Burkhalter 

! src/share/classes/java/lang/Math.java
! src/share/classes/java/lang/StrictMath.java



From chris.hegarty at oracle.com  Fri Aug 23 08:58:15 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Fri, 23 Aug 2013 08:58:15 +0000
Subject: hg: jdk8/tl/jaxws: 8022885: Update JAX-WS RI integration to
	2.2.9-b14140; ...
Message-ID: <20130823085819.860EF48AF0@hg.openjdk.java.net>

Changeset: b99d7e355d4b
Author:    mkos
Date:      2013-08-23 09:57 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b99d7e355d4b

8022885: Update JAX-WS RI integration to 2.2.9-b14140
8013016: Rebase 8009009 against the latest jdk8/jaxws
Reviewed-by: alanb, chegar

! src/share/jaxws_classes/com/sun/istack/internal/tools/ParallelWorldClassLoader.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/annotations/Probe.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/AverageRangeStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/BoundaryStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/BoundedRangeStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/CountStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/RangeStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/StatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/StringStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/TimeStatisticImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_de.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_es.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_it.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/AttributesImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Classes.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Config.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCEventReceiver.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCEventSource.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCHandler.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCInterleaveFilter.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Schema.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/version.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_de.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_es.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_fr.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_it.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ja.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ko.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_pt_BR.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_CN.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/SchemaCache.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAccessorOrderWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAccessorTypeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAnyAttributeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAnyElementWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAttachmentRefWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAttributeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementDeclWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementRefWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementRefsWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementWrapperWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementsWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlEnumValueWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlEnumWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlIDREFWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlIDWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlInlineBinaryDataWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlJavaTypeAdapterWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlListWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlMimeTypeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlMixedWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlNsWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlRegistryWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlRootElementWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaTypeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaTypesWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSeeAlsoWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlTransientWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlTypeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlValueWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CPropertyInfo.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CTypeRef.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/package-info.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/AbstractReferenceFinderImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/DOMForest.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/Util.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.properties
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Init.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlAttributeQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementDeclQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementRefQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementRefsQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlEnumQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlRootElementQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlSchemaQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlSchemaTypeQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlTransientQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlTypeQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlValueQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/core/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeBuiltinLeafInfoImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/BridgeAdapter.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Coordinator.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/XMLSerializer.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerBoolean.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerCharacter.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerDouble.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerFloat.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerInteger.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerLong.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerShort.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Boolean.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Character.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Double.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Float.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Integer.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Long.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Short.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Boolean.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Character.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Double.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Float.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Integer.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Long.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Short.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Double.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Float.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Long.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Short.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Boolean.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Double.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Float.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Long.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Short.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Loader.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages.properties
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/SAXConnector.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/UnmarshallingContext.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/XsiTypeLoader.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Annotated.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Annotation.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Any.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Appinfo.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/AttrDecls.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/AttributeType.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexContent.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexRestriction.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexType.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexTypeHost.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexTypeModel.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Documentation.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Element.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ExplicitGroup.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ExtensionType.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/FixedOrDefault.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Import.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/List.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/LocalAttribute.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/LocalElement.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/NestedParticle.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/NoFixedFacet.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Occurs.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Redefinable.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Schema.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SchemaTop.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleContent.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleDerivation.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleRestriction.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleRestrictionModel.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleType.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleTypeHost.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TopLevelAttribute.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TopLevelElement.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TypeDefParticle.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TypeHost.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Union.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Wildcard.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/EditDistance.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/DTDEventListener.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/DTDHandlerBase.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/DTDParser.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/EndOfInputException.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/EntityDecl.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/ExternalEntity.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/InputEntity.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/InternalEntity.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/MessageCatalog.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/Resolver.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/SimpleHashtable.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/XmlChars.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/XmlNames.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/XmlReader.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/package.html
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/resources/Messages.properties
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AbstractCreatorProcessor.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AbstractProcessor.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AttributesHolder.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/FragmentedArray.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/MutableXMLStreamBuffer.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBuffer.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferException.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferMark.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferResult.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferSource.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/DefaultWithLexicalHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/Features.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/Properties.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/SAXBufferCreator.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamBufferCreator.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamReaderBufferCreator.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamReaderBufferProcessor.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamWriterBufferCreator.java
! src/share/jaxws_classes/com/sun/xml/internal/txw2/output/XMLWriter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/Packet.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/Container.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/ThreadLocalContainerResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/writer/WSDLGeneratorExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/commons/xmlutil/Converter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/MtomCodec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAP11Codec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAP12Codec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAPCodec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/TagInfoset.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/AbstractMessageImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBHeader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/saaj/SAAJMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/StreamMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/StreamingMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/SDDocumentImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/BindingContext.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/pipe/AbstractSchemaValidationTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/version.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XmlUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/WSDLGenerator.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/Messages.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/Messages.properties
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/SAXParserFactoryAdaptor.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/Schema.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_List.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_Restriction.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_Union.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/annotation.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/attributeDeclBody.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/attributeGroupDecl.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/attributeUses.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/complexType.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/complexType_complexContent_body.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/elementDeclBody.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/erSet.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/ersSet.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/facet.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/group.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/identityConstraint.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/importDecl.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/includeDecl.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/modelGroupBody.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/notation.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/occurs.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/particle.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/qname.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/redefine.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/simpleType.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/wildcardBody.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/xpath.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/parser/JAXPParser.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/parser/XSOMParser.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/util/DomAnnotationParserFactory.java
! src/share/jaxws_classes/javax/xml/bind/Binder.java
! src/share/jaxws_classes/javax/xml/bind/ContextFinder.java
! src/share/jaxws_classes/javax/xml/bind/DataBindingException.java
! src/share/jaxws_classes/javax/xml/bind/DatatypeConverter.java
! src/share/jaxws_classes/javax/xml/bind/DatatypeConverterImpl.java
! src/share/jaxws_classes/javax/xml/bind/DatatypeConverterInterface.java
! src/share/jaxws_classes/javax/xml/bind/Element.java
! src/share/jaxws_classes/javax/xml/bind/GetPropertyAction.java
! src/share/jaxws_classes/javax/xml/bind/JAXB.java
! src/share/jaxws_classes/javax/xml/bind/JAXBContext.java
! src/share/jaxws_classes/javax/xml/bind/JAXBElement.java
! src/share/jaxws_classes/javax/xml/bind/JAXBException.java
! src/share/jaxws_classes/javax/xml/bind/JAXBIntrospector.java
! src/share/jaxws_classes/javax/xml/bind/JAXBPermission.java
! src/share/jaxws_classes/javax/xml/bind/MarshalException.java
! src/share/jaxws_classes/javax/xml/bind/Messages.java
! src/share/jaxws_classes/javax/xml/bind/Messages.properties
! src/share/jaxws_classes/javax/xml/bind/NotIdentifiableEvent.java
! src/share/jaxws_classes/javax/xml/bind/ParseConversionEvent.java
! src/share/jaxws_classes/javax/xml/bind/PrintConversionEvent.java
! src/share/jaxws_classes/javax/xml/bind/PropertyException.java
! src/share/jaxws_classes/javax/xml/bind/SchemaOutputResolver.java
! src/share/jaxws_classes/javax/xml/bind/TypeConstraintException.java
! src/share/jaxws_classes/javax/xml/bind/UnmarshalException.java
! src/share/jaxws_classes/javax/xml/bind/Unmarshaller.java
! src/share/jaxws_classes/javax/xml/bind/UnmarshallerHandler.java
! src/share/jaxws_classes/javax/xml/bind/ValidationEvent.java
! src/share/jaxws_classes/javax/xml/bind/ValidationEventHandler.java
! src/share/jaxws_classes/javax/xml/bind/ValidationEventLocator.java
! src/share/jaxws_classes/javax/xml/bind/ValidationException.java
! src/share/jaxws_classes/javax/xml/bind/Validator.java
! src/share/jaxws_classes/javax/xml/bind/WhiteSpaceProcessor.java
! src/share/jaxws_classes/javax/xml/bind/annotation/DomHandler.java
! src/share/jaxws_classes/javax/xml/bind/annotation/W3CDomHandler.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessOrder.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessType.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessorOrder.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessorType.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAnyAttribute.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAnyElement.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAttachmentRef.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAttribute.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElement.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementDecl.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementRef.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementRefs.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementWrapper.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElements.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlEnum.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlEnumValue.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlID.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlIDREF.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlList.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlMixed.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlNs.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlNsForm.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlRegistry.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlRootElement.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchema.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchemaType.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchemaTypes.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSeeAlso.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlTransient.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlType.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlValue.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/CollapsedStringAdapter.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/HexBinaryAdapter.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/NormalizedStringAdapter.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapter.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapters.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/package.html
! src/share/jaxws_classes/javax/xml/bind/annotation/package.html
! src/share/jaxws_classes/javax/xml/bind/attachment/AttachmentMarshaller.java
! src/share/jaxws_classes/javax/xml/bind/attachment/AttachmentUnmarshaller.java
! src/share/jaxws_classes/javax/xml/bind/attachment/package.html
! src/share/jaxws_classes/javax/xml/bind/helpers/AbstractMarshallerImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/AbstractUnmarshallerImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/DefaultValidationEventHandler.java
! src/share/jaxws_classes/javax/xml/bind/helpers/Messages.java
! src/share/jaxws_classes/javax/xml/bind/helpers/Messages.properties
! src/share/jaxws_classes/javax/xml/bind/helpers/NotIdentifiableEventImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/ParseConversionEventImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/PrintConversionEventImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/ValidationEventImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/ValidationEventLocatorImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/package.html
! src/share/jaxws_classes/javax/xml/bind/package.html
! src/share/jaxws_classes/javax/xml/bind/util/JAXBResult.java
! src/share/jaxws_classes/javax/xml/bind/util/JAXBSource.java
! src/share/jaxws_classes/javax/xml/bind/util/Messages.java
! src/share/jaxws_classes/javax/xml/bind/util/Messages.properties
! src/share/jaxws_classes/javax/xml/bind/util/ValidationEventCollector.java
! src/share/jaxws_classes/javax/xml/bind/util/package.html



From chris.hegarty at oracle.com  Fri Aug 23 10:11:40 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Fri, 23 Aug 2013 10:11:40 +0000
Subject: hg: jdk8/tl/jaxws: 8023636: Missing files from 8022885
Message-ID: <20130823101142.65C0348AF4@hg.openjdk.java.net>

Changeset: d8593d8581df
Author:    mkos
Date:      2013-08-23 11:10 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d8593d8581df

8023636: Missing files from 8022885
Reviewed-by: alanb, chegar

+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/StreamingSOAP.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/NamespaceContextExAdaper.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XMLReaderComposite.java



From Alan.Bateman at oracle.com  Fri Aug 23 10:28:17 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 23 Aug 2013 11:28:17 +0100
Subject: RFR [8023130] (process) ProcessBuilder#inheritIO does not work
	on Windows
In-Reply-To: <5216D1E6.2090304@oracle.com>
References: <5216D1E6.2090304@oracle.com>
Message-ID: <52173941.5040203@oracle.com>

On 23/08/2013 04:07, Ivan Gerasimov wrote:
> Hello everybody!
>
> The method ProcessBuilder#inheritIO() is reported to not have any 
> effect on Windows platform.
> The same story is with redirectOutput/Input/Error(Redirect.INHERIT) 
> methods.
> As the result, standard in/out/err aren't inherited.
>
> It turn out that the culprit is the CREATE_NO_WINDOW flag passed to 
> CreateProcessW().
> MS doc says about this flag: "The process is a console application 
> that is being run without a console window."
>
> CREATE_NO_WINDOW flag was added with the fix for 
> http://bugs.sun.com/view_bug.do?bug_id=4244515 to suppress a console 
> window on a newly created process, when it is created from a program 
> launched with javaw.exe.
> Thus, I left this flag only for cases when the program doesn't have a 
> console associated with it.
>
> Would you please help review a fix for this problem?
>
> BUGURL: http://bugs.sun.com/view_bug.do?bug_id=8023130
> WEBREV: http://cr.openjdk.java.net/~igerasim/8023130/0/webrev/
>
Good sleuthing!

Just so I understand, if we have a console (DOS command window for 
example) then will dropping CREATE_NO_WINDOW result in a new window or not?

One thing that it does highlight is that the coverage for inherit in 
ProcessBuilder/Basic.java was not sufficient as this should have been 
caught a long time ago. My preference would be to add to this test 
rather than introduce a new one (ProcessBuilder.java is Martin's 
original mother-of-all tests for ProcessBuilder).

-Alan.


From aleksey.shipilev at oracle.com  Fri Aug 23 10:38:05 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 23 Aug 2013 14:38:05 +0400
Subject: RFR (M) CR 8023234: StampedLock serializes readers on writer
	unlock
In-Reply-To: <52150F82.1090600@oracle.com>
References: <521230D1.9070803@oracle.com>
	
	<52138373.8090903@oracle.com>
	
	<5214FCE4.9030507@oracle.com>
	
	<52150F82.1090600@oracle.com>
Message-ID: <52173B8D.5080001@oracle.com>

Hm, I think I still need the second reviewer.
Anyone?

  http://cr.openjdk.java.net/~shade/8023234/webrev.01/

-Aleksey.

On 08/21/2013 11:05 PM, Aleksey Shipilev wrote:
> Thanks Martin!
> 
> I need a sponsor to push this.
> 
> -Aleksey.
> 
> P.S. The support for multi-threaded tests in jtreg/library is one of the
> things I'm eager to have.
> 
> On 08/21/2013 10:53 PM, Martin Buchholz wrote:
>> OK, approved!
>>
>> I would do things differently, and there is the deeper problem that
>> openjdk provides no test infrastructure for multi-threaded tests, which
>> we are suffering from here.  Now that testng is being used, it's a good
>> time for someone to import test infrastructure from JSR166TestCase
>>
>>
>> On Wed, Aug 21, 2013 at 10:46 AM, Aleksey Shipilev
>> > wrote:
>>
>>     Hi Martin,
>>
>>     On 08/21/2013 06:28 AM, Martin Buchholz wrote:
>>     > If a Reader throws, the test might still pass, since only throwing
>>     from
>>     > the main thread matters.  See infrastructure in JSR166TestCase, e.g.
>>     > threadUnexpectedException.
>>
>>     Yes. I still don't think there is a value in catching the exceptions in
>>     the threads for this concrete regression test. Should the reader die
>>     with the exception, the test will fail anyway, since enough readers are
>>     not available.
>>
>>     > OTOH, there seems no value in converting exceptions in the main thread
>>     > to ISE.  Just declare main to throw Exception or whatever.
>>
>>     This seems to be the stylistic nit. ;) There is the symmetry against
>>     readers code, which wraps the exceptions into the ISE. For my taste, it
>>     looks better to retain that symmetry.
>>
>>     I can still make the changes to the test, if you insist.
>>
>>     -Aleksey.
>>
>>
> 



From sundararajan.athijegannathan at oracle.com  Fri Aug 23 12:39:40 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Fri, 23 Aug 2013 12:39:40 +0000
Subject: hg: jdk8/tl/nashorn: 12 new changesets
Message-ID: <20130823123951.C054048AFE@hg.openjdk.java.net>

Changeset: dbb0a20a6f27
Author:    attila
Date:      2013-08-21 13:39 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/dbb0a20a6f27

8023373: allow super invocation for adapters
Reviewed-by: lagergren, sundar

! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
+ test/script/basic/JDK-8023373.js
+ test/script/basic/JDK-8023373.js.EXPECTED

Changeset: dc322503ce36
Author:    attila
Date:      2013-08-21 13:39 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/dc322503ce36

8022903: Enhance for-in and for-each for Lists and Maps
Reviewed-by: lagergren, sundar

! src/jdk/nashorn/internal/runtime/ScriptRuntime.java
+ test/script/basic/JDK-8022903.js
+ test/script/basic/JDK-8022903.js.EXPECTED

Changeset: b7c04b3b01a7
Author:    sundar
Date:      2013-08-21 17:28 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b7c04b3b01a7

8023368: Instance __proto__ property should exist and be writable.
Reviewed-by: attila, hannesw

! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk/nashorn/internal/runtime/PropertyListener.java
! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java
! src/jdk/nashorn/internal/runtime/PropertyMap.java
! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/resources/Messages.properties
! src/jdk/nashorn/internal/runtime/resources/Options.properties
! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js
+ test/script/basic/JDK-8023368.js
+ test/script/basic/JDK-8023368.js.EXPECTED
+ test/script/basic/JDK-8023368_2.js
+ test/script/basic/JDK-8023368_2.js.EXPECTED
+ test/script/basic/circular_proto.js
+ test/script/basic/circular_proto.js.EXPECTED
+ test/script/basic/mirror_proto_assign.js
+ test/script/basic/mirror_proto_assign.js.EXPECTED
+ test/script/basic/nonextensible_proto_assign.js
+ test/script/basic/nonextensible_proto_assign.js.EXPECTED

Changeset: 54f60d91024c
Author:    sundar
Date:      2013-08-22 18:46 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/54f60d91024c

8023551: Mirror functions can not be invoked using invokeMethod, invokeFunction
Reviewed-by: attila, jlaskey, lagergren

! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
+ test/script/basic/JDK-8023551.js
+ test/script/basic/JDK-8023551.js.EXPECTED
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java

Changeset: 8ad9bcb04e6d
Author:    hannesw
Date:      2013-08-22 17:23 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8ad9bcb04e6d

8023531: new RegExp('').toString() should return '/(?:)/'
Reviewed-by: sundar, jlaskey

! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/WithObject.java
! src/jdk/nashorn/internal/runtime/regexp/RegExp.java
+ test/script/basic/JDK-8023531.js

Changeset: c5c5ab3f420a
Author:    jlaskey
Date:      2013-08-22 13:51 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c5c5ab3f420a

8023228: Debugger information gather is too slow.
Reviewed-by: sundar, lagergren
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/Context.java
+ src/jdk/nashorn/internal/runtime/DebuggerSupport.java

Changeset: 5a1e07b9a3cd
Author:    sundar
Date:      2013-08-22 22:32 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5a1e07b9a3cd

8023560: Arbitrary javax.script.Bindings objects as ENGINE_SCOPE objects are not handled as expected.
Reviewed-by: jlaskey, lagergren, hannesw

! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java
! src/jdk/nashorn/internal/runtime/resources/Options.properties
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java
! test/src/jdk/nashorn/internal/runtime/TrustedScriptEngineTest.java

Changeset: d82ac93aa55c
Author:    sundar
Date:      2013-08-23 16:10 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d82ac93aa55c

8023631: engine.js init script should be loaded into every global instance created by engines
Reviewed-by: attila, hannesw

! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/resources/engine.js
+ test/src/jdk/nashorn/api/scripting/InvocableTest.java
+ test/src/jdk/nashorn/api/scripting/ScopeTest.java
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java
+ test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java

Changeset: 6b6a8fc714a9
Author:    lagergren
Date:      2013-08-23 12:43 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6b6a8fc714a9

8023453: --log=attr did not unindent identNodes
Reviewed-by: attila, jlaskey

! src/jdk/nashorn/internal/codegen/Attr.java

Changeset: 4dcd5a22fdd3
Author:    lagergren
Date:      2013-08-23 12:44 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4dcd5a22fdd3

Merge


Changeset: f18f2ce1b2dc
Author:    attila
Date:      2013-08-23 13:10 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f18f2ce1b2dc

8023630: Implement Java.super() as the preferred way to call super methods
Reviewed-by: jlaskey, lagergren, sundar

! src/jdk/nashorn/internal/objects/NativeJava.java
! src/jdk/nashorn/internal/runtime/JSType.java
! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java
! src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethodLinker.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java
+ src/jdk/nashorn/internal/runtime/linker/JavaSuperAdapter.java
+ src/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java
+ test/script/basic/JDK-8023630.js
+ test/script/basic/JDK-8023630.js.EXPECTED
! test/script/basic/NASHORN-397.js

Changeset: 2ce55025a37d
Author:    sundar
Date:      2013-08-23 16:44 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2ce55025a37d

Merge




From daniel.fuchs at oracle.com  Fri Aug 23 14:41:34 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 23 Aug 2013 16:41:34 +0200
Subject: RFR: 8005899: Logger.getLogger(name, null) should not allow to reset
	a non-null resource bundle
Message-ID: <5217749E.2070603@oracle.com>

Hi,

Please find below a fix for:

8005899: Logger.getLogger(name, null) should not allow to reset
          a non-null resource bundle

The issue here is that whereas in JDK 7,
     Logger.getLogger("foo", null);
will throw an IllegalArgumentException if "foo" has a non null
bundle name, JDK 8 will simply ignore the 'null' parameter and
behave as
     Logger.getLogger("foo");

The fix below restores the IllegalArgumentException in JDK 8.



best regards,

-- daniel


From Alan.Bateman at oracle.com  Fri Aug 23 14:56:44 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 23 Aug 2013 15:56:44 +0100
Subject: Please review fix for 8011944 : Sort fails with
	ArrayIndexOutOfBoundsException
In-Reply-To: <52161F49.3030001@oracle.com>
References: <52161F49.3030001@oracle.com>
Message-ID: <5217782C.3010403@oracle.com>

On 22/08/2013 15:25, roger riggs wrote:
> Please review the fix for:
>
>   JDK-8011944[1] : Sort fails with ArrayIndexOutOfBoundsException
>
> The pending run stack size is estimated based on the input size.
> The worst case sequence of inputs exceeds the current allocation and 
> an exception occurs.
> Increasing the allocation of the pending run stack addresses the issue.
> This was present in the original contribution of Timsort and 
> ComparableTimSort.
>
> Webrev[2]:
>   http://cr.openjdk.java.net/~rriggs/webrev-timsort-8011944/
Increasing the size of the merge stack looks right. Do you know if there 
is potential for other cases that could cause problems?

-Alan


From Lance.Andersen at oracle.com  Fri Aug 23 15:22:56 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Fri, 23 Aug 2013 11:22:56 -0400
Subject: RFR: 8005899: Logger.getLogger(name,
	null) should not allow to reset a non-null resource bundle
In-Reply-To: <5217749E.2070603@oracle.com>
References: <5217749E.2070603@oracle.com>
Message-ID: <45E24D7C-3D79-4AD5-8C84-3F47911D9607@oracle.com>

Looking at the jdk7 source and comparing your change this looks OK.   Would be good to get one more pair of eyes on this as well but I think you should be good to go

Best
Lance
On Aug 23, 2013, at 10:41 AM, Daniel Fuchs wrote:

> Hi,
> 
> Please find below a fix for:
> 
> 8005899: Logger.getLogger(name, null) should not allow to reset
>         a non-null resource bundle
> 
> The issue here is that whereas in JDK 7,
>    Logger.getLogger("foo", null);
> will throw an IllegalArgumentException if "foo" has a non null
> bundle name, JDK 8 will simply ignore the 'null' parameter and
> behave as
>    Logger.getLogger("foo");
> 
> The fix below restores the IllegalArgumentException in JDK 8.
> 
> 
> 
> best regards,
> 
> -- daniel

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From roger.riggs at oracle.com  Fri Aug 23 15:24:04 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Fri, 23 Aug 2013 11:24:04 -0400
Subject: Please review fix for 8011944 : Sort fails with
	ArrayIndexOutOfBoundsException
In-Reply-To: <5217782C.3010403@oracle.com>
References: <52161F49.3030001@oracle.com> <5217782C.3010403@oracle.com>
Message-ID: <52177E94.9010302@oracle.com>

Hi,

I reviewed the algorithm of the test case and it seems to me that it
produces the smallest number of total items to sort for a given stack depth.
I ran it with other stack depths and confirmed that the implementation did
not exceed the new limit.

I was unable to discover a specific explanation or computation for the
current choices to thresholds and corresponding stack depths.

An alternative implementation could use the conservative estimate
and resize the array as needed.  It would avoid overallocation of a
temporary in the normal case.

Thanks, Roger

On 8/23/2013 10:56 AM, Alan Bateman wrote:
> On 22/08/2013 15:25, roger riggs wrote:
>> Please review the fix for:
>>
>>   JDK-8011944[1] : Sort fails with ArrayIndexOutOfBoundsException
>>
>> The pending run stack size is estimated based on the input size.
>> The worst case sequence of inputs exceeds the current allocation and 
>> an exception occurs.
>> Increasing the allocation of the pending run stack addresses the issue.
>> This was present in the original contribution of Timsort and 
>> ComparableTimSort.
>>
>> Webrev[2]:
>>   http://cr.openjdk.java.net/~rriggs/webrev-timsort-8011944/
> Increasing the size of the merge stack looks right. Do you know if 
> there is potential for other cases that could cause problems?
>
> -Alan



From nit.dgp673 at gmail.com  Thu Aug 22 03:37:45 2013
From: nit.dgp673 at gmail.com (Laxmi Narayan NIT DGP)
Date: Thu, 22 Aug 2013 09:07:45 +0530
Subject: hg: jdk8/tl/jdk: 8022228: Intermittent test failures in
	sun/security/ssl/javax/net/ssl/NewAPIs
In-Reply-To: <20130822024717.B922548A76@hg.openjdk.java.net>
References: <20130822024717.B922548A76@hg.openjdk.java.net>
Message-ID: 

is there are any chances of contribution for outsider of oracle and even
student developers ??

*




                         Laxmi Narayan Patel
*
*
MCA NIT Durgapur (Pre final year)
*
*
mob:-    8345847473
*


On Thu, Aug 22, 2013 at 8:16 AM,  wrote:

> Changeset: ec827a62070a
> Author:    xuelei
> Date:      2013-08-21 19:44 -0700
> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ec827a62070a
>
> 8022228: Intermittent test failures in
> sun/security/ssl/javax/net/ssl/NewAPIs
> Reviewed-by: weijun
>
> ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java
> ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java
> ! test/sun/security/ssl/templates/SSLSocketTemplate.java
>
>


From bernd-2013 at eckenfels.net  Thu Aug 22 12:48:19 2013
From: bernd-2013 at eckenfels.net (Bernd Eckenfels)
Date: Thu, 22 Aug 2013 14:48:19 +0200
Subject: RFR: 8022445: fix RMISocketFactory example to avoid using
	localhost
In-Reply-To: <5215D1C5.6000906@oracle.com>
References: <52156237.5070605@oracle.com> <5215D1C5.6000906@oracle.com>
Message-ID: <56F5142A-BEFB-481E-8757-731F1DF60613@eckenfels.net>

All Stream Sockets where you specify an bind address (different from InAddrAny aka "::" or 0.0.0.0) are only bound to a single address family. You can't bind a single listening socket to a dual stack localhost IP Address. getLoopbackAddress is either ::1 or 127.0.0.1 (depending on the stack preferemces) and InetAddress.getByName("localhost") is also one of both (but not necesarily the same, unfortunately). This happened to me in the past, so I wanted to make sure that asumption does not show up in sample code of JavaDocs. Thanks for improving this!

Bernd

Am 22.08.2013 um 10:54 schrieb Alan Bateman :

> On 22/08/2013 01:58, Stuart Marks wrote:
>> Hi all,
>> 
>> Please review this small documentation change to the example I added to RMISocketFactory a couple weeks ago [1]. This change fixes a problem that Bernd Eckenfels pointed out [2] where the interface returned by getLoopbackAddress() might not match the interface that "localhost" resolves to.
> We don't have support for IPv4-only or IPv6-only listeners (at least not with stream oriented sockets, there is support for protocol specific datagram sockets but that doesn't apply here). So I'm curious about the original comments and whether there are configurations or loopback address plumbing where getLoopbackAddress doesn't do the right thing?
> 
> -Alan


From mandy.chung at oracle.com  Fri Aug 23 15:50:28 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 23 Aug 2013 08:50:28 -0700
Subject: RFR: 8005899: Logger.getLogger(name, null) should not allow to
	reset a non-null resource bundle
In-Reply-To: <5217749E.2070603@oracle.com>
References: <5217749E.2070603@oracle.com>
Message-ID: <521784C4.4070201@oracle.com>

Hi Daniel,

The fix looks good.   It might be good to clarify the spec in the case 
when the given resourceBundleName parameter is null?   Perhaps in the 
@params resourceBundleName of the getLogger(String, String) method.

    * @param   resourceBundleName  name of ResourceBundle to be used for localizing
    *                          messages for this logger. May be null if none of
    *                          the messages require localization.

perhaps clarify that null only if the logger does not have a
localization resource bundle set.

thanks
Mandy

On 8/23/2013 7:41 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a fix for:
>
> 8005899: Logger.getLogger(name, null) should not allow to reset
>          a non-null resource bundle
>
> The issue here is that whereas in JDK 7,
>     Logger.getLogger("foo", null);
> will throw an IllegalArgumentException if "foo" has a non null
> bundle name, JDK 8 will simply ignore the 'null' parameter and
> behave as
>     Logger.getLogger("foo");
>
> The fix below restores the IllegalArgumentException in JDK 8.
>
> 
>
> best regards,
>
> -- daniel



From henry.jen at oracle.com  Fri Aug 23 16:11:02 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 23 Aug 2013 09:11:02 -0700
Subject: RFR: 8023528: Rename Comparator combinators to disambiguate
	overloading methods
In-Reply-To: <5216FA75.6040002@oracle.com>
References: <5216D531.5060900@oracle.com> <5216FA75.6040002@oracle.com>
Message-ID: <105E048D-5F22-4EB4-8434-53CCBBCFB5EE@oracle.com>

Thanks Stuart for the review and correct link.

Cheers,
Henry


On Aug 22, 2013, at 11:00 PM, Stuart Marks  wrote:

> Hi Henry,
> 
> Changes look good. It's also good to see some now-extra casts and type witnesses removed. It somewhat makes up for the longer, non-overloaded method names.
> 
> Note, corrected email thread[2] link:
> 
> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-August/002206.html
> 
> s'marks
> 
> On 8/22/13 8:21 PM, Henry Jen wrote:
>> Hi,
>> 
>> Please review a relative simple webrev[1] that basically simply renaming
>> Comparator methods. The reason behind the renaming can be found at this
>> email thread[2]. The specdiff is also available here[3].
>> 
>> Cheers,
>> Henry
>> 
>> [1] http://cr.openjdk.java.net/~henryjen/ccc/8023528/0/webrev/
>> [2]
>> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-expert/2013-August/002206.html
>> [3]
>> http://cr.openjdk.java.net/~henryjen/ccc/8023528/0/specdiff/overview-summary.html
>> 



From ivan.gerasimov at oracle.com  Fri Aug 23 16:11:25 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 23 Aug 2013 20:11:25 +0400
Subject: RFR [8023130] (process) ProcessBuilder#inheritIO does not work
	on Windows
In-Reply-To: <52173941.5040203@oracle.com>
References: <5216D1E6.2090304@oracle.com> <52173941.5040203@oracle.com>
Message-ID: <521789AD.2070208@oracle.com>

Thank you Alan!

On 23.08.2013 14:28, Alan Bateman wrote:
> On 23/08/2013 04:07, Ivan Gerasimov wrote:
>> Hello everybody!
>>
>> The method ProcessBuilder#inheritIO() is reported to not have any 
>> effect on Windows platform.
>> The same story is with redirectOutput/Input/Error(Redirect.INHERIT) 
>> methods.
>> As the result, standard in/out/err aren't inherited.
>>
>> It turn out that the culprit is the CREATE_NO_WINDOW flag passed to 
>> CreateProcessW().
>> MS doc says about this flag: "The process is a console application 
>> that is being run without a console window."
>>
>> CREATE_NO_WINDOW flag was added with the fix for 
>> http://bugs.sun.com/view_bug.do?bug_id=4244515 to suppress a console 
>> window on a newly created process, when it is created from a program 
>> launched with javaw.exe.
>> Thus, I left this flag only for cases when the program doesn't have a 
>> console associated with it.
>>
>> Would you please help review a fix for this problem?
>>
>> BUGURL: http://bugs.sun.com/view_bug.do?bug_id=8023130
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8023130/0/webrev/
>>
> Good sleuthing!
>
> Just so I understand, if we have a console (DOS command window for 
> example) then will dropping CREATE_NO_WINDOW result in a new window or 
> not?
>
No new console for a console application without CREATE_NO_WINDOW flag.
I used a sample program to confirm that:
---------------
class InheritIO {
     public static void main(String[] args) throws Exception {
         int err = new 
ProcessBuilder(args).inheritIO().redirectErrorStream(true).start().waitFor();
         System.err.println("Exit value: " + err);
     }
}
---------------
With the proposed fix running it as '> java InheritIO cmd /?' copies the 
output of the command to the existing console.
No new console is created.

> One thing that it does highlight is that the coverage for inherit in 
> ProcessBuilder/Basic.java was not sufficient as this should have been 
> caught a long time ago. My preference would be to add to this test 
> rather than introduce a new one (ProcessBuilder.java is Martin's 
> original mother-of-all tests for ProcessBuilder).
>
Yes, I agree. It would be better to integrate this test into Basic.java.

Sincerely yours,
Ivan

> -Alan.
>
>



From joel.franck at oracle.com  Fri Aug 23 16:54:36 2013
From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Fri, 23 Aug 2013 18:54:36 +0200
Subject: RFR: 8022343: j.l.Class.getAnnotatedSuperclass() doesn't return
	null in some cases
In-Reply-To: <5216AE11.8090705@oracle.com>
References: <20130816121739.GM12405@jfranck-desktop.jrpg.bea.com>
	
	<5212C532.8030905@oracle.com>
	<20130821120405.GE22953@jfranck-desktop.jrpg.bea.com>
	<5216AE11.8090705@oracle.com>
Message-ID: <29E9B257-EEC1-44E8-A38C-96C0B6114837@oracle.com>

Fixed,

http://cr.openjdk.java.net/~jfranck/8022343/webrev.02/

cheers
/Joel

On Aug 23, 2013, at 2:34 AM, Joseph Darcy  wrote:

> Hi Joel,
> 
> The new version is better, but for the testing in question I would prefer to see something even simpler like:
> 
>    public static void main(String[] args) throws Exception {
>        int failed = 0;
>        Class[] testData = {/* list of class literals*/}
>        for (Class toTest: testData) {
>            Object res = toTest.getAnnotatedSuperclass();
> 
>            if (res != null) {
>                failed++;
>                System.out.println(toTest + ".getAnnotatedSuperclass() returns: "
>                        + res + ", was non-null");
>            }
>        }
> 
>        if (failed != 0)
>            throw new RuntimeException("Test failed, check log for details");
>    }
> 
> 
> -Joe
> 
> On 8/21/2013 5:04 AM, Joel Borggr?n-Franck wrote:
>> Hi Joe, Paul
>> 
>> I rewrote the test in Paul's style without using testNG.
>> 
>> http://cr.openjdk.java.net/~jfranck/8022343/webrev.01/
>> 
>> Please review.
>> 
>> cheers
>> /Joel
>> 
>> On 2013-08-19, Joe Darcy wrote:
>>> Hi Joel,
>>> 
>>> I agree the code looks fine.
>>> 
>>> However, I concur with the general sentiment of Paul test advice
>>> without advocating using testng for this task.
>>> 
>>> A loop over a Class[] initialized with the kinds of values of
>>> interest would seem to be better structured to me and allow for
>>> better exception handing, etc.
>>> 
>>> -Joe
>>> 
>>> On 08/19/2013 01:34 AM, Paul Sandoz wrote:
>>>> Hi Joel,
>>>> 
>>>> The fix looks OK.
>>>> 
>>>> Not suggesting you do the following, unless you really want to, but the test is an example of where TestNG data providers are useful, since all cases will be tested and reported for pass or failure, rather than in this case the first failure will cause other checks (if any) not to be tested and in addition will not report which check failed (one needs to look at the stack trace).
>>>> 
>>>> Not tested:
>>>> 
>>>>   @DataProvider(name = "class")
>>>>   private static Object[][] getClasses() {
>>>>       // Using the stream API because i can :-)
>>>>       // Arguably simpler in this case to use new Object[][] { {} }
>>>>       return Stream.of(
>>>>                                 Object.class,
>>>>                                 If.class,
>>>>                                 Object[].class,
>>>>                                 void.class,
>>>>                                 int.class).
>>>>               map(e -> new Object[] { e }).
>>>>               toArray(Object[][]::new);
>>>>   }
>>>> 
>>>>   @Test(dataProvider = "class")
>>>>   public void testAnnotatedSuperClassIsNull(Class c) {
>>>>       assertNull(c.getAnnotatedSuperclass())
>>>>   }
>>>> 
>>>> Paul.
>>>> 
>>>> On Aug 16, 2013, at 2:17 PM, Joel Borggren-Franck  wrote:
>>>> 
>>>>> Hi
>>>>> 
>>>>> Please review this small fix for a type annotation reflection issue.
>>>>> 
>>>>> The javadoc spec for Class.getAnnotatedSuperclass says:
>>>>> 
>>>>> * If this Class represents either the Object class, an interface type, an
>>>>> * array type, a primitive type, or void, the return value is null.
>>>>> 
>>>>> The patch fixes this.
>>>>> 
>>>>> Webrev at: http://cr.openjdk.java.net/~jfranck/8022343/webrew.00/
>>>>> 
>>>>> Patch also included it at the end of this mail.
>>>>> 
>>>>> cheers
>>>>> /Joel
>>>>> 
>>>>> 
>>>>> 
>>>>> diff -r b07b19182e40 src/share/classes/java/lang/Class.java
>>>>> --- a/src/share/classes/java/lang/Class.java	Thu Aug 15 15:04:59 2013 +0100
>>>>> +++ b/src/share/classes/java/lang/Class.java	Fri Aug 16 13:20:31 2013 +0200
>>>>> @@ -3338,8 +3338,16 @@
>>>>>      * @since 1.8
>>>>>      */
>>>>>     public AnnotatedType getAnnotatedSuperclass() {
>>>>> -         return TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), getConstantPool(), this);
>>>>> -}
>>>>> +        if(this == Object.class ||
>>>>> +                isInterface() ||
>>>>> +                isArray() ||
>>>>> +                isPrimitive() ||
>>>>> +                this == Void.TYPE) {
>>>>> +            return null;
>>>>> +        }
>>>>> +
>>>>> +        return TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), getConstantPool(), this);
>>>>> +    }
>>>>> 
>>>>>     /**
>>>>>      * Returns an array of AnnotatedType objects that represent the use of types to
>>>>> diff -r b07b19182e40 test/java/lang/annotation/TypeAnnotationReflection.java
>>>>> --- a/test/java/lang/annotation/TypeAnnotationReflection.java	Thu Aug 15 15:04:59 2013 +0100
>>>>> +++ b/test/java/lang/annotation/TypeAnnotationReflection.java	Fri Aug 16 13:20:31 2013 +0200
>>>>> @@ -23,7 +23,7 @@
>>>>> 
>>>>> /*
>>>>>  * @test
>>>>> - * @bug 8004698 8007073
>>>>> + * @bug 8004698 8007073 8022343
>>>>>  * @summary Unit test for type annotations
>>>>>  */
>>>>> 
>>>>> @@ -58,7 +58,7 @@
>>>>>     }
>>>>> 
>>>>>     private static void testSuper() throws Exception {
>>>>> -        check(Object.class.getAnnotatedSuperclass().getAnnotations().length == 0);
>>>>> +        check(Object.class.getAnnotatedSuperclass() == null);
>>>>>         check(Class.class.getAnnotatedSuperclass().getAnnotations().length == 0);
>>>>> 
>>>>>         AnnotatedType a;
>>>>> diff -r b07b19182e40 test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java
>>>>> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
>>>>> +++ b/test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java	Fri Aug 16 13:20:31 2013 +0200
>>>>> @@ -0,0 +1,50 @@
>>>>> +/*
>>>>> + * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
>>>>> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>> + *
>>>>> + * This code is free software; you can redistribute it and/or modify it
>>>>> + * under the terms of the GNU General Public License version 2 only, as
>>>>> + * published by the Free Software Foundation.
>>>>> + *
>>>>> + * This code is distributed in the hope that it will be useful, but WITHOUT
>>>>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>>>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>>>> + * version 2 for more details (a copy is included in the LICENSE file that
>>>>> + * accompanied this code).
>>>>> + *
>>>>> + * You should have received a copy of the GNU General Public License version
>>>>> + * 2 along with this work; if not, write to the Free Software Foundation,
>>>>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>>> + *
>>>>> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>>>> + * or visit www.oracle.com if you need additional information or have any
>>>>> + * questions.
>>>>> + */
>>>>> +
>>>>> +/*
>>>>> + * @test
>>>>> + * @bug 8022343
>>>>> + * @summary make sure Class.getAnnotatedSuperclass() returns null when specified to do so
>>>>> + */
>>>>> +
>>>>> +import java.util.*;
>>>>> +import java.lang.annotation.*;
>>>>> +import java.lang.reflect.*;
>>>>> +import java.io.Serializable;
>>>>> +
>>>>> +public class GetAnnotatedSuperclass {
>>>>> +    public static void main(String[] args) throws Exception {
>>>>> +        check(Object.class.getAnnotatedSuperclass() == null);
>>>>> +        check(If.class.getAnnotatedSuperclass() == null);
>>>>> +        check(Object[].class.getAnnotatedSuperclass() == null);
>>>>> +        check(void.class.getAnnotatedSuperclass() == null);
>>>>> +        check(int.class.getAnnotatedSuperclass() == null);
>>>>> +    }
>>>>> +
>>>>> +    private static void check(boolean b) {
>>>>> +        if (!b)
>>>>> +            throw new RuntimeException();
>>>>> +    }
>>>>> +    interface If {}
>>>>> +}
>>>>> +
> 



From joe.darcy at oracle.com  Fri Aug 23 16:57:14 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 23 Aug 2013 09:57:14 -0700
Subject: RFR: 8022343: j.l.Class.getAnnotatedSuperclass() doesn't return
	null in some cases
In-Reply-To: <29E9B257-EEC1-44E8-A38C-96C0B6114837@oracle.com>
References: <20130816121739.GM12405@jfranck-desktop.jrpg.bea.com>
	
	<5212C532.8030905@oracle.com>
	<20130821120405.GE22953@jfranck-desktop.jrpg.bea.com>
	<5216AE11.8090705@oracle.com>
	<29E9B257-EEC1-44E8-A38C-96C0B6114837@oracle.com>
Message-ID: <5217946A.9010003@oracle.com>

Looks good to go back; thanks,

-Joe

On 08/23/2013 09:54 AM, Joel Borggr?n-Franck wrote:
> Fixed,
>
> http://cr.openjdk.java.net/~jfranck/8022343/webrev.02/
>
> cheers
> /Joel
>
> On Aug 23, 2013, at 2:34 AM, Joseph Darcy  wrote:
>
>> Hi Joel,
>>
>> The new version is better, but for the testing in question I would prefer to see something even simpler like:
>>
>>     public static void main(String[] args) throws Exception {
>>         int failed = 0;
>>         Class[] testData = {/* list of class literals*/}
>>         for (Class toTest: testData) {
>>             Object res = toTest.getAnnotatedSuperclass();
>>
>>             if (res != null) {
>>                 failed++;
>>                 System.out.println(toTest + ".getAnnotatedSuperclass() returns: "
>>                         + res + ", was non-null");
>>             }
>>         }
>>
>>         if (failed != 0)
>>             throw new RuntimeException("Test failed, check log for details");
>>     }
>>
>>
>> -Joe
>>
>> On 8/21/2013 5:04 AM, Joel Borggr?n-Franck wrote:
>>> Hi Joe, Paul
>>>
>>> I rewrote the test in Paul's style without using testNG.
>>>
>>> http://cr.openjdk.java.net/~jfranck/8022343/webrev.01/
>>>
>>> Please review.
>>>
>>> cheers
>>> /Joel
>>>
>>> On 2013-08-19, Joe Darcy wrote:
>>>> Hi Joel,
>>>>
>>>> I agree the code looks fine.
>>>>
>>>> However, I concur with the general sentiment of Paul test advice
>>>> without advocating using testng for this task.
>>>>
>>>> A loop over a Class[] initialized with the kinds of values of
>>>> interest would seem to be better structured to me and allow for
>>>> better exception handing, etc.
>>>>
>>>> -Joe
>>>>
>>>> On 08/19/2013 01:34 AM, Paul Sandoz wrote:
>>>>> Hi Joel,
>>>>>
>>>>> The fix looks OK.
>>>>>
>>>>> Not suggesting you do the following, unless you really want to, but the test is an example of where TestNG data providers are useful, since all cases will be tested and reported for pass or failure, rather than in this case the first failure will cause other checks (if any) not to be tested and in addition will not report which check failed (one needs to look at the stack trace).
>>>>>
>>>>> Not tested:
>>>>>
>>>>>    @DataProvider(name = "class")
>>>>>    private static Object[][] getClasses() {
>>>>>        // Using the stream API because i can :-)
>>>>>        // Arguably simpler in this case to use new Object[][] { {} }
>>>>>        return Stream.of(
>>>>>                                  Object.class,
>>>>>                                  If.class,
>>>>>                                  Object[].class,
>>>>>                                  void.class,
>>>>>                                  int.class).
>>>>>                map(e -> new Object[] { e }).
>>>>>                toArray(Object[][]::new);
>>>>>    }
>>>>>
>>>>>    @Test(dataProvider = "class")
>>>>>    public void testAnnotatedSuperClassIsNull(Class c) {
>>>>>        assertNull(c.getAnnotatedSuperclass())
>>>>>    }
>>>>>
>>>>> Paul.
>>>>>
>>>>> On Aug 16, 2013, at 2:17 PM, Joel Borggren-Franck  wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> Please review this small fix for a type annotation reflection issue.
>>>>>>
>>>>>> The javadoc spec for Class.getAnnotatedSuperclass says:
>>>>>>
>>>>>> * If this Class represents either the Object class, an interface type, an
>>>>>> * array type, a primitive type, or void, the return value is null.
>>>>>>
>>>>>> The patch fixes this.
>>>>>>
>>>>>> Webrev at: http://cr.openjdk.java.net/~jfranck/8022343/webrew.00/
>>>>>>
>>>>>> Patch also included it at the end of this mail.
>>>>>>
>>>>>> cheers
>>>>>> /Joel
>>>>>>
>>>>>>
>>>>>>
>>>>>> diff -r b07b19182e40 src/share/classes/java/lang/Class.java
>>>>>> --- a/src/share/classes/java/lang/Class.java	Thu Aug 15 15:04:59 2013 +0100
>>>>>> +++ b/src/share/classes/java/lang/Class.java	Fri Aug 16 13:20:31 2013 +0200
>>>>>> @@ -3338,8 +3338,16 @@
>>>>>>       * @since 1.8
>>>>>>       */
>>>>>>      public AnnotatedType getAnnotatedSuperclass() {
>>>>>> -         return TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), getConstantPool(), this);
>>>>>> -}
>>>>>> +        if(this == Object.class ||
>>>>>> +                isInterface() ||
>>>>>> +                isArray() ||
>>>>>> +                isPrimitive() ||
>>>>>> +                this == Void.TYPE) {
>>>>>> +            return null;
>>>>>> +        }
>>>>>> +
>>>>>> +        return TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), getConstantPool(), this);
>>>>>> +    }
>>>>>>
>>>>>>      /**
>>>>>>       * Returns an array of AnnotatedType objects that represent the use of types to
>>>>>> diff -r b07b19182e40 test/java/lang/annotation/TypeAnnotationReflection.java
>>>>>> --- a/test/java/lang/annotation/TypeAnnotationReflection.java	Thu Aug 15 15:04:59 2013 +0100
>>>>>> +++ b/test/java/lang/annotation/TypeAnnotationReflection.java	Fri Aug 16 13:20:31 2013 +0200
>>>>>> @@ -23,7 +23,7 @@
>>>>>>
>>>>>> /*
>>>>>>   * @test
>>>>>> - * @bug 8004698 8007073
>>>>>> + * @bug 8004698 8007073 8022343
>>>>>>   * @summary Unit test for type annotations
>>>>>>   */
>>>>>>
>>>>>> @@ -58,7 +58,7 @@
>>>>>>      }
>>>>>>
>>>>>>      private static void testSuper() throws Exception {
>>>>>> -        check(Object.class.getAnnotatedSuperclass().getAnnotations().length == 0);
>>>>>> +        check(Object.class.getAnnotatedSuperclass() == null);
>>>>>>          check(Class.class.getAnnotatedSuperclass().getAnnotations().length == 0);
>>>>>>
>>>>>>          AnnotatedType a;
>>>>>> diff -r b07b19182e40 test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java
>>>>>> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
>>>>>> +++ b/test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java	Fri Aug 16 13:20:31 2013 +0200
>>>>>> @@ -0,0 +1,50 @@
>>>>>> +/*
>>>>>> + * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
>>>>>> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>>> + *
>>>>>> + * This code is free software; you can redistribute it and/or modify it
>>>>>> + * under the terms of the GNU General Public License version 2 only, as
>>>>>> + * published by the Free Software Foundation.
>>>>>> + *
>>>>>> + * This code is distributed in the hope that it will be useful, but WITHOUT
>>>>>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>>>>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>>>>> + * version 2 for more details (a copy is included in the LICENSE file that
>>>>>> + * accompanied this code).
>>>>>> + *
>>>>>> + * You should have received a copy of the GNU General Public License version
>>>>>> + * 2 along with this work; if not, write to the Free Software Foundation,
>>>>>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>>>> + *
>>>>>> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>>>>> + * or visit www.oracle.com if you need additional information or have any
>>>>>> + * questions.
>>>>>> + */
>>>>>> +
>>>>>> +/*
>>>>>> + * @test
>>>>>> + * @bug 8022343
>>>>>> + * @summary make sure Class.getAnnotatedSuperclass() returns null when specified to do so
>>>>>> + */
>>>>>> +
>>>>>> +import java.util.*;
>>>>>> +import java.lang.annotation.*;
>>>>>> +import java.lang.reflect.*;
>>>>>> +import java.io.Serializable;
>>>>>> +
>>>>>> +public class GetAnnotatedSuperclass {
>>>>>> +    public static void main(String[] args) throws Exception {
>>>>>> +        check(Object.class.getAnnotatedSuperclass() == null);
>>>>>> +        check(If.class.getAnnotatedSuperclass() == null);
>>>>>> +        check(Object[].class.getAnnotatedSuperclass() == null);
>>>>>> +        check(void.class.getAnnotatedSuperclass() == null);
>>>>>> +        check(int.class.getAnnotatedSuperclass() == null);
>>>>>> +    }
>>>>>> +
>>>>>> +    private static void check(boolean b) {
>>>>>> +        if (!b)
>>>>>> +            throw new RuntimeException();
>>>>>> +    }
>>>>>> +    interface If {}
>>>>>> +}
>>>>>> +



From daniel.fuchs at oracle.com  Fri Aug 23 17:26:29 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 23 Aug 2013 19:26:29 +0200
Subject: RFR: 8005899: Logger.getLogger(name, null) should not allow to
	reset a non-null resource bundle
In-Reply-To: <521784C4.4070201@oracle.com>
References: <5217749E.2070603@oracle.com> <521784C4.4070201@oracle.com>
Message-ID: <52179B45.5090002@oracle.com>

On 8/23/13 5:50 PM, Mandy Chung wrote:
> Hi Daniel,
>
> The fix looks good.   It might be good to clarify the spec in the case
> when the given resourceBundleName parameter is null?   Perhaps in the
> @params resourceBundleName of the getLogger(String, String) method.
>
>     * @param   resourceBundleName  name of ResourceBundle to be used for
> localizing
>     *                          messages for this logger. May be
> null if none of
>     *                          the messages require localization.
>
> perhaps clarify that null only if the logger does not have a
> localization resource bundle set.

Thanks Lance and Mandy!

I have updated the webrev as per your suggestion:



-- daniel
>
> thanks
> Mandy
>
> On 8/23/2013 7:41 AM, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a fix for:
>>
>> 8005899: Logger.getLogger(name, null) should not allow to reset
>>          a non-null resource bundle
>>
>> The issue here is that whereas in JDK 7,
>>     Logger.getLogger("foo", null);
>> will throw an IllegalArgumentException if "foo" has a non null
>> bundle name, JDK 8 will simply ignore the 'null' parameter and
>> behave as
>>     Logger.getLogger("foo");
>>
>> The fix below restores the IllegalArgumentException in JDK 8.
>>
>> 
>>
>> best regards,
>>
>> -- daniel
>



From mandy.chung at oracle.com  Fri Aug 23 17:28:12 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 23 Aug 2013 10:28:12 -0700
Subject: RFR: 8005899: Logger.getLogger(name, null) should not allow to
	reset a non-null resource bundle
In-Reply-To: <52179B45.5090002@oracle.com>
References: <5217749E.2070603@oracle.com> <521784C4.4070201@oracle.com>
	<52179B45.5090002@oracle.com>
Message-ID: <52179BAC.3050507@oracle.com>

Thumbs up.

thanks
Mandy

On 8/23/2013 10:26 AM, Daniel Fuchs wrote:
> On 8/23/13 5:50 PM, Mandy Chung wrote:
>> Hi Daniel,
>>
>> The fix looks good.   It might be good to clarify the spec in the case
>> when the given resourceBundleName parameter is null?   Perhaps in the
>> @params resourceBundleName of the getLogger(String, String) method.
>>
>>     * @param   resourceBundleName  name of ResourceBundle to be used for
>> localizing
>>     *                          messages for this logger. May be
>> null if none of
>>     *                          the messages require localization.
>>
>> perhaps clarify that null only if the logger does not have a
>> localization resource bundle set.
>
> Thanks Lance and Mandy!
>
> I have updated the webrev as per your suggestion:
>
> 
>
> -- daniel
>>
>> thanks
>> Mandy
>>
>> On 8/23/2013 7:41 AM, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Please find below a fix for:
>>>
>>> 8005899: Logger.getLogger(name, null) should not allow to reset
>>>          a non-null resource bundle
>>>
>>> The issue here is that whereas in JDK 7,
>>>     Logger.getLogger("foo", null);
>>> will throw an IllegalArgumentException if "foo" has a non null
>>> bundle name, JDK 8 will simply ignore the 'null' parameter and
>>> behave as
>>>     Logger.getLogger("foo");
>>>
>>> The fix below restores the IllegalArgumentException in JDK 8.
>>>
>>> 
>>>
>>> best regards,
>>>
>>> -- daniel
>>
>



From Lance.Andersen at oracle.com  Fri Aug 23 17:30:56 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Fri, 23 Aug 2013 13:30:56 -0400
Subject: RFR: 8005899: Logger.getLogger(name,
	null) should not allow to reset a non-null resource bundle
In-Reply-To: <52179B45.5090002@oracle.com>
References: <5217749E.2070603@oracle.com> <521784C4.4070201@oracle.com>
	<52179B45.5090002@oracle.com>
Message-ID: <837894AD-8104-40AC-AAFF-598EEBAE3F77@oracle.com>

looks fine dan!

On Aug 23, 2013, at 1:26 PM, Daniel Fuchs wrote:

> On 8/23/13 5:50 PM, Mandy Chung wrote:
>> Hi Daniel,
>> 
>> The fix looks good.   It might be good to clarify the spec in the case
>> when the given resourceBundleName parameter is null?   Perhaps in the
>> @params resourceBundleName of the getLogger(String, String) method.
>> 
>>    * @param   resourceBundleName  name of ResourceBundle to be used for
>> localizing
>>    *                          messages for this logger. May be
>> null if none of
>>    *                          the messages require localization.
>> 
>> perhaps clarify that null only if the logger does not have a
>> localization resource bundle set.
> 
> Thanks Lance and Mandy!
> 
> I have updated the webrev as per your suggestion:
> 
> 
> 
> -- daniel
>> 
>> thanks
>> Mandy
>> 
>> On 8/23/2013 7:41 AM, Daniel Fuchs wrote:
>>> Hi,
>>> 
>>> Please find below a fix for:
>>> 
>>> 8005899: Logger.getLogger(name, null) should not allow to reset
>>>         a non-null resource bundle
>>> 
>>> The issue here is that whereas in JDK 7,
>>>    Logger.getLogger("foo", null);
>>> will throw an IllegalArgumentException if "foo" has a non null
>>> bundle name, JDK 8 will simply ignore the 'null' parameter and
>>> behave as
>>>    Logger.getLogger("foo");
>>> 
>>> The fix below restores the IllegalArgumentException in JDK 8.
>>> 
>>> 
>>> 
>>> best regards,
>>> 
>>> -- daniel
>> 
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From zhong.j.yu at gmail.com  Fri Aug 23 17:51:53 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Fri, 23 Aug 2013 12:51:53 -0500
Subject: RFR: 8023528: Rename Comparator combinators to disambiguate
	overloading methods
In-Reply-To: <105E048D-5F22-4EB4-8434-53CCBBCFB5EE@oracle.com>
References: <5216D531.5060900@oracle.com> <5216FA75.6040002@oracle.com>
	<105E048D-5F22-4EB4-8434-53CCBBCFB5EE@oracle.com>
Message-ID: 

I for one must express the concern that this is extremely ugly API. It
is another blow to the reputation of Java Language.

While we should not support overload with implicit lambda in general
cases, we should and can support it in the restricted case where all
overloading methods agree upon the lambda parameter types. This
restricted case happens to be the most common case where overload is
needed, e.g. Stream.map(), Comparator.comparing(). It is heartbreaking
to hear the decision of banning all overloads because of some bad
corner cases that won't likely happen in real code.

Zhong Yu


On Fri, Aug 23, 2013 at 11:11 AM, Henry Jen  wrote:
> Thanks Stuart for the review and correct link.
>
> Cheers,
> Henry
>
>
> On Aug 22, 2013, at 11:00 PM, Stuart Marks  wrote:
>
>> Hi Henry,
>>
>> Changes look good. It's also good to see some now-extra casts and type witnesses removed. It somewhat makes up for the longer, non-overloaded method names.
>>
>> Note, corrected email thread[2] link:
>>
>> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-August/002206.html
>>
>> s'marks
>>
>> On 8/22/13 8:21 PM, Henry Jen wrote:
>>> Hi,
>>>
>>> Please review a relative simple webrev[1] that basically simply renaming
>>> Comparator methods. The reason behind the renaming can be found at this
>>> email thread[2]. The specdiff is also available here[3].
>>>
>>> Cheers,
>>> Henry
>>>
>>> [1] http://cr.openjdk.java.net/~henryjen/ccc/8023528/0/webrev/
>>> [2]
>>> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-expert/2013-August/002206.html
>>> [3]
>>> http://cr.openjdk.java.net/~henryjen/ccc/8023528/0/specdiff/overview-summary.html
>>>
>


From brian.burkhalter at oracle.com  Fri Aug 23 18:32:17 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 23 Aug 2013 11:32:17 -0700
Subject: =?windows-1252?Q?Going_once=2C_going_twice_=85_=28Java_8_RFR_637?=
	=?windows-1252?Q?8503=3A_In_java=2Emath=2EBigDecimal=2C=09divisi?=
	=?windows-1252?Q?on_by_one_returns_zero=29?=
Message-ID: <6BF8C2F2-9DD9-42D0-8587-4D0A86B016BC@oracle.com>

JDK 8 Reviewers:

Might anyone be inclined to review (and approve?) the patch previous proposed in this posting?

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019581.html

Thanks,

Brian

From brian.burkhalter at oracle.com  Fri Aug 23 18:32:29 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 23 Aug 2013 11:32:29 -0700
Subject: Java 8 RFR 8010430: Math.round has surprising behavior for odd values
	of ulp	1
Message-ID: 

This message follows the RFC http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019560.html posted on August 2.

The issue is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010430.

The proposed patch http://cr.openjdk.java.net/~bpb/8010430/ has the effect of option (A) in the aforementioned RFC.

Thanks,

Brian

From daniel.fuchs at oracle.com  Fri Aug 23 19:02:10 2013
From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com)
Date: Fri, 23 Aug 2013 19:02:10 +0000
Subject: hg: jdk8/tl/jdk: 8005899: Logger.getLogger(name,
	null) should not allow to reset a non-null resource bundle
Message-ID: <20130823190232.AE95C48B16@hg.openjdk.java.net>

Changeset: 4ef82445ea20
Author:    dfuchs
Date:      2013-08-23 20:59 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ef82445ea20

8005899: Logger.getLogger(name, null) should not allow to reset a non-null resource bundle
Reviewed-by: mchung, lancea

! src/share/classes/java/util/logging/Logger.java
+ test/java/util/logging/Logger/getLogger/TestLogger.java
+ test/java/util/logging/Logger/getLogger/testlogger/MyResource.java



From henry.jen at oracle.com  Fri Aug 23 19:17:49 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 23 Aug 2013 12:17:49 -0700
Subject: RFR: 8023681: Fix raw type warning caused by Sink
Message-ID: <5217B55D.2090005@oracle.com>

Hi,

Please kindly review the fix for eliminate some warnings in
java.util.stream package.

Chained Sink is an internal implementation detail, add the type for
downstream is more precise but verbose.

Included is also a couple other warnings cleanup.

http://cr.openjdk.java.net/~henryjen/tl/8023681.0/webrev/

Cheers,
Henry


From brian.goetz at oracle.com  Fri Aug 23 20:06:27 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 23 Aug 2013 16:06:27 -0400
Subject: RFR: 8023681: Fix raw type warning caused by Sink
In-Reply-To: <5217B55D.2090005@oracle.com>
References: <5217B55D.2090005@oracle.com>
Message-ID: <5217C0C3.5050108@oracle.com>

Nice.  +1.

On 8/23/2013 3:17 PM, Henry Jen wrote:
> Hi,
>
> Please kindly review the fix for eliminate some warnings in
> java.util.stream package.
>
> Chained Sink is an internal implementation detail, add the type for
> downstream is more precise but verbose.
>
> Included is also a couple other warnings cleanup.
>
> http://cr.openjdk.java.net/~henryjen/tl/8023681.0/webrev/
>
> Cheers,
> Henry
>


From mike.duigou at oracle.com  Fri Aug 23 20:13:36 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 23 Aug 2013 13:13:36 -0700
Subject: RFR: 8023528: Rename Comparator combinators to disambiguate
	overloading methods
In-Reply-To: <5216D531.5060900@oracle.com>
References: <5216D531.5060900@oracle.com>
Message-ID: 

Looks OK to me.

Mike

On Aug 22 2013, at 20:21 , Henry Jen wrote:

> Hi,
> 
> Please review a relative simple webrev[1] that basically simply renaming
> Comparator methods. The reason behind the renaming can be found at this
> email thread[2]. The specdiff is also available here[3].
> 
> Cheers,
> Henry
> 
> [1] http://cr.openjdk.java.net/~henryjen/ccc/8023528/0/webrev/
> [2]
> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-expert/2013-August/002206.html
> [3]
> http://cr.openjdk.java.net/~henryjen/ccc/8023528/0/specdiff/overview-summary.html



From dmitry.nadezhin at gmail.com  Fri Aug 23 20:24:37 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Sat, 24 Aug 2013 00:24:37 +0400
Subject: Java 8 RFR 8010430: Math.round has surprising behavior for odd
	values of ulp 1
In-Reply-To: 
References: 
Message-ID: 

The specification of java.lang.Math.round() says
    * Returns the closest {@code int} to the argument, with ties
     * rounding up.

It is not clarified what is "ties rounding up".
I guess that it should correspond to the direction "roundTiesToAway" of
IEEE 754-2008
and to the java.math.RoundingMode.HALF_UP .

They round
+0.5 -> +1
-0.5 -> -1

The current implementation of java.lang.Math.round() rounds
+0.5 -> +1
-0.5 -> 0

"ties rounding up" should match IEEE754 standard and other JDK math class,
shouldn't it ?


On Fri, Aug 23, 2013 at 10:32 PM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> This message follows the RFC
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019560.htmlposted on August 2.
>
> The issue is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010430.
>
> The proposed patch http://cr.openjdk.java.net/~bpb/8010430/ has the
> effect of option (A) in the aforementioned RFC.
>
> Thanks,
>
> Brian


From brian.burkhalter at oracle.com  Fri Aug 23 20:32:44 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 23 Aug 2013 13:32:44 -0700
Subject: Java 8 RFR 8010430: Math.round has surprising behavior for odd
	values of ulp 1
In-Reply-To: 
References: 
	
Message-ID: <0099615E-F51D-47C4-9330-582911BBD3EF@oracle.com>

With respect to this issue, the argument satisfies the condition

a == (int)a

or

a == (long)a

so there really is no tie, unless I am missing something. The problem is that in the current implementation the intermediate result

a + 0.5

is rounded according to the IEEE standard so the conditions above are no longer true.

On Aug 23, 2013, at 1:24 PM, Dmitry Nadezhin wrote:

> The specification of java.lang.Math.round() says
>    * Returns the closest {@code int} to the argument, with ties
>     * rounding up.
> 
> It is not clarified what is "ties rounding up".
> I guess that it should correspond to the direction "roundTiesToAway" of
> IEEE 754-2008
> and to the java.math.RoundingMode.HALF_UP .
> 
> They round
> +0.5 -> +1
> -0.5 -> -1
> 
> The current implementation of java.lang.Math.round() rounds
> +0.5 -> +1
> -0.5 -> 0
> 
> "ties rounding up" should match IEEE754 standard and other JDK math class,
> shouldn't it ?



From guy.steele at oracle.com  Fri Aug 23 20:36:50 2013
From: guy.steele at oracle.com (Guy Steele)
Date: Fri, 23 Aug 2013 16:36:50 -0400
Subject: Java 8 RFR 8010430: Math.round has surprising behavior for odd
	values of ulp 1
In-Reply-To: 
References: 
	
Message-ID: <8A126477-C00A-4833-962D-BA1DE1BA0930@oracle.com>

The specification of java.lang.Math.round in the first edition of the
Java Language Specification is quite clear:

public static int round(float a)
  The result is rounded to an integer by adding 1/2, taking the floor of
  the result, and casting the result to type int.
  In other words, the result is equal to the value of the expression
	(int)Math.floor(a + 0.5f)

and a similar statement for the case where the type of the argument is double.

This does not correspond to "rounding away from zero" as in IEEE754.

The phrase "ties rounding up" entered the Java documentation later on
as a (perhaps unfortunately worded) shorthand for the original specification.

--Guy Steele


On Aug 23, 2013, at 4:24 PM, Dmitry Nadezhin  wrote:

> The specification of java.lang.Math.round() says
>    * Returns the closest {@code int} to the argument, with ties
>     * rounding up.
> 
> It is not clarified what is "ties rounding up".
> I guess that it should correspond to the direction "roundTiesToAway" of
> IEEE 754-2008
> and to the java.math.RoundingMode.HALF_UP .
> 
> They round
> +0.5 -> +1
> -0.5 -> -1
> 
> The current implementation of java.lang.Math.round() rounds
> +0.5 -> +1
> -0.5 -> 0
> 
> "ties rounding up" should match IEEE754 standard and other JDK math class,
> shouldn't it ?
> 
> 
> On Fri, Aug 23, 2013 at 10:32 PM, Brian Burkhalter <
> brian.burkhalter at oracle.com> wrote:
> 
>> This message follows the RFC
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019560.htmlposted on August 2.
>> 
>> The issue is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010430.
>> 
>> The proposed patch http://cr.openjdk.java.net/~bpb/8010430/ has the
>> effect of option (A) in the aforementioned RFC.
>> 
>> Thanks,
>> 
>> Brian



From dmitry.nadezhin at gmail.com  Fri Aug 23 20:44:11 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Sat, 24 Aug 2013 00:44:11 +0400
Subject: Java 8 RFR 8010430: Math.round has surprising behavior for odd
	values of ulp 1
In-Reply-To: <0099615E-F51D-47C4-9330-582911BBD3EF@oracle.com>
References: 
	
	<0099615E-F51D-47C4-9330-582911BBD3EF@oracle.com>
Message-ID: 

I guess that the method java.lang.Math.round() should correspond to
roundToIntegralTiesToAway of the IEEE 754-2008. Standard says about it
(section 5.9):
===
roundToIntegralTiesToAway(x) rounds x to the nearest integral value, with
halfway cases
rounding away from zero
===

So the halfway cases are n + 0.5 ( like -1.5, -0.5, +0.5, +1.5).
Standard says that roundToIntegralTiesToAway rounds them to (-2,-1,+1,+2).



On Sat, Aug 24, 2013 at 12:32 AM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> With respect to this issue, the argument satisfies the condition
>
> a == (int)a
>
> or
>
> a == (long)a
>
> so there really is no tie, unless I am missing something. The problem is
> that in the current implementation the intermediate result
>
> a + 0.5
>
> is rounded according to the IEEE standard so the conditions above are no
> longer true.
>
> On Aug 23, 2013, at 1:24 PM, Dmitry Nadezhin wrote:
>
> > The specification of java.lang.Math.round() says
> >    * Returns the closest {@code int} to the argument, with ties
> >     * rounding up.
> >
> > It is not clarified what is "ties rounding up".
> > I guess that it should correspond to the direction "roundTiesToAway" of
> > IEEE 754-2008
> > and to the java.math.RoundingMode.HALF_UP .
> >
> > They round
> > +0.5 -> +1
> > -0.5 -> -1
> >
> > The current implementation of java.lang.Math.round() rounds
> > +0.5 -> +1
> > -0.5 -> 0
> >
> > "ties rounding up" should match IEEE754 standard and other JDK math
> class,
> > shouldn't it ?
>
>


From omajid at redhat.com  Fri Aug 23 21:09:38 2013
From: omajid at redhat.com (Omair Majid)
Date: Fri, 23 Aug 2013 17:09:38 -0400
Subject: Additional source to guess the local timezone ID on linux
Message-ID: <5217CF92.9030307@redhat.com>

Hi,

The algorithm that OpenJDK uses to guess the local timezone ID on Linux
goes like this:

1. If TZ environment variable is set, use that
2. If /etc/timezone is readable, read the time zone from there
3. If /etc/localtime is a symlink, resolve that, and use the name to
guess the time zone.
4. Scan /usr/share/zoneinfo for a file whose contents match the contents
of /etc/localtime.

Step 4 (if it is ever reached) is probably going to lead to incorrect
results since there are a number of timezones that have the same
zoneinfo data (such as Europe/London and Europe/Belfast). So it seems
sensible to me to try and use additional sources to guess the timezone
ID before resorting to file content comparisons.

The webrev adds a step between 2 and 3 that reads and parses
/etc/sysconfig/clock to extract the timezone:

http://cr.openjdk.java.net/~omajid/webrevs/timezone-read-sysconfig-clock/00/

This file exists on some Red Hat Enterprise Linux (and derivative)
distributions and contains contents that look this:

> # The time zone of the system is defined by the contents of /etc/localtime.
> # This file is only for evaluation by system-config-date, do not rely on its
> # contents elsewhere.
> ZONE="Europe/Zurich"

With this, we should be able to identify the exact timezone ID.

Thanks,
Omair
-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681


From brian.burkhalter at oracle.com  Fri Aug 23 21:11:18 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 23 Aug 2013 14:11:18 -0700 (PDT)
Subject: Java 8 RFR 8010430: Math.round has surprising behavior for odd
	values of ulp 1
In-Reply-To: 
References: 
	
	<0099615E-F51D-47C4-9330-582911BBD3EF@oracle.com>
	
Message-ID: 

This is an interesting point and roundToIntegralTiesToAway() does have an appealing symmetry, but I think it is a broader issue than the constrained case I originally posted.

Whichever of the approaches obtains, it seems that if the floating point argument A represents a real number which is also in the space of integers (Z), then one would expect round(A) to equal A. I think this is what most programmers would expect. For what it's worth, this is what appears to be implemented in the C language (GCC 4.2.1).

Brian

On Aug 23, 2013, at 1:44 PM, Dmitry Nadezhin wrote:

> I guess that the method java.lang.Math.round() should correspond to
> roundToIntegralTiesToAway of the IEEE 754-2008. Standard says about it
> (section 5.9):
> ===
> roundToIntegralTiesToAway(x) rounds x to the nearest integral value, with
> halfway cases
> rounding away from zero
> ===
> 
> So the halfway cases are n + 0.5 ( like -1.5, -0.5, +0.5, +1.5).
> Standard says that roundToIntegralTiesToAway rounds them to (-2,-1,+1,+2).



From martinrb at google.com  Fri Aug 23 21:13:28 2013
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 23 Aug 2013 14:13:28 -0700
Subject: =?windows-1252?Q?Re=3A_Going_once=2C_going_twice_=85_=28Java_8_RFR_6378503=3A?=
	=?windows-1252?Q?_In_java=2Emath=2EBigDecimal=2C_division_by_one_returns_zero=29?=
In-Reply-To: <6BF8C2F2-9DD9-42D0-8587-4D0A86B016BC@oracle.com>
References: <6BF8C2F2-9DD9-42D0-8587-4D0A86B016BC@oracle.com>
Message-ID: 

Reviewer of last resort here.

Looks good to me!


On Fri, Aug 23, 2013 at 11:32 AM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> JDK 8 Reviewers:
>
> Might anyone be inclined to review (and approve?) the patch previous
> proposed in this posting?
>
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019581.html
>
> Thanks,
>
> Brian


From mike.duigou at oracle.com  Fri Aug 23 21:14:15 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 23 Aug 2013 14:14:15 -0700
Subject: RFR: 8023681: Fix raw type warning caused by Sink
In-Reply-To: <5217B55D.2090005@oracle.com>
References: <5217B55D.2090005@oracle.com>
Message-ID: 

Nice cleanups. Looks good!

Mike

On Aug 23 2013, at 12:17 , Henry Jen wrote:

> Hi,
> 
> Please kindly review the fix for eliminate some warnings in
> java.util.stream package.
> 
> Chained Sink is an internal implementation detail, add the type for
> downstream is more precise but verbose.
> 
> Included is also a couple other warnings cleanup.
> 
> http://cr.openjdk.java.net/~henryjen/tl/8023681.0/webrev/
> 
> Cheers,
> Henry
> 



From brian.burkhalter at oracle.com  Fri Aug 23 21:15:21 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 23 Aug 2013 14:15:21 -0700 (PDT)
Subject: =?UTF-8?B?UmU6IEdvaW5nIG9uY2UsIGdvaW5nIHR3aWM=?=
	=?UTF-8?B?ZSDigKYgKEphdmEgOCBSRlIgNjM3ODUwMzogSQ==?=
	=?UTF-8?B?biBqYXZhLm1hdGguQmlnRGVjaW1hbCwgZGk=?=
	=?UTF-8?B?dmlzaW9uIGJ5IG9uZSByZXR1cm5zIHplcm8p?=
In-Reply-To: 
References: <6BF8C2F2-9DD9-42D0-8587-4D0A86B016BC@oracle.com>
	
Message-ID: <4C4C60BB-1433-4CB8-AAB0-9210EDCEF82E@oracle.com>

Thank you kind sir!

Brian

On Aug 23, 2013, at 2:13 PM, Martin Buchholz wrote:

> Reviewer of last resort here.
> 
> Looks good to me!
> 



From ali.ebrahimi1781 at gmail.com  Fri Aug 23 21:18:51 2013
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Sat, 24 Aug 2013 01:48:51 +0430
Subject: RFR: 8023681: Fix raw type warning caused by Sink
In-Reply-To: <5217B55D.2090005@oracle.com>
References: <5217B55D.2090005@oracle.com>
Message-ID: 

Why not to make castingIdentity method a constant?


On Fri, Aug 23, 2013 at 11:47 PM, Henry Jen  wrote:

> Hi,
>
> Please kindly review the fix for eliminate some warnings in
> java.util.stream package.
>
> Chained Sink is an internal implementation detail, add the type for
> downstream is more precise but verbose.
>
> Included is also a couple other warnings cleanup.
>
> http://cr.openjdk.java.net/~henryjen/tl/8023681.0/webrev/
>
> Cheers,
> Henry
>
>


From guy.steele at oracle.com  Fri Aug 23 21:33:45 2013
From: guy.steele at oracle.com (Guy Steele)
Date: Fri, 23 Aug 2013 17:33:45 -0400
Subject: Java 8 RFR 8010430: Math.round has surprising behavior for odd
	values of ulp 1
In-Reply-To: 
References: 
	
	<0099615E-F51D-47C4-9330-582911BBD3EF@oracle.com>
	
Message-ID: <31B41145-9166-46B1-9E24-7C5611189577@oracle.com>

There seem to be two distinct issues here:

(1) As originally specified in the first edition of JLS, java.lang.Math.round sometimes
accepts an argument that is equal to a mathematical integer and returns a value that
is another (larger) mathematical integer because IEEE rounding occurs in the addition
of the value 1/2.  Arguably this could be regarded as a mistake in that original
specification, and if I understand correctly, this is the point of the logged issue.

(2) Now you have raised the question of whether this same method java.lang.Math.round
"should" be the same as the operation roundToIntegralTiesToAway of IEEE 754-2008,
or some other operation in some version of IEEE 754.  I assure you that such a correspondence
was never the intent of the original specification; the rounding performed by java.lang.Math.round
and by roundToIntegralTiesToAway are two different kinds of rounding (among many others
that are possible), and it is a mistake to think that they "should" be the same.  If we would like
for Java to support the IEEE 754-2008 operation roundToIntegralTiesToAway, then that method
should have a different name; in fact, "roundToIntegralTiesToAway" would be a good name.  :-)

--Guy

On Aug 23, 2013, at 4:44 PM, Dmitry Nadezhin  wrote:

> I guess that the method java.lang.Math.round() should correspond to
> roundToIntegralTiesToAway of the IEEE 754-2008. Standard says about it
> (section 5.9):
> ===
> roundToIntegralTiesToAway(x) rounds x to the nearest integral value, with
> halfway cases
> rounding away from zero
> ===
> 
> So the halfway cases are n + 0.5 ( like -1.5, -0.5, +0.5, +1.5).
> Standard says that roundToIntegralTiesToAway rounds them to (-2,-1,+1,+2).
> 
> 
> 
> On Sat, Aug 24, 2013 at 12:32 AM, Brian Burkhalter <
> brian.burkhalter at oracle.com> wrote:
> 
>> With respect to this issue, the argument satisfies the condition
>> 
>> a == (int)a
>> 
>> or
>> 
>> a == (long)a
>> 
>> so there really is no tie, unless I am missing something. The problem is
>> that in the current implementation the intermediate result
>> 
>> a + 0.5
>> 
>> is rounded according to the IEEE standard so the conditions above are no
>> longer true.
>> 
>> On Aug 23, 2013, at 1:24 PM, Dmitry Nadezhin wrote:
>> 
>>> The specification of java.lang.Math.round() says
>>>   * Returns the closest {@code int} to the argument, with ties
>>>    * rounding up.
>>> 
>>> It is not clarified what is "ties rounding up".
>>> I guess that it should correspond to the direction "roundTiesToAway" of
>>> IEEE 754-2008
>>> and to the java.math.RoundingMode.HALF_UP .
>>> 
>>> They round
>>> +0.5 -> +1
>>> -0.5 -> -1
>>> 
>>> The current implementation of java.lang.Math.round() rounds
>>> +0.5 -> +1
>>> -0.5 -> 0
>>> 
>>> "ties rounding up" should match IEEE754 standard and other JDK math
>> class,
>>> shouldn't it ?
>> 
>> 



From henry.jen at oracle.com  Fri Aug 23 21:35:27 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 23 Aug 2013 14:35:27 -0700
Subject: RFR: 8022176: Weaken contract of java.lang.AutoCloseable
Message-ID: <5217D59F.80206@oracle.com>

Hi,

Please review the javadoc spec change for AutoCloseable.

Basically, it clarifies that AutoCloseable is to be automatically closed
with try-with-resource construct, and the implementation may or may not
hold resources that need to be closed.

http://cr.openjdk.java.net/~henryjen/ccc/8022176/webrev/

Cheers,
Henry




From mike.duigou at oracle.com  Fri Aug 23 21:40:44 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 23 Aug 2013 14:40:44 -0700
Subject: RFR: 8023681: Fix raw type warning caused by Sink
In-Reply-To: 
References: <5217B55D.2090005@oracle.com>
	
Message-ID: 

I considered that as well but since the types are generics you'd have to cast anyway.

The only viable declaration is:

private static Function CASTING_IDENTITY = i -> i;

On usage you'd have to add (Function) CASTING_IDENTITY

(Which assumes the compiler would even accept this heinous cast, I haven't tried it)

Mike

On Aug 23 2013, at 14:18 , Ali Ebrahimi wrote:

> Why not to make castingIdentity method a constant?
> 
> 
> On Fri, Aug 23, 2013 at 11:47 PM, Henry Jen  wrote:
> 
>> Hi,
>> 
>> Please kindly review the fix for eliminate some warnings in
>> java.util.stream package.
>> 
>> Chained Sink is an internal implementation detail, add the type for
>> downstream is more precise but verbose.
>> 
>> Included is also a couple other warnings cleanup.
>> 
>> http://cr.openjdk.java.net/~henryjen/tl/8023681.0/webrev/
>> 
>> Cheers,
>> Henry
>> 
>> 



From brian.goetz at oracle.com  Fri Aug 23 21:44:45 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 23 Aug 2013 17:44:45 -0400
Subject: RFR: 8023681: Fix raw type warning caused by Sink
In-Reply-To: 
References: <5217B55D.2090005@oracle.com>
	
Message-ID: <5217D7CD.5060409@oracle.com>

Because non-capturing lambdas are *already* constants!  The commonly 
used trick, that was needed with inner classes to avoid instantiating 
multiple instances of essentially identical objects:

   static final Comparator c = new Comparator() { ... }

is effectively implemented automatically (and lazily, instantiated only 
on first use) by the language runtime for non-capturing lambdas.  So the 
"extract into a static" trick can be relegated to the scrap heap of 
"optimizations that don't optimize but still crap up your code".

And, since the method castingIdentity() returns a constant, it will be 
routinely inlined into a constant load.

On 8/23/2013 5:18 PM, Ali Ebrahimi wrote:
> Why not to make castingIdentity method a constant?
>
>
> On Fri, Aug 23, 2013 at 11:47 PM, Henry Jen  wrote:
>
>> Hi,
>>
>> Please kindly review the fix for eliminate some warnings in
>> java.util.stream package.
>>
>> Chained Sink is an internal implementation detail, add the type for
>> downstream is more precise but verbose.
>>
>> Included is also a couple other warnings cleanup.
>>
>> http://cr.openjdk.java.net/~henryjen/tl/8023681.0/webrev/
>>
>> Cheers,
>> Henry
>>
>>


From ali.ebrahimi1781 at gmail.com  Fri Aug 23 21:55:53 2013
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Sat, 24 Aug 2013 02:25:53 +0430
Subject: RFR: 8023681: Fix raw type warning caused by Sink
In-Reply-To: 
References: <5217B55D.2090005@oracle.com>
	
	
Message-ID: 

you can try this.

    private static Function CASTING_IDENTITY = i -> i;

    @SuppressWarnings("unchecked")
    private static  Function castingIdentity() {
         return (Function) CASTING_IDENTITY;
    }


On Sat, Aug 24, 2013 at 2:10 AM, Mike Duigou  wrote:

> I considered that as well but since the types are generics you'd have to
> cast anyway.
>
> The only viable declaration is:
>
> private static Function CASTING_IDENTITY = i -> i;
>
> On usage you'd have to add (Function) CASTING_IDENTITY
>
> (Which assumes the compiler would even accept this heinous cast, I haven't
> tried it)
>
> Mike
>
> On Aug 23 2013, at 14:18 , Ali Ebrahimi wrote:
>
> > Why not to make castingIdentity method a constant?
> >
> >
> > On Fri, Aug 23, 2013 at 11:47 PM, Henry Jen 
> wrote:
> >
> >> Hi,
> >>
> >> Please kindly review the fix for eliminate some warnings in
> >> java.util.stream package.
> >>
> >> Chained Sink is an internal implementation detail, add the type for
> >> downstream is more precise but verbose.
> >>
> >> Included is also a couple other warnings cleanup.
> >>
> >> http://cr.openjdk.java.net/~henryjen/tl/8023681.0/webrev/
> >>
> >> Cheers,
> >> Henry
> >>
> >>
>
>


From mike.duigou at oracle.com  Fri Aug 23 22:13:16 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 23 Aug 2013 15:13:16 -0700
Subject: RFR: 8022176: Weaken contract of java.lang.AutoCloseable
In-Reply-To: <5217D59F.80206@oracle.com>
References: <5217D59F.80206@oracle.com>
Message-ID: <1D0751FC-3E60-4065-A7DD-14E5477FCB35@oracle.com>

Looks like the same text as agreed on the Lambda EG list. So, +1

Mike

On Aug 23 2013, at 14:35 , Henry Jen wrote:

> Hi,
> 
> Please review the javadoc spec change for AutoCloseable.
> 
> Basically, it clarifies that AutoCloseable is to be automatically closed
> with try-with-resource construct, and the implementation may or may not
> hold resources that need to be closed.
> 
> http://cr.openjdk.java.net/~henryjen/ccc/8022176/webrev/
> 
> Cheers,
> Henry
> 
> 



From brent.christian at oracle.com  Fri Aug 23 23:35:04 2013
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 23 Aug 2013 16:35:04 -0700
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets
	or trees (red/black)
In-Reply-To: 
References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
	
	
	
Message-ID: <5217F1A8.2000503@oracle.com>

On 8/22/13 5:01 AM, Paul Sandoz wrote:
> On Aug 21, 2013, at 6:47 PM, Paul Sandoz  wrote:
>> I updated the webrev and replaced TreeBinSplitBackToEntries.java with:
>>
>>   http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/test/java/util/Map/MapBinToFromTreeTest.java.html
 >
 > Another tweak to ensure untreeify is tested on resize (use the same
 > URL above). I think at this point the tests are in reasonable shape
 > and are on a par with previous tests.

The new MapBinToFromTreeTest code looks good.  I confirmed that it hits 
the 4 main cases in split() (tree/untreeify for loHead/hiHead).

(FWIW, I don't believe the entire split() tree ever lands all in one bin 
(loHead and hiHead are never null), though it's possible that it could.)

I agree that we should check back on the code coverage results and 
update the tests as needed.


I've focused on looking at portions of HashMap that I recall being 
tricky (split, treeify, etc).  So far it all looks fine to me.

-Brent


From brian.burkhalter at oracle.com  Fri Aug 23 23:39:10 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 23 Aug 2013 16:39:10 -0700
Subject: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source
	of bottlenecks
Message-ID: <050BDF31-D4C5-447D-A445-38E662A925E4@oracle.com>

With respect to this issue

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7189139

any comments on this potential fix

file:///Users/bpb/Work/JSL/jdk/jdk8/tl8/jdk/7189139/index.html

would be appreciated.

Rudimentary testing with JMH (http://openjdk.java.net/projects/code-tools/jmh/) did not reveal any deleterious performance effects in single-threaded operation nor any obvious improvements in the dual threaded case but testing was done on on my aging Core 2 Duo notebook and is not likely representative of anything approaching real world conditions.

Thanks,

Brian

From brian.burkhalter at oracle.com  Fri Aug 23 23:41:02 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 23 Aug 2013 16:41:02 -0700
Subject: Java 8 RFC 7189139: BigInteger's staticRandom field can be a
	source of bottlenecks
In-Reply-To: <050BDF31-D4C5-447D-A445-38E662A925E4@oracle.com>
References: <050BDF31-D4C5-447D-A445-38E662A925E4@oracle.com>
Message-ID: 


On Aug 23, 2013, at 4:39 PM, Brian Burkhalter wrote:

> With respect to this issue
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7189139
> 
> any comments on this potential fix
> 
> file:///Users/bpb/Work/JSL/jdk/jdk8/tl8/jdk/7189139/index.html

Correction to this webrev link:

http://cr.openjdk.java.net/~bpb/7189139/

D'oh.

> 
> would be appreciated.
> 
> Rudimentary testing with JMH (http://openjdk.java.net/projects/code-tools/jmh/) did not reveal any deleterious performance effects in single-threaded operation nor any obvious improvements in the dual threaded case but testing was done on on my aging Core 2 Duo notebook and is not likely representative of anything approaching real world conditions.
> 
> Thanks,
> 
> Brian



From mike.duigou at oracle.com  Sat Aug 24 00:06:38 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 23 Aug 2013 17:06:38 -0700
Subject: Java 8 RFC 7189139: BigInteger's staticRandom field can be a
	source of bottlenecks
In-Reply-To: 
References: <050BDF31-D4C5-447D-A445-38E662A925E4@oracle.com>
	
Message-ID: <55867AB3-D0B6-4EF3-9C93-BC9396EE2EEF@oracle.com>

I would strongly recommend holding back on this change until someone familiar with the crypto implications takes a look at it. Unfortunately neither the random constructor nor probablePrime indicate any expectations regarding the quality of random numbers needed from the offered PRNG.

- Changing a SecureRandom to a regular non-crypto PRNG causes alarm bells for me. It also surprises me that a method named getSecureRandom() doesn't return a SecureRandom instance! I am not sure to what extent the MillerRabin method actually needs a secure random number generator.

- I ran out of time looking but what public code path results in getSecureRandom() being called? The public methods which take a Random don't seem to allow it to be null.

Urging extreme caution,

Mike


On Aug 23 2013, at 16:41 , Brian Burkhalter wrote:

> 
> On Aug 23, 2013, at 4:39 PM, Brian Burkhalter wrote:
> 
>> With respect to this issue
>> 
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7189139
>> 
>> any comments on this potential fix
>> 
>> file:///Users/bpb/Work/JSL/jdk/jdk8/tl8/jdk/7189139/index.html
> 
> Correction to this webrev link:
> 
> http://cr.openjdk.java.net/~bpb/7189139/
> 
> D'oh.
> 
>> 
>> would be appreciated.
>> 
>> Rudimentary testing with JMH (http://openjdk.java.net/projects/code-tools/jmh/) did not reveal any deleterious performance effects in single-threaded operation nor any obvious improvements in the dual threaded case but testing was done on on my aging Core 2 Duo notebook and is not likely representative of anything approaching real world conditions.
>> 
>> Thanks,
>> 
>> Brian
> 



From brian.burkhalter at oracle.com  Sat Aug 24 00:10:56 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 23 Aug 2013 17:10:56 -0700
Subject: Java 8 RFC 7189139: BigInteger's staticRandom field can be a
	source of bottlenecks
In-Reply-To: <55867AB3-D0B6-4EF3-9C93-BC9396EE2EEF@oracle.com>
References: <050BDF31-D4C5-447D-A445-38E662A925E4@oracle.com>
	
	<55867AB3-D0B6-4EF3-9C93-BC9396EE2EEF@oracle.com>
Message-ID: <77D98FAA-2156-4418-B308-F3EC3F9E216D@oracle.com>


On Aug 23, 2013, at 5:06 PM, Mike Duigou wrote:

> I would strongly recommend holding back on this change until someone familiar with the crypto implications takes a look at it. Unfortunately neither the random constructor nor probablePrime indicate any expectations regarding the quality of random numbers needed from the offered PRNG.
> 
> - Changing a SecureRandom to a regular non-crypto PRNG causes alarm bells for me. It also surprises me that a method named getSecureRandom() doesn't return a SecureRandom instance! I am not sure to what extent the MillerRabin method actually needs a secure random number generator.

It is still a SecureRandom():
 925                 protected Random initialValue() {
 926                     return new java.security.SecureRandom();
 927                 }
> - I ran out of time looking but what public code path results in getSecureRandom() being called? The public methods which take a Random don't seem to allow it to be null.

isProbablePrime(int).

> Urging extreme caution,

Thanks for the comments.

Brian

From mike.duigou at oracle.com  Sat Aug 24 01:18:33 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 23 Aug 2013 18:18:33 -0700
Subject: Java 8 RFC 7189139: BigInteger's staticRandom field can be a
	source of bottlenecks
In-Reply-To: <77D98FAA-2156-4418-B308-F3EC3F9E216D@oracle.com>
References: <050BDF31-D4C5-447D-A445-38E662A925E4@oracle.com>
	
	<55867AB3-D0B6-4EF3-9C93-BC9396EE2EEF@oracle.com>
	<77D98FAA-2156-4418-B308-F3EC3F9E216D@oracle.com>
Message-ID: <1DE9FEF6-A351-493E-9753-5F2E238DB761@oracle.com>


On Aug 23 2013, at 17:10 , Brian Burkhalter wrote:

> 
> On Aug 23, 2013, at 5:06 PM, Mike Duigou wrote:
> 
>> I would strongly recommend holding back on this change until someone familiar with the crypto implications takes a look at it. Unfortunately neither the random constructor nor probablePrime indicate any expectations regarding the quality of random numbers needed from the offered PRNG.

Should we be offering advice regarding the random number generator in the API docs?

>> 
>> - Changing a SecureRandom to a regular non-crypto PRNG causes alarm bells for me. It also surprises me that a method named getSecureRandom() doesn't return a SecureRandom instance! I am not sure to what extent the MillerRabin method actually needs a secure random number generator.
> 
> It is still a SecureRandom():

DOH. I somehow read this as using the new ThreadLocalRandom class. Sorry about the panic.

I would still change the return type of getSecureRandom() and threadRandom's type to SecureRandom.

>  925                 protected Random initialValue() {
>  926                     return new java.security.SecureRandom();
>  927                 }
>> - I ran out of time looking but what public code path results in getSecureRandom() being called? The public methods which take a Random don't seem to allow it to be null.
> 
> isProbablePrime(int).
> 
> 
> Thanks for the comments.
> 
> Brian



From dmitry.nadezhin at gmail.com  Sat Aug 24 03:17:41 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Sat, 24 Aug 2013 07:17:41 +0400
Subject: Java 8 RFR 8010430: Math.round has surprising behavior for odd
	values of ulp 1
In-Reply-To: 
References: 
	
	<0099615E-F51D-47C4-9330-582911BBD3EF@oracle.com>
	
	
Message-ID: 

Guy pointed to JLS 1 semantics. Yes, it was clearer.
Ok. I agree that java.lang.Math.round() and IEEE 754-2008
roundToIntegralTiesToAway() has different semantics.
The current API specification is a little misleading.

I tried to implement JLS 1 semantics in a bit-twiddling way:
===
    public static int round(float a) {
        int intBits = Float.floatToRawIntBits(a);
        int biasedExp = (intBits & FloatConsts.EXP_BIT_MASK) >>
(FloatConsts.SIGNIFICAND_WIDTH - 1);
        int shift = (FloatConsts.SIGNIFICAND_WIDTH - 2 +
FloatConsts.EXP_BIAS) - biasedExp;
        if ((shift & -32) == 0) { // shift >= 0 && shift < 32
            int r = ((intBits & FloatConsts.SIGNIF_BIT_MASK) |
(FloatConsts.SIGNIF_BIT_MASK + 1));
            if (intBits < 0) r = -r;
            return ((r >> shift) + 1) >> 1;
        } else {
            return (int) a;
        }
    }
===

I did't compare performance of this bit-twiddling code with performance of
current code.
I need to choose a microbenchmark tool.
Previously I used the Caliper. I see that OpenJDK suggests another tool:
http://openjdk.java.net/projects/code-tools/jmh/

Nevertheless, I send this variant now in hope that it may be useful.


On Sat, Aug 24, 2013 at 1:11 AM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> This is an interesting point and roundToIntegralTiesToAway() does have an
> appealing symmetry, but I think it is a broader issue than the constrained
> case I originally posted.
>
> Whichever of the approaches obtains, it seems that if the floating point
> argument A represents a real number which is also in the space of integers
> (Z), then one would expect round(A) to equal A. I think this is what most
> programmers would expect. For what it's worth, this is what appears to be
> implemented in the C language (GCC 4.2.1).
>
> Brian
>
> On Aug 23, 2013, at 1:44 PM, Dmitry Nadezhin wrote:
>
> > I guess that the method java.lang.Math.round() should correspond to
> > roundToIntegralTiesToAway of the IEEE 754-2008. Standard says about it
> > (section 5.9):
> > ===
> > roundToIntegralTiesToAway(x) rounds x to the nearest integral value, with
> > halfway cases
> > rounding away from zero
> > ===
> >
> > So the halfway cases are n + 0.5 ( like -1.5, -0.5, +0.5, +1.5).
> > Standard says that roundToIntegralTiesToAway rounds them to
> (-2,-1,+1,+2).
>
>


From Alan.Bateman at oracle.com  Sat Aug 24 08:36:46 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 24 Aug 2013 09:36:46 +0100
Subject: RFR: 8022176: Weaken contract of java.lang.AutoCloseable
In-Reply-To: <5217D59F.80206@oracle.com>
References: <5217D59F.80206@oracle.com>
Message-ID: <5218709E.6070309@oracle.com>

On 23/08/2013 22:35, Henry Jen wrote:
> Hi,
>
> Please review the javadoc spec change for AutoCloseable.
>
> Basically, it clarifies that AutoCloseable is to be automatically closed
> with try-with-resource construct, and the implementation may or may not
> hold resources that need to be closed.
>
> http://cr.openjdk.java.net/~henryjen/ccc/8022176/webrev/
>
I realize this might be agreed wording but I wonder about the term 
"header", shouldn't this be "resource specification"?

A minor comment but maybe it should be "I/O" (rather than "IO") to be 
consistent with the other javadoc.

-Alan.


From chris.hegarty at oracle.com  Sat Aug 24 12:44:26 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sat, 24 Aug 2013 13:44:26 +0100
Subject: RFR: 8022176: Weaken contract of java.lang.AutoCloseable
In-Reply-To: <1D0751FC-3E60-4065-A7DD-14E5477FCB35@oracle.com>
References: <5217D59F.80206@oracle.com>
	<1D0751FC-3E60-4065-A7DD-14E5477FCB35@oracle.com>
Message-ID: <5218AAAA.4080309@oracle.com>

On 23/08/2013 23:13, Mike Duigou wrote:
> Looks like the same text as agreed on the Lambda EG list. So, +1

Yeap, looks good to me too. ( It has been a long road! )

-Chris.

>
> Mike
>
> On Aug 23 2013, at 14:35 , Henry Jen wrote:
>
>> Hi,
>>
>> Please review the javadoc spec change for AutoCloseable.
>>
>> Basically, it clarifies that AutoCloseable is to be automatically closed
>> with try-with-resource construct, and the implementation may or may not
>> hold resources that need to be closed.
>>
>> http://cr.openjdk.java.net/~henryjen/ccc/8022176/webrev/
>>
>> Cheers,
>> Henry
>>
>>
>
>


From dl at cs.oswego.edu  Sat Aug 24 13:09:13 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Sat, 24 Aug 2013 09:09:13 -0400
Subject: RFR: 8022176: Weaken contract of java.lang.AutoCloseable
In-Reply-To: <5218709E.6070309@oracle.com>
References: <5217D59F.80206@oracle.com> <5218709E.6070309@oracle.com>
Message-ID: <5218B079.8000706@cs.oswego.edu>

On 08/24/2013 04:36 AM, Alan Bateman wrote:
> On 23/08/2013 22:35, Henry Jen wrote:
>> Hi,
>>
>> Please review the javadoc spec change for AutoCloseable.
>>
>> Basically, it clarifies that AutoCloseable is to be automatically closed
>> with try-with-resource construct, and the implementation may or may not
>> hold resources that need to be closed.
>>
>> http://cr.openjdk.java.net/~henryjen/ccc/8022176/webrev/
>>
> I realize this might be agreed wording but I wonder about the term
> "header", shouldn't this be "resource specification"?

"resource specification", while accurate, looked confusing here.
But we could include both terms, which seems like an improvement.
See below.

>
> A minor comment but maybe it should be "I/O" (rather than "IO") to be
> consistent with the other javadoc.

Sure.


/**
  * An object that may hold resources (such as file or socket handles)
  * until it is closed. The {@link #close()} method of an {@code AutoCloseable}
  * object is called automatically when exiting a {@code
  * try}-with-resources block for which the object has been declared in
  * the resource specification header. This construction ensures prompt
  * release, avoiding resource exhaustion exceptions and errors that
  * may otherwise occur.
  *
  * @apiNote
  * 
It is possible, and in fact common, for a base class to
  * implement AutoCloseable even though not all of its subclasses or
  * instances will hold releasable resources.  For code that must operate
  * in complete generality, or when it is known that the {@code AutoCloseable}
  * instance requires resource release, it is recommended to use {@code
  * try}-with-resources constructions. However, when using facilities such as
  * {@link java.util.stream.Stream} that support both I/O-based and
  * non-IO-based forms, {@code try}-with-resources blocks are in
  * general unnecessary when using non-I/O-based forms.
  *


From martinrb at google.com  Sat Aug 24 15:45:57 2013
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 24 Aug 2013 08:45:57 -0700
Subject: RFR: 8022176: Weaken contract of java.lang.AutoCloseable
In-Reply-To: <5218B079.8000706@cs.oswego.edu>
References: <5217D59F.80206@oracle.com> <5218709E.6070309@oracle.com>
	<5218B079.8000706@cs.oswego.edu>
Message-ID: 

Looks good, except there's one more IO that needs to be changed to I/O


On Sat, Aug 24, 2013 at 6:09 AM, Doug Lea 
 wrote:

> On 08/24/2013 04:36 AM, Alan Bateman wrote:
>
>> On 23/08/2013 22:35, Henry Jen wrote:
>>
>>> Hi,
>>>
>>> Please review the javadoc spec change for AutoCloseable.
>>>
>>> Basically, it clarifies that AutoCloseable is to be automatically closed
>>> with try-with-resource construct, and the implementation may or may not
>>> hold resources that need to be closed.
>>>
>>> http://cr.openjdk.java.net/~**henryjen/ccc/8022176/webrev/
>>>
>>>  I realize this might be agreed wording but I wonder about the term
>> "header", shouldn't this be "resource specification"?
>>
>
> "resource specification", while accurate, looked confusing here.
> But we could include both terms, which seems like an improvement.
> See below.
>
>
>
>> A minor comment but maybe it should be "I/O" (rather than "IO") to be
>> consistent with the other javadoc.
>>
>
> Sure.
>
>
> /**
>  * An object that may hold resources (such as file or socket handles)
>  * until it is closed. The {@link #close()} method of an {@code
> AutoCloseable}
>  * object is called automatically when exiting a {@code
>  * try}-with-resources block for which the object has been declared in
>  * the resource specification header. This construction ensures prompt
>  * release, avoiding resource exhaustion exceptions and errors that
>  * may otherwise occur.
>  *
>  * @apiNote
>  * 
It is possible, and in fact common, for a base class to
>  * implement AutoCloseable even though not all of its subclasses or
>  * instances will hold releasable resources.  For code that must operate
>  * in complete generality, or when it is known that the {@code
> AutoCloseable}
>  * instance requires resource release, it is recommended to use {@code
>  * try}-with-resources constructions. However, when using facilities such
> as
>  * {@link java.util.stream.Stream} that support both I/O-based and
>  * non-IO-based forms, {@code try}-with-resources blocks are in
>  * general unnecessary when using non-I/O-based forms.
>  *
>


From mike.duigou at oracle.com  Sat Aug 24 16:31:52 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Sat, 24 Aug 2013 09:31:52 -0700
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets
	or trees (red/black)
In-Reply-To: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
Message-ID: <83BF5EA9-9D8C-48FC-B539-B6579DB7E12F@oracle.com>

I will need to spend more time reviewing the HashMap/LinkedHashMap implementations but here are some initial comments.

Mike

HashMap::

- The "Sorry if you don't like..." comment can be omitted.


SpliteratorCharacteristics::

- style comment : I always define my assertXXX in the (value, expected, message) form as well as the (value, expected). Being able to pass the test case name for message is often useful context. It is a little more boilerplate.

- void assertNullComparator(Collection c) {
 210         assertNullComparator(c.spliterator());
 211     }

intentionally throws NPE if c is null? Why not instead assertNull or assertNonNull?


MapBinToFromTreeTest::

- thank you for using "hg move" to preserve history. :-)

- I try to encourage @DataProvider methods to return Iterator rather than Object[][]. I haven't made an incremental data provider which generates cases in next() yet.... but I could someday.

- getCollector(), put(), remove() could all be static

- put(SIZE, m, (i, s) -> { }); could be put(SIZE, m, (i, s) -> { assertEquals(i + 1,s); }); or some other check in put that the construction was expected.

On Aug 21 2013, at 05:25 , Paul Sandoz wrote:

> Hi,
> 
> Here are Doug's Linked/HashMap changes, discussed in a previous thread, as a webrev:
> 
>  http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/
> 
> I also added some tests related to characteristics associated with fixing another bug.
> 
> Looking at the diffs will be tricky given there are so many changes.
> 
> 
> I fixed unchecked warnings in LinkedHashMap, but have not done so for HashMap, where there are many more casts from Node to TreeNode. One way to solve that is with a static method:
> 
>    @SuppressWarnings("unchecked")
>    static  TreeNode asTreeNode(Node n) {
>        return (TreeNode) n;
>    }
> 
> but i dunno what the performance implications are. Perhaps it's best to simply stuff @SuppressWarnings on methods of TreeNode rather than trying to modify code just for the sake of reducing the scope.

Always a tough spot. I've favoured adding annotations to variables wherever possible but when it becomes necessary to suppress for entire methods it does feel like shot

The alternative approach of using a method would almost certainly be inlined and as a result would have little (if any) impact on performance.

I still lean towards suppressing on variables and then see what's left.

> 
> A JPRT job has been kicked off.
> 
> I recommend when this code goes in we look closely at code coverage results to see if we are missing areas testing tree functionality and update/add new tests accordingly.
> 
> Paul.
> 



From jeffhain at rocketmail.com  Sat Aug 24 19:02:14 2013
From: jeffhain at rocketmail.com (Jeff Hain)
Date: Sat, 24 Aug 2013 20:02:14 +0100 (BST)
Subject: Java 8 RFR 8010430: Math.round has surprising behavior for
	odd	values of ulp 1
In-Reply-To: 
References: 		<0099615E-F51D-47C4-9330-582911BBD3EF@oracle.com>		
	
Message-ID: <1377370934.77781.YahooMailNeo@web171703.mail.ir2.yahoo.com>


Dmitry Nadezhin wrote:
>Nevertheless, I send this variant now in hope that it may be useful.

Great! It's much faster than what I proposed, cleaner (only integers),
and according to my tests it behaves the same.

-Jeff

From alan.bateman at oracle.com  Sat Aug 24 20:11:53 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sat, 24 Aug 2013 20:11:53 +0000
Subject: hg: jdk8/tl/jdk: 6378503: In java.math.BigDecimal, division by one
	returns zero; ...
Message-ID: <20130824201246.F01CE48B32@hg.openjdk.java.net>

Changeset: 216a4b93cee8
Author:    bpb
Date:      2013-08-23 14:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/216a4b93cee8

6378503: In java.math.BigDecimal, division by one returns zero
6446965: Using BigDecimal.divideToIntegralValue with extreme scales can lead to an incorrect result
Summary: Fix overflow of ints and ensure appropriate values passed to checkScaleNonZero()
Reviewed-by: darcy, martin
Contributed-by: Brian Burkhalter 

! src/share/classes/java/math/BigDecimal.java
! src/share/classes/java/math/BigInteger.java
! test/java/math/BigDecimal/IntegralDivisionTests.java



From Alan.Bateman at oracle.com  Sat Aug 24 20:40:59 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 24 Aug 2013 21:40:59 +0100
Subject: RFR: 8022176: Weaken contract of java.lang.AutoCloseable
In-Reply-To: <5218B079.8000706@cs.oswego.edu>
References: <5217D59F.80206@oracle.com> <5218709E.6070309@oracle.com>
	<5218B079.8000706@cs.oswego.edu>
Message-ID: <52191A5B.5000201@oracle.com>

On 24/08/2013 14:09, Doug Lea wrote:
>
> "resource specification", while accurate, looked confusing here.
> But we could include both terms, which seems like an improvement.
> See below.
This looks better to me, thanks.

-Alan.


From Alan.Bateman at oracle.com  Sun Aug 25 08:19:02 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 25 Aug 2013 09:19:02 +0100
Subject: RFR [7129312] BufferedInputStream calculates negative array size
	with large streams and mark
In-Reply-To: <5216179E.5060708@oracle.com>
References: <520E2541.9020505@oracle.com> <520E541E.1060403@oracle.com>
	<5211F591.6010504@oracle.com> <521392E0.20604@oracle.com>
	<52148850.6090401@oracle.com> <5216179E.5060708@oracle.com>
Message-ID: <5219BDF6.6010404@oracle.com>

On 22/08/2013 14:52, Ivan Gerasimov wrote:
> Thank you Alan!
>
> Would you please review the updated webrev?
> http://cr.openjdk.java.net/~igerasim/7129312/3/webrev/ 
> 
This looks much better (although I'm still wondering about greedy tests 
wanting to reserve 4GB when running tests concurrently). But let's go 
with what you have for now. One small suggestion is to assume "PARENT" 
when invoking without any args as that will make it easier to run 
interactively. I'm happy to sponsor this, just send me a link to the 
change-set.

-Alan


From paul.sandoz at oracle.com  Sun Aug 25 09:32:24 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Sun, 25 Aug 2013 11:32:24 +0200
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets
	or trees (red/black)
In-Reply-To: 
References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
	
Message-ID: <0EA674B2-5248-4674-9413-284900BC0894@oracle.com>


On Aug 22, 2013, at 5:33 PM, Martin Buchholz  wrote:

> I support the treeification of all the HashMaps.
> 
> On Wed, Aug 21, 2013 at 5:25 AM, Paul Sandoz  wrote:
> 
> I recommend when this code goes in we look closely at code coverage results to see if we are missing areas testing tree functionality and update/add new tests accordingly.
> 
> Testing is indeed a problem. Treeification is only triggered when hash codes collide AND there are sufficient elements in the map.

Yes, i concocted a mechanism to test treeifying and untreeifying. It's tricky to verify it occurs without some more invasive approach such as probing method calls, plus it's very dependent on the internal constants but i don't see how else it can be.

Paul.

>  All existing tests for hash collections could be examined to check whether they can be adapted to additionally test such maps.  But that would be a lot of work.
> 
> See test classes containing
>         public int hashCode() { return 42; }
> in
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/ConcurrentHashMapTest.java?view=co


From paul.sandoz at oracle.com  Sun Aug 25 09:43:47 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Sun, 25 Aug 2013 11:43:47 +0200
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets
	or trees (red/black)
In-Reply-To: <5217F1A8.2000503@oracle.com>
References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
	
	
	
	<5217F1A8.2000503@oracle.com>
Message-ID: <944B6BE3-F913-42DA-8748-C78F21CF7975@oracle.com>


On Aug 24, 2013, at 1:35 AM, Brent Christian  wrote:

> On 8/22/13 5:01 AM, Paul Sandoz wrote:
>> On Aug 21, 2013, at 6:47 PM, Paul Sandoz  wrote:
>>> I updated the webrev and replaced TreeBinSplitBackToEntries.java with:
>>> 
>>>  http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/test/java/util/Map/MapBinToFromTreeTest.java.html
> >
> > Another tweak to ensure untreeify is tested on resize (use the same
> > URL above). I think at this point the tests are in reasonable shape
> > and are on a par with previous tests.
> 
> The new MapBinToFromTreeTest code looks good.  I confirmed that it hits the 4 main cases in split() (tree/untreeify for loHead/hiHead).
> 

Thanks.


> (FWIW, I don't believe the entire split() tree ever lands all in one bin (loHead and hiHead are never null), though it's possible that it could.)
> 

I did not cover those cases, but it should be easy to do so. IIUC either can be null but not both, if e.hash & bit == 0 or not for all in e in the tree.
 

> I agree that we should check back on the code coverage results and update the tests as needed.
> 
> 
> I've focused on looking at portions of HashMap that I recall being tricky (split, treeify, etc).  So far it all looks fine to me.
> 

OK, thanks,
Paul.

From paul.sandoz at oracle.com  Sun Aug 25 10:22:17 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Sun, 25 Aug 2013 12:22:17 +0200
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets
	or trees (red/black)
In-Reply-To: <83BF5EA9-9D8C-48FC-B539-B6579DB7E12F@oracle.com>
References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
	<83BF5EA9-9D8C-48FC-B539-B6579DB7E12F@oracle.com>
Message-ID: <4E4CC0BA-9FA7-45B7-85A0-47B7D2C98888@oracle.com>


On Aug 24, 2013, at 6:31 PM, Mike Duigou  wrote:

> I will need to spend more time reviewing the HashMap/LinkedHashMap implementations but here are some initial comments.
> 

OK, thanks.


> Mike
> 
> HashMap::
> 
> - The "Sorry if you don't like..." comment can be omitted.
> 

Or we could tweak:

     * The concurrent-programming-like SSA-based coding style helps avoid aliasing errors
     * amid all of the twisty pointer operations.


> 
> SpliteratorCharacteristics::
> 
> - style comment : I always define my assertXXX in the (value, expected, message) form as well as the (value, expected). Being able to pass the test case name for message is often useful context. It is a little more boilerplate.
> 

That's a good point. I am terribely lazy about that aspect.


> - void assertNullComparator(Collection c) {
> 210         assertNullComparator(c.spliterator());
> 211     }
> 
> intentionally throws NPE if c is null? Why not instead assertNull or assertNonNull?
> 

No, the collection c is never null, the comparator of the spliterator of the collection is asserted to be null.


> 
> MapBinToFromTreeTest::
> 
> - thank you for using "hg move" to preserve history. :-)
> 

That was a happy accident on my part :-)


> - I try to encourage @DataProvider methods to return Iterator rather than Object[][]. I haven't made an incremental data provider which generates cases in next() yet.... but I could someday.
> 
> - getCollector(), put(), remove() could all be static
> 

I don't have a strong preferences regarding the above. I may tweak the data provider since the logging does not identify the hash map implementation.


> - put(SIZE, m, (i, s) -> { }); could be put(SIZE, m, (i, s) -> { assertEquals(i + 1,s); }); or some other check in put that the construction was expected.
> 

Note that the reuse here is just a convenience to fill up the map. Also there is no real dependence that i + 1 = s. The only constraint is that there are up to but not including s elements, but we don't need to know about the order (and in fact we could add different orders later on as i suspect it might affect the tree shape).


> On Aug 21 2013, at 05:25 , Paul Sandoz wrote:
> 
>> Hi,
>> 
>> Here are Doug's Linked/HashMap changes, discussed in a previous thread, as a webrev:
>> 
>> http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/
>> 
>> I also added some tests related to characteristics associated with fixing another bug.
>> 
>> Looking at the diffs will be tricky given there are so many changes.
>> 
>> 
>> I fixed unchecked warnings in LinkedHashMap, but have not done so for HashMap, where there are many more casts from Node to TreeNode. One way to solve that is with a static method:
>> 
>>   @SuppressWarnings("unchecked")
>>   static  TreeNode asTreeNode(Node n) {
>>       return (TreeNode) n;
>>   }
>> 
>> but i dunno what the performance implications are. Perhaps it's best to simply stuff @SuppressWarnings on methods of TreeNode rather than trying to modify code just for the sake of reducing the scope.
> 
> Always a tough spot. I've favoured adding annotations to variables wherever possible but when it becomes necessary to suppress for entire methods it does feel like shot
> 
> The alternative approach of using a method would almost certainly be inlined and as a result would have little (if any) impact on performance.
> 
> I still lean towards suppressing on variables and then see what's left.
> 

It's kind of awkward, i already tried it and it seemed marginally oppressive in some cases. I should take another swing at it.

Paul.

From kasperni at gmail.com  Sun Aug 25 14:03:50 2013
From: kasperni at gmail.com (Kasper Nielsen)
Date: Sun, 25 Aug 2013 16:03:50 +0200
Subject: java.lang.reflect.Parameter comments
Message-ID: 

Hi,

just 2 short questions/commons on java.lang.reflect.Parameter

1)
I was wondering if there is any reason for java.lang.reflect.Parameter not
to expose the index field?

2)
Also, while Parameter.getParameterizedType() might be a better name than
getGenericType().
I find it kind of annoying that it is called Field.getGenericType() but
Parameter.getParameterizedType(). Lets just have the same name for
practically the same functionality?

Cheers
  Kasper


From forax at univ-mlv.fr  Sun Aug 25 18:04:42 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 25 Aug 2013 20:04:42 +0200
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets
	or trees (red/black)
In-Reply-To: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
Message-ID: <521A473A.6000807@univ-mlv.fr>

On 08/21/2013 02:25 PM, Paul Sandoz wrote:
> Hi,
>
> Here are Doug's Linked/HashMap changes, discussed in a previous thread, as a webrev:
>
>    http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/
>
> I also added some tests related to characteristics associated with fixing another bug.
>
> Looking at the diffs will be tricky given there are so many changes.


The code can be simplified a little bit by using the diamond syntax,
HashMap (lines: 919, 963, 1026, 1497, 1569) and
LinkedHashMap (lines: 255, 264, 270, 278)

There are a bunch of @Override that are missing making the code harder 
than it should to read.

HashMapSpliterator.est should be renamed to estimateSize.

All occurences of "(n - 1) & hash" should be replaced by "hash & (n - 
1)" because it's easier to explain.

TreeNode.getTreeNode() should be a static method and take a Node as 
first argument,
so most of the casts to TreeNode that bother you will disappear :)
   static TreeNode getTreeNode(Node node, int h, Object k) {
     TreeNode first = (TreeNode
>
> I fixed unchecked warnings in LinkedHashMap, but have not done so for HashMap, where there are many more casts from Node to TreeNode. One way to solve that is with a static method:
>
>      @SuppressWarnings("unchecked")
>      static  TreeNode asTreeNode(Node n) {
>          return (TreeNode) n;
>      }
>
> but i dunno what the performance implications are. Perhaps it's best to simply stuff @SuppressWarnings on methods of TreeNode rather than trying to modify code just for the sake of reducing the scope.

You should not need the @SuppressWarnings here?

>
>
> A JPRT job has been kicked off.
>
> I recommend when this code goes in we look closely at code coverage results to see if we are missing areas testing tree functionality and update/add new tests accordingly.
>
> Paul.
>

cheers,
R?mi




From ivan.gerasimov at oracle.com  Sun Aug 25 19:28:04 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sun, 25 Aug 2013 23:28:04 +0400
Subject: RFR [7129312] BufferedInputStream calculates negative array size
	with large streams and mark
In-Reply-To: <5219BDF6.6010404@oracle.com>
References: <520E2541.9020505@oracle.com> <520E541E.1060403@oracle.com>
	<5211F591.6010504@oracle.com> <521392E0.20604@oracle.com>
	<52148850.6090401@oracle.com> <5216179E.5060708@oracle.com>
	<5219BDF6.6010404@oracle.com>
Message-ID: <521A5AC4.4000708@oracle.com>

Thank you Alan!

> This looks much better (although I'm still wondering about greedy 
> tests wanting to reserve 4GB when running tests concurrently). But 
> let's go with what you have for now. One small suggestion is to assume 
> "PARENT" when invoking without any args as that will make it easier to 
> run interactively. I'm happy to sponsor this, just send me a link to 
> the change-set.
>
I couldn't come up with any idea on how to test the overflow without 
actually allocating that much memory.

I simplified the test a bit once again. Instead of invoking the same 
class twice, I created a designated class for the child.
Here's the new webrev: 
http://cr.openjdk.java.net/~igerasim/7129312/4/webrev/
Hope it looks fine.

And here's the exported change set:
http://cr.openjdk.java.net/~igerasim/2commit/7129312-jdk8-Negative-array-size.patch

Sincerely yours,
Ivan


From martinrb at google.com  Sun Aug 25 23:31:02 2013
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 25 Aug 2013 16:31:02 -0700
Subject: RFR [8023130] (process) ProcessBuilder#inheritIO does not work on
	Windows
In-Reply-To: <521789AD.2070208@oracle.com>
References: <5216D1E6.2090304@oracle.com> <52173941.5040203@oracle.com>
	<521789AD.2070208@oracle.com>
Message-ID: 

Historical notes:

I maintained this code for a while, but I've never been a "Windows" guy,
and I rarely sat at an actual Windows machine console.  I don't know of any
test infrastructure for windowed apps.


On Fri, Aug 23, 2013 at 9:11 AM, Ivan Gerasimov
wrote:

> Thank you Alan!
>
>
> On 23.08.2013 14:28, Alan Bateman wrote:
>
>> On 23/08/2013 04:07, Ivan Gerasimov wrote:
>>
>>> Hello everybody!
>>>
>>> The method ProcessBuilder#inheritIO() is reported to not have any effect
>>> on Windows platform.
>>> The same story is with redirectOutput/Input/Error(**Redirect.INHERIT)
>>> methods.
>>> As the result, standard in/out/err aren't inherited.
>>>
>>> It turn out that the culprit is the CREATE_NO_WINDOW flag passed to
>>> CreateProcessW().
>>> MS doc says about this flag: "The process is a console application that
>>> is being run without a console window."
>>>
>>> CREATE_NO_WINDOW flag was added with the fix for
>>> http://bugs.sun.com/view_bug.**do?bug_id=4244515to suppress a console window on a newly created process, when it is created
>>> from a program launched with javaw.exe.
>>> Thus, I left this flag only for cases when the program doesn't have a
>>> console associated with it.
>>>
>>> Would you please help review a fix for this problem?
>>>
>>> BUGURL: http://bugs.sun.com/view_bug.**do?bug_id=8023130
>>> WEBREV: http://cr.openjdk.java.net/~**igerasim/8023130/0/webrev/
>>>
>>>  Good sleuthing!
>>
>> Just so I understand, if we have a console (DOS command window for
>> example) then will dropping CREATE_NO_WINDOW result in a new window or not?
>>
>>  No new console for a console application without CREATE_NO_WINDOW flag.
> I used a sample program to confirm that:
> ---------------
> class InheritIO {
>     public static void main(String[] args) throws Exception {
>         int err = new ProcessBuilder(args).**inheritIO().**
> redirectErrorStream(true).**start().waitFor();
>         System.err.println("Exit value: " + err);
>     }
> }
> ---------------
> With the proposed fix running it as '> java InheritIO cmd /?' copies the
> output of the command to the existing console.
> No new console is created.
>
>
>  One thing that it does highlight is that the coverage for inherit in
>> ProcessBuilder/Basic.java was not sufficient as this should have been
>> caught a long time ago. My preference would be to add to this test rather
>> than introduce a new one (ProcessBuilder.java is Martin's original
>> mother-of-all tests for ProcessBuilder).
>>
>>  Yes, I agree. It would be better to integrate this test into Basic.java.
>
> Sincerely yours,
> Ivan
>
>  -Alan.
>>
>>
>>
>


From david.holmes at oracle.com  Mon Aug 26 01:59:38 2013
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 26 Aug 2013 11:59:38 +1000
Subject: Additional source to guess the local timezone ID on linux
In-Reply-To: <5217CF92.9030307@redhat.com>
References: <5217CF92.9030307@redhat.com>
Message-ID: <521AB68A.7030805@oracle.com>

On 24/08/2013 7:09 AM, Omair Majid wrote:
> Hi,
>
> The algorithm that OpenJDK uses to guess the local timezone ID on Linux
> goes like this:
>
> 1. If TZ environment variable is set, use that
> 2. If /etc/timezone is readable, read the time zone from there
> 3. If /etc/localtime is a symlink, resolve that, and use the name to
> guess the time zone.
> 4. Scan /usr/share/zoneinfo for a file whose contents match the contents
> of /etc/localtime.
>
> Step 4 (if it is ever reached) is probably going to lead to incorrect
> results since there are a number of timezones that have the same
> zoneinfo data (such as Europe/London and Europe/Belfast). So it seems
> sensible to me to try and use additional sources to guess the timezone
> ID before resorting to file content comparisons.
>
> The webrev adds a step between 2 and 3 that reads and parses
> /etc/sysconfig/clock to extract the timezone:
>
> http://cr.openjdk.java.net/~omajid/webrevs/timezone-read-sysconfig-clock/00/
>
> This file exists on some Red Hat Enterprise Linux (and derivative)
> distributions and contains contents that look this:
>
>> # The time zone of the system is defined by the contents of /etc/localtime.
>> # This file is only for evaluation by system-config-date, do not rely on its
>> # contents elsewhere.
>> ZONE="Europe/Zurich"

Surely the implication here is that if this file exists and has this 
data then /etc/localtime should be correctly configured - hence we 
should use that. ie at best this should come after step 3 not before it. 
But even then when someone writes "do not rely on its
contents elsewhere" I'm inclined to do what they suggest!

David

> With this, we should be able to identify the exact timezone ID.
>
> Thanks,
> Omair
>


From omajid at redhat.com  Mon Aug 26 03:18:33 2013
From: omajid at redhat.com (Omair Majid)
Date: Sun, 25 Aug 2013 23:18:33 -0400
Subject: Additional source to guess the local timezone ID on linux
In-Reply-To: <521AB68A.7030805@oracle.com>
References: <5217CF92.9030307@redhat.com> <521AB68A.7030805@oracle.com>
Message-ID: <521AC909.6070106@redhat.com>

Hi David,

Thanks for looking at the patch!

On 08/25/2013 09:59 PM, David Holmes wrote:
> On 24/08/2013 7:09 AM, Omair Majid wrote:
>> The algorithm that OpenJDK uses to guess the local timezone ID on Linux
>> goes like this:
>>
>> 1. If TZ environment variable is set, use that
>> 2. If /etc/timezone is readable, read the time zone from there
>> 3. If /etc/localtime is a symlink, resolve that, and use the name to
>> guess the time zone.
>> 4. Scan /usr/share/zoneinfo for a file whose contents match the contents
>> of /etc/localtime.
>>
>> Step 4 (if it is ever reached) is probably going to lead to incorrect
>> results since there are a number of timezones that have the same
>> zoneinfo data (such as Europe/London and Europe/Belfast). So it seems
>> sensible to me to try and use additional sources to guess the timezone
>> ID before resorting to file content comparisons.
>>
>> The webrev adds a step between 2 and 3 that reads and parses
>> /etc/sysconfig/clock to extract the timezone:
>>
>> http://cr.openjdk.java.net/~omajid/webrevs/timezone-read-sysconfig-clock/00/
>>
>>
>> This file exists on some Red Hat Enterprise Linux (and derivative)
>> distributions and contains contents that look this:
>>
>>> # The time zone of the system is defined by the contents of
>>> /etc/localtime.
>>> # This file is only for evaluation by system-config-date, do not rely
>>> on its
>>> # contents elsewhere.
>>> ZONE="Europe/Zurich"
> 
> Surely the implication here is that if this file exists and has this
> data then /etc/localtime should be correctly configured - hence we
> should use that. ie at best this should come after step 3 not before it.

The systems that I was looking at where /etc/sysconfig/clock exists,
/etc/localtime is not a symlink. So step 3 is doesn't actually do
anything. Anyway, I can move this to after step 3 - I have no issues
with that.

> But even then when someone writes "do not rely on its
> contents elsewhere" I'm inclined to do what they suggest!

Yes, I would prefer to not use this file either, but Petr Machata (who
maintains these timezone related packages in Fedora) tells me it's the
closest thing to an authoritative source. In fact, on an update of the
timezone packages, a script already parses /etc/sysconfig/clock and
copies the zoneinfo file over to /etc/localtime [1].

Oh, and I forgot to mention that this is not a problem on newer
systemd-using Linux distributions (including Arch, Fedora and Gentoo)
where /etc/localtime is always a symlink. They do not carry this
/etc/sysconfig/clock file.

Thanks,
Omair

[1] https://bugzilla.redhat.com/show_bug.cgi?id=186742#c8

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681


From david.holmes at oracle.com  Mon Aug 26 04:09:05 2013
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 26 Aug 2013 14:09:05 +1000
Subject: Additional source to guess the local timezone ID on linux
In-Reply-To: <521AC909.6070106@redhat.com>
References: <5217CF92.9030307@redhat.com> <521AB68A.7030805@oracle.com>
	<521AC909.6070106@redhat.com>
Message-ID: <521AD4E1.6090300@oracle.com>

Hi Omair,

I have reservations about this but will let others comment.

Looking at the code, readEntireFile doesn't close the file if it returns 
-ENOMEM. It also doesn't free the allocated memory if it returns -ENOMEM 
or via the goto fail path. (I'm not a fan of this goto fail style either.)

Thanks,
David

On 26/08/2013 1:18 PM, Omair Majid wrote:
> Hi David,
>
> Thanks for looking at the patch!
>
> On 08/25/2013 09:59 PM, David Holmes wrote:
>> On 24/08/2013 7:09 AM, Omair Majid wrote:
>>> The algorithm that OpenJDK uses to guess the local timezone ID on Linux
>>> goes like this:
>>>
>>> 1. If TZ environment variable is set, use that
>>> 2. If /etc/timezone is readable, read the time zone from there
>>> 3. If /etc/localtime is a symlink, resolve that, and use the name to
>>> guess the time zone.
>>> 4. Scan /usr/share/zoneinfo for a file whose contents match the contents
>>> of /etc/localtime.
>>>
>>> Step 4 (if it is ever reached) is probably going to lead to incorrect
>>> results since there are a number of timezones that have the same
>>> zoneinfo data (such as Europe/London and Europe/Belfast). So it seems
>>> sensible to me to try and use additional sources to guess the timezone
>>> ID before resorting to file content comparisons.
>>>
>>> The webrev adds a step between 2 and 3 that reads and parses
>>> /etc/sysconfig/clock to extract the timezone:
>>>
>>> http://cr.openjdk.java.net/~omajid/webrevs/timezone-read-sysconfig-clock/00/
>>>
>>>
>>> This file exists on some Red Hat Enterprise Linux (and derivative)
>>> distributions and contains contents that look this:
>>>
>>>> # The time zone of the system is defined by the contents of
>>>> /etc/localtime.
>>>> # This file is only for evaluation by system-config-date, do not rely
>>>> on its
>>>> # contents elsewhere.
>>>> ZONE="Europe/Zurich"
>>
>> Surely the implication here is that if this file exists and has this
>> data then /etc/localtime should be correctly configured - hence we
>> should use that. ie at best this should come after step 3 not before it.
>
> The systems that I was looking at where /etc/sysconfig/clock exists,
> /etc/localtime is not a symlink. So step 3 is doesn't actually do
> anything. Anyway, I can move this to after step 3 - I have no issues
> with that.
>
>> But even then when someone writes "do not rely on its
>> contents elsewhere" I'm inclined to do what they suggest!
>
> Yes, I would prefer to not use this file either, but Petr Machata (who
> maintains these timezone related packages in Fedora) tells me it's the
> closest thing to an authoritative source. In fact, on an update of the
> timezone packages, a script already parses /etc/sysconfig/clock and
> copies the zoneinfo file over to /etc/localtime [1].
>
> Oh, and I forgot to mention that this is not a problem on newer
> systemd-using Linux distributions (including Arch, Fedora and Gentoo)
> where /etc/localtime is always a symlink. They do not carry this
> /etc/sysconfig/clock file.
>
> Thanks,
> Omair
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=186742#c8
>


From weijun.wang at oracle.com  Mon Aug 26 08:08:43 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 26 Aug 2013 16:08:43 +0800
Subject: RFR 8022761: SQE test regression on wrongly signed indexed jar
	file
In-Reply-To: <52121976.60708@oracle.com>
References: <520861FA.4090605@oracle.com> <52121976.60708@oracle.com>
Message-ID: <521B0D0B.2010000@oracle.com>

Ping again.

On 8/19/13 9:11 PM, Weijun Wang wrote:
> Hi Sherman
>
> I try out "jar i" after signing and it puts INDEX.LIST at the very
> beginning of the file. Does this mean INDEX.LIST was actually an
> exception? Or it just "jari" bug?
>
> Anyway, I think I should update the fix for 8021788 and here is the webrev:
>
>    http://cr.openjdk.java.net/~weijun/8022761/webrev.00/
>
> Now it also skips INDEX.LIST, i.e. update line 142 to
>
>    if (uname.equals(JarFile.MANIFEST_NAME) ||
>            uname.equals(JarIndex.INDEX_NAME) ) {
>
> After this change, if INDEX.LIST appears before the MANIFEST and
> signature-related files, it will not be treated as signed. This should
> usually be true because it only happens when you call "jar i" after
> signing a jar which means INDEX.LIST *is* unsigned.
>
> Thanks
> Max
>
> On 8/12/13 12:18 PM, Weijun Wang wrote:
>> Hi Sherman
>>
>> SQE observes a regression in their test suite and
>> the reason is my recent fix for 8021788 at
>>
>>    http://hg.openjdk.java.net/jdk8/tl/jdk/rev/758e3117899c
>>
>> The jar file mentioned contains
>>
>>      66 Mon Jun 04 15:42:18 CST 2007 META-INF/INDEX.LIST
>>     323 Sat Apr 01 15:47:28 CST 2000 META-INF/MANIFEST.MF
>>     376 Mon Jun 04 15:41:00 CST 2007 META-INF/MYKEY.SF
>>     972 Sat Apr 01 15:47:38 CST 2000 META-INF/MYKEY.DSA
>>       0 Sat Apr 01 15:46:58 CST 2000 META-INF/
>>       0 Sat Apr 01 15:45:16 CST 2000 test/
>>      21 Sat Apr 01 15:46:24 CST 2000 test/test0
>>      21 Sat Apr 01 15:46:18 CST 2000 test/test1
>>      21 Sat Apr 01 15:46:04 CST 2000 test/test2
>>      21 Sat Apr 01 15:46:10 CST 2000 test/test3
>>
>> After JDK-8021788, the file is regarded as an unsigned jar because the
>> updated JarVerifier goes thru all signature-related files and treats all
>> others not. Here the first one is not signature-related so none is.
>>
>> Is fix for JDK-8021788 wrong? Inside JarVerifier.java, we have
>>
>>    * Assumptions:
>>    * 1. The manifest should be the first entry in the META-INF directory.
>>    * 2. The .SF/.DSA/.EC files follow the manifest, before any normal
>> entries
>>
>> Is this INDEX.LIST an exception?
>>
>> Thanks
>> Max


From Alan.Bateman at oracle.com  Mon Aug 26 08:40:34 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 26 Aug 2013 09:40:34 +0100
Subject: Additional source to guess the local timezone ID on linux
In-Reply-To: <5217CF92.9030307@redhat.com>
References: <5217CF92.9030307@redhat.com>
Message-ID: <521B1482.104@oracle.com>


Including i18n-dev on this discussion because that is where this code is 
maintained.


On 23/08/2013 22:09, Omair Majid wrote:
> Hi,
>
> The algorithm that OpenJDK uses to guess the local timezone ID on Linux
> goes like this:
>
> 1. If TZ environment variable is set, use that
> 2. If /etc/timezone is readable, read the time zone from there
> 3. If /etc/localtime is a symlink, resolve that, and use the name to
> guess the time zone.
> 4. Scan /usr/share/zoneinfo for a file whose contents match the contents
> of /etc/localtime.
>
> Step 4 (if it is ever reached) is probably going to lead to incorrect
> results since there are a number of timezones that have the same
> zoneinfo data (such as Europe/London and Europe/Belfast). So it seems
> sensible to me to try and use additional sources to guess the timezone
> ID before resorting to file content comparisons.
>
> The webrev adds a step between 2 and 3 that reads and parses
> /etc/sysconfig/clock to extract the timezone:
>
> http://cr.openjdk.java.net/~omajid/webrevs/timezone-read-sysconfig-clock/00/
>
> This file exists on some Red Hat Enterprise Linux (and derivative)
> distributions and contains contents that look this:
>
>> # The time zone of the system is defined by the contents of /etc/localtime.
>> # This file is only for evaluation by system-config-date, do not rely on its
>> # contents elsewhere.
>> ZONE="Europe/Zurich"
> With this, we should be able to identify the exact timezone ID.
>
> Thanks,
> Omair



From alan.bateman at oracle.com  Mon Aug 26 09:04:09 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 26 Aug 2013 09:04:09 +0000
Subject: hg: jdk8/tl/jdk: 8023139:
	java/nio/file/WatchService/SensitivityModifier.java failing
	intermittently (win8)
Message-ID: <20130826090449.47C6448B54@hg.openjdk.java.net>

Changeset: 0ee3b995d63b
Author:    alanb
Date:      2013-08-26 10:01 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ee3b995d63b

8023139: java/nio/file/WatchService/SensitivityModifier.java failing intermittently (win8)
Reviewed-by: alanb
Contributed-by: yiming.wang at oracle.com

! test/java/nio/file/WatchService/SensitivityModifier.java



From Alan.Bateman at oracle.com  Mon Aug 26 10:29:16 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 26 Aug 2013 11:29:16 +0100
Subject: Please review fix for 8011944 : Sort fails with
	ArrayIndexOutOfBoundsException
In-Reply-To: <52177E94.9010302@oracle.com>
References: <52161F49.3030001@oracle.com> <5217782C.3010403@oracle.com>
	<52177E94.9010302@oracle.com>
Message-ID: <521B2DFC.3000408@oracle.com>

On 23/08/2013 16:24, roger riggs wrote:
> Hi,
>
> I reviewed the algorithm of the test case and it seems to me that it
> produces the smallest number of total items to sort for a given stack 
> depth.
> I ran it with other stack depths and confirmed that the implementation 
> did
> not exceed the new limit.
>
> I was unable to discover a specific explanation or computation for the
> current choices to thresholds and corresponding stack depths.
>
> An alternative implementation could use the conservative estimate
> and resize the array as needed.  It would avoid overallocation of a
> temporary in the normal case.
>
> Thanks, Roger
I searched around but don't see any crumbs that explain the current 
stack depths.

Anyway, I think what you have is fine and should be pushed.

-Alan


From Alan.Bateman at oracle.com  Mon Aug 26 10:33:14 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 26 Aug 2013 11:33:14 +0100
Subject: RFR [7129312] BufferedInputStream calculates negative array size
	with large streams and mark
In-Reply-To: <521A5AC4.4000708@oracle.com>
References: <520E2541.9020505@oracle.com> <520E541E.1060403@oracle.com>
	<5211F591.6010504@oracle.com> <521392E0.20604@oracle.com>
	<52148850.6090401@oracle.com> <5216179E.5060708@oracle.com>
	<5219BDF6.6010404@oracle.com> <521A5AC4.4000708@oracle.com>
Message-ID: <521B2EEA.608@oracle.com>

On 25/08/2013 20:28, Ivan Gerasimov wrote:
> I couldn't come up with any idea on how to test the overflow without 
> actually allocating that much memory.:
>
>
> I simplified the test a bit once again. Instead of invoking the same 
> class twice, I created a designated class for the child.
> Here's the new webrev: 
> http://cr.openjdk.java.net/~igerasim/7129312/4/webrev/
> Hope it looks fine.
>
> And here's the exported change set:
> http://cr.openjdk.java.net/~igerasim/2commit/7129312-jdk8-Negative-array-size.patch
I think I'd preferred using the parameter to indicate that the child 
should be launcher but what you have is okay. I'll push this for you 
shortly.

-Alan


From alan.bateman at oracle.com  Mon Aug 26 10:35:06 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 26 Aug 2013 10:35:06 +0000
Subject: hg: jdk8/tl/jdk: 7129312: BufferedInputStream calculates negative
	array size with large streams and mark
Message-ID: <20130826103531.1189748B56@hg.openjdk.java.net>

Changeset: 67a1a031876a
Author:    igerasim
Date:      2013-08-25 23:20 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/67a1a031876a

7129312: BufferedInputStream calculates negative array size with large streams and mark
Reviewed-by: alanb

! src/share/classes/java/io/BufferedInputStream.java
+ test/java/io/BufferedInputStream/LargeCopyWithMark.java



From joel.franck at oracle.com  Mon Aug 26 11:47:46 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Mon, 26 Aug 2013 11:47:46 +0000
Subject: hg: jdk8/tl/jdk: 8022343: j.l.Class.getAnnotatedSuperclass() doesn't
	return null in some cases
Message-ID: <20130826114801.4A35F48B59@hg.openjdk.java.net>

Changeset: 6917c114b197
Author:    jfranck
Date:      2013-08-26 13:38 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6917c114b197

8022343: j.l.Class.getAnnotatedSuperclass() doesn't return null in some cases
Reviewed-by: darcy, vromero, psandoz

! src/share/classes/java/lang/Class.java
! test/java/lang/annotation/TypeAnnotationReflection.java
+ test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java



From aleksey.shipilev at oracle.com  Mon Aug 26 12:19:18 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 26 Aug 2013 16:19:18 +0400
Subject: Java 8 RFC 7189139: BigInteger's staticRandom field can be a
	source of bottlenecks
In-Reply-To: <050BDF31-D4C5-447D-A445-38E662A925E4@oracle.com>
References: <050BDF31-D4C5-447D-A445-38E662A925E4@oracle.com>
Message-ID: <521B47C6.9010407@oracle.com>

Hi Brian,

On 08/24/2013 03:39 AM, Brian Burkhalter wrote:
> file:///Users/bpb/Work/JSL/jdk/jdk8/tl8/jdk/7189139/index.html
> 
> would be appreciated.

I'm puzzled over this fix.

Isn't the scalability bottleneck being inherent to SecureRandom, because
it piggybacks on the system entropy pool, which is depleted every so
often? What good the thread-local instances of SR actually bring to us?

As discussed in the relevant threads in the original bug report, the
actual fix should be a very accurate replacement of SR with some other
faster and reliable RNG to avoid the inherent scalability bottlenecks.

> Rudimentary testing with JMH 
> (http://openjdk.java.net/projects/code-tools/jmh/) did not reveal any
> deleterious performance effects in single-threaded operation nor any
> obvious improvements in the dual threaded case but testing was done
> on on my aging Core 2 Duo notebook and is not likely representative
> of anything approaching real world conditions.

That further reinforces my belief this particular change is not really
required :)

-Aleksey.



From aleksey.shipilev at oracle.com  Mon Aug 26 12:20:22 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 26 Aug 2013 16:20:22 +0400
Subject: RFR (M) CR 8023234: StampedLock serializes readers on writer
	unlock
In-Reply-To: <52173B8D.5080001@oracle.com>
References: <521230D1.9070803@oracle.com>
	
	<52138373.8090903@oracle.com>
	
	<5214FCE4.9030507@oracle.com>
	
	<52150F82.1090600@oracle.com> <52173B8D.5080001@oracle.com>
Message-ID: <521B4806.70906@oracle.com>

Reminder :)

-Aleksey.

On 08/23/2013 02:38 PM, Aleksey Shipilev wrote:
> Hm, I think I still need the second reviewer.
> Anyone?
> 
>   http://cr.openjdk.java.net/~shade/8023234/webrev.01/
> 
> -Aleksey.
> 
> On 08/21/2013 11:05 PM, Aleksey Shipilev wrote:
>> Thanks Martin!
>>
>> I need a sponsor to push this.
>>
>> -Aleksey.
>>
>> P.S. The support for multi-threaded tests in jtreg/library is one of the
>> things I'm eager to have.
>>
>> On 08/21/2013 10:53 PM, Martin Buchholz wrote:
>>> OK, approved!
>>>
>>> I would do things differently, and there is the deeper problem that
>>> openjdk provides no test infrastructure for multi-threaded tests, which
>>> we are suffering from here.  Now that testng is being used, it's a good
>>> time for someone to import test infrastructure from JSR166TestCase
>>>
>>>
>>> On Wed, Aug 21, 2013 at 10:46 AM, Aleksey Shipilev
>>> > wrote:
>>>
>>>     Hi Martin,
>>>
>>>     On 08/21/2013 06:28 AM, Martin Buchholz wrote:
>>>     > If a Reader throws, the test might still pass, since only throwing
>>>     from
>>>     > the main thread matters.  See infrastructure in JSR166TestCase, e.g.
>>>     > threadUnexpectedException.
>>>
>>>     Yes. I still don't think there is a value in catching the exceptions in
>>>     the threads for this concrete regression test. Should the reader die
>>>     with the exception, the test will fail anyway, since enough readers are
>>>     not available.
>>>
>>>     > OTOH, there seems no value in converting exceptions in the main thread
>>>     > to ISE.  Just declare main to throw Exception or whatever.
>>>
>>>     This seems to be the stylistic nit. ;) There is the symmetry against
>>>     readers code, which wraps the exceptions into the ISE. For my taste, it
>>>     looks better to retain that symmetry.
>>>
>>>     I can still make the changes to the test, if you insist.
>>>
>>>     -Aleksey.
>>>
>>>
>>
> 



From ivan.gerasimov at oracle.com  Mon Aug 26 12:39:57 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 26 Aug 2013 16:39:57 +0400
Subject: RFR [7129312] BufferedInputStream calculates negative array size
	with large streams and mark
In-Reply-To: <521B2EEA.608@oracle.com>
References: <520E2541.9020505@oracle.com> <520E541E.1060403@oracle.com>
	<5211F591.6010504@oracle.com> <521392E0.20604@oracle.com>
	<52148850.6090401@oracle.com> <5216179E.5060708@oracle.com>
	<5219BDF6.6010404@oracle.com> <521A5AC4.4000708@oracle.com>
	<521B2EEA.608@oracle.com>
Message-ID: <521B4C9D.5060602@oracle.com>

Thank you Alan!

Ivan

On 26.08.2013 14:33, Alan Bateman wrote:
> On 25/08/2013 20:28, Ivan Gerasimov wrote:
>> I couldn't come up with any idea on how to test the overflow without 
>> actually allocating that much memory.:
>>
>>
>> I simplified the test a bit once again. Instead of invoking the same 
>> class twice, I created a designated class for the child.
>> Here's the new webrev: 
>> http://cr.openjdk.java.net/~igerasim/7129312/4/webrev/
>> Hope it looks fine.
>>
>> And here's the exported change set:
>> http://cr.openjdk.java.net/~igerasim/2commit/7129312-jdk8-Negative-array-size.patch 
>>
> I think I'd preferred using the parameter to indicate that the child 
> should be launcher but what you have is okay. I'll push this for you 
> shortly.
>
> -Alan
>
>



From joel.franck at oracle.com  Mon Aug 26 12:39:05 2013
From: joel.franck at oracle.com (Joel Borggren-Franck)
Date: Mon, 26 Aug 2013 14:39:05 +0200
Subject: RFR: 5047859 : (reflect) Class.getField can't find String[].length
Message-ID: <20130826123905.GA26606@jfranck-desktop.jrpg.bea.com>

Hi,

Please review doc fix and test for http://bugs.sun.com/view_bug.do?bug_id=5047859

http://cr.openjdk.java.net/~jfranck/5047859/webrev.00/

This is a spec change to update the spec to match the long-standing implementation.

There is also a clarification of getFields() javadoc without changing the
spec.

cheers
/Joel


From aleksey.shipilev at oracle.com  Mon Aug 26 12:46:48 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 26 Aug 2013 16:46:48 +0400
Subject: JDK 8 RFC 6470700: Math.random() / Math.initRNG() uses "double
	checked locking"
In-Reply-To: <022F8725-278E-44AF-B26A-779E089E33CC@oracle.com>
References: <022F8725-278E-44AF-B26A-779E089E33CC@oracle.com>
Message-ID: <521B4E38.7010709@oracle.com>

On 08/22/2013 03:37 AM, Brian Burkhalter wrote:
> With respect to this issue
> 
> http://bugs.sun.com/view_bug.do?bug_id=6470700
> 
> the code of concern from java.lang.Math is
> 
> 701    private static Random randomNumberGenerator;
> 702
> 703    private static synchronized Random initRNG() {
> 704        Random rnd = randomNumberGenerator;
> 705        return (rnd == null) ? (randomNumberGenerator = new Random()) : rnd;
> 706     }
> 
> 731    public static double random() {
> 732        Random rnd = randomNumberGenerator;
> 733        if (rnd == null) rnd = initRNG();
> 734        return rnd.nextDouble();
> 735    }
> 
> where the class variable "randomNumberGenerator" is not used anywhere else in the class. The complaint is that this is an instance of the broken double-checked locking pattern. While at first glance this might appear to be the case, it does not seem so to me. It looks more like an attempt to avoid calling a synchronized method if "randomNumberGenerator" has already been initialized.
> 
> A more typical pattern would be
> 
>     private static Random randomNumberGenerator;
> 
>     private static synchronized Random getRNG() {
>         if (randomNumberGenerator == null) {
>             randomNumberGenerator = new Random();
>         }
>         return randomNumberGenerator;
>     }
> 
>     public static double random() {
>         return getRNG().nextDouble();
>     }
> 
> Comments, please.

(Sorry, I'm late to the party!)

I'm surprised people are still haunted by DCL :) In the correct form, it
has generally negligible synchronization overheads associated with
volatile read, and in return you have no class metadata waste. As in:

  private static volatile Random rng;

  private static Random getRNG() {
    if (rng == null) {
       synchronized(Math.class) {
          rng = new Random();
       }
    }
    return rng;
  }

  public static double random() {
    return getRNG().nextDouble();
  }

Also, random() will probably be the scalability bottleneck anyway due to
j.l.Random internal atomics. That means, we do not have to provide the
best possible performance for getRNG(), but rather eliminate the
scalability bottleneck. Holder idiom has a benefit of being sequentially
faster (because JITs elide the class init checks, and read the static
field), but in this case of heavy-weight mechanics in j.u.Random, it is
irrelevant. Hence, we can minimize the downside for class metadata
growth by going with DCL.

I would think the *major* problem the patch should fix is the visibility
of new Random() state in the other threads, because its instance is
being published via the data race -- both correct DCL and Holder idiom
solve that. But then again, our current implementation for Random is
using AtomicLong, which has the inherent thread-safeness, making the
only erroneous scenario impossible.

Bottom-line: commit either correct DCL "just" to secure ourselves from
the adversarial j.u.Random changes.

-Aleksey.


From fweimer at redhat.com  Mon Aug 26 12:51:42 2013
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 26 Aug 2013 14:51:42 +0200
Subject: RFR: 5047859 : (reflect) Class.getField can't find String[].length
In-Reply-To: <20130826123905.GA26606@jfranck-desktop.jrpg.bea.com>
References: <20130826123905.GA26606@jfranck-desktop.jrpg.bea.com>
Message-ID: <521B4F5E.2020203@redhat.com>

On 08/26/2013 02:39 PM, Joel Borggren-Franck wrote:
> Hi,
>
> Please review doc fix and test for http://bugs.sun.com/view_bug.do?bug_id=5047859
>
> http://cr.openjdk.java.net/~jfranck/5047859/webrev.00/
>
> This is a spec change to update the spec to match the long-standing implementation.

Perhaps use {@code length} instead of 'length'?  Technically, I don't 
think the length field exists at all.  The Java language just happens to 
use field syntax to represent the arraylength opcode.  But adding some 
clarification to the documentation certainly doesn't hurt.

-- 
Florian Weimer / Red Hat Product Security Team


From paul.sandoz at oracle.com  Mon Aug 26 13:15:00 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 26 Aug 2013 15:15:00 +0200
Subject: Java 8 RFC 7189139: BigInteger's staticRandom field can be a
	source of bottlenecks
In-Reply-To: <521B47C6.9010407@oracle.com>
References: <050BDF31-D4C5-447D-A445-38E662A925E4@oracle.com>
	<521B47C6.9010407@oracle.com>
Message-ID: <7AC9117C-0AF1-485C-AC69-590029494298@oracle.com>


On Aug 26, 2013, at 2:19 PM, Aleksey Shipilev  wrote:

> Hi Brian,
> 
> On 08/24/2013 03:39 AM, Brian Burkhalter wrote:
>> file:///Users/bpb/Work/JSL/jdk/jdk8/tl8/jdk/7189139/index.html
>> 
>> would be appreciated.
> 
> I'm puzzled over this fix.
> 
> Isn't the scalability bottleneck being inherent to SecureRandom, because
> it piggybacks on the system entropy pool, which is depleted every so
> often? What good the thread-local instances of SR actually bring to us?
> 


Right, see here:

  http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/009176.html

"I spent some time looking at the implementation of SecureRandom and of sun.security.provider.NativePRNG. The implementation of NativePRNG uses a static singleton to perform all of the work, so that looked like the concurrency bottleneck. But when I rewrote that class, it turns out that even removing all of the Java level concurrency bottlenecks, we still can't generate concurrent secure random numbers, because the NativePRNG reads /dev/urandom for each byte, and that is inherently sequential and is the bottleneck to the entire process of generating secure random numbers."


> As discussed in the relevant threads in the original bug report, the
> actual fix should be a very accurate replacement of SR with some other
> faster and reliable RNG to avoid the inherent scalability bottlenecks.
> 

I don't know about the PRNG requirements for Miller-Rabin but the changes to TLR in review might be a possible substitute for SR in this case, since TLR will be updated to use the same PRNG algorithm as SplittableRandom, which passes DieHarder tests.  Otherwise, i think we may just be stuck with SR.

Paul.

>> Rudimentary testing with JMH 
>> (http://openjdk.java.net/projects/code-tools/jmh/) did not reveal any
>> deleterious performance effects in single-threaded operation nor any
>> obvious improvements in the dual threaded case but testing was done
>> on on my aging Core 2 Duo notebook and is not likely representative
>> of anything approaching real world conditions.
> 
> That further reinforces my belief this particular change is not really
> required :)
> 
> -Aleksey.
> 


From paul.sandoz at oracle.com  Mon Aug 26 13:18:33 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 26 Aug 2013 15:18:33 +0200
Subject: RFR (M) CR 8023234: StampedLock serializes readers on writer
	unlock
In-Reply-To: <521B4806.70906@oracle.com>
References: <521230D1.9070803@oracle.com>
	
	<52138373.8090903@oracle.com>
	
	<5214FCE4.9030507@oracle.com>
	
	<52150F82.1090600@oracle.com> <52173B8D.5080001@oracle.com>
	<521B4806.70906@oracle.com>
Message-ID: <58582DB2-4EB3-4800-9D7A-E5398BE64BE3@oracle.com>


On Aug 26, 2013, at 2:20 PM, Aleksey Shipilev  wrote:

> Reminder :)
> 

IIRC one reviewer should be sufficient, plus i don't feel qualified to review this at the moment. But i suspect you will also need a committer :-) i can do that for you.

Paul.

From joel.franck at oracle.com  Mon Aug 26 13:28:04 2013
From: joel.franck at oracle.com (Joel Borggren-Franck)
Date: Mon, 26 Aug 2013 15:28:04 +0200
Subject: RFR: 5047859 : (reflect) Class.getField can't find String[].length
In-Reply-To: <521B4F5E.2020203@redhat.com>
References: <20130826123905.GA26606@jfranck-desktop.jrpg.bea.com>
	<521B4F5E.2020203@redhat.com>
Message-ID: <20130826132804.GB26606@jfranck-desktop.jrpg.bea.com>

Hi Florian,

Thanks for the comments,

On 2013-08-26, Florian Weimer wrote:
> On 08/26/2013 02:39 PM, Joel Borggren-Franck wrote:
> >Hi,
> >
> >Please review doc fix and test for http://bugs.sun.com/view_bug.do?bug_id=5047859
> >
> >http://cr.openjdk.java.net/~jfranck/5047859/webrev.00/
> >
> >This is a spec change to update the spec to match the long-standing implementation.
> 
> Perhaps use {@code length} instead of 'length'?

I agree, will fix.

> Technically, I
> don't think the length field exists at all.  The Java language just
> happens to use field syntax to represent the arraylength opcode.
> But adding some clarification to the documentation certainly doesn't
> hurt.
> 

The language spec (JLS $10.7) is very clear that there is a length
member for array types, and that it is public, final and a field. I
don't think most vm's implement it as a field, but that shouldn't
matter. So while I agree this is clarifying it is actually a "bug fix"
as well.

cheers
/Joel


From aleksey.shipilev at oracle.com  Mon Aug 26 13:37:07 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 26 Aug 2013 17:37:07 +0400
Subject: RFR (M) CR 8023234: StampedLock serializes readers on writer
	unlock
In-Reply-To: <58582DB2-4EB3-4800-9D7A-E5398BE64BE3@oracle.com>
References: <521230D1.9070803@oracle.com>
	
	<52138373.8090903@oracle.com>
	
	<5214FCE4.9030507@oracle.com>
	
	<52150F82.1090600@oracle.com> <52173B8D.5080001@oracle.com>
	<521B4806.70906@oracle.com>
	<58582DB2-4EB3-4800-9D7A-E5398BE64BE3@oracle.com>
Message-ID: <521B5A03.7010302@oracle.com>

On 08/26/2013 05:18 PM, Paul Sandoz wrote:
> 
> On Aug 26, 2013, at 2:20 PM, Aleksey Shipilev
>  wrote:
> 
>> Reminder :)
>> 
> 
> IIRC one reviewer should be sufficient, plus i don't feel qualified
> to review this at the moment. But i suspect you will also need a
> committer :-) i can do that for you.

Ah, if only one reviewer is required, then Martin had already reviewed.
Please push! (Do you need the changeset?)

  http://cr.openjdk.java.net/~shade/8023234/webrev.01/

-Aleksey.


From aleksey.shipilev at oracle.com  Mon Aug 26 13:52:42 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 26 Aug 2013 17:52:42 +0400
Subject: RFR (M) CR 8023234: StampedLock serializes readers on writer
	unlock
In-Reply-To: <521B5A03.7010302@oracle.com>
References: <521230D1.9070803@oracle.com>
	
	<52138373.8090903@oracle.com>
	
	<5214FCE4.9030507@oracle.com>
	
	<52150F82.1090600@oracle.com> <52173B8D.5080001@oracle.com>
	<521B4806.70906@oracle.com>
	<58582DB2-4EB3-4800-9D7A-E5398BE64BE3@oracle.com>
	<521B5A03.7010302@oracle.com>
Message-ID: <521B5DAA.5060609@oracle.com>

On 08/26/2013 05:37 PM, Aleksey Shipilev wrote:
> On 08/26/2013 05:18 PM, Paul Sandoz wrote:
>>
>> On Aug 26, 2013, at 2:20 PM, Aleksey Shipilev
>>  wrote:
>>
>>> Reminder :)
>>>
>>
>> IIRC one reviewer should be sufficient, plus i don't feel qualified
>> to review this at the moment. But i suspect you will also need a
>> committer :-) i can do that for you.
> 
> Ah, if only one reviewer is required, then Martin had already reviewed.
> Please push! (Do you need the changeset?)
> 
>   http://cr.openjdk.java.net/~shade/8023234/webrev.01/

Changeset:
  http://cr.openjdk.java.net/~shade/8023234/8023234.changeset

-Aleksey.



From paul.sandoz at oracle.com  Mon Aug 26 14:20:29 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 26 Aug 2013 14:20:29 +0000
Subject: hg: jdk8/tl/jdk: 8023234: StampedLock serializes readers on writer
	unlock
Message-ID: <20130826142104.159D148B60@hg.openjdk.java.net>

Changeset: 8a36fc7f494c
Author:    shade
Date:      2013-08-26 17:50 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a36fc7f494c

8023234: StampedLock serializes readers on writer unlock
Summary: Sync-up the fix from jsr166 CVS, signal more readers on writer unlock
Reviewed-by: martin, shade
Contributed-by: Doug Lea 


! src/share/classes/java/util/concurrent/locks/StampedLock.java
+ test/java/util/concurrent/locks/StampedLock/ReadersUnlockAfterWriteUnlock.java



From guy.steele at oracle.com  Mon Aug 26 14:52:06 2013
From: guy.steele at oracle.com (Guy Steele)
Date: Mon, 26 Aug 2013 10:52:06 -0400
Subject: Java 8 RFR 8010430: Math.round has surprising behavior for odd
	values of ulp 1
In-Reply-To: <1377370934.77781.YahooMailNeo@web171703.mail.ir2.yahoo.com>
References: 		<0099615E-F51D-47C4-9330-582911BBD3EF@oracle.com>		
	
	<1377370934.77781.YahooMailNeo@web171703.mail.ir2.yahoo.com>
Message-ID: <31920C83-8AEC-443E-94BB-300B2F7B17EE@oracle.com>


On Aug 24, 2013, at 3:02 PM, Jeff Hain  wrote:

> 
> Dmitry Nadezhin wrote:
>> Nevertheless, I send this variant now in hope that it may be useful.
> 
> Great! It's much faster than what I proposed, cleaner (only integers),
> and according to my tests it behaves the same.

Excellent!  Nice piece of work---thanks, Dmitry.



From roger.riggs at oracle.com  Mon Aug 26 15:12:05 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Mon, 26 Aug 2013 11:12:05 -0400
Subject: RFR: 5047859 : (reflect) Class.getField can't find String[].length
In-Reply-To: <20130826123905.GA26606@jfranck-desktop.jrpg.bea.com>
References: <20130826123905.GA26606@jfranck-desktop.jrpg.bea.com>
Message-ID: <521B7045.80908@oracle.com>

Hi Joel,

Looks fine except for a typo in the test ArrayLength.java, line 28: 
"Filed" -> "Field".

(Not a Reviewer).

Roger

On 8/26/2013 8:39 AM, Joel Borggren-Franck wrote:
> Hi,
>
> Please review doc fix and test for http://bugs.sun.com/view_bug.do?bug_id=5047859
>
> http://cr.openjdk.java.net/~jfranck/5047859/webrev.00/
>
> This is a spec change to update the spec to match the long-standing implementation.
>
> There is also a clarification of getFields() javadoc without changing the
> spec.
>
> cheers
> /Joel



From roger.riggs at oracle.com  Mon Aug 26 16:00:48 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Mon, 26 Aug 2013 16:00:48 +0000
Subject: hg: jdk8/tl/jdk: 8011944: Sort fails with
	ArrayIndexOutOfBoundsException
Message-ID: <20130826160109.BC73D48B69@hg.openjdk.java.net>

Changeset: 07585a2483fa
Author:    rriggs
Date:      2013-08-26 11:46 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07585a2483fa

8011944: Sort fails with ArrayIndexOutOfBoundsException
Summary: Increase the size of pending stack and add test cases
Reviewed-by: alanb

! src/share/classes/java/util/ComparableTimSort.java
! src/share/classes/java/util/TimSort.java
+ test/java/util/Arrays/TimSortStackSize.java



From joel.franck at oracle.com  Mon Aug 26 16:09:49 2013
From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Mon, 26 Aug 2013 18:09:49 +0200
Subject: RFR: 8022343: j.l.Class.getAnnotatedSuperclass() doesn't return
	null in some cases
In-Reply-To: <20130816121739.GM12405@jfranck-desktop.jrpg.bea.com>
References: <20130816121739.GM12405@jfranck-desktop.jrpg.bea.com>
Message-ID: <6A477AA7-88DD-491B-9989-BDC447AA8D48@oracle.com>

Joe, Paul, Vicente,

Thanks for the reviews!

cheers
/Joel

On 16 aug 2013, at 14:17, Joel Borggren-Franck  wrote:

> Hi
> 
> Please review this small fix for a type annotation reflection issue.
> 
> The javadoc spec for Class.getAnnotatedSuperclass says: 
> 
> * If this Class represents either the Object class, an interface type, an
> * array type, a primitive type, or void, the return value is null.
> 
> The patch fixes this.
> 
> Webrev at: http://cr.openjdk.java.net/~jfranck/8022343/webrew.00/
> 
> Patch also included it at the end of this mail.
> 
> cheers
> /Joel
> 
> 
> 
> diff -r b07b19182e40 src/share/classes/java/lang/Class.java
> --- a/src/share/classes/java/lang/Class.java	Thu Aug 15 15:04:59 2013 +0100
> +++ b/src/share/classes/java/lang/Class.java	Fri Aug 16 13:20:31 2013 +0200
> @@ -3338,8 +3338,16 @@
>      * @since 1.8
>      */
>     public AnnotatedType getAnnotatedSuperclass() {
> -         return TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), getConstantPool(), this);
> -}
> +        if(this == Object.class ||
> +                isInterface() ||
> +                isArray() ||
> +                isPrimitive() ||
> +                this == Void.TYPE) {
> +            return null;
> +        }
> +
> +        return TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), getConstantPool(), this);
> +    }
> 
>     /**
>      * Returns an array of AnnotatedType objects that represent the use of types to
> diff -r b07b19182e40 test/java/lang/annotation/TypeAnnotationReflection.java
> --- a/test/java/lang/annotation/TypeAnnotationReflection.java	Thu Aug 15 15:04:59 2013 +0100
> +++ b/test/java/lang/annotation/TypeAnnotationReflection.java	Fri Aug 16 13:20:31 2013 +0200
> @@ -23,7 +23,7 @@
> 
> /*
>  * @test
> - * @bug 8004698 8007073
> + * @bug 8004698 8007073 8022343
>  * @summary Unit test for type annotations
>  */
> 
> @@ -58,7 +58,7 @@
>     }
> 
>     private static void testSuper() throws Exception {
> -        check(Object.class.getAnnotatedSuperclass().getAnnotations().length == 0);
> +        check(Object.class.getAnnotatedSuperclass() == null);
>         check(Class.class.getAnnotatedSuperclass().getAnnotations().length == 0);
> 
>         AnnotatedType a;
> diff -r b07b19182e40 test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java	Fri Aug 16 13:20:31 2013 +0200
> @@ -0,0 +1,50 @@
> +/*
> + * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> + *
> + * This code is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 only, as
> + * published by the Free Software Foundation.
> + *
> + * This code is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> + * version 2 for more details (a copy is included in the LICENSE file that
> + * accompanied this code).
> + *
> + * You should have received a copy of the GNU General Public License version
> + * 2 along with this work; if not, write to the Free Software Foundation,
> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> + *
> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
> + * or visit www.oracle.com if you need additional information or have any
> + * questions.
> + */
> +
> +/*
> + * @test
> + * @bug 8022343
> + * @summary make sure Class.getAnnotatedSuperclass() returns null when specified to do so
> + */
> +
> +import java.util.*;
> +import java.lang.annotation.*;
> +import java.lang.reflect.*;
> +import java.io.Serializable;
> +
> +public class GetAnnotatedSuperclass {
> +    public static void main(String[] args) throws Exception {
> +        check(Object.class.getAnnotatedSuperclass() == null);
> +        check(If.class.getAnnotatedSuperclass() == null);
> +        check(Object[].class.getAnnotatedSuperclass() == null);
> +        check(void.class.getAnnotatedSuperclass() == null);
> +        check(int.class.getAnnotatedSuperclass() == null);
> +    }
> +
> +    private static void check(boolean b) {
> +        if (!b)
> +            throw new RuntimeException();
> +    }
> +    interface If {}
> +}
> +



From xueming.shen at oracle.com  Mon Aug 26 16:40:10 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 26 Aug 2013 09:40:10 -0700
Subject: RFR 8022761: SQE test regression on wrongly signed indexed jar
	file
In-Reply-To: <52121976.60708@oracle.com>
References: <520861FA.4090605@oracle.com> <52121976.60708@oracle.com>
Message-ID: <521B84EA.6050302@oracle.com>

On 08/19/2013 06:11 AM, Weijun Wang wrote:
> Hi Sherman
>
> I try out "jar i" after signing and it puts INDEX.LIST at the very beginning of the file. Does this mean INDEX.LIST was actually an exception? Or it's just a bug?
>
> Anyway, I think I should update the fix for 8021788 and here is the webrev:
>
>   http://cr.openjdk.java.net/~weijun/8022761/webrev.00/
>
> Now it also skips INDEX.LIST, i.e. update line 142 to
>
>   if (uname.equals(JarFile.MANIFEST_NAME) ||
>           uname.equals(JarIndex.INDEX_NAME) ) {
>
> After this change, if INDEX.LIST appears before the MANIFEST and signature-related files, it will not be treated as signed. This should usually be true because it only happens when you call "jar i" after signing a jar which means INDEX.LIST *is* unsigned.
>
> Thanks
> Max
>
> On 8/12/13 12:18 PM, Weijun Wang wrote:
>> Hi Sherman
>>
>> SQE observes a regression in their test suite and
>> the reason is my recent fix for 8021788 at
>>
>>    http://hg.openjdk.java.net/jdk8/tl/jdk/rev/758e3117899c
>>
>> The jar file mentioned contains
>>
>>      66 Mon Jun 04 15:42:18 CST 2007 META-INF/INDEX.LIST
>>     323 Sat Apr 01 15:47:28 CST 2000 META-INF/MANIFEST.MF
>>     376 Mon Jun 04 15:41:00 CST 2007 META-INF/MYKEY.SF
>>     972 Sat Apr 01 15:47:38 CST 2000 META-INF/MYKEY.DSA
>>       0 Sat Apr 01 15:46:58 CST 2000 META-INF/
>>       0 Sat Apr 01 15:45:16 CST 2000 test/
>>      21 Sat Apr 01 15:46:24 CST 2000 test/test0
>>      21 Sat Apr 01 15:46:18 CST 2000 test/test1
>>      21 Sat Apr 01 15:46:04 CST 2000 test/test2
>>      21 Sat Apr 01 15:46:10 CST 2000 test/test3
>>
>> After JDK-8021788, the file is regarded as an unsigned jar because the
>> updated JarVerifier goes thru all signature-related files and treats all
>> others not. Here the first one is not signature-related so none is.
>>
>> Is fix for JDK-8021788 wrong? Inside JarVerifier.java, we have
>>
>>    * Assumptions:
>>    * 1. The manifest should be the first entry in the META-INF directory.
>>    * 2. The .SF/.DSA/.EC files follow the manifest, before any normal
>> entries
>>
>> Is this INDEX.LIST an exception?
>>

Hi Max,

The assumption was made probably before the jar index was introduced(1.3?).
Jar spec never assumes the "order" of the files inside the meta-inf directory
(the spec treats the jar/zip file as a file system, the implementation then faces
this issue when the archive is handled in "steam"), but our implementation
does have the assumption. JarInputStream has a similar assumption regarding
the manifest.mf and a workaround for jarindex, if the jarindex is the first one.
I would take it as an implementation details.

The change looks fine.

-Sherman

>> Thanks
>> Max



From mandy.chung at oracle.com  Mon Aug 26 17:26:35 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 26 Aug 2013 10:26:35 -0700
Subject: RFR: 5047859 : (reflect) Class.getField can't find String[].length
In-Reply-To: <20130826123905.GA26606@jfranck-desktop.jrpg.bea.com>
References: <20130826123905.GA26606@jfranck-desktop.jrpg.bea.com>
Message-ID: <521B8FCB.2060600@oracle.com>

Joel,

The spec of the getFields and getDeclaredFields() methods both states this:

   This method returns an array of length 0 if the class
   or interface declares no fields, or if this|Class|  object
   represents a primitive type, an array class, or void.

The spec of the getDeclaredField() method has this sentence:

   Note that this method will not reflect the {@code length}
   field of an array class.

Your change is okay and it would be good to keep the getField(s)
and getDeclaredField(s) methods be consistent and states its
return value "if this|Class|  object represents a primitive type,
an array class, or void"

Mandy

On 8/26/2013 5:39 AM, Joel Borggren-Franck wrote:
> Hi,
>
> Please review doc fix and test for http://bugs.sun.com/view_bug.do?bug_id=5047859
>
> http://cr.openjdk.java.net/~jfranck/5047859/webrev.00/
>
> This is a spec change to update the spec to match the long-standing implementation.
>
> There is also a clarification of getFields() javadoc without changing the
> spec.
>
> cheers
> /Joel



From sean.coffey at oracle.com  Mon Aug 26 17:34:36 2013
From: sean.coffey at oracle.com (sean.coffey at oracle.com)
Date: Mon, 26 Aug 2013 17:34:36 +0000
Subject: hg: jdk8/tl/jdk: 8016018: Typo in AbstractStringBuilder#indexOf and
	#lastIndexOf descriptions
Message-ID: <20130826173447.BBEA048B6F@hg.openjdk.java.net>

Changeset: 92a66af7f834
Author:    igerasim
Date:      2013-08-26 18:26 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92a66af7f834

8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions
Reviewed-by: alanb, chegar

! src/share/classes/java/lang/AbstractStringBuilder.java



From mike.duigou at oracle.com  Mon Aug 26 18:38:22 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Mon, 26 Aug 2013 18:38:22 +0000
Subject: hg: jdk8/tl: 8023491: Remove target names from test/Makefile and
	defer to sub-repo makefiles.
Message-ID: <20130826183822.7C91C48B79@hg.openjdk.java.net>

Changeset: f643fee2b40f
Author:    mduigou
Date:      2013-08-26 10:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/f643fee2b40f

8023491: Remove target names from test/Makefile and defer to sub-repo makefiles.
Reviewed-by: erikj

! common/makefiles/Main.gmk
! test/Makefile



From jonathan.gibbons at oracle.com  Mon Aug 26 18:49:13 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Mon, 26 Aug 2013 18:49:13 +0000
Subject: hg: jdk8/tl/langtools: 8023701: Fix badly named test
Message-ID: <20130826184916.B9D5B48B7B@hg.openjdk.java.net>

Changeset: 60f156c653d3
Author:    jjg
Date:      2013-08-26 11:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/60f156c653d3

8023701: Fix badly named test
Reviewed-by: bpatel

- test/com/sun/javadoc/testNavagation/TestNavagation.java
- test/com/sun/javadoc/testNavagation/pkg/A.java
- test/com/sun/javadoc/testNavagation/pkg/C.java
- test/com/sun/javadoc/testNavagation/pkg/E.java
- test/com/sun/javadoc/testNavagation/pkg/I.java
+ test/com/sun/javadoc/testNavigation/TestNavigation.java
+ test/com/sun/javadoc/testNavigation/pkg/A.java
+ test/com/sun/javadoc/testNavigation/pkg/C.java
+ test/com/sun/javadoc/testNavigation/pkg/E.java
+ test/com/sun/javadoc/testNavigation/pkg/I.java



From paul.sandoz at oracle.com  Mon Aug 26 20:10:40 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 26 Aug 2013 22:10:40 +0200
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets
	or trees (red/black)
In-Reply-To: <521A473A.6000807@univ-mlv.fr>
References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
	<521A473A.6000807@univ-mlv.fr>
Message-ID: <83208874-EB5A-4CD8-A78D-39A599FB3FF8@oracle.com>


On Aug 25, 2013, at 8:04 PM, Remi Forax  wrote:

> On 08/21/2013 02:25 PM, Paul Sandoz wrote:
>> Hi,
>> 
>> Here are Doug's Linked/HashMap changes, discussed in a previous thread, as a webrev:
>> 
>>   http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/
>> 
>> I also added some tests related to characteristics associated with fixing another bug.
>> 
>> Looking at the diffs will be tricky given there are so many changes.
> 
> 
> The code can be simplified a little bit by using the diamond syntax,
> HashMap (lines: 919, 963, 1026, 1497, 1569) and
> LinkedHashMap (lines: 255, 264, 270, 278)
> 
> There are a bunch of @Override that are missing making the code harder than it should to read.
> 

Yes, i think this is because it sticks to the 166 style i suspect. Easy to change.


> HashMapSpliterator.est should be renamed to estimateSize.
> 
> All occurences of "(n - 1) & hash" should be replaced by "hash & (n - 1)" because it's easier to explain.
> 

I am OK with how they are, and it's consistent with other code.


> TreeNode.getTreeNode() should be a static method and take a Node as first argument,
> so most of the casts to TreeNode that bother you will disappear :)
>  static TreeNode getTreeNode(Node node, int h, Object k) {
>    TreeNode first = (TreeNode    return ((first.parent != null) ? first.root() : firt).find(h, k, null);
>  }
> 

Yes, that will reduce the casts.


> In putVal, line 654, the null check (e != null) makes the method hard to read,
> at least I think a comment saying that it means that an existing node need to be altered is needed.
> 

e.g.:

            if (e != null) { // existing mapping for key


> And I still don't like the way the method clone() is implemented (the older implementation has the same issue),
> result should not be initialized to null and the catch clause should thow an InternalError or an AssertionError,
> 

You mean like this:

    public Object clone() {
        HashMap result = null;
        try {
            result = (HashMap)super.clone();
        } catch (CloneNotSupportedException e) {
            // this shouldn't happen, since we are Cloneable
            throw new InternalError(e);
        }
        result.reinitialize();
        result.putMapEntries(this, false);
        return result;
    }



> Taking a look to the generated assemblies for HashMap.get(), there are three differences,
> 1) the old implementation and the new implementation both have a shortcut to return null,
>    but the condition is slightly different, the old implementation test if size == 0 while
>    the new one test if arraylength <= 0.
>    So the new implementation use less load but at the price of a less general condition.
> 2) the new implementation do a lot of less bits twiddling on the hashCode value
> 3) the old implementation use an array of Object and not an array of Node, so
>    there is a supplementary fast checkcast.
> apart that the whole code is identical, so the introduction of the tree implementation has
> no runtime cost if the tree is not needed.
> 
> For HashMap.put, the new implementation has no runtime cost too and does fewer loads
> because the code of the old implementation was written in the stupid way
> (the field 'table' has to be loaded several times by example).
> 
> so the code is clearly an improvement compared to the previous versions in term of 'assembly beauty' :)
> 
>> 
>> 
>> I fixed unchecked warnings in LinkedHashMap, but have not done so for HashMap, where there are many more casts from Node to TreeNode. One way to solve that is with a static method:
>> 
>>     @SuppressWarnings("unchecked")
>>     static  TreeNode asTreeNode(Node n) {
>>         return (TreeNode) n;
>>     }
>> 
>> but i dunno what the performance implications are. Perhaps it's best to simply stuff @SuppressWarnings on methods of TreeNode rather than trying to modify code just for the sake of reducing the scope.
> 
> You should not need the @SuppressWarnings here?
> 

Doh, clearly i am not thinking straight here and got confused over unchecked!

Paul.

From mike.duigou at oracle.com  Mon Aug 26 20:38:24 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 26 Aug 2013 13:38:24 -0700
Subject: 8020292: j.u.SplittableRandom
In-Reply-To: <9F153157-0FC5-4385-B1BC-4FE2D43006F4@oracle.com>
References: <9F153157-0FC5-4385-B1BC-4FE2D43006F4@oracle.com>
Message-ID: <170DE4F2-15EE-4594-8334-6105935C9D33@oracle.com>

With most recent changes, +1.

Mike

On Aug 19 2013, at 04:06 , Paul Sandoz wrote:

> Hi,
> 
> This is the patch for SplittableRandom:
> 
>  http://cr.openjdk.java.net/~psandoz/tl/JDK-8020292-SplittableRandom/webrev/
> 
> The algorithm remains the same as reported by Doug on the 9th August:
> 
>  http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019768.html
> 
> Paul.



From xueming.shen at oracle.com  Mon Aug 26 20:54:53 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 26 Aug 2013 13:54:53 -0700
Subject: RFR:  JDK-8023647,," abc1c " .matches( " (\\w)+1\\1 " )) returns false
Message-ID: <521BC09D.2060800@oracle.com>

Hi,

Please help review the proposed change for 8023647:

http://cr.openjdk.java.net/~sherman/8023647/webrev

It appears group index updating in situation of GroupCurly backing off
is incorrect from day one (the bug is reproducible back to jdk5). The
current implementation does not back off the index to a previous match,
but the one is being back off.

The ln#4459 is updating a local variable before return, which is not
necessary, I removed it with this change.

Thanks,
-Sherman


From paul.sandoz at oracle.com  Mon Aug 26 20:55:36 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 26 Aug 2013 20:55:36 +0000
Subject: hg: jdk8/tl/jdk: 8020292: j.u.SplittableRandom
Message-ID: <20130826205600.268B448B83@hg.openjdk.java.net>

Changeset: 5ce9025c9e1a
Author:    psandoz
Date:      2013-08-26 22:55 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ce9025c9e1a

8020292: j.u.SplittableRandom
Reviewed-by: mduigou
Contributed-by: Guy Steele , Doug Lea 
, Brian Goetz , Paul Sandoz 

+ src/share/classes/java/util/SplittableRandom.java
+ test/java/util/SplittableRandom/SplittableRandomTest.java
+ test/java/util/stream/test/org/openjdk/tests/java/util/SplittableRandomTest.java



From forax at univ-mlv.fr  Mon Aug 26 21:13:28 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 26 Aug 2013 23:13:28 +0200
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets
	or trees (red/black)
In-Reply-To: <83208874-EB5A-4CD8-A78D-39A599FB3FF8@oracle.com>
References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
	<521A473A.6000807@univ-mlv.fr>
	<83208874-EB5A-4CD8-A78D-39A599FB3FF8@oracle.com>
Message-ID: <521BC4F8.2060001@univ-mlv.fr>

On 08/26/2013 10:10 PM, Paul Sandoz wrote:
> On Aug 25, 2013, at 8:04 PM, Remi Forax  wrote:
>
>> On 08/21/2013 02:25 PM, Paul Sandoz wrote:
>>> Hi,
>>>
>>> Here are Doug's Linked/HashMap changes, discussed in a previous thread, as a webrev:
>>>
>>>    http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/
>>>
>>> I also added some tests related to characteristics associated with fixing another bug.
>>>
>>> Looking at the diffs will be tricky given there are so many changes.
>>
>> The code can be simplified a little bit by using the diamond syntax,
>> HashMap (lines: 919, 963, 1026, 1497, 1569) and
>> LinkedHashMap (lines: 255, 264, 270, 278)
>>
>> There are a bunch of @Override that are missing making the code harder than it should to read.
>>
> Yes, i think this is because it sticks to the 166 style i suspect. Easy to change.
>
>
>> HashMapSpliterator.est should be renamed to estimateSize.
>>
>> All occurences of "(n - 1) & hash" should be replaced by "hash & (n - 1)" because it's easier to explain.
>>
> I am OK with how they are, and it's consistent with other code.

Ok, not a big deal.

>
>
>> TreeNode.getTreeNode() should be a static method and take a Node as first argument,
>> so most of the casts to TreeNode that bother you will disappear :)
>>   static TreeNode getTreeNode(Node node, int h, Object k) {
>>     TreeNode first = (TreeNode>     return ((first.parent != null) ? first.root() : firt).find(h, k, null);
>>   }
>>
> Yes, that will reduce the casts.
>
>
>> In putVal, line 654, the null check (e != null) makes the method hard to read,
>> at least I think a comment saying that it means that an existing node need to be altered is needed.
>>
> e.g.:
>
>              if (e != null) { // existing mapping for key

Yes, perfect.

>
>
>> And I still don't like the way the method clone() is implemented (the older implementation has the same issue),
>> result should not be initialized to null and the catch clause should thow an InternalError or an AssertionError,
>>
> You mean like this:
>
>      public Object clone() {
>          HashMap result = null;
>          try {
>              result = (HashMap)super.clone();
>          } catch (CloneNotSupportedException e) {
>              // this shouldn't happen, since we are Cloneable
>              throw new InternalError(e);
>          }
>          result.reinitialize();
>          result.putMapEntries(this, false);
>          return result;
>      }

Yes, and in that case, you don't need to initialize result to null (the 
first line), because when result is used
(result.reinitialize()) result is already initialized by the return 
value of super.clone().

[... ]

>
>>>
>>> I fixed unchecked warnings in LinkedHashMap, but have not done so for HashMap, where there are many more casts from Node to TreeNode. One way to solve that is with a static method:
>>>
>>>      @SuppressWarnings("unchecked")
>>>      static  TreeNode asTreeNode(Node n) {
>>>          return (TreeNode) n;
>>>      }
>>>
>>> but i dunno what the performance implications are. Perhaps it's best to simply stuff @SuppressWarnings on methods of TreeNode rather than trying to modify code just for the sake of reducing the scope.
>> You should not need the @SuppressWarnings here?
>>
> Doh, clearly i am not thinking straight here and got confused over unchecked!
>
> Paul.

regards,
R?mi



From henry.jen at oracle.com  Mon Aug 26 22:20:16 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Mon, 26 Aug 2013 22:20:16 +0000
Subject: hg: jdk8/tl/jdk: 8023681: Fix raw type warning caused by Sink
Message-ID: <20130826222042.C71A848B87@hg.openjdk.java.net>

Changeset: 35c1609d9488
Author:    henryjen
Date:      2013-08-09 09:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/35c1609d9488

8023681: Fix raw type warning caused by Sink
Reviewed-by: mduigou, briangoetz

! src/share/classes/java/util/stream/Collectors.java
! src/share/classes/java/util/stream/DistinctOps.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/Sink.java
! src/share/classes/java/util/stream/SliceOps.java
! src/share/classes/java/util/stream/SortedOps.java



From jonathan.gibbons at oracle.com  Mon Aug 26 22:56:30 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Mon, 26 Aug 2013 22:56:30 +0000
Subject: hg: jdk8/tl/langtools: 8023768: Use the unannotatedType in cyclicity
	checks.
Message-ID: <20130826225633.9D81D48B89@hg.openjdk.java.net>

Changeset: 7bf6313e1ced
Author:    jjg
Date:      2013-08-26 15:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7bf6313e1ced

8023768: Use the unannotatedType in cyclicity checks.
Reviewed-by: jjg
Contributed-by: wdietl at gmail.com

! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/annotations/typeAnnotations/failures/TypeVariableCycleTest.java



From brian.burkhalter at oracle.com  Mon Aug 26 23:19:52 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 26 Aug 2013 16:19:52 -0700
Subject: Java 8 RFR 8010430: Math.round has surprising behavior for odd
	values of ulp 1
In-Reply-To: <31920C83-8AEC-443E-94BB-300B2F7B17EE@oracle.com>
References: 		<0099615E-F51D-47C4-9330-582911BBD3EF@oracle.com>		
	
	<1377370934.77781.YahooMailNeo@web171703.mail.ir2.yahoo.com>
	<31920C83-8AEC-443E-94BB-300B2F7B17EE@oracle.com>
Message-ID: 

On Aug 26, 2013, at 7:52 AM, Guy Steele wrote:

> On Aug 24, 2013, at 3:02 PM, Jeff Hain  wrote:
> 
>> 
>> Dmitry Nadezhin wrote:
>>> Nevertheless, I send this variant now in hope that it may be useful.
>> 
>> Great! It's much faster than what I proposed, cleaner (only integers),
>> and according to my tests it behaves the same.
> 
> Excellent!  Nice piece of work---thanks, Dmitry.

Indeed - thanks, Dmitry! That is much better than what I proposed.

I did a quick and dirty JMH test with this code and it looks to be more than 6% faster for double and more than 24% faster for float versus the current codebase. The speed up is probably more than these values which should be considered lower bounds on speed improvement.

I have updated the webrev accordingly:

http://cr.openjdk.java.net/~bpb/8010430/

Approval by a Reviewer of this patch is still needed.

Thanks,

Brian

From david.holmes at oracle.com  Tue Aug 27 00:12:08 2013
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Tue, 27 Aug 2013 00:12:08 +0000
Subject: hg: jdk8/tl/jdk: 8014135: The JVMTI specification does not conform to
	recent changes in JNI specification
Message-ID: <20130827001233.54B4148B8C@hg.openjdk.java.net>

Changeset: 9586ca82bd8b
Author:    bpittore
Date:      2013-08-26 11:27 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9586ca82bd8b

8014135: The JVMTI specification does not conform to recent changes in JNI specification
Summary: Added support for statically linked agents
Reviewed-by: alanb, sspitsyn, bobv, coleenp

! src/share/classes/com/sun/tools/attach/VirtualMachine.java



From dan.xu at oracle.com  Tue Aug 27 00:18:34 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Mon, 26 Aug 2013 17:18:34 -0700
Subject: RFR: JDK-8023765 -- Improve MaxPathLength.java testcase and reduce
	its test load
Message-ID: <521BF05A.1090805@oracle.com>

Hi All,

MaxPathLength.javais a troublesome testcase, and fails intermittently in 
the nightly test. And it also runs for a long time, especially on 
Windows platforms. Inorder to improve the test stability, I remove its 
unnecessary test iterations, and use NIOdelete method todo the clean-up 
to make the potential failureseasier for diagnosis. Please review 
thechanges. Thanks!

bug: https://bugs.openjdk.java.net/browse/JDK-8023765
webrev: http://cr.openjdk.java.net/~dxu/8023765/webrev/

-Dan


From mike.duigou at oracle.com  Tue Aug 27 01:37:10 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 26 Aug 2013 18:37:10 -0700
Subject: RFR: 8021591 : (s) Additional explicit null checks
In-Reply-To: 
References: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com>
	<51FA8584.1000702@oracle.com>
	<31FFC5F9-2950-44DA-B846-D1A8E8AA9E18@oracle.com>
	
Message-ID: <122CAFC8-5DF9-4ACA-920A-AF416D5E873D@oracle.com>


On Aug 19 2013, at 15:35 , Martin Buchholz wrote:

> My feeling is that the JDK specs have been creeping in the direction of excessive pedantry and doc lawyerism.  I think it's overall a benefit of Java that its documentation is more readable (at the cost of being a little less precise) than the typical ISO spec.

There is a definite tension here. We would like to keep the documentation and specification as readable as possible while still being sufficiently exacting so that behaviour of an API can be correctly predicted by a reader. It goes further than that though because Oracle employs an entire group of engineers who examine the JDK API javadocs looking for normative statements and then write tests to confirm that implementations conform to the API documentation/specification.  The number and quality of tests they provide to ensure conformance has been steadily increasing (and accelerating). Is this a good thing? To me it seems so. When I hear that people encounter problems (other than performance) when switching among Vector<->ArrayList<->LinkedList<->CopyOnWriteArrayList or HashMap<->ConcurrentHashMap or TreeSet<->ConcurrentSkipListSet because of arbitrary corner case differences between implementations I become smy

> 
> So we usually say "returns true if the foo got frozzled" instead of the more precise "returns true if and only if the foo got frozzled".
> It's "obvious" that an NPE is thrown on an attempt to derefence a null arg, which might not happen in some corner case.  I think it's overall a detriment if either extra null checks are inserted or the spec is made more precise but less readable.

Unfortunately the need for NPE documentation is something that seems to have recently gotten worse. It seems to becoming accepted that it is necessary to document what happens when a null reference is passed even when the parameter provides no specific mention of null handling. I blame the plethora of APIs that for inadequate reasons use "null" as their universal solvent--absent, "don't care", default, unknown, maybe-it-works. This could include some JDK APIs such as use of null Comparator to mean "natural order". I remain hopeful that the JSR 305 annotations will reduce some of the burden of documenting null handling. 

> Consider the Throws spec for 
> http://download.java.net/jdk8/docs/api/java/util/TreeMap.html#containsKey(java.lang.Object)
> 
> ClassCastException - if the specified key cannot be compared with the keys currently in the map
> 
> That's incomplete and imprecise, but don't pessimize by adding code to compare the arg with every key in the map!  (which is the equivalent of what is happening here)

Yes, more precise would be to say "could not be compared to some key currently already in the map", but the intent was clear.

On the opposite side we have regular requests (https://bugs.openjdk.java.net/browse/JDK-7014079 plus duplicates it references) to "fix" the specification of HashSet contains() so that it mentions it considers the hashCode() value in addition to equals(). The belief expressed by these reporters is generally that if the JDK developers had fully specified the contract in the HashSet.contains() method along with it's actual behaviour then they would not have used the class incorrectly (generally missing or incorrect equals()/hashCode()).

> A vote from me for maintaining the already high level of pedantry we have, but not raising it any further.

I always imagine it's more like limbo. ;-)

Mike

> 
> 
> 
> On Mon, Aug 19, 2013 at 3:15 PM, Mike Duigou  wrote:
> 
> On Aug 1 2013, at 08:57 , Alan Bateman wrote:
> 
> > On 26/07/2013 16:31, Mike Duigou wrote:
> >> Hello all;
> >>
> >> This patch adds some missing checks for null that, according to interface contract, should be throwing NPE. It also improves the existing tests to check for these cases.
> >>
> >> http://cr.openjdk.java.net/~mduigou/JDK-8021591/0/webrev/
> >>
> >> The changes to src/share/classes/java/util/concurrent/ConcurrentHashMap.java will be synchronized separately with the jsr166 workspace. They are part of this review to avoid test failures.
> >>
> >> Mike
> > As retainAll and removeAll are long standing methods, are there are cases where we might now throw NPE when we didn't previously?
> 
> Yes.
> 
> retainAll(null) and removeAll(null) will more consistently throw NPE. Previously the NPE was not thrown by some collections when the collection they were empty.
> 
> > I'm just wondering if any of these need to be looked at more closely, minimally to get into release/compatibility notes.
> 
> I will definitely tag this issue for release notes mention.
> 
> > -Alan
> 
> 



From mike.duigou at oracle.com  Tue Aug 27 03:16:00 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 26 Aug 2013 20:16:00 -0700
Subject: RFR: 8021591 : (s) Additional explicit null checks
In-Reply-To: <122CAFC8-5DF9-4ACA-920A-AF416D5E873D@oracle.com>
References: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com>
	<51FA8584.1000702@oracle.com>
	<31FFC5F9-2950-44DA-B846-D1A8E8AA9E18@oracle.com>
	
	<122CAFC8-5DF9-4ACA-920A-AF416D5E873D@oracle.com>
Message-ID: 


On Aug 26 2013, at 18:37 , Mike Duigou wrote:

> 
> On Aug 19 2013, at 15:35 , Martin Buchholz wrote:
> 
>> My feeling is that the JDK specs have been creeping in the direction of excessive pedantry and doc lawyerism.  I think it's overall a benefit of Java that its documentation is more readable (at the cost of being a little less precise) than the typical ISO spec.
> 
> There is a definite tension here. We would like to keep the documentation and specification as readable as possible while still being sufficiently exacting so that behaviour of an API can be correctly predicted by a reader. It goes further than that though because Oracle employs an entire group of engineers who examine the JDK API javadocs looking for normative statements and then write tests to confirm that implementations conform to the API documentation/specification.  The number and quality of tests they provide to ensure conformance has been steadily increasing (and accelerating). Is this a good thing? To me it seems so. When I hear that people encounter problems (other than performance) when switching among Vector<->ArrayList<->LinkedList<->CopyOnWriteArrayList or HashMap<->ConcurrentHashMap or TreeSet<->ConcurrentSkipListSet because of arbitrary corner case differences between implementations I become smy

Sorry, replying to my own message to finish an incomplete sentence.

...sympathetic to concerns that the JDK docs/specs are not specific enough.

Mike

From david.holmes at oracle.com  Tue Aug 27 03:21:43 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 27 Aug 2013 13:21:43 +1000
Subject: RFR: 5047859 : (reflect) Class.getField can't find String[].length
In-Reply-To: <20130826123905.GA26606@jfranck-desktop.jrpg.bea.com>
References: <20130826123905.GA26606@jfranck-desktop.jrpg.bea.com>
Message-ID: <521C1B47.5050601@oracle.com>

Hi Joel,

On 26/08/2013 10:39 PM, Joel Borggren-Franck wrote:
> Hi,
>
> Please review doc fix and test for http://bugs.sun.com/view_bug.do?bug_id=5047859
>
> http://cr.openjdk.java.net/~jfranck/5047859/webrev.00/
>
> This is a spec change to update the spec to match the long-standing implementation.

Have to wonder why reflection chose to ignore 'length' when the JLS is 
so clear that it is a field ??

Anyway ... I think the added wording to getField() is okay but:

1604      * follows.  Let C be the class or interface represented by 
this object:

I don't think it necessary, or desirable to replace 'class' with 'class 
or interface' here. If you do then you should do it everywhere - which 
would be bad. Plus does it really mean "class, or interface, or enum, or 
annotation" ? Sometimes "class" just means the thing a Class represents.

> There is also a clarification of getFields() javadoc without changing the
> spec.

I don't think this change make sense given it already says it returns a 
zero-length array for array classes - as Mandy pointed out. I don't 
think this "clarification" is needed.

David

> cheers
> /Joel
>


From mike.duigou at oracle.com  Tue Aug 27 03:52:31 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 26 Aug 2013 20:52:31 -0700
Subject: RFR(2nd): 8023275: Wrapping collections should override default
	methods
In-Reply-To: <52154AEF.3040507@oracle.com>
References: <52126F7B.60602@oracle.com>
	<03DB347B-7A9A-4150-8251-0C36FE317806@oracle.com>
	<52154AEF.3040507@oracle.com>
Message-ID: <7B132E84-9400-4C98-8CF9-89C1A7EC82BB@oracle.com>

Looks good. 

On Aug 21 2013, at 16:19 , Henry Jen wrote:

> On 08/20/2013 02:21 AM, Paul Sandoz wrote:
>> [resending unsigned, sorry if a dup arrives later on]
>> 
>> On Aug 19, 2013, at 9:18 PM, Henry Jen  wrote:
>> 
>>> Hi,
>>> 
>>> Please review the webrev at
>>> http://cr.openjdk.java.net/~henryjen/tl/8023275/0/webrev/
>>> 
>>> The patch adds override on default methods for a couple wrapping classed
>>> and delegate those to underlying class.
>>> 
>>> There is a minor revise on synchronizedCollection javadoc to cover Stream.
>>> 
>> 
>> Looks good.
>> 
>> 
>>> A sanity check on wrapper classes to ensure default methods are override.
>>> 
>> 
>> You might want to additionally use an ArrayList instance for unmodifiableList/synchronizedList/checkedList, so as to check both unmod list impls:
>> 
>>   public static  List unmodifiableList(List list) {
>>       return (list instanceof RandomAccess ?
>>               new UnmodifiableRandomAccessList<>(list) :
>>               new UnmodifiableList<>(list));
>>   }
>> 
> 
> Good point, I also added Navigable into the test.

Thank you for adding these.

Mike

> http://cr.openjdk.java.net/~henryjen/tl/8023275/2/webrev/
> 
> Cheers,
> Henry



From lana.steuck at oracle.com  Tue Aug 27 05:20:16 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 27 Aug 2013 05:20:16 +0000
Subject: hg: jdk8/tl/corba: 2 new changesets
Message-ID: <20130827052022.CF0A448BA2@hg.openjdk.java.net>

Changeset: d411c60a8c2f
Author:    cl
Date:      2013-08-15 09:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/d411c60a8c2f

Added tag jdk8-b103 for changeset 49c4a777fdfd

! .hgtags

Changeset: 4e38de7c767e
Author:    cl
Date:      2013-08-22 09:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/4e38de7c767e

Added tag jdk8-b104 for changeset d411c60a8c2f

! .hgtags



From lana.steuck at oracle.com  Tue Aug 27 05:20:26 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 27 Aug 2013 05:20:26 +0000
Subject: hg: jdk8/tl: 9 new changesets
Message-ID: <20130827052027.B374E48BA3@hg.openjdk.java.net>

Changeset: ceefd94ef326
Author:    cl
Date:      2013-08-15 09:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/ceefd94ef326

Added tag jdk8-b103 for changeset b7e64be81c8a

! .hgtags

Changeset: 4fb877dfe5c4
Author:    erikj
Date:      2013-08-15 17:14 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/4fb877dfe5c4

8020411: lin32 - JDK 8 build for Linux-i586 on Oracle Linux 6.4 64-bit machines does not generate the bundles directory in the build directory
Reviewed-by: tbell

! common/autoconf/generated-configure.sh
! common/autoconf/platform.m4
! common/autoconf/spec.gmk.in

Changeset: f10f673d9b17
Author:    igerasim
Date:      2013-08-16 14:43 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/f10f673d9b17

8023156: make dist-clean should remove javacservers directory
Reviewed-by: erikj

! common/makefiles/Main.gmk

Changeset: dadf49495ab4
Author:    erikj
Date:      2013-08-19 10:31 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/dadf49495ab4

8021430: 64 bit JDK build fails on windows 7 due to missing corba source files
Reviewed-by: tbell, katleman

! common/makefiles/IdlCompilation.gmk

Changeset: 96c1b9b7524b
Author:    katleman
Date:      2013-08-20 15:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/96c1b9b7524b

Merge


Changeset: c3b5197f2851
Author:    cl
Date:      2013-08-22 09:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/c3b5197f2851

Added tag jdk8-b104 for changeset 96c1b9b7524b

! .hgtags

Changeset: e8a3edda1f60
Author:    lana
Date:      2013-08-20 17:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/e8a3edda1f60

Merge


Changeset: 056398db9dcb
Author:    lana
Date:      2013-08-23 14:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/056398db9dcb

Merge

! common/autoconf/generated-configure.sh

Changeset: 163091288aeb
Author:    lana
Date:      2013-08-26 14:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/163091288aeb

Merge

! common/makefiles/Main.gmk



From lana.steuck at oracle.com  Tue Aug 27 05:20:31 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 27 Aug 2013 05:20:31 +0000
Subject: hg: jdk8/tl/jaxp: 4 new changesets
Message-ID: <20130827052056.027AB48BA4@hg.openjdk.java.net>

Changeset: a22fe9bd01e6
Author:    cl
Date:      2013-08-15 09:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a22fe9bd01e6

Added tag jdk8-b103 for changeset b1ceab582fc6

! .hgtags

Changeset: af28b93bfb6f
Author:    cl
Date:      2013-08-22 09:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/af28b93bfb6f

Added tag jdk8-b104 for changeset a22fe9bd01e6

! .hgtags

Changeset: d4d6422ec564
Author:    lana
Date:      2013-08-20 17:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d4d6422ec564

Merge


Changeset: 09a46ec11f88
Author:    lana
Date:      2013-08-23 14:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/09a46ec11f88

Merge




From lana.steuck at oracle.com  Tue Aug 27 05:20:35 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 27 Aug 2013 05:20:35 +0000
Subject: hg: jdk8/tl/jaxws: 3 new changesets
Message-ID: <20130827052056.7DA8C48BA5@hg.openjdk.java.net>

Changeset: 42211ab0ab1c
Author:    cl
Date:      2013-08-15 09:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/42211ab0ab1c

Added tag jdk8-b103 for changeset 6cdc6ed98780

! .hgtags

Changeset: 88390df7ed2c
Author:    cl
Date:      2013-08-22 09:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/88390df7ed2c

Added tag jdk8-b104 for changeset 42211ab0ab1c

! .hgtags

Changeset: 533c1032337c
Author:    lana
Date:      2013-08-26 14:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/533c1032337c

Merge




From lana.steuck at oracle.com  Tue Aug 27 05:20:46 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 27 Aug 2013 05:20:46 +0000
Subject: hg: jdk8/tl/nashorn: 5 new changesets
Message-ID: <20130827052057.0813148BA6@hg.openjdk.java.net>

Changeset: afc100513451
Author:    cl
Date:      2013-08-15 09:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/afc100513451

Added tag jdk8-b103 for changeset 414203de4374

! .hgtags

Changeset: 74244f43c577
Author:    cl
Date:      2013-08-22 09:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/74244f43c577

Added tag jdk8-b104 for changeset afc100513451

! .hgtags

Changeset: 1f2394beecf7
Author:    lana
Date:      2013-08-20 17:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1f2394beecf7

Merge

- src/jdk/internal/dynalink/support/Backport.java
- src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/MapIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java

Changeset: f484bfb624dd
Author:    lana
Date:      2013-08-23 14:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f484bfb624dd

Merge

- src/jdk/internal/dynalink/support/Backport.java
- src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/MapIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java

Changeset: a18f92a0a910
Author:    lana
Date:      2013-08-26 14:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a18f92a0a910

Merge




From lana.steuck at oracle.com  Tue Aug 27 05:20:47 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 27 Aug 2013 05:20:47 +0000
Subject: hg: jdk8/tl/langtools: 6 new changesets
Message-ID: <20130827052114.E6B9448BA7@hg.openjdk.java.net>

Changeset: dd4a00c220c6
Author:    cl
Date:      2013-08-15 09:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dd4a00c220c6

Added tag jdk8-b103 for changeset 76cfe7c61f25

! .hgtags

Changeset: f2ee3a4e7927
Author:    cl
Date:      2013-08-22 09:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f2ee3a4e7927

Added tag jdk8-b104 for changeset dd4a00c220c6

! .hgtags

Changeset: b59a0b4675c9
Author:    lana
Date:      2013-08-20 17:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b59a0b4675c9

Merge

- test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java
- test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java

Changeset: 375834b5cf08
Author:    lana
Date:      2013-08-23 14:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/375834b5cf08

Merge

- test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java
- test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java

Changeset: 00ca54ceca1b
Author:    lana
Date:      2013-08-26 14:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/00ca54ceca1b

Merge


Changeset: cc3fb73f5e08
Author:    lana
Date:      2013-08-26 22:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cc3fb73f5e08

Merge




From lana.steuck at oracle.com  Tue Aug 27 05:20:56 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 27 Aug 2013 05:20:56 +0000
Subject: hg: jdk8/tl/hotspot: 32 new changesets
Message-ID: <20130827052233.5940E48BA8@hg.openjdk.java.net>

Changeset: 0bbd1c775bef
Author:    cl
Date:      2013-08-15 09:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0bbd1c775bef

Added tag jdk8-b103 for changeset 6f9be7f87b96

! .hgtags

Changeset: 39127bb12d32
Author:    amurillo
Date:      2013-08-09 01:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/39127bb12d32

8022688: new hotspot build - hs25-b46
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: ca0165daa6ec
Author:    sspitsyn
Date:      2013-08-06 16:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca0165daa6ec

7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments
Summary: Restore the appendix argument after PopFrame() call
Reviewed-by: twisti, coleenp
Contributed-by: serguei.spitsyn at oracle.com

! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/interpreterRuntime.hpp

Changeset: c54a3122f9c8
Author:    omajid
Date:      2013-08-06 12:28 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c54a3122f9c8

8022188: Make zero compile after 8016131 and 8016697
Reviewed-by: dholmes, twisti

! src/cpu/zero/vm/entryFrame_zero.hpp
! src/cpu/zero/vm/frame_zero.inline.hpp
! src/cpu/zero/vm/stubGenerator_zero.cpp
! src/os_cpu/linux_zero/vm/os_linux_zero.cpp

Changeset: 196aa14f9f29
Author:    dholmes
Date:      2013-08-06 21:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/196aa14f9f29

Merge


Changeset: 195ff07bc7f6
Author:    dsamersoff
Date:      2013-08-07 19:02 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/195ff07bc7f6

8021771: warning stat64 is deprecated - when building on OSX 10.7.5
Summary: stat64 have to be replaced with stat
Reviewed-by: dholmes, kmo
Contributed-by: rednaxelafx at gmail.com

! src/os/bsd/vm/attachListener_bsd.cpp

Changeset: 31f3b1e1c5e5
Author:    dcubed
Date:      2013-08-08 09:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/31f3b1e1c5e5

8016601: Unable to build hsx24 on Windows using project creator and Visual Studio
Summary: ProjectCreator tool is modified to support two new options: '-relativeAltSrcInclude' and '-altRelativeInclude' which prevents IDE linker errors. Also fixed some cmd line build linker warnings. Misc cleanups.
Reviewed-by: rdurbin, coleenp

! make/windows/create.bat
! make/windows/create_obj_files.sh
! make/windows/makefiles/projectcreator.make
! make/windows/makefiles/trace.make
! make/windows/makefiles/vm.make
! src/share/tools/ProjectCreator/BuildConfig.java
! src/share/tools/ProjectCreator/FileTreeCreatorVC10.java
! src/share/tools/ProjectCreator/ProjectCreator.java
! src/share/tools/ProjectCreator/WinGammaPlatform.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java

Changeset: c661fa2e5189
Author:    iklam
Date:      2013-08-08 14:45 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c661fa2e5189

8022093: syntax error near "umpiconninfo_t" -- when building on Solaris 10
Summary: Added extra help message in make/solaris/makefiles/dtrace.make
Reviewed-by: dholmes, sspitsyn

! make/solaris/makefiles/dtrace.make

Changeset: 57ac7245594c
Author:    minqi
Date:      2013-08-08 15:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/57ac7245594c

8019583: [TESTBUG] runtime/7107135 always passes
Summary: If java test return none zero, the value will be override by 'if' statement, the exit value will always '0' and pass. Fix by recording the result in a variable.
Reviewed-by: coleenp, dholmes, iklam
Contributed-by: yumin.qi at oracle.com

! test/runtime/7107135/Test7107135.sh

Changeset: 6222a021d582
Author:    minqi
Date:      2013-08-08 20:13 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6222a021d582

Merge


Changeset: 98aa538fd97e
Author:    mikael
Date:      2013-08-09 09:51 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/98aa538fd97e

8022452: Hotspot needs to know about Windows 8.1 and Windows Server 2012 R2
Summary: Add support for recognizing Windows 8.1 and Server 2012 R2 and minor cleanup
Reviewed-by: coleenp, dsamersoff

! src/os/windows/vm/os_windows.cpp

Changeset: ed7c17e7d45b
Author:    dcubed
Date:      2013-08-09 13:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ed7c17e7d45b

Merge


Changeset: 7b03590c334b
Author:    dcubed
Date:      2013-08-09 15:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7b03590c334b

Merge


Changeset: bd0e82136b03
Author:    iklam
Date:      2013-08-10 10:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bd0e82136b03

8022740: Visual 2008 IDE build is broken
Summary: Fixed project generation code, and added warning to upgrade to VS 2008 SP1.
Reviewed-by: dcubed, ccheung

! make/windows/projectfiles/common/Makefile
! src/share/tools/ProjectCreator/FileTreeCreator.java
! src/share/tools/ProjectCreator/FileTreeCreatorVC10.java
! src/share/tools/ProjectCreator/FileTreeCreatorVC7.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java

Changeset: 85147f28faba
Author:    coleenp
Date:      2013-08-12 17:24 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/85147f28faba

8009728: nsk/jvmti/AttachOnDemand/attach030 crashes on Win32
Summary: ActiveMethodOopsCache was used to keep track of old versions of some methods that are cached in Universe but is buggy with permgen removal and not needed anymore
Reviewed-by: sspitsyn, dcubed, mseledtsov

! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! test/runtime/RedefineObject/Agent.java
! test/runtime/RedefineObject/TestRedefineObject.java
+ test/runtime/RedefineObject/WalkThroughInvoke.java

Changeset: d1034bd8cefc
Author:    adlertz
Date:      2013-08-07 17:56 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d1034bd8cefc

8022284: Hide internal data structure in PhaseCFG
Summary: Hide private node to block mapping using public interface
Reviewed-by: kvn, roland

! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/buildOopMap.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/domgraph.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/opto/ifg.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/output.hpp
! src/share/vm/opto/postaloc.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: ce8969c36762
Author:    adlertz
Date:      2013-08-07 18:04 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ce8969c36762

8022475: Remove unneeded ad-files
Summary: Remove .ad files that are not used
Reviewed-by: kvn

! make/bsd/makefiles/adlc.make
! make/linux/makefiles/adlc.make
! make/solaris/makefiles/adlc.make
! make/windows/makefiles/adlc.make
- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad

Changeset: 5394ec69f112
Author:    rbackman
Date:      2013-08-09 18:05 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5394ec69f112

Merge

- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad

Changeset: 11237ee74aae
Author:    iignatyev
Date:      2013-08-10 10:01 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/11237ee74aae

8019915: whitebox testClearMethodStateTest fails with tiered on sparc
Summary: 'compileonly' directive has beens added to each 'compiler/whitebox' test
Reviewed-by: kvn

! test/compiler/whitebox/ClearMethodStateTest.java
! test/compiler/whitebox/CompilerWhiteBoxTest.java
! test/compiler/whitebox/DeoptimizeAllTest.java
! test/compiler/whitebox/DeoptimizeMethodTest.java
! test/compiler/whitebox/EnqueueMethodForCompilationTest.java
! test/compiler/whitebox/IsMethodCompilableTest.java
! test/compiler/whitebox/MakeMethodNotCompilableTest.java
! test/compiler/whitebox/SetDontInlineMethodTest.java
! test/compiler/whitebox/SetForceInlineMethodTest.java

Changeset: bcc4f6f54d83
Author:    kvn
Date:      2013-08-14 10:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bcc4f6f54d83

8022993: Convert MAX_UNROLL constant to LoopMaxUnroll C2 flag
Summary: Replace MAX_UNROLL constant with new C2 LoopMaxUnroll flag.
Reviewed-by: roland

! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/loopTransform.cpp

Changeset: 56b94e55267a
Author:    rbackman
Date:      2013-08-15 15:26 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/56b94e55267a

Merge

- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad

Changeset: 9766f73e770d
Author:    stefank
Date:      2013-05-31 14:32 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9766f73e770d

8022880: False sharing between PSPromotionManager instances
Summary: Pad the PSPromotionManager instances in the manager array.
Reviewed-by: brutisso, jmasa

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp
! src/share/vm/gc_implementation/parNew/parOopClosures.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp
+ src/share/vm/memory/padded.hpp
+ src/share/vm/memory/padded.inline.hpp
! src/share/vm/utilities/debug.hpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 330dfb0476f4
Author:    brutisso
Date:      2013-08-14 09:02 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/330dfb0476f4

8022800: Use specific generations rather than generation iteration
Reviewed-by: jmasa, ehelin

! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/memory/cardTableRS.hpp
! src/share/vm/memory/defNewGeneration.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/memory/genMarkSweep.cpp
! src/share/vm/memory/genRemSet.hpp

Changeset: 3f22cbf5275d
Author:    brutisso
Date:      2013-08-14 10:55 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3f22cbf5275d

Merge


Changeset: 5d9995d16b26
Author:    ehelin
Date:      2013-08-14 13:49 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5d9995d16b26

8022899: SunStudio compiler can not handle EXCEPTION_MARK and inlining
Reviewed-by: coleenp, mgerdin

! src/share/vm/utilities/exceptions.hpp

Changeset: bd902affe102
Author:    brutisso
Date:      2013-08-15 10:05 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bd902affe102

8023021: Unnecessary clearing of the card table introduced by the fix for JDK-8023013
Reviewed-by: stefank, ehelin

! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/memory/cardTableRS.hpp
! src/share/vm/memory/genMarkSweep.cpp
! src/share/vm/memory/genRemSet.hpp

Changeset: 274ce305e5b9
Author:    ehelin
Date:      2013-08-13 18:16 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/274ce305e5b9

8020598: ObjectCountEventSender::send needs INCLUDE_TRACE guards when building OpenJDK with INCLUDE_TRACE=0
Reviewed-by: stefank, brutisso, sjohanss

! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp

Changeset: 33d39b75663f
Author:    ehelin
Date:      2013-08-15 06:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/33d39b75663f

Merge


Changeset: 5a62937e55b3
Author:    brutisso
Date:      2013-08-16 09:02 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5a62937e55b3

Merge

- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad

Changeset: 580430d131cc
Author:    amurillo
Date:      2013-08-16 04:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/580430d131cc

Merge

- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad

Changeset: 104743074675
Author:    amurillo
Date:      2013-08-16 04:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/104743074675

Added tag hs25-b46 for changeset 580430d131cc

! .hgtags

Changeset: c93e0a210e1b
Author:    cl
Date:      2013-08-22 09:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c93e0a210e1b

Added tag jdk8-b104 for changeset 104743074675

! .hgtags



From lana.steuck at oracle.com  Tue Aug 27 05:22:10 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 27 Aug 2013 05:22:10 +0000
Subject: hg: jdk8/tl/jdk: 23 new changesets
Message-ID: <20130827052721.2B1BC48BA9@hg.openjdk.java.net>

Changeset: f1d8d15bfcb5
Author:    cl
Date:      2013-08-15 09:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1d8d15bfcb5

Added tag jdk8-b103 for changeset e0f6039c0290

! .hgtags

Changeset: c982f579b67e
Author:    cl
Date:      2013-08-22 09:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c982f579b67e

Added tag jdk8-b104 for changeset f1d8d15bfcb5

! .hgtags

Changeset: 2722f4000b65
Author:    jgodinez
Date:      2013-08-15 11:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2722f4000b65

8023045: [MacOSX] PrinterIOException when printing a JComponent
Reviewed-by: bae, jchen

! src/share/classes/sun/print/PSPrinterJob.java

Changeset: b44ce67c0565
Author:    vadim
Date:      2013-08-16 15:57 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b44ce67c0565

8013446: [parfait] Memory leak in jdk/src/windows/native/sun/java2d/opengl/WGLSurfaceData.c
Reviewed-by: bae, prr

! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c

Changeset: dadd43e02a79
Author:    prr
Date:      2013-08-19 03:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dadd43e02a79

8017580: Crash in font loading code on Linux (due to use of reflection)
Reviewed-by: bae, vadim

! src/share/native/sun/font/sunFont.c
! src/share/native/sun/font/sunfontids.h

Changeset: 0c950b2be7ab
Author:    jgodinez
Date:      2013-08-19 11:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c950b2be7ab

8022241: [macosx] [PIT] lookupPrintServices() returns one too long array
Reviewed-by: prr, jchen

! src/solaris/classes/sun/print/UnixPrintServiceLookup.java

Changeset: 64be71ae6185
Author:    lana
Date:      2013-08-20 17:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64be71ae6185

Merge


Changeset: 903a279f1fce
Author:    ant
Date:      2013-08-09 05:20 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/903a279f1fce

8013611: Modal dialog fails to obtain keyboard focus
Reviewed-by: leonidr

! src/share/classes/java/awt/KeyboardFocusManager.java
+ test/java/awt/Focus/8013611/JDK8013611.java

Changeset: 2cd1a041381b
Author:    alexsch
Date:      2013-08-09 14:16 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2cd1a041381b

7121409: Two conformance tests for AccessibleText.getCharacterBounds(int i) fail
Reviewed-by: serb

! src/share/classes/javax/swing/JLabel.java

Changeset: 4702ab74b70a
Author:    serb
Date:      2013-08-13 15:41 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4702ab74b70a

7027045: (doc) java/awt/Window.java has several typos in javadoc
Reviewed-by: art, serb
Contributed-by: konstantin.perikov at gmail.com

! src/share/classes/java/awt/Window.java

Changeset: 149bf2400fa1
Author:    lana
Date:      2013-08-13 15:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/149bf2400fa1

Merge

- test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java
- test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh

Changeset: c5db3ec83cba
Author:    pchelko
Date:      2013-08-14 16:17 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c5db3ec83cba

8013454: [parfait] Memory leak in jdk/src/windows/native/sun/windows/awt_Cursor.cpp
8012079: [parfait] possible null pointer dereference in jdk/src/windows/native/sun/windows/awt_Font.cpp
Reviewed-by: art, serb

! src/windows/native/sun/windows/awt_Cursor.cpp
! src/windows/native/sun/windows/awt_Font.cpp

Changeset: 1d6ce0070fd3
Author:    pchelko
Date:      2013-08-14 17:20 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d6ce0070fd3

7173464: Clipboard.getAvailableDataFlavors: Comparison method violates contract
Reviewed-by: anthony, art, serb

! src/share/classes/sun/awt/datatransfer/ClipboardTransferable.java
! src/share/classes/sun/awt/datatransfer/DataTransferer.java
+ test/sun/awt/datatransfer/DataFlavorComparatorTest.java

Changeset: 3930a827160a
Author:    leonidr
Date:      2013-08-15 01:17 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3930a827160a

8022997: [macosx] Remaining duplicated key events
Reviewed-by: anthony, serb

! src/macosx/native/sun/awt/CMenuItem.m
! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java

Changeset: d7a34d7e7f22
Author:    alitvinov
Date:      2013-08-15 14:20 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d7a34d7e7f22

7191018: Manual test closed/java/awt/JAWT causes JVM to crash starting from JDK 5
Reviewed-by: anthony, serb

! src/solaris/native/sun/awt/awt_DrawingSurface.c

Changeset: c089e93e6444
Author:    serb
Date:      2013-08-16 16:52 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c089e93e6444

8020051: [TEST_BUG] Testcase for 8004859 has a typo
Reviewed-by: anthony

! test/java/awt/Graphics2D/Test8004859/Test8004859.java

Changeset: e3316cd6ca47
Author:    serb
Date:      2013-08-16 20:56 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e3316cd6ca47

8006085: [findbugs] a warning on javax.sound.sampled.DataLine$Info constructor
Reviewed-by: art, prr

! src/share/classes/javax/sound/sampled/DataLine.java

Changeset: 64dc24e0d577
Author:    serb
Date:      2013-08-16 21:18 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64dc24e0d577

8005980: [findbugs] More com.sun.media.sound.* warnings
Reviewed-by: art, prr

! src/share/classes/com/sun/media/sound/DataPusher.java
! src/share/classes/com/sun/media/sound/ModelStandardDirector.java
! src/share/classes/com/sun/media/sound/ModelStandardIndexedDirector.java
! src/share/classes/com/sun/media/sound/SoftMixingClip.java
! src/share/classes/sun/audio/AudioData.java

Changeset: fefa29e15a14
Author:    lana
Date:      2013-08-20 17:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fefa29e15a14

Merge


Changeset: a79fcf53195f
Author:    lana
Date:      2013-08-20 17:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a79fcf53195f

Merge

- src/share/classes/com/sun/security/auth/PolicyParser.java
- src/share/classes/com/sun/security/auth/SubjectCodeSource.java
- src/share/classes/java/util/jar/UnsupportedProfileException.java
- src/share/classes/sun/security/provider/ConfigSpiFile.java
- test/java/net/URLClassLoader/profiles/Basic.java
- test/java/net/URLClassLoader/profiles/Lib.java
- test/java/net/URLClassLoader/profiles/basic.sh
- test/tools/jar/AddAndUpdateProfile.java
- test/tools/launcher/profiles/Basic.java
- test/tools/launcher/profiles/Logging.java
- test/tools/launcher/profiles/Main.java
- test/tools/launcher/profiles/VersionCheck.java

Changeset: 9626ba160e3d
Author:    lana
Date:      2013-08-23 14:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9626ba160e3d

Merge

- src/share/classes/com/sun/security/auth/PolicyParser.java
- src/share/classes/com/sun/security/auth/SubjectCodeSource.java
- src/share/classes/java/util/jar/UnsupportedProfileException.java
- src/share/classes/sun/security/provider/ConfigSpiFile.java
- test/java/net/URLClassLoader/profiles/Basic.java
- test/java/net/URLClassLoader/profiles/Lib.java
- test/java/net/URLClassLoader/profiles/basic.sh
- test/tools/jar/AddAndUpdateProfile.java
- test/tools/launcher/profiles/Basic.java
- test/tools/launcher/profiles/Logging.java
- test/tools/launcher/profiles/Main.java
- test/tools/launcher/profiles/VersionCheck.java

Changeset: c58e39bb5d62
Author:    lana
Date:      2013-08-26 14:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c58e39bb5d62

Merge


Changeset: 6cdc679e3412
Author:    lana
Date:      2013-08-26 22:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6cdc679e3412

Merge




From peter.levart at gmail.com  Tue Aug 27 06:54:31 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 27 Aug 2013 08:54:31 +0200
Subject: 8020292: j.u.SplittableRandom
In-Reply-To: <9F153157-0FC5-4385-B1BC-4FE2D43006F4@oracle.com>
References: <9F153157-0FC5-4385-B1BC-4FE2D43006F4@oracle.com>
Message-ID: <521C4D27.7010509@gmail.com>

Hi,

The system property name "java.util.secureRandomSeed" suggests that it 
is not for SplittableRandom only. Now that ThreadLocalRandom is 
algorithmically aligned with SplittableRandom, should initial seed for 
TLR instances also use the same algorithm?

Regards, Peter

On 08/19/2013 01:06 PM, Paul Sandoz wrote:
> Hi,
>
> This is the patch for SplittableRandom:
>
>    http://cr.openjdk.java.net/~psandoz/tl/JDK-8020292-SplittableRandom/webrev/
>
> The algorithm remains the same as reported by Doug on the 9th August:
>
>    http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019768.html
>
> Paul.



From masayoshi.okutsu at oracle.com  Tue Aug 27 07:00:42 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 27 Aug 2013 16:00:42 +0900
Subject:  Additional source to guess the local timezone ID on
	linux
In-Reply-To: <521B1482.104@oracle.com>
References: <5217CF92.9030307@redhat.com> <521B1482.104@oracle.com>
Message-ID: <521C4E9A.3050902@oracle.com>

Hi Omair,

/etc/sysconfig/clock used to be supported, but it was removed in JDK 7. 
The problem is discussed in bug #6456628.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6456628

Have you tested your fix on all Red Hat-like distros, including some 
older releases, with all the time zone IDs?

Thanks,
Masayoshi

On 8/26/2013 5:40 PM, Alan Bateman wrote:
>
> Including i18n-dev on this discussion because that is where this code 
> is maintained.
>
>
> On 23/08/2013 22:09, Omair Majid wrote:
>> Hi,
>>
>> The algorithm that OpenJDK uses to guess the local timezone ID on Linux
>> goes like this:
>>
>> 1. If TZ environment variable is set, use that
>> 2. If /etc/timezone is readable, read the time zone from there
>> 3. If /etc/localtime is a symlink, resolve that, and use the name to
>> guess the time zone.
>> 4. Scan /usr/share/zoneinfo for a file whose contents match the contents
>> of /etc/localtime.
>>
>> Step 4 (if it is ever reached) is probably going to lead to incorrect
>> results since there are a number of timezones that have the same
>> zoneinfo data (such as Europe/London and Europe/Belfast). So it seems
>> sensible to me to try and use additional sources to guess the timezone
>> ID before resorting to file content comparisons.
>>
>> The webrev adds a step between 2 and 3 that reads and parses
>> /etc/sysconfig/clock to extract the timezone:
>>
>> http://cr.openjdk.java.net/~omajid/webrevs/timezone-read-sysconfig-clock/00/ 
>>
>>
>> This file exists on some Red Hat Enterprise Linux (and derivative)
>> distributions and contains contents that look this:
>>
>>> # The time zone of the system is defined by the contents of 
>>> /etc/localtime.
>>> # This file is only for evaluation by system-config-date, do not 
>>> rely on its
>>> # contents elsewhere.
>>> ZONE="Europe/Zurich"
>> With this, we should be able to identify the exact timezone ID.
>>
>> Thanks,
>> Omair
>



From Alan.Bateman at oracle.com  Tue Aug 27 07:02:32 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 27 Aug 2013 08:02:32 +0100
Subject: RFR:  JDK-8023647, , " abc1c " .matches( " (\\w)+1\\1 " )) returns
	false
In-Reply-To: <521BC09D.2060800@oracle.com>
References: <521BC09D.2060800@oracle.com>
Message-ID: <521C4F08.4010704@oracle.com>

On 26/08/2013 21:54, Xueming Shen wrote:
> Hi,
>
> Please help review the proposed change for 8023647:
>
> http://cr.openjdk.java.net/~sherman/8023647/webrev
>
> It appears group index updating in situation of GroupCurly backing off
> is incorrect from day one (the bug is reproducible back to jdk5). The
> current implementation does not back off the index to a previous match,
> but the one is being back off.
>
> The ln#4459 is updating a local variable before return, which is not
> necessary, I removed it with this change.
This looks okay to me, I just wonder if there we need other tests here 
to be confident that there aren't other issues.

-Alan


From Alan.Bateman at oracle.com  Tue Aug 27 07:12:51 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 27 Aug 2013 08:12:51 +0100
Subject: RFR: JDK-8023765 -- Improve MaxPathLength.java testcase and reduce
	its test load
In-Reply-To: <521BF05A.1090805@oracle.com>
References: <521BF05A.1090805@oracle.com>
Message-ID: <521C5173.4070701@oracle.com>

On 27/08/2013 01:18, Dan Xu wrote:
> Hi All,
>
> MaxPathLength.javais a troublesome testcase, and fails intermittently 
> in the nightly test. And it also runs for a long time, especially on 
> Windows platforms. Inorder to improve the test stability, I remove its 
> unnecessary test iterations, and use NIOdelete method todo the 
> clean-up to make the potential failureseasier for diagnosis. Please 
> review thechanges. Thanks!
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8023765
> webrev: http://cr.openjdk.java.net/~dxu/8023765/webrev/
>
> -Dan
The double to quickly skip over the names to MAX_LENGTH/2 looks reasonable.

I guess fileCreated should really be fileExists as it may be deleted and 
then deleted. An alternative here would be to use Files.deleteIfExists 
as that would avoid the need to introduce flags to track whether the 
directory and exist exists.

-Alan


From paul.sandoz at oracle.com  Tue Aug 27 08:19:37 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 27 Aug 2013 10:19:37 +0200
Subject: 8020292: j.u.SplittableRandom
In-Reply-To: <521C4D27.7010509@gmail.com>
References: <9F153157-0FC5-4385-B1BC-4FE2D43006F4@oracle.com>
	<521C4D27.7010509@gmail.com>
Message-ID: <4F0AA1D2-EB2A-4724-9B3F-AB1F12E23498@oracle.com>


On Aug 27, 2013, at 8:54 AM, Peter Levart  wrote:

> Hi,
> 
> The system property name "java.util.secureRandomSeed" suggests that it is not for SplittableRandom only. Now that ThreadLocalRandom is algorithmically aligned with SplittableRandom, should initial seed for TLR instances also use the same algorithm?
> 

Well spotted, yes that was the intention. 

We did sync this with TLR but ran into an issue due to it's current use in WeakHashMap and Hashtable e.g. in WeakHashMap:

    final void initHashSeed() {
        if (sun.misc.VM.isBooted() && Holder.USE_HASHSEED) {
            // Do not set hashSeed more than once!
            // assert hashSeed == 0;
            int seed = ThreadLocalRandom.current().nextInt();
            hashSeed = (seed != 0) ? seed : 1;
        }
    }

The first call to TLR.current() will initialize the TLR class and uses InetAddress or SecureRandom, which in turn results in use of WeakHashMap and the second call to TLR.current() that throws a NPE that causes an java.lang.ExceptionInInitializerError.

My understanding is the hash seed functionality will be removed and when done we can add such functionality back to TLR.

It would be good to remove this functionality soonish so we can get this feature in.

Paul.

From weijun.wang at oracle.com  Tue Aug 27 09:51:22 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Tue, 27 Aug 2013 09:51:22 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130827095225.1083C48BB4@hg.openjdk.java.net>

Changeset: ca53110f1c74
Author:    weijun
Date:      2013-08-27 17:50 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca53110f1c74

8015669: KerberosPrincipal::equals should ignore name-type
Reviewed-by: mullan

! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java
+ test/sun/security/krb5/auto/KPEquals.java

Changeset: 4bddc344848e
Author:    weijun
Date:      2013-08-27 17:50 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bddc344848e

8022761: regression: SecurityException is NOT thrown while trying to pack a wrongly signed Indexed Jar file
Reviewed-by: sherman

! src/share/classes/java/util/jar/JarVerifier.java
+ test/sun/security/tools/jarsigner/jvindex.sh



From paul.sandoz at oracle.com  Tue Aug 27 10:00:12 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 27 Aug 2013 12:00:12 +0200
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets
	or trees (red/black)
In-Reply-To: <521BC4F8.2060001@univ-mlv.fr>
References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
	<521A473A.6000807@univ-mlv.fr>
	<83208874-EB5A-4CD8-A78D-39A599FB3FF8@oracle.com>
	<521BC4F8.2060001@univ-mlv.fr>
Message-ID: <4A4245E1-4153-45BF-8658-DB6822BD31D2@oracle.com>


On Aug 26, 2013, at 11:13 PM, Remi Forax  wrote:

> On 08/26/2013 10:10 PM, Paul Sandoz wrote:
>> On Aug 25, 2013, at 8:04 PM, Remi Forax  wrote:
>> 
>>> On 08/21/2013 02:25 PM, Paul Sandoz wrote:
>>>> Hi,
>>>> 
>>>> Here are Doug's Linked/HashMap changes, discussed in a previous thread, as a webrev:
>>>> 
>>>>   http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/
>>>> 
>>>> I also added some tests related to characteristics associated with fixing another bug.
>>>> 
>>>> Looking at the diffs will be tricky given there are so many changes.
>>> 
>>> The code can be simplified a little bit by using the diamond syntax,
>>> HashMap (lines: 919, 963, 1026, 1497, 1569) and
>>> LinkedHashMap (lines: 255, 264, 270, 278)
>>> 
>>> There are a bunch of @Override that are missing making the code harder than it should to read.
>>> 
>> Yes, i think this is because it sticks to the 166 style i suspect. Easy to change.
>> 

Note that j.u. classes are quite inconsistent in this respect to using diamonds and @Overrides. My preference is to do a sweeping change to all such code. I wonder if an IDE can automate that?

 
>>> In putVal, line 654, the null check (e != null) makes the method hard to read,
>>> at least I think a comment saying that it means that an existing node need to be altered is needed.
>>> 
>> e.g.:
>> 
>>             if (e != null) { // existing mapping for key
> 
> Yes, perfect.
> 
>> 
>> 
>>> And I still don't like the way the method clone() is implemented (the older implementation has the same issue),
>>> result should not be initialized to null and the catch clause should thow an InternalError or an AssertionError,
>>> 
>> You mean like this:
>> 
>>     public Object clone() {
>>         HashMap result = null;
>>         try {
>>             result = (HashMap)super.clone();
>>         } catch (CloneNotSupportedException e) {
>>             // this shouldn't happen, since we are Cloneable
>>             throw new InternalError(e);
>>         }
>>         result.reinitialize();
>>         result.putMapEntries(this, false);
>>         return result;
>>     }
> 
> Yes, and in that case, you don't need to initialize result to null (the first line), because when result is used
> (result.reinitialize()) result is already initialized by the return value of super.clone().
> 

Thanks.

Here is the latest patch that also includes updates for the above 2 comments and Mike's comments:

  http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/

Paul.

From Thomas.Salter at unisys.com  Tue Aug 27 12:07:20 2013
From: Thomas.Salter at unisys.com (Salter, Thomas A)
Date: Tue, 27 Aug 2013 07:07:20 -0500
Subject: core-libs-dev Digest, Vol 76, Issue 112
In-Reply-To: 
References: 
Message-ID: <63D5DCACD1E9E34C89C8203C64F521C30148F7F12A9A@USEA-EXCH7.na.uis.unisys.com>

I vote for pedantry, though not necessarily for every NPE.

I've had to port the JDK to a non-standard operating system.  The docs are frequently inadequate to answer detailed coding questions, so I end up reading code to figure out what is supposed to happen.  Even then, we sometimes don't sort things out until we run the conformance tests.

The root cause, of course, is that the same spec serves as both user documentation and implementation specification.  It's inevitable that there will be too much information for users and too little for implementers.

Tom Salter

------------------------------

Message: 3
Date: Mon, 26 Aug 2013 20:16:00 -0700
From: Mike Duigou 
Subject: Re: RFR: 8021591 : (s) Additional explicit null checks
To: "core-libs-dev at openjdk.java.net Libs"
	
Message-ID: 
Content-Type: text/plain; charset=iso-8859-1


On Aug 26 2013, at 18:37 , Mike Duigou wrote:

> 
> On Aug 19 2013, at 15:35 , Martin Buchholz wrote:
> 
>> My feeling is that the JDK specs have been creeping in the direction of excessive pedantry and doc lawyerism.  I think it's overall a benefit of Java that its documentation is more readable (at the cost of being a little less precise) than the typical ISO spec.
> 
> There is a definite tension here. We would like to keep the documentation and specification as readable as possible while still being sufficiently exacting so that behaviour of an API can be correctly predicted by a reader. It goes further than that though because Oracle employs an entire group of engineers who examine the JDK API javadocs looking for normative statements and then write tests to confirm that implementations conform to the API documentation/specification.  The number and quality of tests they provide to ensure conformance has been steadily increasing (and accelerating). Is this a good thing? To me it seems so. When I hear that people encounter problems (other than performance) when switching among Vector<->ArrayList<->LinkedList<->CopyOnWriteArrayList or HashMap<->ConcurrentHashMap or TreeSet<->ConcurrentSkipListSet because of arbitrary corner case differences between implementations I become smy

Sorry, replying to my own message to finish an incomplete sentence.

...sympathetic to concerns that the JDK docs/specs are not specific enough.

Mike



From peter.levart at gmail.com  Tue Aug 27 13:00:32 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 27 Aug 2013 15:00:32 +0200
Subject: RFR JDK-8011940 : java.lang.Class.getAnnotations() always enters
	synchronized method
In-Reply-To: <5253559F-B078-4ABF-9D5C-3BA2879669BB@oracle.com>
References: <5202733D.60205@gmail.com> <520278DF.2060102@oracle.com>
	<520777E5.3050304@gmail.com>
	<20130812105439.GC6420@jfranck-desktop.jrpg.bea.com>
	<5208D7A7.9070608@gmail.com>
	<5253559F-B078-4ABF-9D5C-3BA2879669BB@oracle.com>
Message-ID: <521CA2F0.1020701@gmail.com>

Hi Joel and others,

Here's a 3rd revision of this proposed patch:

http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationData/webrev.03/

I used LinkedHashMap for annotations in this one. It means that now even 
.getAnnotations() are reported in "declaration order": 1st inherited 
(includes overridden) then declared (that are not overriding). For 
example, using @Inherited annotations A1, A2, A3:

@A1("C")
@A2("C")
class C {}

@A1("D")
@A3("D")
class D extends C {}

D.class.getAnnotations() now returns: { @A1("D"), @A2("C"), @A3("D") } ...

The LHM constructor uses the following expression to estimate the 
initial capacity of the LHM:

3326                         annotations = new LinkedHashMap<>((Math.max(
3327                                 declaredAnnotations.size(),
3328                                 Math.min(12, declaredAnnotations.size() + superAnnotations.size())
3329                             ) * 4 + 2) / 3
3330                         );


I think this strikes some balance between effectivity and accuracy of 
estimation. I could pre-scan the superclass annotations and calculate 
the exact final size of the annotations Map before constructing it 
though. Tell me if this is worth the effort.

I also created a test that tests 3 things:
- class annotation inheritance
- order of class annotations reported by .getAnnotations() and 
.getDeclaredAnnotations() methods (although not specified, the order is 
now stable and resembles declaration order)
- behaviour of class annotation caching when class is redefined


Regards, Peter

On 08/13/2013 09:52 AM, Joel Borggr?n-Franck wrote:
> Hi,
>
> Comments inline,
>
> On 12 aug 2013, at 14:40, Peter Levart  wrote:
>> On 08/12/2013 12:54 PM, Joel Borggren-Franck wrote:
>> - annotation (@interface)  declarations can themselves be redefined (for example, defaults changed). Such redefinitions don't affect already initialized annotations. Default values are cached in AnnotationType which is not invalidated as a result of class redefinition. Maybe it should be. And even if AnnotationType was invalidated as a result of class redefinition, the defaults are looked-up when particular annotations are initialized and then combined with parsed values in a single values map inside each annotation instance (proxy), so invalidating AnnotationType would have no effect on those annotations.
>>
>>> 3326                 if (annotations == null) { // lazy construction
>>> 3327                     annotations = new HashMap<>();
>>> 3328                 }
>>>
>>> I think this should be a LinkedHashMap, so that iteration is predictable
>>> (I know it isn't in the current code). Also the size of the map is known
>>> so you can use a constructor with an explicit initial capacity.
>> Right, AnnotationParser does return LinkedHashMap, so at least decalredAnnotations are in parse-order. I will change the code to use LinkedHashMap for inherited/combined case too.
> Thanks.
>
>> The number of annotations that end-up in inherited/combined Map is not known in advance. I could make a separate pre-scan for superclass annotations that are @Inheritable and don't have the same key as any of declared annotations and then sum this count with declared annotations count, but I don't think this will be very effective. I could allocate a large-enough Map to always fit (the count of superclass annotations + the count of declared annotations), but that could sometimes lead to much over-allocated Maps. I could take the min(DEFAULT_CAPACITY, superclass annotations count + declared annotations count) as the initial capacity for the Map. What do you think which of those 3 alternatives is the best?
> My bad. I was thinking of the case where every inherited annotation was overridden, in that case annotations.size() == declaredAnnotations.size(). That is of course not generally true. I'm fine with handling this as a follow up since the situation is no worse than today and the surrounding code is better. However,
>
> 1) We should really measure this.
> 2) My gut feeling is that the ratio of not overridden inherited annotations to declared annotations is small IE the expected nr of annotations is much closer to declare annotations than to declared + superclass annotations.
> 3) The default initial capacity is 16 and load factor is 0.75. I do think the mean nr of annotations is closer to 3 than to 12. We are probably wasting some space here.
>
> Perhaps use min(default cap, (total annotations/0.75 (+ 1?))) for now as that will make the situation no worse than today and often better?
>
>>> Since this is a fairly significant rewrite I think it might be good to
>>> make sure our tests exercise the new code. Can you run some kind of
>>> coverage report on this?
>> I successfully ran the jdk_lang jtreg tests which contain several tests for annotations.
> I'm a bit worried these tests doesn't cover annotations + class redefine. But I might be persuaded to have more extensive testing as a follow up as well.
>
> cheers
> /Joel



From martinrb at google.com  Tue Aug 27 13:51:42 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 27 Aug 2013 06:51:42 -0700
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets
	or trees (red/black)
In-Reply-To: <4A4245E1-4153-45BF-8658-DB6822BD31D2@oracle.com>
References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
	<521A473A.6000807@univ-mlv.fr>
	<83208874-EB5A-4CD8-A78D-39A599FB3FF8@oracle.com>
	<521BC4F8.2060001@univ-mlv.fr>
	<4A4245E1-4153-45BF-8658-DB6822BD31D2@oracle.com>
Message-ID: 

On Tue, Aug 27, 2013 at 3:00 AM, Paul Sandoz  wrote:

>
> >>> There are a bunch of @Override that are missing making the code harder
> than it should to read.
> >>>
> >> Yes, i think this is because it sticks to the 166 style i suspect. Easy
> to change.
> >>
>
> Note that j.u. classes are quite inconsistent in this respect to using
> diamonds and @Overrides. My preference is to do a sweeping change to all
> such code.


For jsr166, we continue to maintain some support for jdk6 and use javac6 in
places, and so we've been known to de-<> for portability.   We're also not
huge fans of using @Override pervasively.


From omajid at redhat.com  Tue Aug 27 13:59:56 2013
From: omajid at redhat.com (Omair Majid)
Date: Tue, 27 Aug 2013 09:59:56 -0400
Subject:  Additional source to guess the local timezone ID on
	linux
In-Reply-To: <521C4E9A.3050902@oracle.com>
References: <5217CF92.9030307@redhat.com> <521B1482.104@oracle.com>
	<521C4E9A.3050902@oracle.com>
Message-ID: <521CB0DC.7000701@redhat.com>

On 08/27/2013 03:00 AM, Masayoshi Okutsu wrote:
> /etc/sysconfig/clock used to be supported, but it was removed in JDK 7.
> The problem is discussed in bug #6456628.
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6456628

Thanks for that link. I did not know that this support was present in
JDK7 but then removed. I did not expect various distributions and
versions to have significant differences in that file either.

> Have you tested your fix on all Red Hat-like distros, including some
> older releases, with all the time zone IDs?

No, I tested this with Red Hat Enterprise Linux 6. I did not try it on
older versions. I know newer versions of Fedora don't ship with this
file any more.

Given that this support was removed because there were significant
differences in that file making maintenance harder in OpenJDK, I am
going to withdraw this patch.

Thanks to everyone who reviewed and commented on it.

Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681


From dan.xu at oracle.com  Tue Aug 27 14:15:08 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Tue, 27 Aug 2013 07:15:08 -0700
Subject: RFR: JDK-8023765 -- Improve MaxPathLength.java testcase and reduce
	its test load
In-Reply-To: <521C5173.4070701@oracle.com>
References: <521BF05A.1090805@oracle.com> <521C5173.4070701@oracle.com>
Message-ID: <521CB46C.5060307@oracle.com>

On 08/27/2013 12:12 AM, Alan Bateman wrote:
> On 27/08/2013 01:18, Dan Xu wrote:
>> Hi All,
>>
>> MaxPathLength.javais a troublesome testcase, and fails intermittently 
>> in the nightly test. And it also runs for a long time, especially on 
>> Windows platforms. Inorder to improve the test stability, I remove 
>> its unnecessary test iterations, and use NIOdelete method todo the 
>> clean-up to make the potential failureseasier for diagnosis. Please 
>> review thechanges. Thanks!
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8023765
>> webrev: http://cr.openjdk.java.net/~dxu/8023765/webrev/
>>
>> -Dan
> The double to quickly skip over the names to MAX_LENGTH/2 looks 
> reasonable.
>
> I guess fileCreated should really be fileExists as it may be deleted 
> and then deleted. An alternative here would be to use 
> Files.deleteIfExists as that would avoid the need to introduce flags 
> to track whether the directory and exist exists.
>
> -Alan
Hi Alan,

Those flag names are a little misleading. Sorry about that.

fileCreated and dirCreated are actually tracking the existence of new 
file and directories. If the new file gets deleted, I marked the flag to 
false in the code. And at the end, I also change the recorded file path 
after the rename operation.

I agree that using deleteIfExists is a good alternative. In my original 
thought, I plan to monitor every step and make sure all file operations 
happen as expected. Thanks!

-Dan


From sundararajan.athijegannathan at oracle.com  Tue Aug 27 14:22:31 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Tue, 27 Aug 2013 14:22:31 +0000
Subject: hg: jdk8/tl/nashorn: 10 new changesets
Message-ID: <20130827142242.4903548BC2@hg.openjdk.java.net>

Changeset: badc919cd621
Author:    lagergren
Date:      2013-08-23 14:16 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/badc919cd621

8023550: -d option was broken for any dir but '.'. Fixed Java warnings.
Reviewed-by: jlaskey, sundar

! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java
! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java
! src/jdk/internal/dynalink/ChainedCallSite.java
! src/jdk/internal/dynalink/DefaultBootstrapper.java
! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! src/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/internal/codegen/CompilationPhase.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/objects/NativeRegExp.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/DebuggerSupport.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/regexp/joni/ArrayCompiler.java
! src/jdk/nashorn/internal/runtime/regexp/joni/BitSet.java
! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java
! src/jdk/nashorn/internal/runtime/regexp/joni/CodeRangeBuffer.java
! src/jdk/nashorn/internal/runtime/regexp/joni/Lexer.java
! src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java
! src/jdk/nashorn/internal/runtime/regexp/joni/Region.java
! src/jdk/nashorn/internal/runtime/regexp/joni/ScannerSupport.java
! src/jdk/nashorn/internal/runtime/regexp/joni/SearchAlgorithm.java
! src/jdk/nashorn/internal/runtime/regexp/joni/StackMachine.java
! src/jdk/nashorn/internal/runtime/regexp/joni/WarnCallback.java
! src/jdk/nashorn/internal/runtime/regexp/joni/ast/EncloseNode.java
! src/jdk/nashorn/internal/runtime/regexp/joni/ast/Node.java
! src/jdk/nashorn/internal/runtime/regexp/joni/ast/QuantifierNode.java
! src/jdk/nashorn/internal/runtime/regexp/joni/exception/ErrorMessages.java
! tools/fxshell/jdk/nashorn/tools/FXShell.java

Changeset: e2d94d032760
Author:    jlaskey
Date:      2013-08-23 09:56 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e2d94d032760

8020946: TokenType#toString returned null
Reviewed-by: hannesw, lagergren
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/parser/TokenType.java

Changeset: eb7b8340ce3a
Author:    lagergren
Date:      2013-08-23 15:46 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/eb7b8340ce3a

8023454: Updated DEVELOPER_README and command line flags, ensuring that undocumented flags that aren't guaranteed to work (disabled by default) and that are work in progress show up with an EXPERIMENTAL tag.
Reviewed-by: attila, jlaskey

! docs/DEVELOPER_README
! src/jdk/nashorn/internal/runtime/resources/Options.properties

Changeset: 12820c8d0a5d
Author:    jlaskey
Date:      2013-08-23 12:20 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/12820c8d0a5d

8019987: String trimRight and trimLeft could be defined
Reviewed-by: sundar
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/objects/NativeString.java
+ test/script/basic/JDK-8019987.js

Changeset: c19c66e661a9
Author:    hannesw
Date:      2013-08-26 15:59 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c19c66e661a9

8023650: Regexp m flag does not recognize CRNL or CR
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java
! src/jdk/nashorn/internal/runtime/regexp/joni/Config.java
! src/jdk/nashorn/internal/runtime/regexp/joni/EncodingHelper.java
! src/jdk/nashorn/internal/runtime/regexp/joni/Lexer.java
! src/jdk/nashorn/internal/runtime/regexp/joni/Matcher.java
! src/jdk/nashorn/tools/Shell.java
+ test/script/basic/JDK-8023650.js

Changeset: 99e48c76d11f
Author:    jlaskey
Date:      2013-08-26 15:33 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/99e48c76d11f

8023721: Simplify eval in DebuggerSupport.
Reviewed-by: sundar, lagergren, hannesw
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/DebuggerSupport.java

Changeset: 3bd077423a08
Author:    sundar
Date:      2013-08-27 15:54 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3bd077423a08

8022773: ScriptEngineTest.printManyTest fails
Reviewed-by: lagergren, attila

! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java

Changeset: 47f0a4c4b729
Author:    attila
Date:      2013-08-27 13:17 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/47f0a4c4b729

8023780: Gracefully handle @CS methods while binding bean properties
Reviewed-by: jlaskey, lagergren, sundar

! src/jdk/nashorn/internal/objects/NativeObject.java
+ test/script/basic/JDK-8023780.js
+ test/script/basic/JDK-8023780.js.EXPECTED

Changeset: bda0e89f88ae
Author:    sundar
Date:      2013-08-27 18:57 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/bda0e89f88ae

8023784: Object.prototype.toString should contain the class name for all instances
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java
! src/jdk/nashorn/internal/objects/NativeFloat32Array.java
! src/jdk/nashorn/internal/objects/NativeFloat64Array.java
! src/jdk/nashorn/internal/objects/NativeInt16Array.java
! src/jdk/nashorn/internal/objects/NativeInt32Array.java
! src/jdk/nashorn/internal/objects/NativeInt8Array.java
! src/jdk/nashorn/internal/objects/NativeUint16Array.java
! src/jdk/nashorn/internal/objects/NativeUint32Array.java
! src/jdk/nashorn/internal/objects/NativeUint8Array.java
! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java
! src/jdk/nashorn/internal/runtime/ScriptRuntime.java
+ test/script/basic/JDK-8023784.js
+ test/script/basic/JDK-8023784.js.EXPECTED
! test/script/basic/NASHORN-377.js.EXPECTED

Changeset: 101606d3eb84
Author:    sundar
Date:      2013-08-27 19:26 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/101606d3eb84

Merge




From sean.mullan at oracle.com  Tue Aug 27 14:47:34 2013
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Tue, 27 Aug 2013 14:47:34 +0000
Subject: hg: jdk8/tl/jdk: 8023769: JDK-8016850 broke the old build
Message-ID: <20130827144802.7A91E48BC4@hg.openjdk.java.net>

Changeset: 134283a88499
Author:    mullan
Date:      2013-08-27 10:46 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/134283a88499

8023769: JDK-8016850 broke the old build
Summary: remove files that were moved/removed from com/sun/security/auth/FILES_java.gmk
Reviewed-by: chegar, xuelei

! make/com/sun/security/auth/FILES_java.gmk



From sean.mullan at oracle.com  Tue Aug 27 17:00:32 2013
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Tue, 27 Aug 2013 17:00:32 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130827170114.3E4EF48BD4@hg.openjdk.java.net>

Changeset: 6a1bfcde4d4d
Author:    mullan
Date:      2013-08-27 12:04 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a1bfcde4d4d

8019830: Add com.sun.media.sound to the list of restricted package
Reviewed-by: vinnie

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! test/java/lang/SecurityManager/CheckPackageAccess.java

Changeset: 3575263eefab
Author:    mullan
Date:      2013-08-27 12:27 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3575263eefab

Merge

- src/share/classes/com/sun/security/auth/PolicyParser.java
- src/share/classes/com/sun/security/auth/SubjectCodeSource.java
- src/share/classes/sun/misc/Compare.java
- src/share/classes/sun/misc/Sort.java



From bhavesh.x.patel at oracle.com  Tue Aug 27 18:42:23 2013
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Tue, 27 Aug 2013 18:42:23 +0000
Subject: hg: jdk8/tl/langtools: 7052170: javadoc -charset option generates
	wrong meta tag
Message-ID: <20130827184229.9910448BE1@hg.openjdk.java.net>

Changeset: 7fb27bc201cc
Author:    bpatel
Date:      2013-08-27 11:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7fb27bc201cc

7052170: javadoc -charset option generates wrong meta tag
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlAttr.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java
+ test/com/sun/javadoc/testCharset/TestCharset.java
+ test/com/sun/javadoc/testCharset/pkg/Foo.java



From joe.darcy at oracle.com  Tue Aug 27 18:46:44 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 27 Aug 2013 18:46:44 +0000
Subject: hg: jdk8/tl/jdk: 8023827: Fix doclint issues in javax.net.ssl
Message-ID: <20130827184707.54C9948BE2@hg.openjdk.java.net>

Changeset: 51151b440e95
Author:    darcy
Date:      2013-08-27 11:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51151b440e95

8023827: Fix doclint issues in javax.net.ssl
Reviewed-by: wetmore, xuelei

! src/share/classes/javax/net/ssl/SNIHostName.java
! src/share/classes/javax/net/ssl/X509KeyManager.java



From paul.sandoz at oracle.com  Tue Aug 27 19:06:45 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 27 Aug 2013 21:06:45 +0200
Subject: Take 2  Re: RFR 8023155: Ensure functional consistency across
	Random, ThreadLocalRandom, SplittableRandom
In-Reply-To: <2F2B4DE7-93F4-42C5-96B3-591C52CF24F8@oracle.com>
References: 
	
	<2F2B4DE7-93F4-42C5-96B3-591C52CF24F8@oracle.com>
Message-ID: <23E46AED-3025-4EDF-BF91-D337E7B522A6@oracle.com>

Updated:

  http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/webrev/

- we reverted the addition of the new next* methods on Random. The stream-based methods remain unchanged. Decided to be extra conservative, since there may be sub-classes that define such methods (not unusual e.g. just like TLR) and the contract might be different to what we specify (probably most likely around error handling but there could be other subtle issues).

- the stream-based int origin/bound support is defined using nextInt methods rather than next, which should be better when used with existing sub-classes.

- some additional tests were added for double-related origin/bounds methods of Random, ThreadLocalRandom, and SplittableRandom.

Note for TLR default constructors the seed is not yet based on the same algorithm as SplittableRandom. As discussed in a previous email we cannot do that until the hash seed functionality is removed from WeakHashMap and Hashtable.

Paul.



From henry.jen at oracle.com  Tue Aug 27 19:08:23 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Tue, 27 Aug 2013 19:08:23 +0000
Subject: hg: jdk8/tl/jdk: 8023275: Wrapping collections should override
	default methods
Message-ID: <20130827190924.2BB8348BE8@hg.openjdk.java.net>

Changeset: ade440668f94
Author:    henryjen
Date:      2013-08-26 22:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ade440668f94

8023275: Wrapping collections should override default methods
Reviewed-by: mduigou, psandoz

! src/share/classes/java/util/Collections.java
+ test/java/util/Collections/Wrappers.java



From joe.darcy at oracle.com  Tue Aug 27 18:59:39 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 27 Aug 2013 18:59:39 +0000
Subject: hg: jdk8/tl/langtools: 8023826: Typo in warning about obsolete source
	/ target values
Message-ID: <20130827185942.4591C48BE3@hg.openjdk.java.net>

Changeset: 662a5188bded
Author:    darcy
Date:      2013-08-27 11:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/662a5188bded

8023826: Typo in warning about obsolete source / target values
Reviewed-by: jjg, wmdietl

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java



From xueming.shen at oracle.com  Tue Aug 27 19:51:41 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Tue, 27 Aug 2013 19:51:41 +0000
Subject: hg: jdk8/tl/jdk: 8023647: "abc1c".matches("(\\w)+1\\1")) returns false
Message-ID: <20130827195214.B335F48BEF@hg.openjdk.java.net>

Changeset: 3f6777cbfe69
Author:    sherman
Date:      2013-08-27 12:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f6777cbfe69

8023647: "abc1c".matches("(\\w)+1\\1")) returns false
Summary: to correct the wrong GroupCurly group index backoff code
Reviewed-by: alanb

! src/share/classes/java/util/regex/Pattern.java
! test/java/util/regex/RegExTest.java



From forax at univ-mlv.fr  Tue Aug 27 21:25:08 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 27 Aug 2013 23:25:08 +0200
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets
	or trees (red/black)
In-Reply-To: <4A4245E1-4153-45BF-8658-DB6822BD31D2@oracle.com>
References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
	<521A473A.6000807@univ-mlv.fr>
	<83208874-EB5A-4CD8-A78D-39A599FB3FF8@oracle.com>
	<521BC4F8.2060001@univ-mlv.fr>
	<4A4245E1-4153-45BF-8658-DB6822BD31D2@oracle.com>
Message-ID: <521D1934.7020307@univ-mlv.fr>

On 08/27/2013 12:00 PM, Paul Sandoz wrote:
> On Aug 26, 2013, at 11:13 PM, Remi Forax  wrote:
>
>> On 08/26/2013 10:10 PM, Paul Sandoz wrote:
>>> On Aug 25, 2013, at 8:04 PM, Remi Forax  wrote:
>>>
>>>> On 08/21/2013 02:25 PM, Paul Sandoz wrote:
>>>>> Hi,
>>>>>
>>>>> Here are Doug's Linked/HashMap changes, discussed in a previous thread, as a webrev:
>>>>>
>>>>>    http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/
>>>>>
>>>>> I also added some tests related to characteristics associated with fixing another bug.
>>>>>
>>>>> Looking at the diffs will be tricky given there are so many changes.
>>>> The code can be simplified a little bit by using the diamond syntax,
>>>> HashMap (lines: 919, 963, 1026, 1497, 1569) and
>>>> LinkedHashMap (lines: 255, 264, 270, 278)
>>>>
>>>> There are a bunch of @Override that are missing making the code harder than it should to read.
>>>>
>>> Yes, i think this is because it sticks to the 166 style i suspect. Easy to change.
>>>
> Note that j.u. classes are quite inconsistent in this respect to using diamonds and @Overrides. My preference is to do a sweeping change to all such code. I wonder if an IDE can automate that?

Eclipse has a 'cleanup tool' for that. So it is able to add @Override 
but unfortunately, not to add diamonds.

[...]

> Thanks.
>
> Here is the latest patch that also includes updates for the above 2 comments and Mike's comments:
>
>    http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/
>
> Paul.

It looks good for me.

R?mi



From xueming.shen at oracle.com  Tue Aug 27 21:42:23 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 27 Aug 2013 14:42:23 -0700
Subject: RFR JDK-8023713: ZipFileSystem has compatiable issue to handle old
	zip file.
Message-ID: <521D1D3F.4000003@oracle.com>

Hi,

Please help review the change for #8023713

http://cr.openjdk.java.net/~sherman/8023713/webrev

The root cause is that the newly introduced ZOS.writeExtra() (for
#8015666) fails to handle "irregular" extra data field. The zip spec
requires the the extra data stars with 4 bytes of "tag + size" pair
and then followed by the actual "extra data". The "offending" zip
file actually has the "irregular" extra data field with 1 single byte
as the extra data. That said, the implementation (ZOS) should still
be able handle this kind of zip entry correctly and appropriately.

The proposed solution is to simply copy the specified extra data
into the output stream.

Thanks!
-Sherman


From forax at univ-mlv.fr  Tue Aug 27 21:38:01 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 27 Aug 2013 23:38:01 +0200
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets
	or trees (red/black)
In-Reply-To: 
References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
	<521A473A.6000807@univ-mlv.fr>
	<83208874-EB5A-4CD8-A78D-39A599FB3FF8@oracle.com>
	<521BC4F8.2060001@univ-mlv.fr>
	<4A4245E1-4153-45BF-8658-DB6822BD31D2@oracle.com>
	
Message-ID: <521D1C39.30201@univ-mlv.fr>

On 08/27/2013 03:51 PM, Martin Buchholz wrote:
> On Tue, Aug 27, 2013 at 3:00 AM, Paul Sandoz  wrote:
>
[...]

>> Note that j.u. classes are quite inconsistent in this respect to using
>> diamonds and @Overrides. My preference is to do a sweeping change to all
>> such code.
>
> For jsr166, we continue to maintain some support for jdk6 and use javac6 in
> places, and so we've been known to de-<> for portability.   We're also not
> huge fans of using @Override pervasively.

 From a reader perspective, @Override is great to figure out which part 
of the code
is part of the supertypes contract and which part is specific to the class.

R?mi



From mike.duigou at oracle.com  Tue Aug 27 21:47:44 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 27 Aug 2013 14:47:44 -0700
Subject: Take 2  Re: RFR 8023155: Ensure functional consistency
	across Random, ThreadLocalRandom, SplittableRandom
In-Reply-To: <23E46AED-3025-4EDF-BF91-D337E7B522A6@oracle.com>
References: 
	
	<2F2B4DE7-93F4-42C5-96B3-591C52CF24F8@oracle.com>
	<23E46AED-3025-4EDF-BF91-D337E7B522A6@oracle.com>
Message-ID: 

Looks good.

Random::

- Seems fine.


ThreadLocalRandom::

- I don't understand the point of having a writeObject() if the readResolve() ignores the result. My expectation for a serialized TLR might be that upon de-serialization the seeding state is restored. If that isn't provided, why offer any serialization at all? Alternately we should be more explicit that the seeding state is not part of the serialization.

- There's no test for the serialization behaviour.

SplittableRandomTest::

- executeAndCatch -> assertThrows perhaps? There are a few implementations of assertThrows around in other tests (which haven't been collected into a library yet).


Mike

On Aug 27 2013, at 12:06 , Paul Sandoz wrote:

> Updated:
> 
>  http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/webrev/
> 
> - we reverted the addition of the new next* methods on Random. The stream-based methods remain unchanged. Decided to be extra conservative, since there may be sub-classes that define such methods (not unusual e.g. just like TLR) and the contract might be different to what we specify (probably most likely around error handling but there could be other subtle issues).
> 
> - the stream-based int origin/bound support is defined using nextInt methods rather than next, which should be better when used with existing sub-classes.
> 
> - some additional tests were added for double-related origin/bounds methods of Random, ThreadLocalRandom, and SplittableRandom.
> 
> Note for TLR default constructors the seed is not yet based on the same algorithm as SplittableRandom. As discussed in a previous email we cannot do that until the hash seed functionality is removed from WeakHashMap and Hashtable.

Soon I hope.



> Paul.
> 
> 



From martinrb at google.com  Tue Aug 27 22:07:06 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 27 Aug 2013 15:07:06 -0700
Subject: RFR JDK-8023713: ZipFileSystem has compatiable issue to handle
	old zip file.
In-Reply-To: <521D1D3F.4000003@oracle.com>
References: <521D1D3F.4000003@oracle.com>
Message-ID: 

It does seem vaguely reasonable to support any extra data.

Don't you want to also handle arbitrary byte arrays, if e.g. one the 16-bit
size fields overflows the extra data?
It looks to me like getExtraLen could return a negative number.

And put a SPACE after "if".


On Tue, Aug 27, 2013 at 2:42 PM, Xueming Shen wrote:

> Hi,
>
> Please help review the change for #8023713
>
> http://cr.openjdk.java.net/~**sherman/8023713/webrev
>
> The root cause is that the newly introduced ZOS.writeExtra() (for
> #8015666) fails to handle "irregular" extra data field. The zip spec
> requires the the extra data stars with 4 bytes of "tag + size" pair
> and then followed by the actual "extra data". The "offending" zip
> file actually has the "irregular" extra data field with 1 single byte
> as the extra data. That said, the implementation (ZOS) should still
> be able handle this kind of zip entry correctly and appropriately.
>
> The proposed solution is to simply copy the specified extra data
> into the output stream.
>
> Thanks!
> -Sherman
>


From mike.duigou at oracle.com  Tue Aug 27 22:56:23 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 27 Aug 2013 15:56:23 -0700
Subject: RFR: 8021591 : (s) Additional explicit null checks
In-Reply-To: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com>
References: <17DBA593-2AD1-4E42-8DD1-790511B63B3F@oracle.com>
Message-ID: <74270D6C-72EE-4768-98CB-B74E79952C1F@oracle.com>

Hello all;

Here's an updated version of the patch which incorporates feedback and improves the tests (the reason for delay):

http://cr.openjdk.java.net/~mduigou/JDK-8021591/1/webrev/

The substance of the patch is largely to add missing checks that the collection provided to removeAll()/retainAll() is not null. The specification of these methods in the Collection interface has always indicated that an NPE should be thrown if the passed collection was null. Historically various implementations were inconsistent about whether they threw the NPE if a null collection was passed. Some collections would throw the NPE, some would not. The intent of this patch is to improve consistency and since there were examples of the NPE being correctly thrown the most prudent approach seems to have all implementations throw the NPE. If there had been no examples of the NPE being thrown then it would have been more prudent to amend the interface spec to remove the NPE notice.

A few other inconsistencies around null handling were also resolved. Some unit tests issues were also cleaned up.

Mike

On Jul 26 2013, at 16:31 , Mike Duigou wrote:

> Hello all;
> 
> This patch adds some missing checks for null that, according to interface contract, should be throwing NPE. It also improves the existing tests to check for these cases. 
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8021591/0/webrev/
> 
> The changes to src/share/classes/java/util/concurrent/ConcurrentHashMap.java will be synchronized separately with the jsr166 workspace. They are part of this review to avoid test failures.
> 
> Mike



From xueming.shen at oracle.com  Tue Aug 27 23:09:06 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 27 Aug 2013 16:09:06 -0700
Subject: RFR JDK-8023713: ZipFileSystem has compatiable issue to handle
	old zip file.
In-Reply-To: 
References: <521D1D3F.4000003@oracle.com>
	
Message-ID: <521D3192.2060702@oracle.com>

On 08/27/2013 03:07 PM, Martin Buchholz wrote:
> It does seem vaguely reasonable to support any extra data.
>
> Don't you want to also handle arbitrary byte arrays, if e.g. one the 16-bit size fields overflows the extra data?
> It looks to me like getExtraLen could return a negative number.
>

probably I should. The webrev has been updated to simply
copy the rest of the extra data, if the "sz" is either < 0 or
out of the range.

http://cr.openjdk.java.net/~sherman/8023713/webrev/


> And put a SPACE after "if".

updated.

Thanks!
-Sherman

>
>
> On Tue, Aug 27, 2013 at 2:42 PM, Xueming Shen > wrote:
>
>     Hi,
>
>     Please help review the change for #8023713
>
>     http://cr.openjdk.java.net/~sherman/8023713/webrev 
>
>     The root cause is that the newly introduced ZOS.writeExtra() (for
>     #8015666) fails to handle "irregular" extra data field. The zip spec
>     requires the the extra data stars with 4 bytes of "tag + size" pair
>     and then followed by the actual "extra data". The "offending" zip
>     file actually has the "irregular" extra data field with 1 single byte
>     as the extra data. That said, the implementation (ZOS) should still
>     be able handle this kind of zip entry correctly and appropriately.
>
>     The proposed solution is to simply copy the specified extra data
>     into the output stream.
>
>     Thanks!
>     -Sherman
>
>



From mike.duigou at oracle.com  Tue Aug 27 23:17:25 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 27 Aug 2013 16:17:25 -0700
Subject: RFR: 8015068 : (m) Use jtreg -exclude for problemlist.txt
	processing
In-Reply-To: <145F648E-CDE7-4C36-8E4B-F56ED39C0C5E@oracle.com>
References: <145F648E-CDE7-4C36-8E4B-F56ED39C0C5E@oracle.com>
Message-ID: <6F54F866-5384-4B0C-AC36-826838760C1E@oracle.com>

Hello all;

I have updated the changeset for this issue based upon feedback from the earlier version. As a result of intervening work this version contains even more cleanup.

http://cr.openjdk.java.net/~mduigou/JDK-8015068/1/webrev/

Since the last revision:

- One open issue remains--handling of shared_library_permissions. The proposed patch uses a pattern rule, "jdk_%", rather than explicit make targets. This means the knowledge of which targets required shared_library_permissions has been lost. The shared_library_permissions target could be run unconditionally as part of prep but I am uncertain if this is reasonable. Alternatives?

- The previously proposed behaviour of writing testoutput to the current directory if not ALT_OUTPUTDIR is provided has been changed in response to feedback. Output will now be written to jdk/testoutput and this directory has been added to the .hgignore. Since most people are expected to use only the root repo make which sets ALT_OUTPUTDIR it is not expected that this change will make any difference for most users.

As before, testing of this patch requires using a source build of JTReg as it requires one fix that is not in the promoted builds. This changeset will not be integrated until after the next JTReg promotion.

Mike

On Aug 7 2013, at 14:44 , Mike Duigou wrote:

> Hello all;
> 
> This changesest simplifies how the the jdk/test/Makefile processes excluded tests. Previously the test exclusions were pre-processed by scripts in the Makefile before being passed to JTReg. JTReg will now the all the processing. The change depends upon improvements in JTReg since the test exclude mechanism was originally defined.
> 
> There are some changes in the reporting. Most obvious is that the excludelist.txt output file is no longer produced. The 'excluded' count in the summary report may be removed in a future reporting depending on whether the value can be calculated some other way.
> 
> Additional to the exclusion list processing changes some other changes are possible as a result of the changes to exclusion processing. In particular the obsolete (and incorrect) logic for determining the build path included in the test/Makefile is now removed. If no output directory is provided via ALT_OUTPUTDIR then a default location in the current directory is used, "testoutput". At some point in the future this could be improved to get the CONF from the build configuration but that is not currently possible.
> 
> Testing of this patch requires using a source build of JTReg as it requires one fix that is not in the promoted builds. 
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8015068/0/webrev/
> 
> Mike



From dan.xu at oracle.com  Tue Aug 27 23:20:23 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Tue, 27 Aug 2013 16:20:23 -0700
Subject: RFR: JDK-4792059 -- test/java/io/pathNames/GeneralSolaris.java fails
	on symbolic links
Message-ID: <521D3437.1080003@oracle.com>

Hi,

When GeneralSolaris testcase follows symbolic link to pick up an 
existing file or directory for testing, it will fail the assertion in 
check()method because the file path canonicalization process will result 
in the real path not a path containing symbolic link. I enforce this 
test not to use any symbolic link as a testing file ordirectory to avoid 
this problem. Please help review my fix. Thanks!

bug: https://bugs.openjdk.java.net/browse/JDK-4792059
webrev: http://cr.openjdk.java.net/~dxu/4792059/webrev/

-Dan


From kellyohair at gmail.com  Tue Aug 27 23:30:45 2013
From: kellyohair at gmail.com (Kelly O'Hair)
Date: Tue, 27 Aug 2013 16:30:45 -0700
Subject: RFR: 8015068 : (m) Use jtreg -exclude for problemlist.txt
	processing
In-Reply-To: <6F54F866-5384-4B0C-AC36-826838760C1E@oracle.com>
References: <145F648E-CDE7-4C36-8E4B-F56ED39C0C5E@oracle.com>
	<6F54F866-5384-4B0C-AC36-826838760C1E@oracle.com>
Message-ID: <37888C6F-1006-486C-A9EC-89D88C36493E@gmail.com>

Nice.

I think deleting code should be like hazard pay, double the normal hourly wage, but deleting Makefile lines should be triple wage. :)  Looks great to me.  Not that I use this makefile much anymore.

-kto

On Aug 27, 2013, at 4:17 PM, Mike Duigou wrote:

> Hello all;
> 
> I have updated the changeset for this issue based upon feedback from the earlier version. As a result of intervening work this version contains even more cleanup.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8015068/1/webrev/
> 
> Since the last revision:
> 
> - One open issue remains--handling of shared_library_permissions. The proposed patch uses a pattern rule, "jdk_%", rather than explicit make targets. This means the knowledge of which targets required shared_library_permissions has been lost. The shared_library_permissions target could be run unconditionally as part of prep but I am uncertain if this is reasonable. Alternatives?
> 
> - The previously proposed behaviour of writing testoutput to the current directory if not ALT_OUTPUTDIR is provided has been changed in response to feedback. Output will now be written to jdk/testoutput and this directory has been added to the .hgignore. Since most people are expected to use only the root repo make which sets ALT_OUTPUTDIR it is not expected that this change will make any difference for most users.
> 
> As before, testing of this patch requires using a source build of JTReg as it requires one fix that is not in the promoted builds. This changeset will not be integrated until after the next JTReg promotion.
> 
> Mike
> 
> On Aug 7 2013, at 14:44 , Mike Duigou wrote:
> 
>> Hello all;
>> 
>> This changesest simplifies how the the jdk/test/Makefile processes excluded tests. Previously the test exclusions were pre-processed by scripts in the Makefile before being passed to JTReg. JTReg will now the all the processing. The change depends upon improvements in JTReg since the test exclude mechanism was originally defined.
>> 
>> There are some changes in the reporting. Most obvious is that the excludelist.txt output file is no longer produced. The 'excluded' count in the summary report may be removed in a future reporting depending on whether the value can be calculated some other way.
>> 
>> Additional to the exclusion list processing changes some other changes are possible as a result of the changes to exclusion processing. In particular the obsolete (and incorrect) logic for determining the build path included in the test/Makefile is now removed. If no output directory is provided via ALT_OUTPUTDIR then a default location in the current directory is used, "testoutput". At some point in the future this could be improved to get the CONF from the build configuration but that is not currently possible.
>> 
>> Testing of this patch requires using a source build of JTReg as it requires one fix that is not in the promoted builds. 
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8015068/0/webrev/
>> 
>> Mike
> 



From mike.duigou at oracle.com  Wed Aug 28 02:06:26 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 27 Aug 2013 19:06:26 -0700
Subject: RFR: 7057785 : (xs) Add note to hashCode() that support for self
	referential is optional
Message-ID: <9B998061-4597-4792-BBE1-2A378AC0C6EE@oracle.com>

Hello all;

Fairly frequently it is reported that various Collection/Map implementations of hashCode() fail when the instance directly or indirectly contains itself. For a variety of reasons, mostly performance and resource related, most implementations choose not to support calculation of hash codes for self-referential collections. This is not likely to change. So to reduce confusion and "bug" reports I am proposing a non-normative @apiNote be added to Collection and HashMap. The text of the proposed note is:

> Support for calculation of hash code by self referential {Collection|Map}s (they either directly or indirectly contain themselves) is optional. Few Collection implementations support calculation of hash code for self referential instances.


http://cr.openjdk.java.net/~mduigou/JDK-7057785/0/webrev/

Cheers,

Mike

From martinrb at google.com  Wed Aug 28 02:40:56 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 27 Aug 2013 19:40:56 -0700
Subject: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets
	or trees (red/black)
In-Reply-To: <521D1C39.30201@univ-mlv.fr>
References: <9565A13B-8CA7-468B-B314-11740B5ABC0D@oracle.com>
	<521A473A.6000807@univ-mlv.fr>
	<83208874-EB5A-4CD8-A78D-39A599FB3FF8@oracle.com>
	<521BC4F8.2060001@univ-mlv.fr>
	<4A4245E1-4153-45BF-8658-DB6822BD31D2@oracle.com>
	
	<521D1C39.30201@univ-mlv.fr>
Message-ID: 

On Tue, Aug 27, 2013 at 2:38 PM, Remi Forax  wrote:

>
>>
>> For jsr166, we continue to maintain some support for jdk6 and use javac6
>> in
>> places, and so we've been known to de-<> for portability.   We're also not
>> huge fans of using @Override pervasively.
>>
>
> From a reader perspective, @Override is great to figure out which part of
> the code
> is part of the supertypes contract and which part is specific to the class.
>

I don't dispute that @Override provides some useful information.  But is it
worth that feeling I get every time I see an @Override, that some bug
splatted on my monitor, and can't be cleaned?

Why not go further, and do:

@SpecifiedBy(Collection)
@SpecifiedBy(List)
@Overrides(Object)


From dmitry.nadezhin at gmail.com  Wed Aug 28 02:44:17 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Wed, 28 Aug 2013 06:44:17 +0400
Subject: Java 8 RFR 8010430: Math.round has surprising behavior for odd
	values of ulp 1
In-Reply-To: 
References: 
	
	<0099615E-F51D-47C4-9330-582911BBD3EF@oracle.com>
	
	
	
	<1377370934.77781.YahooMailNeo@web171703.mail.ir2.yahoo.com>
	<31920C83-8AEC-443E-94BB-300B2F7B17EE@oracle.com>
	
Message-ID: 

Is it reasonable to make specification clearer ?

Either to return JLS 1 specification:
<<<
The result is rounded to an integer by adding , taking the floor of the
result, and casting the result to type long.
>>>
or to replace "rounding up" with "rounding to positive infinity":
<<<
Returns the closest {@code int} to the argument, with ties rounding to
positive infinity.
>>>


On Tue, Aug 27, 2013 at 3:19 AM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> On Aug 26, 2013, at 7:52 AM, Guy Steele wrote:
>
> On Aug 24, 2013, at 3:02 PM, Jeff Hain  wrote:
>
>
> Dmitry Nadezhin wrote:
>
> Nevertheless, I send this variant now in hope that it may be useful.
>
>
> Great! It's much faster than what I proposed, cleaner (only integers),
>
> and according to my tests it behaves the same.
>
>
> Excellent!  Nice piece of work---thanks, Dmitry.
>
>
> Indeed - thanks, Dmitry! That is much better than what I proposed.
>
> I did a quick and dirty JMH test with this code and it looks to be more
> than 6% faster for double and more than 24% faster for float versus the
> current codebase. The speed up is probably more than these values which
> should be considered lower bounds on speed improvement.
>
> I have updated the webrev accordingly:
>
> http://cr.openjdk.java.net/~bpb/8010430/
>
> Approval by a Reviewer of this patch is still needed.
>
> Thanks,
>
> Brian
>


From henry.jen at oracle.com  Wed Aug 28 04:24:49 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Wed, 28 Aug 2013 04:24:49 +0000
Subject: hg: jdk8/tl/jdk: 8023528: Rename Comparator combinators to
	disambiguate overloading methods
Message-ID: <20130828042521.5AB2A48C07@hg.openjdk.java.net>

Changeset: be2d25a277a7
Author:    henryjen
Date:      2013-08-21 20:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/be2d25a277a7

8023528: Rename Comparator combinators to disambiguate overloading methods
Reviewed-by: mduigou, smarks

! src/share/classes/java/util/Comparator.java
! test/java/util/Comparator/BasicTest.java
! test/java/util/Map/EntryComparators.java
! test/java/util/function/BinaryOperator/BasicTest.java



From chris.hegarty at oracle.com  Wed Aug 28 08:53:24 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 28 Aug 2013 09:53:24 +0100
Subject: RFR JDK-8023713: ZipFileSystem has compatiable issue to handle
	old zip file.
In-Reply-To: <521D3192.2060702@oracle.com>
References: <521D1D3F.4000003@oracle.com>
	
	<521D3192.2060702@oracle.com>
Message-ID: <521DBA84.5090302@oracle.com>

On 28/08/2013 00:09, Xueming Shen wrote:
> On 08/27/2013 03:07 PM, Martin Buchholz wrote:
>> It does seem vaguely reasonable to support any extra data.
>>
>> Don't you want to also handle arbitrary byte arrays, if e.g. one the
>> 16-bit size fields overflows the extra data?
>> It looks to me like getExtraLen could return a negative number.
>>
>
> probably I should. The webrev has been updated to simply
> copy the rest of the extra data, if the "sz" is either < 0 or
> out of the range.
>
> http://cr.openjdk.java.net/~sherman/8023713/webrev/

Looks ok to me Sherman.

-Chris.

>
>
>> And put a SPACE after "if".
>
> updated.
>
> Thanks!
> -Sherman
>
>>
>>
>> On Tue, Aug 27, 2013 at 2:42 PM, Xueming Shen > > wrote:
>>
>> Hi,
>>
>> Please help review the change for #8023713
>>
>> http://cr.openjdk.java.net/~sherman/8023713/webrev
>> 
>>
>> The root cause is that the newly introduced ZOS.writeExtra() (for
>> #8015666) fails to handle "irregular" extra data field. The zip spec
>> requires the the extra data stars with 4 bytes of "tag + size" pair
>> and then followed by the actual "extra data". The "offending" zip
>> file actually has the "irregular" extra data field with 1 single byte
>> as the extra data. That said, the implementation (ZOS) should still
>> be able handle this kind of zip entry correctly and appropriately.
>>
>> The proposed solution is to simply copy the specified extra data
>> into the output stream.
>>
>> Thanks!
>> -Sherman
>>
>>
>


From dawid.weiss at gmail.com  Wed Aug 28 09:44:08 2013
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Wed, 28 Aug 2013 11:44:08 +0200
Subject: Simple RFR: 8203311 Clean up profile-includes.txt
In-Reply-To: <5214809D.6040300@oracle.com>
References: <5212AB5C.6080804@oracle.com> <521461CC.2050402@gmail.com>
	<521471DE.3050905@oracle.com> <52147AF6.9050401@gmail.com>
	<5214809D.6040300@oracle.com>
Message-ID: 

David,

Is the fix for this committed anywhere? I've just tried building from
scratch and I'm getting the same error.

Dawid

On Wed, Aug 21, 2013 at 10:55 AM, David Holmes  wrote:
> Fix on the way. This exposed another piece that was missing from the
> original change. But mea culpa for not doing an OPENJDK build. Sorry about
> that.
>
> Thanks,
> David
>
>
> On 21/08/2013 6:31 PM, Andreas Rieber wrote:
>>
>> Hi David,
>>
>> On 21.08.13 09:53, David Holmes wrote:
>>>
>>> Hi Andreas,
>>>
>>> On 21/08/2013 4:44 PM, Andreas Rieber wrote:
>>>>
>>>> Hi David,
>>>>
>>>> your change causes build problems with ubuntu 12.04. Result is:
>>>>
>>>> make[2]: Entering directory `/usr/local/src/jdk8tl/jdk/makefiles'
>>>> make[2]: *** No rule to make target
>>>>
>>>> `/usr/local/src/jdk8tl/build/linux-x86-normal-server-release/images/lib/jfr.jar',
>>>>
>>>>
>>>> needed by `all'.  Stop.
>>>> make[2]: Leaving directory `/usr/local/src/jdk8tl/jdk/makefiles'
>>>> make[1]: *** [images] Error 2
>>>> make[1]: Leaving directory `/usr/local/src/jdk8tl/jdk/makefiles'
>>>> make: *** [images-only] Error 2
>>>>
>>>> I tried several make clean, configure and so on but only when i rollback
>>>> your change i can compile.
>>>
>>>
>>> I presume this is an OpenJDK build?
>>
>>
>> Yes, openJDK build. Just tried clean fresh build on ubuntu 13.04 with
>> jdk8tl, same result:
>>
>> ## Starting images
>> Creating images/lib/charsets.jar
>> make[2]: *** No rule to make target
>>
>> `/usr/local/src/jdk8tl/build/linux-x86_64-normal-server-release/images/lib/jfr.jar',
>> needed by `all'.  Stop.
>> make[2]: *** Waiting for unfinished jobs....
>> Creating images/lib/ext/dnsns.jar
>> Creating images/lib/ext/cldrdata.jar
>> make[1]: *** [images] Error 2
>> make: *** [images-only] Error 2
>>
>>>
>>> That is quite puzzling .... I will investigate.
>>
>>
>> thanks for puzzling
>> Andreas
>>
>>>
>>> Thanks,
>>> David
>>>
>>>> Andreas
>>>>
>>>>
>>>> On 20.08.13 01:33, David Holmes wrote:
>>>>>
>>>>> http://cr.openjdk.java.net/~dholmes/8023311/webrev/
>>>>>
>>>>> Patch inlined below
>>>>>
>>>>> This is a trivial cleanup following on from an earlier change under
>>>>> 8017570. JFR was moved from profile compact3 to the full JRE but not
>>>>> all
>>>>> the variables in profile-includes.txt were updated as needed. jfr.jar
>>>>> needed to removed from the profile3 jar list and added to the jre jar
>>>>> list.
>>>>>
>>>>> This has no impact on the actual build artifacts - JFR was, and
>>>>> remains,
>>>>> in the full JRE only.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> --- old/makefiles/profile-includes.txt    2013-08-19 19:10:17.554355677
>>>>> -0400
>>>>> +++ new/makefiles/profile-includes.txt    2013-08-19 19:10:14.586187808
>>>>> -0400
>>>>> @@ -102,6 +102,7 @@
>>>>>       security/US_export_policy.jar \
>>>>>       security/local_policy.jar
>>>>>
>>>>> +
>>>>>   PROFILE_2_JRE_BIN_FILES := \
>>>>>       rmid$(EXE_SUFFIX) \
>>>>>       rmiregistry$(EXE_SUFFIX)
>>>>> @@ -140,7 +141,6 @@
>>>>>   PROFILE_3_JRE_OTHER_FILES :=
>>>>>
>>>>>   PROFILE_3_JRE_JAR_FILES := \
>>>>> -    jfr.jar \
>>>>>       management-agent.jar
>>>>>
>>>>>
>>>>> @@ -253,6 +253,6 @@
>>>>>       ext/cldrdata.jar \
>>>>>       ext/dnsns.jar \
>>>>>       ext/nashorn.jar \
>>>>> -    ext/zipfs.jar
>>>>> -
>>>>> +    ext/zipfs.jar \
>>>>> +    jfr.jar
>>>>>
>>>>
>>
>


From scolebourne at joda.org  Wed Aug 28 09:55:14 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 28 Aug 2013 10:55:14 +0100
Subject: RFR: 7057785 : (xs) Add note to hashCode() that support for self
	referential is optional
In-Reply-To: <9B998061-4597-4792-BBE1-2A378AC0C6EE@oracle.com>
References: <9B998061-4597-4792-BBE1-2A378AC0C6EE@oracle.com>
Message-ID: 

I lke the idea, but the wording feels a little opaque as the result is
typically StackOverflow.

Also, I prefer a style with the @apiNote on a line of its own, rather
like a heading. It makes the documentation easier to read in source
code, and has no effect on the output Javadoc.

@apiNote
If the Collection is self-referential, where it directly or indirectly
contains itself, then the calculation of hashCode may fail with an
exception. Implementations may optionally try to handle this scenario,
however most current implementations do not do so.

Stephen

On 28 August 2013 03:06, Mike Duigou  wrote:
> Hello all;
>
> Fairly frequently it is reported that various Collection/Map implementations of hashCode() fail when the instance directly or indirectly contains itself. For a variety of reasons, mostly performance and resource related, most implementations choose not to support calculation of hash codes for self-referential collections. This is not likely to change. So to reduce confusion and "bug" reports I am proposing a non-normative @apiNote be added to Collection and HashMap. The text of the proposed note is:
>
>> Support for calculation of hash code by self referential {Collection|Map}s (they either directly or indirectly contain themselves) is optional. Few Collection implementations support calculation of hash code for self referential instances.
>
>
> http://cr.openjdk.java.net/~mduigou/JDK-7057785/0/webrev/
>
> Cheers,
>
> Mike


From rieberandreas at gmail.com  Wed Aug 28 10:00:04 2013
From: rieberandreas at gmail.com (Andreas Rieber)
Date: Wed, 28 Aug 2013 12:00:04 +0200
Subject: Simple RFR: 8203311 Clean up profile-includes.txt
In-Reply-To: 
References: <5212AB5C.6080804@oracle.com> <521461CC.2050402@gmail.com>
	<521471DE.3050905@oracle.com> <52147AF6.9050401@gmail.com>
	<5214809D.6040300@oracle.com>
	
Message-ID: <521DCA24.9040704@gmail.com>

Hi Dawid,

the fix is in jdk8tl already, just missed to come into jdk8. It's only a 
few lines.

Andreas

Here the changeset:

Changeset: 3b8fed46b2a8
Author:    dholmes
Date:      2013-08-21 05:56 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b8fed46b2a8

8023460: OPENJDK build fails due to missing jfr.jar
Reviewed-by: alanb

! makefiles/Profiles.gmk


On 28.08.13 11:44, Dawid Weiss wrote:
> David,
>
> Is the fix for this committed anywhere? I've just tried building from
> scratch and I'm getting the same error.
>
> Dawid
>
> On Wed, Aug 21, 2013 at 10:55 AM, David Holmes  wrote:
>> Fix on the way. This exposed another piece that was missing from the
>> original change. But mea culpa for not doing an OPENJDK build. Sorry about
>> that.
>>
>> Thanks,
>> David
>>
>>
>> On 21/08/2013 6:31 PM, Andreas Rieber wrote:
>>>
>>> Hi David,
>>>
>>> On 21.08.13 09:53, David Holmes wrote:
>>>>
>>>> Hi Andreas,
>>>>
>>>> On 21/08/2013 4:44 PM, Andreas Rieber wrote:
>>>>>
>>>>> Hi David,
>>>>>
>>>>> your change causes build problems with ubuntu 12.04. Result is:
>>>>>
>>>>> make[2]: Entering directory `/usr/local/src/jdk8tl/jdk/makefiles'
>>>>> make[2]: *** No rule to make target
>>>>>
>>>>> `/usr/local/src/jdk8tl/build/linux-x86-normal-server-release/images/lib/jfr.jar',
>>>>>
>>>>>
>>>>> needed by `all'.  Stop.
>>>>> make[2]: Leaving directory `/usr/local/src/jdk8tl/jdk/makefiles'
>>>>> make[1]: *** [images] Error 2
>>>>> make[1]: Leaving directory `/usr/local/src/jdk8tl/jdk/makefiles'
>>>>> make: *** [images-only] Error 2
>>>>>
>>>>> I tried several make clean, configure and so on but only when i rollback
>>>>> your change i can compile.
>>>>
>>>>
>>>> I presume this is an OpenJDK build?
>>>
>>>
>>> Yes, openJDK build. Just tried clean fresh build on ubuntu 13.04 with
>>> jdk8tl, same result:
>>>
>>> ## Starting images
>>> Creating images/lib/charsets.jar
>>> make[2]: *** No rule to make target
>>>
>>> `/usr/local/src/jdk8tl/build/linux-x86_64-normal-server-release/images/lib/jfr.jar',
>>> needed by `all'.  Stop.
>>> make[2]: *** Waiting for unfinished jobs....
>>> Creating images/lib/ext/dnsns.jar
>>> Creating images/lib/ext/cldrdata.jar
>>> make[1]: *** [images] Error 2
>>> make: *** [images-only] Error 2
>>>
>>>>
>>>> That is quite puzzling .... I will investigate.
>>>
>>>
>>> thanks for puzzling
>>> Andreas
>>>
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Andreas
>>>>>
>>>>>
>>>>> On 20.08.13 01:33, David Holmes wrote:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dholmes/8023311/webrev/
>>>>>>
>>>>>> Patch inlined below
>>>>>>
>>>>>> This is a trivial cleanup following on from an earlier change under
>>>>>> 8017570. JFR was moved from profile compact3 to the full JRE but not
>>>>>> all
>>>>>> the variables in profile-includes.txt were updated as needed. jfr.jar
>>>>>> needed to removed from the profile3 jar list and added to the jre jar
>>>>>> list.
>>>>>>
>>>>>> This has no impact on the actual build artifacts - JFR was, and
>>>>>> remains,
>>>>>> in the full JRE only.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>> --- old/makefiles/profile-includes.txt    2013-08-19 19:10:17.554355677
>>>>>> -0400
>>>>>> +++ new/makefiles/profile-includes.txt    2013-08-19 19:10:14.586187808
>>>>>> -0400
>>>>>> @@ -102,6 +102,7 @@
>>>>>>        security/US_export_policy.jar \
>>>>>>        security/local_policy.jar
>>>>>>
>>>>>> +
>>>>>>    PROFILE_2_JRE_BIN_FILES := \
>>>>>>        rmid$(EXE_SUFFIX) \
>>>>>>        rmiregistry$(EXE_SUFFIX)
>>>>>> @@ -140,7 +141,6 @@
>>>>>>    PROFILE_3_JRE_OTHER_FILES :=
>>>>>>
>>>>>>    PROFILE_3_JRE_JAR_FILES := \
>>>>>> -    jfr.jar \
>>>>>>        management-agent.jar
>>>>>>
>>>>>>
>>>>>> @@ -253,6 +253,6 @@
>>>>>>        ext/cldrdata.jar \
>>>>>>        ext/dnsns.jar \
>>>>>>        ext/nashorn.jar \
>>>>>> -    ext/zipfs.jar
>>>>>> -
>>>>>> +    ext/zipfs.jar \
>>>>>> +    jfr.jar
>>>>>>
>>>>>
>>>
>>



From dawid.weiss at gmail.com  Wed Aug 28 10:04:17 2013
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Wed, 28 Aug 2013 12:04:17 +0200
Subject: Simple RFR: 8203311 Clean up profile-includes.txt
In-Reply-To: <521DCA24.9040704@gmail.com>
References: <5212AB5C.6080804@oracle.com> <521461CC.2050402@gmail.com>
	<521471DE.3050905@oracle.com> <52147AF6.9050401@gmail.com>
	<5214809D.6040300@oracle.com>
	
	<521DCA24.9040704@gmail.com>
Message-ID: 

Thanks Andreas, I'll switch to that revision.

On Wed, Aug 28, 2013 at 12:00 PM, Andreas Rieber
 wrote:
> Hi Dawid,
>
> the fix is in jdk8tl already, just missed to come into jdk8. It's only a few
> lines.
>
> Andreas
>
> Here the changeset:
>
> Changeset: 3b8fed46b2a8
> Author:    dholmes
> Date:      2013-08-21 05:56 -0400
> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b8fed46b2a8
>
> 8023460: OPENJDK build fails due to missing jfr.jar
> Reviewed-by: alanb
>
> ! makefiles/Profiles.gmk
>
>
>
> On 28.08.13 11:44, Dawid Weiss wrote:
>>
>> David,
>>
>> Is the fix for this committed anywhere? I've just tried building from
>> scratch and I'm getting the same error.
>>
>> Dawid
>>
>> On Wed, Aug 21, 2013 at 10:55 AM, David Holmes 
>> wrote:
>>>
>>> Fix on the way. This exposed another piece that was missing from the
>>> original change. But mea culpa for not doing an OPENJDK build. Sorry
>>> about
>>> that.
>>>
>>> Thanks,
>>> David
>>>
>>>
>>> On 21/08/2013 6:31 PM, Andreas Rieber wrote:
>>>>
>>>>
>>>> Hi David,
>>>>
>>>> On 21.08.13 09:53, David Holmes wrote:
>>>>>
>>>>>
>>>>> Hi Andreas,
>>>>>
>>>>> On 21/08/2013 4:44 PM, Andreas Rieber wrote:
>>>>>>
>>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> your change causes build problems with ubuntu 12.04. Result is:
>>>>>>
>>>>>> make[2]: Entering directory `/usr/local/src/jdk8tl/jdk/makefiles'
>>>>>> make[2]: *** No rule to make target
>>>>>>
>>>>>>
>>>>>> `/usr/local/src/jdk8tl/build/linux-x86-normal-server-release/images/lib/jfr.jar',
>>>>>>
>>>>>>
>>>>>> needed by `all'.  Stop.
>>>>>> make[2]: Leaving directory `/usr/local/src/jdk8tl/jdk/makefiles'
>>>>>> make[1]: *** [images] Error 2
>>>>>> make[1]: Leaving directory `/usr/local/src/jdk8tl/jdk/makefiles'
>>>>>> make: *** [images-only] Error 2
>>>>>>
>>>>>> I tried several make clean, configure and so on but only when i
>>>>>> rollback
>>>>>> your change i can compile.
>>>>>
>>>>>
>>>>>
>>>>> I presume this is an OpenJDK build?
>>>>
>>>>
>>>>
>>>> Yes, openJDK build. Just tried clean fresh build on ubuntu 13.04 with
>>>> jdk8tl, same result:
>>>>
>>>> ## Starting images
>>>> Creating images/lib/charsets.jar
>>>> make[2]: *** No rule to make target
>>>>
>>>>
>>>> `/usr/local/src/jdk8tl/build/linux-x86_64-normal-server-release/images/lib/jfr.jar',
>>>> needed by `all'.  Stop.
>>>> make[2]: *** Waiting for unfinished jobs....
>>>> Creating images/lib/ext/dnsns.jar
>>>> Creating images/lib/ext/cldrdata.jar
>>>> make[1]: *** [images] Error 2
>>>> make: *** [images-only] Error 2
>>>>
>>>>>
>>>>> That is quite puzzling .... I will investigate.
>>>>
>>>>
>>>>
>>>> thanks for puzzling
>>>> Andreas
>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Andreas
>>>>>>
>>>>>>
>>>>>> On 20.08.13 01:33, David Holmes wrote:
>>>>>>>
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dholmes/8023311/webrev/
>>>>>>>
>>>>>>> Patch inlined below
>>>>>>>
>>>>>>> This is a trivial cleanup following on from an earlier change under
>>>>>>> 8017570. JFR was moved from profile compact3 to the full JRE but not
>>>>>>> all
>>>>>>> the variables in profile-includes.txt were updated as needed. jfr.jar
>>>>>>> needed to removed from the profile3 jar list and added to the jre jar
>>>>>>> list.
>>>>>>>
>>>>>>> This has no impact on the actual build artifacts - JFR was, and
>>>>>>> remains,
>>>>>>> in the full JRE only.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>> --- old/makefiles/profile-includes.txt    2013-08-19
>>>>>>> 19:10:17.554355677
>>>>>>> -0400
>>>>>>> +++ new/makefiles/profile-includes.txt    2013-08-19
>>>>>>> 19:10:14.586187808
>>>>>>> -0400
>>>>>>> @@ -102,6 +102,7 @@
>>>>>>>        security/US_export_policy.jar \
>>>>>>>        security/local_policy.jar
>>>>>>>
>>>>>>> +
>>>>>>>    PROFILE_2_JRE_BIN_FILES := \
>>>>>>>        rmid$(EXE_SUFFIX) \
>>>>>>>        rmiregistry$(EXE_SUFFIX)
>>>>>>> @@ -140,7 +141,6 @@
>>>>>>>    PROFILE_3_JRE_OTHER_FILES :=
>>>>>>>
>>>>>>>    PROFILE_3_JRE_JAR_FILES := \
>>>>>>> -    jfr.jar \
>>>>>>>        management-agent.jar
>>>>>>>
>>>>>>>
>>>>>>> @@ -253,6 +253,6 @@
>>>>>>>        ext/cldrdata.jar \
>>>>>>>        ext/dnsns.jar \
>>>>>>>        ext/nashorn.jar \
>>>>>>> -    ext/zipfs.jar
>>>>>>> -
>>>>>>> +    ext/zipfs.jar \
>>>>>>> +    jfr.jar
>>>>>>>
>>>>>>
>>>>
>>>
>


From david.holmes at oracle.com  Wed Aug 28 10:08:25 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 28 Aug 2013 20:08:25 +1000
Subject: Simple RFR: 8203311 Clean up profile-includes.txt
In-Reply-To: 
References: <5212AB5C.6080804@oracle.com> <521461CC.2050402@gmail.com>
	<521471DE.3050905@oracle.com> <52147AF6.9050401@gmail.com>
	<5214809D.6040300@oracle.com>
	
	<521DCA24.9040704@gmail.com>
	
Message-ID: <521DCC19.8060006@oracle.com>

Sorry about that. I thought the two fixes were travelling together else 
I would have taken steps to put them together. :(

David

On 28/08/2013 8:04 PM, Dawid Weiss wrote:
> Thanks Andreas, I'll switch to that revision.
>
> On Wed, Aug 28, 2013 at 12:00 PM, Andreas Rieber
>  wrote:
>> Hi Dawid,
>>
>> the fix is in jdk8tl already, just missed to come into jdk8. It's only a few
>> lines.
>>
>> Andreas
>>
>> Here the changeset:
>>
>> Changeset: 3b8fed46b2a8
>> Author:    dholmes
>> Date:      2013-08-21 05:56 -0400
>> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b8fed46b2a8
>>
>> 8023460: OPENJDK build fails due to missing jfr.jar
>> Reviewed-by: alanb
>>
>> ! makefiles/Profiles.gmk
>>
>>
>>
>> On 28.08.13 11:44, Dawid Weiss wrote:
>>>
>>> David,
>>>
>>> Is the fix for this committed anywhere? I've just tried building from
>>> scratch and I'm getting the same error.
>>>
>>> Dawid
>>>
>>> On Wed, Aug 21, 2013 at 10:55 AM, David Holmes 
>>> wrote:
>>>>
>>>> Fix on the way. This exposed another piece that was missing from the
>>>> original change. But mea culpa for not doing an OPENJDK build. Sorry
>>>> about
>>>> that.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>
>>>> On 21/08/2013 6:31 PM, Andreas Rieber wrote:
>>>>>
>>>>>
>>>>> Hi David,
>>>>>
>>>>> On 21.08.13 09:53, David Holmes wrote:
>>>>>>
>>>>>>
>>>>>> Hi Andreas,
>>>>>>
>>>>>> On 21/08/2013 4:44 PM, Andreas Rieber wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi David,
>>>>>>>
>>>>>>> your change causes build problems with ubuntu 12.04. Result is:
>>>>>>>
>>>>>>> make[2]: Entering directory `/usr/local/src/jdk8tl/jdk/makefiles'
>>>>>>> make[2]: *** No rule to make target
>>>>>>>
>>>>>>>
>>>>>>> `/usr/local/src/jdk8tl/build/linux-x86-normal-server-release/images/lib/jfr.jar',
>>>>>>>
>>>>>>>
>>>>>>> needed by `all'.  Stop.
>>>>>>> make[2]: Leaving directory `/usr/local/src/jdk8tl/jdk/makefiles'
>>>>>>> make[1]: *** [images] Error 2
>>>>>>> make[1]: Leaving directory `/usr/local/src/jdk8tl/jdk/makefiles'
>>>>>>> make: *** [images-only] Error 2
>>>>>>>
>>>>>>> I tried several make clean, configure and so on but only when i
>>>>>>> rollback
>>>>>>> your change i can compile.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I presume this is an OpenJDK build?
>>>>>
>>>>>
>>>>>
>>>>> Yes, openJDK build. Just tried clean fresh build on ubuntu 13.04 with
>>>>> jdk8tl, same result:
>>>>>
>>>>> ## Starting images
>>>>> Creating images/lib/charsets.jar
>>>>> make[2]: *** No rule to make target
>>>>>
>>>>>
>>>>> `/usr/local/src/jdk8tl/build/linux-x86_64-normal-server-release/images/lib/jfr.jar',
>>>>> needed by `all'.  Stop.
>>>>> make[2]: *** Waiting for unfinished jobs....
>>>>> Creating images/lib/ext/dnsns.jar
>>>>> Creating images/lib/ext/cldrdata.jar
>>>>> make[1]: *** [images] Error 2
>>>>> make: *** [images-only] Error 2
>>>>>
>>>>>>
>>>>>> That is quite puzzling .... I will investigate.
>>>>>
>>>>>
>>>>>
>>>>> thanks for puzzling
>>>>> Andreas
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Andreas
>>>>>>>
>>>>>>>
>>>>>>> On 20.08.13 01:33, David Holmes wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~dholmes/8023311/webrev/
>>>>>>>>
>>>>>>>> Patch inlined below
>>>>>>>>
>>>>>>>> This is a trivial cleanup following on from an earlier change under
>>>>>>>> 8017570. JFR was moved from profile compact3 to the full JRE but not
>>>>>>>> all
>>>>>>>> the variables in profile-includes.txt were updated as needed. jfr.jar
>>>>>>>> needed to removed from the profile3 jar list and added to the jre jar
>>>>>>>> list.
>>>>>>>>
>>>>>>>> This has no impact on the actual build artifacts - JFR was, and
>>>>>>>> remains,
>>>>>>>> in the full JRE only.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>> --- old/makefiles/profile-includes.txt    2013-08-19
>>>>>>>> 19:10:17.554355677
>>>>>>>> -0400
>>>>>>>> +++ new/makefiles/profile-includes.txt    2013-08-19
>>>>>>>> 19:10:14.586187808
>>>>>>>> -0400
>>>>>>>> @@ -102,6 +102,7 @@
>>>>>>>>         security/US_export_policy.jar \
>>>>>>>>         security/local_policy.jar
>>>>>>>>
>>>>>>>> +
>>>>>>>>     PROFILE_2_JRE_BIN_FILES := \
>>>>>>>>         rmid$(EXE_SUFFIX) \
>>>>>>>>         rmiregistry$(EXE_SUFFIX)
>>>>>>>> @@ -140,7 +141,6 @@
>>>>>>>>     PROFILE_3_JRE_OTHER_FILES :=
>>>>>>>>
>>>>>>>>     PROFILE_3_JRE_JAR_FILES := \
>>>>>>>> -    jfr.jar \
>>>>>>>>         management-agent.jar
>>>>>>>>
>>>>>>>>
>>>>>>>> @@ -253,6 +253,6 @@
>>>>>>>>         ext/cldrdata.jar \
>>>>>>>>         ext/dnsns.jar \
>>>>>>>>         ext/nashorn.jar \
>>>>>>>> -    ext/zipfs.jar
>>>>>>>> -
>>>>>>>> +    ext/zipfs.jar \
>>>>>>>> +    jfr.jar
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>


From paul.sandoz at oracle.com  Wed Aug 28 10:10:25 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 28 Aug 2013 12:10:25 +0200
Subject: Potential issue with CHM.toArray
Message-ID: <41149C78-1097-4B86-9E3F-147CA859697B@oracle.com>

Hi,

Intermittent failures were reported with the CHM toArray test in the JDK.

I updated the tests to increase the number of runs and the number of workers and i can reliably reproduce on my laptop, see below.

The test presumes the size should always increase but fails when it observes a new new size less than the previously observed size. 

Is that a valid assumption? especially when resizing is in progress and bins are transferred from the old to the new table e.g. if one sets the initial capacity of the CHM in the test to say 8 * 1024 (double the number of entries)  there is no issue. 

The toArray implementation essentially uses the iterator, with some use of size estimates to create arrays with hopefully minimal re-sizing. So there is nothing particular about toArray regarding traversal.

Paul.

public class toArray {

    public static void main(String[] args) throws Throwable {
        for (int i = 0; i < 100; i++) {
            main();
        }
    }

    public static void main() throws Throwable {
        final Throwable throwable[] = new Throwable[1];
        final ConcurrentHashMap m
            = new ConcurrentHashMap();

        BiConsumer r = (o, b) -> {
            for (int i = o; i < b; i++)
                m.put(i, i);
        };

        final int nWorkers = 4;
        final int sizePerWorker = 1024;
        final int maxSize = nWorkers * sizePerWorker;
        List workers = IntStream.range(0, nWorkers).
                map(w -> w * sizePerWorker).
                mapToObj(w -> (Runnable )() -> r.accept(w, w + sizePerWorker)).
                map(Thread::new).collect(toList());

        final Thread foreman = new Thread() {
            public Throwable exception = null;
            private int prevSize = 0;

            private boolean checkProgress(Object[] a) {
                int size = a.length;
                System.out.println(size);
                if (size < prevSize) throw new RuntimeException("WRONG WAY");
                if (size > maxSize)  throw new RuntimeException("OVERSHOOT");
                if (size == maxSize) return true;
                prevSize = size;
                return false;
            }

            public void run() {
                try {
                    Integer[] empty = new Integer[0];
                    while (true) {
                        if (checkProgress(m.values().toArray())) return;
                        if (checkProgress(m.keySet().toArray())) return;
                        if (checkProgress(m.values().toArray(empty))) return;
                        if (checkProgress(m.keySet().toArray(empty))) return;
                    }
                } catch (Throwable t) {
                   throwable[0] = t;
                }}};

        foreman.start();
        workers.stream().forEach(Thread::start);

        workers.stream().forEach(toArray::join);
        foreman.join();

        if (throwable[0] != null)
            throw throwable[0];
    }

    static void join(Thread t) {
        try {
            t.join();
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
    }
}

From paul.sandoz at oracle.com  Wed Aug 28 10:12:41 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 28 Aug 2013 12:12:41 +0200
Subject: Take 2  Re: RFR 8023155: Ensure functional consistency
	across Random, ThreadLocalRandom, SplittableRandom
In-Reply-To: 
References: 
	
	<2F2B4DE7-93F4-42C5-96B3-591C52CF24F8@oracle.com>
	<23E46AED-3025-4EDF-BF91-D337E7B522A6@oracle.com>
	
Message-ID: <56AABA97-BCFA-4B64-BEFE-73E2F97C6086@oracle.com>

On Aug 27, 2013, at 11:47 PM, Mike Duigou  wrote:
> ThreadLocalRandom::
> 
> - I don't understand the point of having a writeObject() if the readResolve() ignores the result. My expectation for a serialized TLR might be that upon de-serialization the seeding state is restored. If that isn't provided, why offer any serialization at all? Alternately we should be more explicit that the seeding state is not part of the serialization.
> 

My understanding is it preserves compatibility when deserializing, as indicated by the internal comment:

     * still allowing a call from constructor.  Note that
     * serialization is completely unnecessary because there is only a
     * static singleton.  But we generate a serial form containing
     * "rnd" and "initialized" fields to ensure compatibility across
     * versions.


> - There's no test for the serialization behaviour.
> 

Right, neither for the TCK AFAICT. (There is a serialization test for Random in the JCK.) Issue logged, 8023896.


> SplittableRandomTest::
> 
> - executeAndCatch -> assertThrows perhaps? There are a few implementations of assertThrows around in other tests (which haven't been collected into a library yet).
> 

There are also a few implementations of executeAndCatch lying around too caused by me :-) I agree it is a bad name. We should change all of 'em. I logged another issue, 8023897.

I wish there was a common library of additional functionality that is missing from TestNG itself.

Paul.

From Alan.Bateman at oracle.com  Wed Aug 28 10:56:25 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 28 Aug 2013 11:56:25 +0100
Subject: RFR JDK-8023713: ZipFileSystem has compatiable issue to handle
	old zip file.
In-Reply-To: <521D3192.2060702@oracle.com>
References: <521D1D3F.4000003@oracle.com>
	
	<521D3192.2060702@oracle.com>
Message-ID: <521DD759.3080708@oracle.com>

On 28/08/2013 00:09, Xueming Shen wrote:
> On 08/27/2013 03:07 PM, Martin Buchholz wrote:
>> It does seem vaguely reasonable to support any extra data.
>>
>> Don't you want to also handle arbitrary byte arrays, if e.g. one the 
>> 16-bit size fields overflows the extra data?
>> It looks to me like getExtraLen could return a negative number.
>>
>
> probably I should. The webrev has been updated to simply
> copy the rest of the extra data, if the "sz" is either < 0 or
> out of the range.
>
> http://cr.openjdk.java.net/~sherman/8023713/webrev/
>
The updated webrev looks okay, just odd to see an entry named " 
TestExtreTime" (which may have been a continuation of a typo in the 
original test).

-Alan.


From Alan.Bateman at oracle.com  Wed Aug 28 11:05:17 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 28 Aug 2013 12:05:17 +0100
Subject: RFR: JDK-4792059 -- test/java/io/pathNames/GeneralSolaris.java
	fails on symbolic links
In-Reply-To: <521D3437.1080003@oracle.com>
References: <521D3437.1080003@oracle.com>
Message-ID: <521DD96D.7050005@oracle.com>

On 28/08/2013 00:20, Dan Xu wrote:
> Hi,
>
> When GeneralSolaris testcase follows symbolic link to pick up an 
> existing file or directory for testing, it will fail the assertion in 
> check()method because the file path canonicalization process will 
> result in the real path not a path containing symbolic link. I enforce 
> this test not to use any symbolic link as a testing file ordirectory 
> to avoid this problem. Please help review my fix. Thanks!
>
> bug: https://bugs.openjdk.java.net/browse/JDK-4792059
> webrev: http://cr.openjdk.java.net/~dxu/4792059/webrev/
>
> -Dan
You can drop the exists check as Files.isXXXX can't return true if the 
file doesn't exist. Otherwise looks okay to me.

-Alan.


From Alan.Bateman at oracle.com  Wed Aug 28 11:11:19 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 28 Aug 2013 12:11:19 +0100
Subject: RFR: 8015068 : (m) Use jtreg -exclude for problemlist.txt
	processing
In-Reply-To: <6F54F866-5384-4B0C-AC36-826838760C1E@oracle.com>
References: <145F648E-CDE7-4C36-8E4B-F56ED39C0C5E@oracle.com>
	<6F54F866-5384-4B0C-AC36-826838760C1E@oracle.com>
Message-ID: <521DDAD7.9000701@oracle.com>

On 28/08/2013 00:17, Mike Duigou wrote:
> Hello all;
>
> I have updated the changeset for this issue based upon feedback from the earlier version. As a result of intervening work this version contains even more cleanup.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8015068/1/webrev/
>
> Since the last revision:
>
> - One open issue remains--handling of shared_library_permissions. The proposed patch uses a pattern rule, "jdk_%", rather than explicit make targets. This means the knowledge of which targets required shared_library_permissions has been lost. The shared_library_permissions target could be run unconditionally as part of prep but I am uncertain if this is reasonable. Alternatives?
>
> - The previously proposed behaviour of writing testoutput to the current directory if not ALT_OUTPUTDIR is provided has been changed in response to feedback. Output will now be written to jdk/testoutput and this directory has been added to the .hgignore. Since most people are expected to use only the root repo make which sets ALT_OUTPUTDIR it is not expected that this change will make any difference for most users.
>
> As before, testing of this patch requires using a source build of JTReg as it requires one fix that is not in the promoted builds. This changeset will not be integrated until after the next JTReg promotion.
>
> Mike
>
The updated webrev looks good to me too although I expect the output 
location will be visited again in the future.

(I like Kelly's suggestion for hazard pay for those working on these 
make files).

-Alan.


From dl at cs.oswego.edu  Wed Aug 28 11:18:24 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 28 Aug 2013 07:18:24 -0400
Subject: Potential issue with CHM.toArray
In-Reply-To: <41149C78-1097-4B86-9E3F-147CA859697B@oracle.com>
References: <41149C78-1097-4B86-9E3F-147CA859697B@oracle.com>
Message-ID: <521DDC80.4030506@cs.oswego.edu>

On 08/28/2013 06:10 AM, Paul Sandoz wrote:
> Hi,
>
> Intermittent failures were reported with the CHM toArray test in the JDK.
>
> I updated the tests to increase the number of runs and the number of workers and i can reliably reproduce on my laptop, see below.
>
> The test presumes the size should always increase

CHM has disclaimers (that possibly could be better emphasized) that
size() and related methods return estimates that may not be accurate
during concurrent updates. So the behavior you see doesn't seem
to be forbidden, but is surprising enough that it might be worth
addressing by restarting if post-check of size doesn't match array size.
I will make sure this doesn't induce hidden livelocks etc, and if all
is well, submit update.

-Doug




From peter.levart at gmail.com  Wed Aug 28 13:13:57 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 28 Aug 2013 15:13:57 +0200
Subject: Potential issue with CHM.toArray
In-Reply-To: <41149C78-1097-4B86-9E3F-147CA859697B@oracle.com>
References: <41149C78-1097-4B86-9E3F-147CA859697B@oracle.com>
Message-ID: <521DF795.8070905@gmail.com>

On 08/28/2013 12:10 PM, Paul Sandoz wrote:
> Hi,
>
> Intermittent failures were reported with the CHM toArray test in the JDK.
>
> I updated the tests to increase the number of runs and the number of workers and i can reliably reproduce on my laptop, see below.
>
> The test presumes the size should always increase but fails when it observes a new new size less than the previously observed size.
>
> Is that a valid assumption?

I guess it should be a valid assumption. If a thread observes some 
entries in the Map at a particular time and the same thread observes 
less entries at a later time it means that some entries have 
disappeared. That observation is surprising if the only modifications to 
the Map are concurrent insertions of new entries...

> especially when resizing is in progress and bins are transferred from the old to the new table e.g. if one sets the initial capacity of the CHM in the test to say 8 * 1024 (double the number of entries)  there is no issue.
>
> The toArray implementation essentially uses the iterator, with some use of size estimates to create arrays with hopefully minimal re-sizing. So there is nothing particular about toArray regarding traversal.

The same can be observed by just counting the elements returned from 
Iterators of various Collection views...

It's interesting to print out the two consecutive arrays when this 
happens. Here's one such occurrence:

prevArray: [0, 1024, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 
16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 
34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47]
nextArray: [0, 1024, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 
16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32]

I modified the CHM.Traverser class (a base for all Iterators) to collect 
all tables that it traverses via ForwardingNode.nextTable links during 
iteration. Here's one such occurrence printing also the state of 
Traverser after the iteration:

prevIterator(iterations=62): tab lengths/hashCodes=[ 32/119d7047 
64/776ec8df 32/119d7047 64/776ec8df], index=32, baseIndex=32, 
baseLimit=32, baseSize=32
nextIterator(iterations=36): tab lengths/hashCodes=[ 32/119d7047 
64/776ec8df 32/119d7047], index=48, baseIndex=16, baseLimit=32, baseSize=32


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 in "forward" 
direction, leading to from smaller to larger tables?


Regards, Peter

>
> Paul.



From masayoshi.okutsu at oracle.com  Wed Aug 28 13:25:43 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 28 Aug 2013 22:25:43 +0900
Subject:  java.util.Locale changes
In-Reply-To: <521DC36C.2050703@gmail.com>
References: <521DC21F.1090309@gmail.com> <521DC36C.2050703@gmail.com>
Message-ID: <521DFA57.2060502@oracle.com>

(adding core-libs-dev)

Hi Christian,

RFC 4647 defines The Language Priority List [1]. The use of 
java.util.List would be a natural fit, which is the reason why List is 
used. But use of Iterable does work (as API design). The parameter name 
`priorityIterable' sounds a bit odd, though.

Does use of Iterable add much value to the API? (Please note that List 
is also used in Locale.LanguageRange.)

Thanks,
Masayoshi

[1] http://tools.ietf.org/html/rfc4647#section-2.3

On 2013/08/28 18:31, Christian Beikov wrote:
> Hello there,
>
> I have just seen the changes you want to apply to java.util.Locale in 
> JDK 8 and was wondering why you are forcing the use of a 
> java.util.List in the lookup and filter methods. The related methods 
> of java.util.Locale are
>
> public static Locale lookup(List priorityList, 
> Collection locales)
> public static String lookupTag(List 
> priorityList, Collection tags)
> public static List filterTags(List 
> priorityList, Collection tags)
> public static List filterTags(List 
> priorityList, Collection tags, Locale.FilteringMode mode)
> public static List filter(List 
> priorityList, Collection locales)
> public static List filter(List 
> priorityList, Collection locales, Locale.FilteringMode mode)
>
> which could be changed to
>
> public static Locale lookup(Iterable 
> priorityIterable, Collection locales)
> public static String lookupTag(Iterable 
> priorityIterable, Collection tags)
> public static List filterTags(Iterable 
> priorityIterable, Collection tags)
> public static List filterTags(Iterable 
> priorityIterable, Collection tags, Locale.FilteringMode mode)
> public static List filter(Iterable 
> priorityIterable, Collection locales)
> public static List filter(Iterable 
> priorityIterable, Collection locales, Locale.FilteringMode mode)
>
> The use of java.util.Collection would also be ok.
> One could also use a java.util.Set or something similar to represent 
> the language ranges. I just wanted to provide that feedback if anyone 
> cares. I am also ok with java.util.List but since you are only relying 
> on the iteration order of the priorityList I was curious about the 
> reason.
>



From gnu.andrew at redhat.com  Wed Aug 28 13:26:07 2013
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 28 Aug 2013 09:26:07 -0400 (EDT)
Subject:  Additional source to guess the local timezone ID on
	linux
In-Reply-To: <521CB0DC.7000701@redhat.com>
References: <5217CF92.9030307@redhat.com> <521B1482.104@oracle.com>
	<521C4E9A.3050902@oracle.com> <521CB0DC.7000701@redhat.com>
Message-ID: <1683825431.2780469.1377696367771.JavaMail.root@redhat.com>

----- Original Message -----
> On 08/27/2013 03:00 AM, Masayoshi Okutsu wrote:
> > /etc/sysconfig/clock used to be supported, but it was removed in JDK 7.
> > The problem is discussed in bug #6456628.
> > 
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6456628
> 
> Thanks for that link. I did not know that this support was present in
> JDK7 but then removed. I did not expect various distributions and
> versions to have significant differences in that file either.
> 

To bring things full circle:

https://bugzilla.redhat.com/show_bug.cgi?id=489586

"BTW: I'll change the warning boilerplate to this to make it more clear:

# The time zone of the system is defined by the contents of /etc/localtime.
# This file is only for evaluation by system-config-date, do not rely on its
# contents elsewhere."

https://bugzilla.redhat.com/show_bug.cgi?id=489586#c2

> > Have you tested your fix on all Red Hat-like distros, including some
> > older releases, with all the time zone IDs?
> 
> No, I tested this with Red Hat Enterprise Linux 6. I did not try it on
> older versions. I know newer versions of Fedora don't ship with this
> file any more.
> 
> Given that this support was removed because there were significant
> differences in that file making maintenance harder in OpenJDK, I am
> going to withdraw this patch.
> 
> Thanks to everyone who reviewed and commented on it.
> 
> Omair
> 
> --
> PGP Key: 66484681 (http://pgp.mit.edu/)
> Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From joel.franck at oracle.com  Wed Aug 28 13:39:34 2013
From: joel.franck at oracle.com (Joel =?utf-8?Q?Borggr=C3=A9n-Franck?=)
Date: Wed, 28 Aug 2013 15:39:34 +0200
Subject: RFR: 5047859 : (reflect) Class.getField can't find String[].length
In-Reply-To: <521B8FCB.2060600@oracle.com>
References: <20130826123905.GA26606@jfranck-desktop.jrpg.bea.com>
	<521B8FCB.2060600@oracle.com>
Message-ID: <20130828133934.GG4531@jfranck-desktop.jrpg.bea.com>

Hi Mandy,

Thanks for your comments,

On 2013-08-26, Mandy Chung wrote:
> Joel,
> 
> The spec of the getFields and getDeclaredFields() methods both states this:
> 
>   This method returns an array of length 0 if the class
>   or interface declares no fields, or if this|Class|  object
>   represents a primitive type, an array class, or void.
> 
> The spec of the getDeclaredField() method has this sentence:
> 
>   Note that this method will not reflect the {@code length}
>   field of an array class.
> 
> Your change is okay and it would be good to keep the getField(s)
> and getDeclaredField(s) methods be consistent and states its
> return value "if this|Class|  object represents a primitive type,
> an array class, or void"

I agree the javadoc for the 4 methods should be more uniform. The note
in getDeclaredFields() isn't that good IMHO as for example the term
'array class' in not used in JLS.

I'll be back shortly with an updated webrev.

cheers
/Joel


From alan.bateman at oracle.com  Wed Aug 28 14:33:51 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 28 Aug 2013 14:33:51 +0000
Subject: hg: jdk8/tl/jdk: 8023717: (process) ProcessBuilder should catch
	SecurityException rather than AccessControlException
Message-ID: <20130828143416.D038248C29@hg.openjdk.java.net>

Changeset: 2efa310226f7
Author:    alanb
Date:      2013-08-28 14:07 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2efa310226f7

8023717: (process) ProcessBuilder should catch SecurityException rather than AccessControlException
Reviewed-by: wetmore, alanb
Contributed-by: martinrb at google.com

! src/share/classes/java/lang/ProcessBuilder.java



From brian.burkhalter at oracle.com  Wed Aug 28 14:48:40 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 28 Aug 2013 07:48:40 -0700
Subject: Java 8 RFR 8010430: Math.round has surprising behavior for odd
	values of ulp 1
In-Reply-To: 
References: 
	
	<0099615E-F51D-47C4-9330-582911BBD3EF@oracle.com>
	
	
	
	<1377370934.77781.YahooMailNeo@web171703.mail.ir2.yahoo.com>
	<31920C83-8AEC-443E-94BB-300B2F7B17EE@oracle.com>
	
	
Message-ID: 

On Aug 27, 2013, at 7:44 PM, Dmitry Nadezhin wrote:

> Is it reasonable to make specification clearer ?
> 
> Either to return JLS 1 specification:
> <<<
> The result is rounded to an integer by adding , taking the floor of the result, and casting the result to type long.
> >>>

This verbiage would imply no change to the implementation with the odd ULP unity cases continuing to exhibit the problem described in the issue.

> or to replace "rounding up" with "rounding to positive infinity":
> <<<
> Returns the closest {@code int} to the argument, with ties rounding to positive infinity.
> >>>

This change could accompany the implementation change I posted in the updated webrev.

Thanks,

Brian

From alan.bateman at oracle.com  Wed Aug 28 14:53:08 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 28 Aug 2013 14:53:08 +0000
Subject: hg: jdk8/tl/jdk: 8022594: Potential deadlock in  of
	sun.nio.ch.Util/IOUtil
Message-ID: <20130828145330.265AB48C2B@hg.openjdk.java.net>

Changeset: 378acd4d03c8
Author:    alanb
Date:      2013-08-28 15:50 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/378acd4d03c8

8022594: Potential deadlock in  of sun.nio.ch.Util/IOUtil
Reviewed-by: chegar

! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java
! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java
! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java
! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/share/classes/sun/nio/ch/FileChannelImpl.java
! src/share/classes/sun/nio/ch/IOUtil.java
! src/share/classes/sun/nio/ch/Net.java
! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/share/classes/sun/nio/ch/Util.java
! src/solaris/classes/sun/nio/ch/DatagramDispatcher.java
! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java
! src/solaris/classes/sun/nio/ch/EPoll.java
! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/EPollPort.java
! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java
! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java
! src/solaris/classes/sun/nio/ch/InheritedChannel.java
! src/solaris/classes/sun/nio/ch/KQueue.java
! src/solaris/classes/sun/nio/ch/KQueuePort.java
! src/solaris/classes/sun/nio/ch/NativeThread.java
! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java
! src/solaris/classes/sun/nio/ch/SolarisEventPort.java
! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java
! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java
! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java
! src/windows/classes/sun/nio/ch/DatagramDispatcher.java
! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java
! src/windows/classes/sun/nio/ch/FileKey.java
! src/windows/classes/sun/nio/ch/Iocp.java
! src/windows/classes/sun/nio/ch/PipeImpl.java
! src/windows/classes/sun/nio/ch/SocketDispatcher.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java
! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java



From mike.duigou at oracle.com  Wed Aug 28 15:49:13 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 28 Aug 2013 08:49:13 -0700
Subject: RFR: 7057785 : (xs) Add note to hashCode() that support for self
	referential is optional
In-Reply-To: 
References: <9B998061-4597-4792-BBE1-2A378AC0C6EE@oracle.com>
	
Message-ID: 

Thanks Stephen,

I am fine with your wording. Any other votes or suggested wordings?

Mike

On Aug 28 2013, at 02:55 , Stephen Colebourne wrote:

> I lke the idea, but the wording feels a little opaque as the result is
> typically StackOverflow.
> 
> Also, I prefer a style with the @apiNote on a line of its own, rather
> like a heading. It makes the documentation easier to read in source
> code, and has no effect on the output Javadoc.
> 
> @apiNote
> If the Collection is self-referential, where it directly or indirectly
> contains itself, then the calculation of hashCode may fail with an
> exception. Implementations may optionally try to handle this scenario,
> however most current implementations do not do so.
> 
> Stephen
> 
> On 28 August 2013 03:06, Mike Duigou  wrote:
>> Hello all;
>> 
>> Fairly frequently it is reported that various Collection/Map implementations of hashCode() fail when the instance directly or indirectly contains itself. For a variety of reasons, mostly performance and resource related, most implementations choose not to support calculation of hash codes for self-referential collections. This is not likely to change. So to reduce confusion and "bug" reports I am proposing a non-normative @apiNote be added to Collection and HashMap. The text of the proposed note is:
>> 
>>> Support for calculation of hash code by self referential {Collection|Map}s (they either directly or indirectly contain themselves) is optional. Few Collection implementations support calculation of hash code for self referential instances.
>> 
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-7057785/0/webrev/
>> 
>> Cheers,
>> 
>> Mike



From xueming.shen at oracle.com  Wed Aug 28 16:29:45 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 28 Aug 2013 09:29:45 -0700
Subject: RFR JDK-8023713: ZipFileSystem has compatiable issue to handle
	old zip file.
In-Reply-To: <521DD759.3080708@oracle.com>
References: <521D1D3F.4000003@oracle.com>
	
	<521D3192.2060702@oracle.com> <521DD759.3080708@oracle.com>
Message-ID: <521E2579.5030208@oracle.com>

On 08/28/2013 03:56 AM, Alan Bateman wrote:
> On 28/08/2013 00:09, Xueming Shen wrote:
>> On 08/27/2013 03:07 PM, Martin Buchholz wrote:
>>> It does seem vaguely reasonable to support any extra data.
>>>
>>> Don't you want to also handle arbitrary byte arrays, if e.g. one the 16-bit size fields overflows the extra data?
>>> It looks to me like getExtraLen could return a negative number.
>>>
>>
>> probably I should. The webrev has been updated to simply
>> copy the rest of the extra data, if the "sz" is either < 0 or
>> out of the range.
>>
>> http://cr.openjdk.java.net/~sherman/8023713/webrev/
>>
> The updated webrev looks okay, just odd to see an entry named " TestExtreTime" (which may have been a continuation of a typo in the original test).
>

Thanks Alan! That was indeed a typo:-) fixed in updated webrev.

-Sherman


From xueming.shen at oracle.com  Wed Aug 28 16:43:58 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Wed, 28 Aug 2013 16:43:58 +0000
Subject: hg: jdk8/tl/jdk: 8023713: ZipFileSystem crashes on old zip file
Message-ID: <20130828164438.79F9A6236B@hg.openjdk.java.net>

Changeset: 690b2931baef
Author:    sherman
Date:      2013-08-28 09:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/690b2931baef

8023713: ZipFileSystem crashes on old zip file
Summary: to handle extra data field copy correctly even the extra data does not follow the spec
Reviewed-by: alanb, martin, chegar

! src/share/classes/java/util/zip/ZipOutputStream.java
! test/java/util/zip/TestExtraTime.java



From martinrb at google.com  Wed Aug 28 17:45:19 2013
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 28 Aug 2013 10:45:19 -0700
Subject: RFR JDK-8023713: ZipFileSystem has compatiable issue to handle
	old zip file.
In-Reply-To: <521D3192.2060702@oracle.com>
References: <521D1D3F.4000003@oracle.com>
	
	<521D3192.2060702@oracle.com>
Message-ID: 

get16 can not return negative values, right?
So elide the
sz < 0 below
 666             if (sz < 0 || (off + 4 + sz) > len) {
 667                 break;
 668             }

Otherwise, looks good to me.



On Tue, Aug 27, 2013 at 4:09 PM, Xueming Shen wrote:

> **
> On 08/27/2013 03:07 PM, Martin Buchholz wrote:
>
>  It does seem vaguely reasonable to support any extra data.
>
>  Don't you want to also handle arbitrary byte arrays, if e.g. one the
> 16-bit size fields overflows the extra data?
> It looks to me like getExtraLen could return a negative number.
>
>
> probably I should. The webrev has been updated to simply
> copy the rest of the extra data, if the "sz" is either < 0 or
> out of the range.
>
> http://cr.openjdk.java.net/~sherman/8023713/webrev/
>
>
>
>  And put a SPACE after "if".
>
>
> updated.
>
> Thanks!
> -Sherman
>
>
>
>
> On Tue, Aug 27, 2013 at 2:42 PM, Xueming Shen wrote:
>
>> Hi,
>>
>> Please help review the change for #8023713
>>
>> http://cr.openjdk.java.net/~sherman/8023713/webrev
>>
>> The root cause is that the newly introduced ZOS.writeExtra() (for
>> #8015666) fails to handle "irregular" extra data field. The zip spec
>> requires the the extra data stars with 4 bytes of "tag + size" pair
>> and then followed by the actual "extra data". The "offending" zip
>> file actually has the "irregular" extra data field with 1 single byte
>> as the extra data. That said, the implementation (ZOS) should still
>> be able handle this kind of zip entry correctly and appropriately.
>>
>> The proposed solution is to simply copy the specified extra data
>> into the output stream.
>>
>> Thanks!
>> -Sherman
>>
>
>
>


From dmitry.nadezhin at gmail.com  Wed Aug 28 17:55:09 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Wed, 28 Aug 2013 21:55:09 +0400
Subject: Java 8 RFR 8010430: Math.round has surprising behavior for odd
	values of ulp 1
In-Reply-To: 
References: 
	
	<0099615E-F51D-47C4-9330-582911BBD3EF@oracle.com>
	
	
	
	<1377370934.77781.YahooMailNeo@web171703.mail.ir2.yahoo.com>
	<31920C83-8AEC-443E-94BB-300B2F7B17EE@oracle.com>
	
	
	
Message-ID: 

TLS 1 specification contained verbal statement
"The result is rounded to an integer by adding , taking the floor of the
result, and casting the result to type int".
and Java code
Math.floor(f + 0.5).

It seems to me that the verbal statement says about mathematical "+" .
It maps a pair of reals to there exact sum without rounding.

"+" in Java code is machine adding that is mathematic adding followed by
rounding.

In my opionion this is the source of mismatch.
The verbal TLS 1 statement  is equivalent to
"Returns the closest {@code int} to the argument, with ties rounding to
positive infinity".
The Java code "Math.floor(f + 0.5) is not.

This is just a remark.
I agree that formulation "Returns the closest {@code int} to the argument,
with ties rounding to positive infinity" is clear.


On Wed, Aug 28, 2013 at 6:48 PM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> On Aug 27, 2013, at 7:44 PM, Dmitry Nadezhin wrote:
>
> Is it reasonable to make specification clearer ?
>
> Either to return JLS 1 specification:
> <<<
> The result is rounded to an integer by adding , taking the floor of the
> result, and casting the result to type long.
> >>>
>
>
> This verbiage would imply no change to the implementation with the odd ULP
> unity cases continuing to exhibit the problem described in the issue.
>
> or to replace "rounding up" with "rounding to positive infinity":
> <<<
> Returns the closest {@code int} to the argument, with ties rounding to
> positive infinity.
> >>>
>
>
> This change could accompany the implementation change I posted in the
> updated webrev.
>
> Thanks,
>
> Brian
>


From xueming.shen at oracle.com  Wed Aug 28 17:59:47 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 28 Aug 2013 10:59:47 -0700
Subject: RFR JDK-8023713: ZipFileSystem has compatiable issue to handle
	old zip file.
In-Reply-To: 
References: <521D1D3F.4000003@oracle.com>		<521D3192.2060702@oracle.com>
	
Message-ID: <521E3A93.3020302@oracle.com>

On 08/28/2013 10:45 AM, Martin Buchholz wrote:
> get16 can not return negative values, right?
correct. will remove it in a separate push. thanks!

> So elide the
> sz < 0 below
>  666             if (sz < 0 || (off + 4 + sz) > len) {
>  667                 break;
>  668             }
>
> Otherwise, looks good to me.
>
>
>
> On Tue, Aug 27, 2013 at 4:09 PM, Xueming Shen > wrote:
>
>     On 08/27/2013 03:07 PM, Martin Buchholz wrote:
>>     It does seem vaguely reasonable to support any extra data.
>>
>>     Don't you want to also handle arbitrary byte arrays, if e.g. one the 16-bit size fields overflows the extra data?
>>     It looks to me like getExtraLen could return a negative number.
>>
>
>     probably I should. The webrev has been updated to simply
>     copy the rest of the extra data, if the "sz" is either < 0 or
>     out of the range.
>
>     http://cr.openjdk.java.net/~sherman/8023713/webrev/ 
>
>
>
>>     And put a SPACE after "if".
>
>     updated.
>
>     Thanks!
>     -Sherman
>
>
>>
>>
>>     On Tue, Aug 27, 2013 at 2:42 PM, Xueming Shen > wrote:
>>
>>         Hi,
>>
>>         Please help review the change for #8023713
>>
>>         http://cr.openjdk.java.net/~sherman/8023713/webrev 
>>
>>         The root cause is that the newly introduced ZOS.writeExtra() (for
>>         #8015666) fails to handle "irregular" extra data field. The zip spec
>>         requires the the extra data stars with 4 bytes of "tag + size" pair
>>         and then followed by the actual "extra data". The "offending" zip
>>         file actually has the "irregular" extra data field with 1 single byte
>>         as the extra data. That said, the implementation (ZOS) should still
>>         be able handle this kind of zip entry correctly and appropriately.
>>
>>         The proposed solution is to simply copy the specified extra data
>>         into the output stream.
>>
>>         Thanks!
>>         -Sherman
>>
>>
>
>



From brian.burkhalter at oracle.com  Wed Aug 28 17:58:55 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 28 Aug 2013 10:58:55 -0700
Subject: Java 8 RFR 8010430: Math.round has surprising behavior for odd
	values of ulp 1
In-Reply-To: 
References: 
	
	<0099615E-F51D-47C4-9330-582911BBD3EF@oracle.com>
	
	
	
	<1377370934.77781.YahooMailNeo@web171703.mail.ir2.yahoo.com>
	<31920C83-8AEC-443E-94BB-300B2F7B17EE@oracle.com>
	
	
	
	
Message-ID: 

On Aug 28, 2013, at 10:55 AM, Dmitry Nadezhin wrote:

> TLS 1 specification contained verbal statement
> "The result is rounded to an integer by adding , taking the floor of the result, and casting the result to typeint".
> and Java code
> Math.floor(f + 0.5).
> 
> It seems to me that the verbal statement says about mathematical "+" .
> It maps a pair of reals to there exact sum without rounding.
> 
> "+" in Java code is machine adding that is mathematic adding followed by rounding.
> 
> In my opionion this is the source of mismatch.

Agreed.

> The verbal TLS 1 statement  is equivalent to
> "Returns the closest {@code int} to the argument, with ties rounding to positive infinity".
> The Java code "Math.floor(f + 0.5) is not.
> 
> This is just a remark.
> I agree that formulation "Returns the closest {@code int} to the argument, with ties rounding to positive infinity" is clear.

If others agree, I can update the webrev to use this verbiage. A CCC might be in order as well.

Brian

From henry.jen at oracle.com  Wed Aug 28 17:17:30 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Wed, 28 Aug 2013 17:17:30 +0000
Subject: hg: jdk8/tl/langtools: 8014566: Remove @ignore tags from
	MethodReference66 and InInterface when 8013875 is fixed
Message-ID: <20130828171737.A464F62371@hg.openjdk.java.net>

Changeset: 7de7100c30ce
Author:    henryjen
Date:      2013-08-28 10:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7de7100c30ce

8014566: Remove @ignore tags from MethodReference66 and InInterface when 8013875 is fixed
Reviewed-by: briangoetz, jjg

! test/tools/javac/lambda/MethodReference66.java
! test/tools/javac/lambda/lambdaExecution/InInterface.java



From martinrb at google.com  Wed Aug 28 18:48:55 2013
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 28 Aug 2013 11:48:55 -0700
Subject: RFR: 7057785 : (xs) Add note to hashCode() that support for self
	referential is optional
In-Reply-To: 
References: <9B998061-4597-4792-BBE1-2A378AC0C6EE@oracle.com>
	
	
Message-ID: 

This isn't just about hashCode - I'm not sure why you are singling it out.
 What about toString?  Or really, any recursive ("deep") algorithm.  And
the typical failure mode is inflooping or stack overflow.


On Wed, Aug 28, 2013 at 8:49 AM, Mike Duigou  wrote:

> Thanks Stephen,
>
> I am fine with your wording. Any other votes or suggested wordings?
>
> Mike
>
> On Aug 28 2013, at 02:55 , Stephen Colebourne wrote:
>
> > I lke the idea, but the wording feels a little opaque as the result is
> > typically StackOverflow.
> >
> > Also, I prefer a style with the @apiNote on a line of its own, rather
> > like a heading. It makes the documentation easier to read in source
> > code, and has no effect on the output Javadoc.
> >
> > @apiNote
> > If the Collection is self-referential, where it directly or indirectly
> > contains itself, then the calculation of hashCode may fail with an
> > exception. Implementations may optionally try to handle this scenario,
> > however most current implementations do not do so.
> >
> > Stephen
> >
> > On 28 August 2013 03:06, Mike Duigou  wrote:
> >> Hello all;
> >>
> >> Fairly frequently it is reported that various Collection/Map
> implementations of hashCode() fail when the instance directly or indirectly
> contains itself. For a variety of reasons, mostly performance and resource
> related, most implementations choose not to support calculation of hash
> codes for self-referential collections. This is not likely to change. So to
> reduce confusion and "bug" reports I am proposing a non-normative @apiNote
> be added to Collection and HashMap. The text of the proposed note is:
> >>
> >>> Support for calculation of hash code by self referential
> {Collection|Map}s (they either directly or indirectly contain themselves)
> is optional. Few Collection implementations support calculation of hash
> code for self referential instances.
> >>
> >>
> >> http://cr.openjdk.java.net/~mduigou/JDK-7057785/0/webrev/
> >>
> >> Cheers,
> >>
> >> Mike
>
>


From paul.sandoz at oracle.com  Wed Aug 28 20:13:49 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 28 Aug 2013 20:13:49 +0000
Subject: hg: jdk8/tl/jdk: 8023155: Ensure functional consistency across Random,
	ThreadLocalRandom, SplittableRandom
Message-ID: <20130828201419.3B4096237E@hg.openjdk.java.net>

Changeset: b1f41565b806
Author:    psandoz
Date:      2013-08-28 22:11 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b1f41565b806

8023155: Ensure functional consistency across Random, ThreadLocalRandom, SplittableRandom
Reviewed-by: mduigou
Contributed-by: Doug Lea 
, Paul Sandoz 

! src/share/classes/java/util/Random.java
! src/share/classes/java/util/concurrent/ThreadLocalRandom.java
! test/java/util/Random/RandomStreamTest.java
+ test/java/util/Random/RandomTest.java
! test/java/util/SplittableRandom/SplittableRandomTest.java
+ test/java/util/concurrent/ThreadLocalRandom/ThreadLocalRandomTest.java



From joel.franck at oracle.com  Wed Aug 28 20:26:01 2013
From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Wed, 28 Aug 2013 22:26:01 +0200
Subject: RFR: 5047859 : (reflect) Class.getField can't find String[].length
In-Reply-To: <521C1B47.5050601@oracle.com>
References: <20130826123905.GA26606@jfranck-desktop.jrpg.bea.com>
	<521C1B47.5050601@oracle.com>
Message-ID: <7EDA6A56-9D11-49A0-8E22-45133EBCB0E3@oracle.com>

Hi David,

On Aug 27, 2013, at 5:21 AM, David Holmes  wrote:

> Hi Joel,
> 
> On 26/08/2013 10:39 PM, Joel Borggren-Franck wrote:
>> Hi,
>> 
>> Please review doc fix and test for http://bugs.sun.com/view_bug.do?bug_id=5047859
>> 
>> http://cr.openjdk.java.net/~jfranck/5047859/webrev.00/
>> 
>> This is a spec change to update the spec to match the long-standing implementation.
> 
> Have to wonder why reflection chose to ignore 'length' when the JLS is so clear that it is a field ??
> 

This is way before my time but my guess is that hotspot got this wrong way back when. From my experience with how length was implemented in JRockit it wasn't obvious that it should be reflected as a Field.

> Anyway ... I think the added wording to getField() is okay but:
> 
> 1604      * follows.  Let C be the class or interface represented by this object:
> 
> I don't think it necessary, or desirable to replace 'class' with 'class or interface' here. If you do then you should do it everywhere - which would be bad. Plus does it really mean "class, or interface, or enum, or annotation" ? Sometimes "class" just means the thing a Class represents.

I think it is a reasonable compromise between legalese precision and brevity. The javadoc for Class is already inconsistent, using 'class or interface' in some parts and a sole 'class' in others where 'class or interface' would be more appropriate. I don't think it is realistic to expect a big rewrite of our API doc for consistency, but that shouldn't stop us from improving things locally. There are a few more clarification to the reflective parts of the  Class docs in in the pipe.

Annotation types are interface types and enum types are class types so it rarely makes sense to single them out unless they are a special case. Interface types are not class types.

>> There is also a clarification of getFields() javadoc without changing the
>> spec.
> 
> I don't think this change make sense given it already says it returns a zero-length array for array classes - as Mandy pointed out. I don't think this "clarification" is needed.

Agreed. I plan to revisit this part.

cheers
/Joel

From Alan.Bateman at oracle.com  Wed Aug 28 20:42:00 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 28 Aug 2013 21:42:00 +0100
Subject:  java.util.Locale changes
In-Reply-To: <521DFA57.2060502@oracle.com>
References: <521DC21F.1090309@gmail.com> <521DC36C.2050703@gmail.com>
	<521DFA57.2060502@oracle.com>
Message-ID: <521E6098.9080801@oracle.com>

On 28/08/2013 14:25, Masayoshi Okutsu wrote:
> (adding core-libs-dev)
>
> Hi Christian,
>
> RFC 4647 defines The Language Priority List [1]. The use of 
> java.util.List would be a natural fit, which is the reason why List is 
> used. But use of Iterable does work (as API design). The parameter 
> name `priorityIterable' sounds a bit odd, though.
>
> Does use of Iterable add much value to the API? (Please note that List 
> is also used in Locale.LanguageRange.)
>
It depends on the usages but Iterable would be a bit more flexible. Does 
the locale matcher require to do anything except iterate over the 
elements? The return could be looked at it but it depends on the typical 
usage -- would the user of the API typically just iterate over the 
matched Locales?

-Alan.


From henry.jen at oracle.com  Wed Aug 28 21:10:43 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 28 Aug 2013 14:10:43 -0700
Subject: RFR: 8017513: Support for closeable streams
Message-ID: <521E6753.9020603@oracle.com>

Hi,

Please review the webrev at
http://cr.openjdk.java.net/~henryjen/ccc/8017513/1/webrev/

Based on the feedback/discussion from last time, the EG decided to
weaken AutoCloseable contract(see RFR 8022176[1]), and have Stream
extend AutoCloseable.

A quick briefing of the webrev,
- Remove CloseableStream and DelegatingStream, which was previous used
to implement close of resource
- BaseStream extends AutoCloseable, thus all Stream implementation will
implements close()
- onClose() method allows to chain up close handlers which are invoked
by close()
- Change use of CloseableStream to Stream, mainly java.nio.file.Files
and various tests.

The specdiff is also available at
http://cr.openjdk.java.net/~henryjen/ccc/8017513/1/specdiff/overview-summary.html

Cheers,
Henry

[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/020236.html


From henry.jen at oracle.com  Wed Aug 28 21:15:51 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 28 Aug 2013 14:15:51 -0700
Subject: RFR: 8022176: Weaken contract of java.lang.AutoCloseable
In-Reply-To: <52191A5B.5000201@oracle.com>
References: <5217D59F.80206@oracle.com> <5218709E.6070309@oracle.com>
	<5218B079.8000706@cs.oswego.edu> <52191A5B.5000201@oracle.com>
Message-ID: <521E6887.6080500@oracle.com>

On 08/24/2013 01:40 PM, Alan Bateman wrote:
> On 24/08/2013 14:09, Doug Lea wrote:
>>
>> "resource specification", while accurate, looked confusing here.
>> But we could include both terms, which seems like an improvement.
>> See below.
> This looks better to me, thanks.
> 

Updated webrev as concluded on this email thread, please review at

http://cr.openjdk.java.net/~henryjen/ccc/8022176/1/webrev/

Cheers,
Henry




From xueming.shen at oracle.com  Wed Aug 28 21:28:50 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 28 Aug 2013 14:28:50 -0700
Subject: RFR: JDK-6341345: (spec) Console.reader() should make it clear that
	the reader requires line termination
Message-ID: <521E6B92.4030703@oracle.com>

Alan,

My mailbox suggests that you have already reviewed this one back to the
past May, somehow I dropped the ball some where. Here is the webrev and
CCC again (the change is a trivial spec clarification, which I should have
done 8 years ago).

http://cr.openjdk.java.net/~sherman/6341345
http://ccc.us.oracle.com/6341345

Thanks
-Sherman



From mike.duigou at oracle.com  Wed Aug 28 22:13:33 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 28 Aug 2013 15:13:33 -0700
Subject: RFR: 7057785 : (xs) Add note to hashCode() that support for self
	referential is optional
In-Reply-To: 
References: <9B998061-4597-4792-BBE1-2A378AC0C6EE@oracle.com>
	
	
	
Message-ID: 


On Aug 28 2013, at 11:48 , Martin Buchholz wrote:

> This isn't just about hashCode - I'm not sure why you are singling it out.  What about toString?

A reasonable point. The bug reports are just about as common for toString() being "broken" for self-referential collections.

>  Or really, any recursive ("deep") algorithm.

A class level note then for specific classes? A general warning on the interfaces regarding self-referential being optional?

Mike

>  And the typical failure mode is inflooping or stack overflow. 
> 
> 
> On Wed, Aug 28, 2013 at 8:49 AM, Mike Duigou  wrote:
> Thanks Stephen,
> 
> I am fine with your wording. Any other votes or suggested wordings?
> 
> Mike
> 
> On Aug 28 2013, at 02:55 , Stephen Colebourne wrote:
> 
> > I lke the idea, but the wording feels a little opaque as the result is
> > typically StackOverflow.
> >
> > Also, I prefer a style with the @apiNote on a line of its own, rather
> > like a heading. It makes the documentation easier to read in source
> > code, and has no effect on the output Javadoc.
> >
> > @apiNote
> > If the Collection is self-referential, where it directly or indirectly
> > contains itself, then the calculation of hashCode may fail with an
> > exception. Implementations may optionally try to handle this scenario,
> > however most current implementations do not do so.
> >
> > Stephen
> >
> > On 28 August 2013 03:06, Mike Duigou  wrote:
> >> Hello all;
> >>
> >> Fairly frequently it is reported that various Collection/Map implementations of hashCode() fail when the instance directly or indirectly contains itself. For a variety of reasons, mostly performance and resource related, most implementations choose not to support calculation of hash codes for self-referential collections. This is not likely to change. So to reduce confusion and "bug" reports I am proposing a non-normative @apiNote be added to Collection and HashMap. The text of the proposed note is:
> >>
> >>> Support for calculation of hash code by self referential {Collection|Map}s (they either directly or indirectly contain themselves) is optional. Few Collection implementations support calculation of hash code for self referential instances.
> >>
> >>
> >> http://cr.openjdk.java.net/~mduigou/JDK-7057785/0/webrev/
> >>
> >> Cheers,
> >>
> >> Mike
> 
> 



From dan.xu at oracle.com  Wed Aug 28 22:18:17 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Wed, 28 Aug 2013 15:18:17 -0700
Subject: RFR: JDK-4792059 -- test/java/io/pathNames/GeneralSolaris.java
	fails on symbolic links
In-Reply-To: <521DD96D.7050005@oracle.com>
References: <521D3437.1080003@oracle.com> <521DD96D.7050005@oracle.com>
Message-ID: <521E7729.8050408@oracle.com>

Thank you, Alan.

I have updated my webrev to 
http://cr.openjdk.java.net/~dxu/4792059/webrev.01/.

-Dan


On 08/28/2013 04:05 AM, Alan Bateman wrote:
> On 28/08/2013 00:20, Dan Xu wrote:
>> Hi,
>>
>> When GeneralSolaris testcase follows symbolic link to pick up an 
>> existing file or directory for testing, it will fail the assertion in 
>> check()method because the file path canonicalization process will 
>> result in the real path not a path containing symbolic link. I 
>> enforce this test not to use any symbolic link as a testing file 
>> ordirectory to avoid this problem. Please help review my fix. Thanks!
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-4792059
>> webrev: http://cr.openjdk.java.net/~dxu/4792059/webrev/
>>
>> -Dan
> You can drop the exists check as Files.isXXXX can't return true if the 
> file doesn't exist. Otherwise looks okay to me.
>
> -Alan.



From jonathan.gibbons at oracle.com  Wed Aug 28 22:41:21 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 28 Aug 2013 22:41:21 +0000
Subject: hg: jdk8/tl/langtools: 8010310: [javadoc] Error processing sources
	with -private
Message-ID: <20130828224126.38AC562385@hg.openjdk.java.net>

Changeset: 189942cdf585
Author:    jjg
Date:      2013-08-28 15:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/189942cdf585

8010310: [javadoc] Error processing sources with -private
Reviewed-by: vromero, mcimadamore

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java
+ test/tools/javadoc/nonConstExprs/Test.java



From guy.steele at oracle.com  Wed Aug 28 22:47:27 2013
From: guy.steele at oracle.com (Guy Steele)
Date: Wed, 28 Aug 2013 18:47:27 -0400
Subject: RFR: 7057785 : (xs) Add note to hashCode() that support for self
	referential is optional
In-Reply-To: 
References: <9B998061-4597-4792-BBE1-2A378AC0C6EE@oracle.com>
	
	
	
	
Message-ID: 


On Aug 28, 2013, at 6:13 PM, Mike Duigou  wrote:

> 
> On Aug 28 2013, at 11:48 , Martin Buchholz wrote:
> 
>> This isn't just about hashCode - I'm not sure why you are singling it out.  What about toString?
> 
> A reasonable point. The bug reports are just about as common for toString() being "broken" for self-referential collections.


*ahem* Y'know, Common Lisp had a good solution for printing self-referential structures (by a user-extensible print function) back in 1984.

It leaned on the solution that had been provided in Interlisp in 1974.  On a machine with one megabyte of main memory and a speed of 1 MIPS.

This is not rocket science.




From eliasen at mindspring.com  Wed Aug 28 22:54:51 2013
From: eliasen at mindspring.com (Alan Eliasen)
Date: Wed, 28 Aug 2013 16:54:51 -0600
Subject: RFR: 7057785 : (xs) Add note to hashCode() that support for self
	referential is optional
In-Reply-To: 
References: <9B998061-4597-4792-BBE1-2A378AC0C6EE@oracle.com>
	
	
	
	
	
Message-ID: <521E7FBB.1040106@mindspring.com>

On 08/28/2013 04:47 PM, Guy Steele wrote:
>  *ahem* Y'know, Common Lisp had a good solution for
> printing self-referential structures (by a user-extensible print
> function) back in 1984.
> 
> It leaned on the solution that had been provided in Interlisp in
> 1974.  On a machine with one megabyte of main memory and a speed of 1
> MIPS.
> 
> This is not rocket science. 

   Hehe.  So could you please describe the solution?

-- 
  Alan Eliasen
  eliasen at mindspring.com
  http://futureboy.us/


From mike.duigou at oracle.com  Wed Aug 28 23:23:39 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 28 Aug 2013 16:23:39 -0700
Subject: RFR: 7057785 : (xs) Add note to hashCode() that support for self
	referential is optional
In-Reply-To: <521E7FBB.1040106@mindspring.com>
References: <9B998061-4597-4792-BBE1-2A378AC0C6EE@oracle.com>
	
	
	
	
	
	<521E7FBB.1040106@mindspring.com>
Message-ID: 


On Aug 28 2013, at 15:54 , Alan Eliasen wrote:

> On 08/28/2013 04:47 PM, Guy Steele wrote:
>>  *ahem* Y'know, Common Lisp had a good solution for
>> printing self-referential structures (by a user-extensible print
>> function) back in 1984.
>> 
>> It leaned on the solution that had been provided in Interlisp in
>> 1974.  On a machine with one megabyte of main memory and a speed of 1
>> MIPS.
>> 
>> This is not rocket science. 
> 
>   Hehe.  So could you please describe the solution?

I am unsure what solution was used in Common Lisp (I think I knew once). The most likely solution for Java Collections would be to use a ThreadLocal which potentially recursive methods could check/set on entry and avoid recursing. Explicitly concurrent hostile implementations could use a plain boolean field rather than a ThreadLocal.

So toString() becomes:

public String toString() {
   if(recursed.get()) {
       return "<>"; // self-referential
   }
   
   recursed(true);
   try {
       // ... the normal toString() ...
   } finally {
     recursed.set(true);
   }
}

For performance and footprints reasons the Java Collections chose not to do something like this. Graph preserving operations like serialization will generally use a hash table with objects added by identity as keys to the table before they are traversed. Any objects re-encountered during traversal will be not-retraversed and are replaced in the stream with their identity.

Mike

> 
> -- 
>  Alan Eliasen
>  eliasen at mindspring.com
>  http://futureboy.us/



From dan.xu at oracle.com  Wed Aug 28 23:49:36 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Wed, 28 Aug 2013 16:49:36 -0700
Subject: RFR: JDK-8023765 -- Improve MaxPathLength.java testcase and reduce
	its test load
In-Reply-To: <521CB46C.5060307@oracle.com>
References: <521BF05A.1090805@oracle.com> <521C5173.4070701@oracle.com>
	<521CB46C.5060307@oracle.com>
Message-ID: <521E8C90.1090504@oracle.com>


On 08/27/2013 07:15 AM, Dan Xu wrote:
> On 08/27/2013 12:12 AM, Alan Bateman wrote:
>> On 27/08/2013 01:18, Dan Xu wrote:
>>> Hi All,
>>>
>>> MaxPathLength.javais a troublesome testcase, and fails 
>>> intermittently in the nightly test. And it also runs for a long 
>>> time, especially on Windows platforms. Inorder to improve the test 
>>> stability, I remove its unnecessary test iterations, and use 
>>> NIOdelete method todo the clean-up to make the potential 
>>> failureseasier for diagnosis. Please review thechanges. Thanks!
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023765
>>> webrev: http://cr.openjdk.java.net/~dxu/8023765/webrev/
>>>
>>> -Dan
>> The double to quickly skip over the names to MAX_LENGTH/2 looks 
>> reasonable.
>>
>> I guess fileCreated should really be fileExists as it may be deleted 
>> and then deleted. An alternative here would be to use 
>> Files.deleteIfExists as that would avoid the need to introduce flags 
>> to track whether the directory and exist exists.
>>
>> -Alan
> Hi Alan,
>
> Those flag names are a little misleading. Sorry about that.
>
> fileCreated and dirCreated are actually tracking the existence of new 
> file and directories. If the new file gets deleted, I marked the flag 
> to false in the code. And at the end, I also change the recorded file 
> path after the rename operation.
>
> I agree that using deleteIfExists is a good alternative. In my 
> original thought, I plan to monitor every step and make sure all file 
> operations happen as expected. Thanks!
>
> -Dan

Stuart brought a very good point for this test failure in the main bug, 
JDK-7160013. According to his comment, "Bottom line is that a Windows 
daemon (not an anti-virus scanner) may hold a file in delete-pending 
state for a short amount of time after it's been deleted. While it's in 
this state, if you ask if the file exists, the system will say that it 
does not. However, if you try to create a new file with the same name, 
you get an access denied error."

And I re-checked remarks in the Windows APIs used for deleting file in 
[1] and directory in [2]. According to the spec, these APIs only mark a 
file/directory for deletion on close. And the delete operation does not 
occur until the last handle to it is closed. Therefore, if a Windows 
daemon opens a handle towards those newly-created directories (I think 
anti-virus on-access scanner may do a similar thing), the delete 
operation will be put in delete-pending state, and the next immediate 
call to create the same directory structure will fail.

Based on the above information, I updated this testcase to make it 
create different directory structure in each loop, so that the 
next-create operation will not conflict with previous pending delete 
operation. I also follow Alan's suggestion to use Files.deleteIfExists 
in the latest change. Please review it at 
http://cr.openjdk.java.net/~dxu/8023765/webrev.01/. Thanks!

-Dan


[1] 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363915%28v=vs.85%29.aspx
[2] 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365488%28v=vs.85%29.aspx


From joe.darcy at oracle.com  Thu Aug 29 01:48:18 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Wed, 28 Aug 2013 18:48:18 -0700
Subject: Java 8 RFR 8010430: Math.round has surprising behavior for odd
	values of ulp 1
In-Reply-To: <8A126477-C00A-4833-962D-BA1DE1BA0930@oracle.com>
References: 
	
	<8A126477-C00A-4833-962D-BA1DE1BA0930@oracle.com>
Message-ID: <521EA862.9060008@oracle.com>

Hello,

On 8/23/2013 1:36 PM, Guy Steele wrote:
> The specification of java.lang.Math.round in the first edition of the
> Java Language Specification is quite clear:
>
> public static int round(float a)
>    The result is rounded to an integer by adding 1/2, taking the floor of
>    the result, and casting the result to type int.
>    In other words, the result is equal to the value of the expression
> 	(int)Math.floor(a + 0.5f)
>
> and a similar statement for the case where the type of the argument is double.
>
> This does not correspond to "rounding away from zero" as in IEEE754.
>
> The phrase "ties rounding up" entered the Java documentation later on
> as a (perhaps unfortunately worded) shorthand for the original specification.

To give some context, the original specification was changed in JDK 7 
under bug

     JDK-6430675 Math.round has surprising behavior for 0x1.fffffffffffffp-2
     http://bugs.sun.com/view_bug.do?bug_id=6430675

At the time, it was making the rounds that Math.round gave a "wrong" 
answer for an input value equal to the largest floating-point value less 
than 0.5: Math.round(0.49999999999999994) returned 1 rather than 0. The 
result is wrong in terms of being unexpected; it was the result mandated 
by the operational definition of the specification.

I addressed JDK-6430675 by changing the implementation and removing the 
operational definition of Math.round. While I thought I had ruled out 
unexpected round-off behavior at the other end of the range, mea culpa, 
I did not account for the issues reported in 8010430.

-Joe

>
> --Guy Steele
>
>
> On Aug 23, 2013, at 4:24 PM, Dmitry Nadezhin  wrote:
>
>> The specification of java.lang.Math.round() says
>>     * Returns the closest {@code int} to the argument, with ties
>>      * rounding up.
>>
>> It is not clarified what is "ties rounding up".
>> I guess that it should correspond to the direction "roundTiesToAway" of
>> IEEE 754-2008
>> and to the java.math.RoundingMode.HALF_UP .
>>
>> They round
>> +0.5 -> +1
>> -0.5 -> -1
>>
>> The current implementation of java.lang.Math.round() rounds
>> +0.5 -> +1
>> -0.5 -> 0
>>
>> "ties rounding up" should match IEEE754 standard and other JDK math class,
>> shouldn't it ?
>>
>>
>> On Fri, Aug 23, 2013 at 10:32 PM, Brian Burkhalter <
>> brian.burkhalter at oracle.com> wrote:
>>
>>> This message follows the RFC
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019560.htmlposted on August 2.
>>>
>>> The issue is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010430.
>>>
>>> The proposed patch http://cr.openjdk.java.net/~bpb/8010430/ has the
>>> effect of option (A) in the aforementioned RFC.
>>>
>>> Thanks,
>>>
>>> Brian



From mandy.chung at oracle.com  Thu Aug 29 01:54:25 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 28 Aug 2013 18:54:25 -0700
Subject: RFR: 5047859 : (reflect) Class.getField can't find String[].length
In-Reply-To: <20130828133934.GG4531@jfranck-desktop.jrpg.bea.com>
References: <20130826123905.GA26606@jfranck-desktop.jrpg.bea.com>
	<521B8FCB.2060600@oracle.com>
	<20130828133934.GG4531@jfranck-desktop.jrpg.bea.com>
Message-ID: <521EA9D1.5060608@oracle.com>


On 8/28/2013 6:39 AM, Joel Borggr?n-Franck wrote:
> Hi Mandy,
>
> Thanks for your comments,
>
> On 2013-08-26, Mandy Chung wrote:
>> Joel,
>>
>> The spec of the getFields and getDeclaredFields() methods both states this:
>>
>>    This method returns an array of length 0 if the class
>>    or interface declares no fields, or if this|Class|  object
>>    represents a primitive type, an array class, or void.
>>
>> The spec of the getDeclaredField() method has this sentence:
>>
>>    Note that this method will not reflect the {@code length}
>>    field of an array class.
>>
>> Your change is okay and it would be good to keep the getField(s)
>> and getDeclaredField(s) methods be consistent and states its
>> return value "if this|Class|  object represents a primitive type,
>> an array class, or void"
> I agree the javadoc for the 4 methods should be more uniform. The note
> in getDeclaredFields() isn't that good IMHO as for example the term
> 'array class' in not used in JLS.
>
> I'll be back shortly with an updated webrev.
>

You may also want to check out getConstructor(s) and 
getDeclaredConstructor(s) that seem to have similar inconsistency issue.

Mandy


From guy.steele at oracle.com  Thu Aug 29 02:03:36 2013
From: guy.steele at oracle.com (Guy Steele)
Date: Wed, 28 Aug 2013 22:03:36 -0400
Subject: Java 8 RFR 8010430: Math.round has surprising behavior for odd
	values of ulp 1
In-Reply-To: <521EA862.9060008@oracle.com>
References: 
	
	<8A126477-C00A-4833-962D-BA1DE1BA0930@oracle.com>
	<521EA862.9060008@oracle.com>
Message-ID: 

Thanks for this context, Joe.  And, truth be told, the fact there was a discrepancy
between the textual and code descriptions of the operation may well have been
my error.  (I don't have a clear memory either way, but it's the sort of text
I would have worked on rather than Bill.)

In any case, I think everyone is now agreed on "the right thing" for going forward.

--Guy

On Aug 28, 2013, at 9:48 PM, Joseph Darcy  wrote:

> Hello,
> 
> On 8/23/2013 1:36 PM, Guy Steele wrote:
>> The specification of java.lang.Math.round in the first edition of the
>> Java Language Specification is quite clear:
>> 
>> public static int round(float a)
>>   The result is rounded to an integer by adding 1/2, taking the floor of
>>   the result, and casting the result to type int.
>>   In other words, the result is equal to the value of the expression
>> 	(int)Math.floor(a + 0.5f)
>> 
>> and a similar statement for the case where the type of the argument is double.
>> 
>> This does not correspond to "rounding away from zero" as in IEEE754.
>> 
>> The phrase "ties rounding up" entered the Java documentation later on
>> as a (perhaps unfortunately worded) shorthand for the original specification.
> 
> To give some context, the original specification was changed in JDK 7 under bug
> 
>    JDK-6430675 Math.round has surprising behavior for 0x1.fffffffffffffp-2
>    http://bugs.sun.com/view_bug.do?bug_id=6430675
> 
> At the time, it was making the rounds that Math.round gave a "wrong" answer for an input value equal to the largest floating-point value less than 0.5: Math.round(0.49999999999999994) returned 1 rather than 0. The result is wrong in terms of being unexpected; it was the result mandated by the operational definition of the specification.
> 
> I addressed JDK-6430675 by changing the implementation and removing the operational definition of Math.round. While I thought I had ruled out unexpected round-off behavior at the other end of the range, mea culpa, I did not account for the issues reported in 8010430.
> 
> -Joe
> 
>> 
>> --Guy Steele
>> 
>> 
>> On Aug 23, 2013, at 4:24 PM, Dmitry Nadezhin  wrote:
>> 
>>> The specification of java.lang.Math.round() says
>>>    * Returns the closest {@code int} to the argument, with ties
>>>     * rounding up.
>>> 
>>> It is not clarified what is "ties rounding up".
>>> I guess that it should correspond to the direction "roundTiesToAway" of
>>> IEEE 754-2008
>>> and to the java.math.RoundingMode.HALF_UP .
>>> 
>>> They round
>>> +0.5 -> +1
>>> -0.5 -> -1
>>> 
>>> The current implementation of java.lang.Math.round() rounds
>>> +0.5 -> +1
>>> -0.5 -> 0
>>> 
>>> "ties rounding up" should match IEEE754 standard and other JDK math class,
>>> shouldn't it ?
>>> 
>>> 
>>> On Fri, Aug 23, 2013 at 10:32 PM, Brian Burkhalter <
>>> brian.burkhalter at oracle.com> wrote:
>>> 
>>>> This message follows the RFC
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019560.htmlposted on August 2.
>>>> 
>>>> The issue is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010430.
>>>> 
>>>> The proposed patch http://cr.openjdk.java.net/~bpb/8010430/ has the
>>>> effect of option (A) in the aforementioned RFC.
>>>> 
>>>> Thanks,
>>>> 
>>>> Brian
> 



From guy.steele at oracle.com  Thu Aug 29 02:10:29 2013
From: guy.steele at oracle.com (Guy Steele)
Date: Wed, 28 Aug 2013 22:10:29 -0400
Subject: RFR: 7057785 : (xs) Add note to hashCode() that support for self
	referential is optional
In-Reply-To: <521E7FBB.1040106@mindspring.com>
References: <9B998061-4597-4792-BBE1-2A378AC0C6EE@oracle.com>
	
	
	
	
	
	<521E7FBB.1040106@mindspring.com>
Message-ID: 

What Mike said.  It's basically the same problem as for serialization,
so you keep a hashtable of all objects traversed---but you need not record
objects that have no subobjects and have "simple" or "short" printed representations
(such as numbers and maybe short strings).

In full generality it requires two traversals.  Then as you format each object
on the second traversal, objects encountered more than once can be given
labels on first occurrence and references on later occurrences.  Common Lisp
uses "#nnn=" for labels and "#nnn# for references, for integers nnn, so a list
containing three occurrences of the same sublist as well as two self-references
and the symbol BAZ might print in this way:

  #1=(#1# #2=(a b c) #2# #1# BAZ #2#)

Common Lisp has a global (dynamically scoped) variable *print-circle* that
controls whether to use the circularity-detection algorithm.

--Guy

On Aug 28, 2013, at 6:54 PM, Alan Eliasen  wrote:

> On 08/28/2013 04:47 PM, Guy Steele wrote:
>>  *ahem* Y'know, Common Lisp had a good solution for
>> printing self-referential structures (by a user-extensible print
>> function) back in 1984.
>> 
>> It leaned on the solution that had been provided in Interlisp in
>> 1974.  On a machine with one megabyte of main memory and a speed of 1
>> MIPS.
>> 
>> This is not rocket science. 
> 
>   Hehe.  So could you please describe the solution?
> 
> -- 
>  Alan Eliasen
>  eliasen at mindspring.com
>  http://futureboy.us/



From brian.burkhalter at oracle.com  Thu Aug 29 02:54:59 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 28 Aug 2013 19:54:59 -0700
Subject: Java 8 RFR 8010430: Math.round has surprising behavior for odd
	values of ulp 1
In-Reply-To: 
References: 
	
	<8A126477-C00A-4833-962D-BA1DE1BA0930@oracle.com>
	<521EA862.9060008@oracle.com>
	
Message-ID: 

I will update the javadoc in the webrev and repost tomorrow.

Brian

On Aug 28, 2013, at 7:03 PM, Guy Steele wrote:

> In any case, I think everyone is now agreed on "the right thing" for going forward.



From david.holmes at oracle.com  Thu Aug 29 05:18:35 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 29 Aug 2013 15:18:35 +1000
Subject: RFR: 5047859 : (reflect) Class.getField can't find String[].length
In-Reply-To: <7EDA6A56-9D11-49A0-8E22-45133EBCB0E3@oracle.com>
References: <20130826123905.GA26606@jfranck-desktop.jrpg.bea.com>
	<521C1B47.5050601@oracle.com>
	<7EDA6A56-9D11-49A0-8E22-45133EBCB0E3@oracle.com>
Message-ID: <521ED9AB.1020309@oracle.com>

On 29/08/2013 6:26 AM, Joel Borggr?n-Franck wrote:
> Hi David,
>
> On Aug 27, 2013, at 5:21 AM, David Holmes  wrote:
>
>> Hi Joel,
>>
>> On 26/08/2013 10:39 PM, Joel Borggren-Franck wrote:
>>> Hi,
>>>
>>> Please review doc fix and test for http://bugs.sun.com/view_bug.do?bug_id=5047859
>>>
>>> http://cr.openjdk.java.net/~jfranck/5047859/webrev.00/
>>>
>>> This is a spec change to update the spec to match the long-standing implementation.
>>
>> Have to wonder why reflection chose to ignore 'length' when the JLS is so clear that it is a field ??
>>
>
> This is way before my time but my guess is that hotspot got this wrong way back when. From my experience with how length was implemented in JRockit it wasn't obvious that it should be reflected as a Field.
>
>> Anyway ... I think the added wording to getField() is okay but:
>>
>> 1604      * follows.  Let C be the class or interface represented by this object:
>>
>> I don't think it necessary, or desirable to replace 'class' with 'class or interface' here. If you do then you should do it everywhere - which would be bad. Plus does it really mean "class, or interface, or enum, or annotation" ? Sometimes "class" just means the thing a Class represents.
>
> I think it is a reasonable compromise between legalese precision and brevity. The javadoc for Class is already inconsistent, using 'class or interface' in some parts and a sole 'class' in others where 'class or interface' would be more appropriate. I don't think it is realistic to expect a big rewrite of our API doc for consistency, but that shouldn't stop us from improving things locally. There are a few more clarification to the reflective parts of the  Class docs in in the pipe.

Even locally there are other uses of "class" which really mean "class or 
interface" (or maybe even Class object?)-

1623      * @return the {@code Field} object of this class specified by

1631      *         ancestor of the class loader for the current class and

1634      *         of this class.

But changing these would not improve clarity at all IMHO. Using "class" 
to mean "class or interface" is extremely common. Once the method specs, 
as in this case, have stated that the method applies to "class or 
interface" then I think it is perfectly fine to simply say "class" 
thereafter unless you really need to distinguish between classes and 
interfaces.

Cheers,
David
------


> Annotation types are interface types and enum types are class types so it rarely makes sense to single them out unless they are a special case. Interface types are not class types.
>
>>> There is also a clarification of getFields() javadoc without changing the
>>> spec.
>>
>> I don't think this change make sense given it already says it returns a zero-length array for array classes - as Mandy pointed out. I don't think this "clarification" is needed.
>
> Agreed. I plan to revisit this part.
>
> cheers
> /Joel
>


From Alan.Bateman at oracle.com  Thu Aug 29 06:42:01 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 29 Aug 2013 07:42:01 +0100
Subject: RFR: JDK-4792059 -- test/java/io/pathNames/GeneralSolaris.java
	fails on symbolic links
In-Reply-To: <521E7729.8050408@oracle.com>
References: <521D3437.1080003@oracle.com> <521DD96D.7050005@oracle.com>
	<521E7729.8050408@oracle.com>
Message-ID: <521EED39.8070601@oracle.com>

On 28/08/2013 23:18, Dan Xu wrote:
> Thank you, Alan.
>
> I have updated my webrev to 
> http://cr.openjdk.java.net/~dxu/4792059/webrev.01/.
>
> -Dan
Looks fine.

-Alan


From Alan.Bateman at oracle.com  Thu Aug 29 06:58:01 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 29 Aug 2013 07:58:01 +0100
Subject: RFR: 8017513: Support for closeable streams
In-Reply-To: <521E6753.9020603@oracle.com>
References: <521E6753.9020603@oracle.com>
Message-ID: <521EF0F9.3000008@oracle.com>

On 28/08/2013 22:10, Henry Jen wrote:
> Hi,
>
> Please review the webrev at
> http://cr.openjdk.java.net/~henryjen/ccc/8017513/1/webrev/
>
> Based on the feedback/discussion from last time, the EG decided to
> weaken AutoCloseable contract(see RFR 8022176[1]), and have Stream
> extend AutoCloseable.
>
> A quick briefing of the webrev,
> - Remove CloseableStream and DelegatingStream, which was previous used
> to implement close of resource
> - BaseStream extends AutoCloseable, thus all Stream implementation will
> implements close()
> - onClose() method allows to chain up close handlers which are invoked
> by close()
> - Change use of CloseableStream to Stream, mainly java.nio.file.Files
> and various tests.
>
> The specdiff is also available at
> http://cr.openjdk.java.net/~henryjen/ccc/8017513/1/specdiff/overview-summary.html
>
> Cheers,
> Henry
>
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/020236.html
>
In Files then you've expanded the wildcard on the imports but left 
java.nio.file.attribute.*; (this seems a long list, I think one or two 
may be javadoc references only).

I think I mentioned this previously but in the Files.list/walk/etc. 
methods where you close the resource (on error|runtimeexception) then 
it's probably best to catch the IOException and add it as a suppressed 
exception.

Minor nits in Files but all the 
 usages after a space before the 
wording. Also can you combine L123-124 on the same line so that the 
formatting is locally consistent.

StreamCloseTest.java has the GPL+CP copyright, I assume you'll replace 
that before pushing.

Otherwise looks good to me.

-Alan.



From Alan.Bateman at oracle.com  Thu Aug 29 07:03:33 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 29 Aug 2013 08:03:33 +0100
Subject: RFR: JDK-6341345: (spec) Console.reader() should make it clear
	that the reader requires line termination
In-Reply-To: <521E6B92.4030703@oracle.com>
References: <521E6B92.4030703@oracle.com>
Message-ID: <521EF245.2040800@oracle.com>

On 28/08/2013 22:28, Xueming Shen wrote:
> Alan,
>
> My mailbox suggests that you have already reviewed this one back to the
> past May, somehow I dropped the ball some where. Here is the webrev and
> CCC again (the change is a trivial spec clarification, which I should 
> have
> done 8 years ago).
>
> http://cr.openjdk.java.net/~sherman/6341345
The wording looks okay, maybe it should be "read methods" as Reader 
defines more than on read method. You should probably use {@code ...} 
around both Reader and read too.

-Alan


From Alan.Bateman at oracle.com  Thu Aug 29 07:20:53 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 29 Aug 2013 08:20:53 +0100
Subject: RFR: JDK-8023765 -- Improve MaxPathLength.java testcase and reduce
	its test load
In-Reply-To: <521E8C90.1090504@oracle.com>
References: <521BF05A.1090805@oracle.com> <521C5173.4070701@oracle.com>
	<521CB46C.5060307@oracle.com> <521E8C90.1090504@oracle.com>
Message-ID: <521EF655.7070605@oracle.com>

On 29/08/2013 00:49, Dan Xu wrote:
> :
>
> Stuart brought a very good point for this test failure in the main 
> bug, JDK-7160013. According to his comment, "Bottom line is that a 
> Windows daemon (not an anti-virus scanner) may hold a file in 
> delete-pending state for a short amount of time after it's been 
> deleted. While it's in this state, if you ask if the file exists, the 
> system will say that it does not. However, if you try to create a new 
> file with the same name, you get an access denied error."
>
> And I re-checked remarks in the Windows APIs used for deleting file in 
> [1] and directory in [2]. According to the spec, these APIs only mark 
> a file/directory for deletion on close. And the delete operation does 
> not occur until the last handle to it is closed. Therefore, if a 
> Windows daemon opens a handle towards those newly-created directories 
> (I think anti-virus on-access scanner may do a similar thing), the 
> delete operation will be put in delete-pending state, and the next 
> immediate call to create the same directory structure will fail.
>
> Based on the above information, I updated this testcase to make it 
> create different directory structure in each loop, so that the 
> next-create operation will not conflict with previous pending delete 
> operation. I also follow Alan's suggestion to use Files.deleteIfExists 
> in the latest change. Please review it at 
> http://cr.openjdk.java.net/~dxu/8023765/webrev.01/. Thanks!
If we want stable and fast test execution on Windows machines then I 
think we have to remove these sources of interference. In my view this 
means disabling the services that snoop on your usage so that they 
aren't opening files that are trying to move or remove. It also means 
configuring the AV software to exclude some area of the file system that 
we can use as the test work tree.

Anyway, the patch looks okay, it's just the new comment on L60 might be 
a bit mis-leading.

-Alan.


From masayoshi.okutsu at oracle.com  Thu Aug 29 08:24:06 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 29 Aug 2013 17:24:06 +0900
Subject:  java.util.Locale changes
In-Reply-To: <521E6098.9080801@oracle.com>
References: <521DC21F.1090309@gmail.com> <521DC36C.2050703@gmail.com>
	<521DFA57.2060502@oracle.com> <521E6098.9080801@oracle.com>
Message-ID: <521F0526.7020904@oracle.com>

I took a look at the implementation. The matcher code just iterates the 
given priority list. isEmpty() is used, but it shouldn't be a problem. 
As far as an Iterable gives an Iterator which consistently iterates 
elements based on the priority or weight, the Iterable works.

Use of Iterable does give more flexibility, but I'm not sure how much it 
would add value to the API use. You can implement your own Iterable, but 
would many developers implement an Iterable to give a language priority 
list?

Masayoshi

On 2013/08/29 5:42, Alan Bateman wrote:
> On 28/08/2013 14:25, Masayoshi Okutsu wrote:
>> (adding core-libs-dev)
>>
>> Hi Christian,
>>
>> RFC 4647 defines The Language Priority List [1]. The use of 
>> java.util.List would be a natural fit, which is the reason why List 
>> is used. But use of Iterable does work (as API design). The parameter 
>> name `priorityIterable' sounds a bit odd, though.
>>
>> Does use of Iterable add much value to the API? (Please note that 
>> List is also used in Locale.LanguageRange.)
>>
> It depends on the usages but Iterable would be a bit more flexible. 
> Does the locale matcher require to do anything except iterate over the 
> elements? The return could be looked at it but it depends on the 
> typical usage -- would the user of the API typically just iterate over 
> the matched Locales?
>
> -Alan.



From paul.sandoz at oracle.com  Thu Aug 29 08:31:31 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 29 Aug 2013 10:31:31 +0200
Subject: RFR: 8022176: Weaken contract of java.lang.AutoCloseable
In-Reply-To: <521E6887.6080500@oracle.com>
References: <5217D59F.80206@oracle.com> <5218709E.6070309@oracle.com>
	<5218B079.8000706@cs.oswego.edu> <52191A5B.5000201@oracle.com>
	<521E6887.6080500@oracle.com>
Message-ID: <5000A61C-151A-41C6-8EDA-4C3CB5BEB83B@oracle.com>


On Aug 28, 2013, at 11:15 PM, Henry Jen  wrote:

> On 08/24/2013 01:40 PM, Alan Bateman wrote:
>> On 24/08/2013 14:09, Doug Lea wrote:
>>> 
>>> "resource specification", while accurate, looked confusing here.
>>> But we could include both terms, which seems like an improvement.
>>> See below.
>> This looks better to me, thanks.
>> 
> 
> Updated webrev as concluded on this email thread, please review at
> 
> http://cr.openjdk.java.net/~henryjen/ccc/8022176/1/webrev/
> 

Looks good.

Paul.

From paul.sandoz at oracle.com  Thu Aug 29 08:51:47 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 29 Aug 2013 10:51:47 +0200
Subject: RFR: 8017513: Support for closeable streams
In-Reply-To: <521EF0F9.3000008@oracle.com>
References: <521E6753.9020603@oracle.com> <521EF0F9.3000008@oracle.com>
Message-ID: 


On Aug 29, 2013, at 8:58 AM, Alan Bateman  wrote:

> On 28/08/2013 22:10, Henry Jen wrote:
>> Hi,
>> 
>> Please review the webrev at
>> http://cr.openjdk.java.net/~henryjen/ccc/8017513/1/webrev/
>> 
>> Based on the feedback/discussion from last time, the EG decided to
>> weaken AutoCloseable contract(see RFR 8022176[1]), and have Stream
>> extend AutoCloseable.
>> 
>> A quick briefing of the webrev,
>> - Remove CloseableStream and DelegatingStream, which was previous used
>> to implement close of resource
>> - BaseStream extends AutoCloseable, thus all Stream implementation will
>> implements close()
>> - onClose() method allows to chain up close handlers which are invoked
>> by close()
>> - Change use of CloseableStream to Stream, mainly java.nio.file.Files
>> and various tests.
>> 
>> The specdiff is also available at
>> http://cr.openjdk.java.net/~henryjen/ccc/8017513/1/specdiff/overview-summary.html
>> 
>> Cheers,
>> Henry
>> 
>> [1]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/020236.html
>> 
> In Files then you've expanded the wildcard on the imports but left java.nio.file.attribute.*; (this seems a long list, I think one or two may be javadoc references only).
> 
> I think I mentioned this previously but in the Files.list/walk/etc. methods where you close the resource (on error|runtimeexception) then it's probably best to catch the IOException and add it as a suppressed exception.
> 

Can TWR be used?

try (DirectoryStream ds = Files.newDirectoryStream(dir) {
    ...
}

Paul.

From Alan.Bateman at oracle.com  Thu Aug 29 09:15:00 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 29 Aug 2013 10:15:00 +0100
Subject: RFR: 8017513: Support for closeable streams
In-Reply-To: 
References: <521E6753.9020603@oracle.com> <521EF0F9.3000008@oracle.com>
	
Message-ID: <521F1114.3070703@oracle.com>

On 29/08/2013 09:51, Paul Sandoz wrote:
> On Aug 29, 2013, at 8:58 AM, Alan Bateman  wrote:
>
>> :
>>
>> I think I mentioned this previously but in the Files.list/walk/etc. methods where you close the resource (on error|runtimeexception) then it's probably best to catch the IOException and add it as a suppressed exception.
>>
> Can TWR be used?
>
> try (DirectoryStream  ds = Files.newDirectoryStream(dir) {
>      ...
> }
>
It should be only closed for the error/exception case (as the Stream 
will keep the directory open).

Henry - Paul's comment reminds of that "one or more" doesn't need to the 
javadoc for Files.lines as it only opens one directory.

-Alan.


From staffan.larsen at oracle.com  Thu Aug 29 09:26:05 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Thu, 29 Aug 2013 09:26:05 +0000
Subject: hg: jdk8/tl/jdk: 8023786: (jdk) setjmp/longjmp changes the process
	signal mask on OS X
Message-ID: <20130829093110.91F276239C@hg.openjdk.java.net>

Changeset: 779ff9f3b2e3
Author:    sla
Date:      2013-08-29 11:22 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/779ff9f3b2e3

8023786: (jdk) setjmp/longjmp changes the process signal mask on OS X
Reviewed-by: dholmes

! src/share/back/SDE.c
! src/share/native/common/check_code.c



From paul.sandoz at oracle.com  Thu Aug 29 10:00:27 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 29 Aug 2013 12:00:27 +0200
Subject: Java 8 RFC 7189139: BigInteger's staticRandom field can be a
	source of bottlenecks
In-Reply-To: <7AC9117C-0AF1-485C-AC69-590029494298@oracle.com>
References: <050BDF31-D4C5-447D-A445-38E662A925E4@oracle.com>
	<521B47C6.9010407@oracle.com>
	<7AC9117C-0AF1-485C-AC69-590029494298@oracle.com>
Message-ID: 

On Aug 26, 2013, at 3:15 PM, Paul Sandoz  wrote:
>> As discussed in the relevant threads in the original bug report, the
>> actual fix should be a very accurate replacement of SR with some other
>> faster and reliable RNG to avoid the inherent scalability bottlenecks.
>> 
> 
> I don't know about the PRNG requirements for Miller-Rabin but the changes to TLR in review might be a possible substitute for SR in this case, since TLR will be updated to use the same PRNG algorithm as SplittableRandom, which passes DieHarder tests.  Otherwise, i think we may just be stuck with SR.
> 

FYI the updates to ThreadLocalRandom are now in tl, so it is possible to more easily investigate whether this can substitute SecureRandom.



IIUC the Miller-Rabin algorithm seems almost embarrassingly parallel.

One could write a Spliterator in combination with SplittableRandom to generate an appropriate source of BigInteger instances hooked up to a stream:

  Stream s = BigInteger.randomStream(pp.bitLength(), n);
  return s.filter(b -> b.compareTo(ONE) > 0 && b.compareTo(pp) < 0).map(b -> test(b, pp)).allMatch(r -> r == true);

I suppose in some respects it is unfortunate to have to write a Spliterator instead of piggybacking off IntStream.range(0, n) and associating with functions to create a SplittableRandom and split based on how the range is split.

Another way could be to write a Spliterator for a source of depth and SplittablleRandom, then hook that up to flatMap:

  Stream> s = ...;  
  return s.flatMap((d, sr) -> bigInts(sr, pp.bitLength(), n / (1 << d)).map(b -> test(b, pp)).allMatch(r -> r == true);



Paul.

From paul.sandoz at oracle.com  Thu Aug 29 10:04:56 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 29 Aug 2013 12:04:56 +0200
Subject: RFR: 8017513: Support for closeable streams
In-Reply-To: <521F1114.3070703@oracle.com>
References: <521E6753.9020603@oracle.com> <521EF0F9.3000008@oracle.com>
	
	<521F1114.3070703@oracle.com>
Message-ID: <857B1BAE-0559-4122-9FDA-838969ED8106@oracle.com>


On Aug 29, 2013, at 11:15 AM, Alan Bateman  wrote:

> On 29/08/2013 09:51, Paul Sandoz wrote:
>> On Aug 29, 2013, at 8:58 AM, Alan Bateman  wrote:
>> 
>>> :
>>> 
>>> I think I mentioned this previously but in the Files.list/walk/etc. methods where you close the resource (on error|runtimeexception) then it's probably best to catch the IOException and add it as a suppressed exception.
>>> 
>> Can TWR be used?
>> 
>> try (DirectoryStream  ds = Files.newDirectoryStream(dir) {
>>     ...
>> }
>> 
> It should be only closed for the error/exception case (as the Stream will keep the directory open).
> 

Doh, i need some coffee...

Paul.


> Henry - Paul's comment reminds of that "one or more" doesn't need to the javadoc for Files.lines as it only opens one directory.
> 
> -Alan.


From daniel.fuchs at oracle.com  Thu Aug 29 10:42:26 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 29 Aug 2013 12:42:26 +0200
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety issues
Message-ID: <521F2592.4060604@oracle.com>

Hi,

This is a fix for an old bug which rightfully remarks that
whereas access to 'level' in handler is synchronized,
access to other mutable fields - like 'filter' etc...
is not - which is inconsistent.



I have tried to keep the fix simple - simply adding
synchronized to method declarations when it was clear that
there was an inconsistency.

I also looked at the subclasses of j.u.l.Handler

In some places I resorted to using a synchronized block to avoid
calling overridable / external method from within the lock.

The changed methods are simple accessors, and subclasses of
Handler are already full of synchronized methods (e.g.
methods like publish(...) are already synchronized)
so the risk of fixing these simple accessors should be limited.

best regards,

-- daniel


From david.holmes at oracle.com  Thu Aug 29 11:33:07 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 29 Aug 2013 21:33:07 +1000
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: <521F2592.4060604@oracle.com>
References: <521F2592.4060604@oracle.com>
Message-ID: <521F3173.1050801@oracle.com>

Hi Daniel,

On the surface these changes seem reasonable - the code looks the way it 
should have been written in the first place.

The risk with these kinds of changes are always performance and 
deadlocks. :) I would not be surprised, given this is logging, that 
somewhere there is a path that might lead to a deadlock - but I have no 
practical way to ascertain that.

Wait for a true core-libs Reviewer before pushing this one. :)

David

On 29/08/2013 8:42 PM, Daniel Fuchs wrote:
> Hi,
>
> This is a fix for an old bug which rightfully remarks that
> whereas access to 'level' in handler is synchronized,
> access to other mutable fields - like 'filter' etc...
> is not - which is inconsistent.
>
> 
>
> I have tried to keep the fix simple - simply adding
> synchronized to method declarations when it was clear that
> there was an inconsistency.
>
> I also looked at the subclasses of j.u.l.Handler
>
> In some places I resorted to using a synchronized block to avoid
> calling overridable / external method from within the lock.
>
> The changed methods are simple accessors, and subclasses of
> Handler are already full of synchronized methods (e.g.
> methods like publish(...) are already synchronized)
> so the risk of fixing these simple accessors should be limited.
>
> best regards,
>
> -- daniel


From dl at cs.oswego.edu  Thu Aug 29 11:44:48 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 29 Aug 2013 07:44:48 -0400
Subject: Potential issue with CHM.toArray
In-Reply-To: <521DF795.8070905@gmail.com>
References: <41149C78-1097-4B86-9E3F-147CA859697B@oracle.com>
	<521DF795.8070905@gmail.com>
Message-ID: <521F3430.4050802@cs.oswego.edu>

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 in "forward" direction, leading to from smaller to
> larger tables?

They aren't required to be -- to preserve nonblockingness of traversal,
they can revert to old versions of table. This is legal but disconcerting
and surprising. I now think that giving up on pure non-blockingness
(only in the case of concurrent resizes) and helping to transfer
(which can block), thus forcing monotonicity,  is  a better policy.
An update is forthcoming. (Thanks to Paul for finding a use case
leading to this better policy!)

-Doug



From jason_mehrens at hotmail.com  Thu Aug 29 12:14:08 2013
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 29 Aug 2013 07:14:08 -0500
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: <521F3173.1050801@oracle.com>
References: <521F2592.4060604@oracle.com>,<521F3173.1050801@oracle.com>
Message-ID: 

Hi Daniel,
 
Why not take the code the opposite direction and change everything to volatile?  The properties of handler are mostly read and rarely written.  If isLoggable, getLevel, and getFilter were lock free the LogRecords that are not loggable could barge past the publish method.  That way you would only block threads that are actually publishing information of interest.
 
Jason
 
> Date: Thu, 29 Aug 2013 21:33:07 +1000
> From: david.holmes at oracle.com
> To: daniel.fuchs at oracle.com
> Subject: Re: RFR: JDK-6823527: java.util.logging.Handler has thread safety	issues
> CC: core-libs-dev at openjdk.java.net
> 
> Hi Daniel,
> 
> On the surface these changes seem reasonable - the code looks the way it 
> should have been written in the first place.
> 
> The risk with these kinds of changes are always performance and 
> deadlocks. :) I would not be surprised, given this is logging, that 
> somewhere there is a path that might lead to a deadlock - but I have no 
> practical way to ascertain that.
> 
> Wait for a true core-libs Reviewer before pushing this one. :)
> 
> David
> 
> On 29/08/2013 8:42 PM, Daniel Fuchs wrote:
> > Hi,
> >
> > This is a fix for an old bug which rightfully remarks that
> > whereas access to 'level' in handler is synchronized,
> > access to other mutable fields - like 'filter' etc...
> > is not - which is inconsistent.
> >
> > 
> >
> > I have tried to keep the fix simple - simply adding
> > synchronized to method declarations when it was clear that
> > there was an inconsistency.
> >
> > I also looked at the subclasses of j.u.l.Handler
> >
> > In some places I resorted to using a synchronized block to avoid
> > calling overridable / external method from within the lock.
> >
> > The changed methods are simple accessors, and subclasses of
> > Handler are already full of synchronized methods (e.g.
> > methods like publish(...) are already synchronized)
> > so the risk of fixing these simple accessors should be limited.
> >
> > best regards,
> >
> > -- daniel
 		 	   		  

From daniel.fuchs at oracle.com  Thu Aug 29 13:08:45 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 29 Aug 2013 15:08:45 +0200
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: 
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>
	
Message-ID: <521F47DD.2020502@oracle.com>

On 8/29/13 2:14 PM, Jason Mehrens wrote:
> Hi Daniel,
>
> Why not take the code the opposite direction and change everything to
> volatile?  The properties of handler are mostly read and rarely
> written.  If isLoggable, getLevel, and getFilter were lock free
> the LogRecords that are not loggable could barge past the publish
> method.  That way you would only block threads that are actually
> publishing information of interest.
>
> Jason

Hi Jason,

Yes - this is a possibility I envisaged too.
But would that be better?

I didn't want to remove any synchronized blocks because I'm
really not sure of what consequences it might have.

getLevel()/setLevel() are already synchronized on Handler.
It is my belief that most operation already need to call
getLevel(). So synchronizing on getFilter/setFilter etc.
should not be such a big issue.

Also - synchronizing on 'this' has the advantage that the lock
can be shared with subclasses - I mean - that's what a
subclass would usually expect...

But if I hear strong opinions that 'volatile' is definitely better
for this case I'm prepared to alter my patch.
I personally tend to use 'volatile' only sparsely - when it's clear
that it's the better solution.

best regards,

-- daniel

>
>  > Date: Thu, 29 Aug 2013 21:33:07 +1000
>  > From: david.holmes at oracle.com
>  > To: daniel.fuchs at oracle.com
>  > Subject: Re: RFR: JDK-6823527: java.util.logging.Handler has thread
> safety issues
>  > CC: core-libs-dev at openjdk.java.net
>  >
>  > Hi Daniel,
>  >
>  > On the surface these changes seem reasonable - the code looks the way it
>  > should have been written in the first place.
>  >
>  > The risk with these kinds of changes are always performance and
>  > deadlocks. :) I would not be surprised, given this is logging, that
>  > somewhere there is a path that might lead to a deadlock - but I have no
>  > practical way to ascertain that.
>  >
>  > Wait for a true core-libs Reviewer before pushing this one. :)
>  >
>  > David
>  >
>  > On 29/08/2013 8:42 PM, Daniel Fuchs wrote:
>  > > Hi,
>  > >
>  > > This is a fix for an old bug which rightfully remarks that
>  > > whereas access to 'level' in handler is synchronized,
>  > > access to other mutable fields - like 'filter' etc...
>  > > is not - which is inconsistent.
>  > >
>  > > 
>  > >
>  > > I have tried to keep the fix simple - simply adding
>  > > synchronized to method declarations when it was clear that
>  > > there was an inconsistency.
>  > >
>  > > I also looked at the subclasses of j.u.l.Handler
>  > >
>  > > In some places I resorted to using a synchronized block to avoid
>  > > calling overridable / external method from within the lock.
>  > >
>  > > The changed methods are simple accessors, and subclasses of
>  > > Handler are already full of synchronized methods (e.g.
>  > > methods like publish(...) are already synchronized)
>  > > so the risk of fixing these simple accessors should be limited.
>  > >
>  > > best regards,
>  > >
>  > > -- daniel



From tom.hawtin at oracle.com  Thu Aug 29 13:30:19 2013
From: tom.hawtin at oracle.com (Tom Hawtin)
Date: Thu, 29 Aug 2013 14:30:19 +0100
Subject: RFR: 7057785 : (xs) Add note to hashCode() that support for self
	referential is optional
In-Reply-To: 
References: <9B998061-4597-4792-BBE1-2A378AC0C6EE@oracle.com>
	
	
	
	
	
	<521E7FBB.1040106@mindspring.com>
	
Message-ID: <521F4CEB.5000408@oracle.com>

On 29/08/2013 00:23, Mike Duigou wrote:

> I am unsure what solution was used in Common Lisp (I think I knew once). The most likely solution for Java Collections would be to use a ThreadLocal which potentially recursive methods could check/set on entry and avoid recursing. Explicitly concurrent hostile implementations could use a plain boolean field rather than a ThreadLocal.

There are many problems with that, as you'd expect with anything 
involving ThreadLocal. Any use of threads (say the new 
Spliterable-related stuff) is going to have surprising behaviour. 
Callers have to be aware of global state, so may get incorrect answers 
(perhaps okay for logging, not so good for hashtables).

The problem is the APIs. Fiddling with internal implementation will just 
end in "cleverness".

Tom


From jason_mehrens at hotmail.com  Thu Aug 29 15:29:27 2013
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 29 Aug 2013 10:29:27 -0500
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: <521F47DD.2020502@oracle.com>
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>,
	,
	<521F47DD.2020502@oracle.com>
Message-ID: 
















> Yes - this is a possibility I envisaged too.
> But would that be better?
> 
> I didn't want to remove any synchronized blocks because I'm
> really not sure of what consequences it might have. 
> getLevel()/setLevel() are already synchronized on Handler.
> It is my belief that most operation already need to call
> getLevel(). So synchronizing on getFilter/setFilter etc.
> should not be such a big issue.
The only reason that I can think of for synchronizing any of the j.u.Handler methods is that the code was created prior to the JMM revision of volatile in JDK 1.5.  The lock policy is required for the 3 abstract methods so that a single LogRecord is published all or nothing.  The level, filter, error manager, encoding could all be declared volatile with no locking.  For the subclasses the locking for publish is too coarse.  The isLoggable method should be called outside the lock. 
> Also - synchronizing on 'this' has the advantage that the lock
> can be shared with subclasses - I mean - that's what a
> subclass would usually expect...
The same was true for COWList (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6282140) but, the lock policy changed over time.   This is bug is about thread safety issues so subclass should have little expectations.
 

> But if I hear strong opinions that 'volatile' is definitely better
> for this case I'm prepared to alter my patch.
> I personally tend to use 'volatile' only sparsely - when it's clear
> that it's the better solution. The common case is that Handler.getFoo are a hot methods and Handler.setFoo are cold.  You could always declare the level, filter, error manager, and encoding volatile and have only the setFoo methods synchronize when setting the property. Jason




 		 	   		  

From daniel.fuchs at oracle.com  Thu Aug 29 15:38:48 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 29 Aug 2013 17:38:48 +0200
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: 
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>,
	,
	<521F47DD.2020502@oracle.com>
	
Message-ID: <521F6B08.4000902@oracle.com>

Hi Jason,

Yes - that makes sense. I think we want the setter to use the
same lock than e.g. publish because we don't want the level
(or filter or encoding or whatever) to be changed while
publish is executing.

However I see no harm in allowing other threads to read the
variables values while setters/publish are executing - since
all the writes (I means setters) only write 1 single value.

OK - unless I hear an objection to that I'll prepare a new
changeset where the variables will be volatile, the getters
will not be synchronized, but the setters will.

Thanks for your feedback!

-- daniel

On 8/29/13 5:29 PM, Jason Mehrens wrote:
>  > Yes - this is a possibility I envisaged too.
>  > But would that be better?
>  >
>  > I didn't want to remove any synchronized blocks because I'm
>  > really not sure of what consequences it might have.
>  > getLevel()/setLevel() are already synchronized on Handler.
>  > It is my belief that most operation already need to call
>  > getLevel(). So synchronizing on getFilter/setFilter etc.
>  > should not be such a big issue.
> The only reason that I can think of for synchronizing any of the
> j.u.Handler methods is that the code was created prior to the JMM
> revision of volatile in JDK 1.5.  The lock policy is required for the 3
> abstract methods so that a single LogRecord is published all or
> nothing.  The level, filter, error manager, encoding could all be
> declared volatile with no locking.  For the subclasses the locking for
> publish is too coarse.  The isLoggable method should be called outside
> the lock.
>
>  > Also - synchronizing on 'this' has the advantage that the lock
>  > can be shared with subclasses - I mean - that's what a
>  > subclass would usually expect...
> The same was true for COWList
> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6282140) but, the
> lock policy changed over time.   This is bug is about thread safety
> issues so subclass should have little expectations.
>
>
>  > But if I hear strong opinions that 'volatile' is definitely better
>  > for this case I'm prepared to alter my patch.
>  > I personally tend to use 'volatile' only sparsely - when it's clear
>  > that it's the better solution.
> The common case is that Handler.getFoo are a hot methods and
> Handler.setFoo are cold.  You could always declare the level, filter,
> error manager, and encoding volatile and have only the setFoo methods
> synchronize when setting the property.
> Jason



From xueming.shen at oracle.com  Thu Aug 29 16:50:17 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 29 Aug 2013 09:50:17 -0700
Subject: RFR: JDK-6341345: (spec) Console.reader() should make it clear
	that the reader requires line termination
In-Reply-To: <521EF245.2040800@oracle.com>
References: <521E6B92.4030703@oracle.com> <521EF245.2040800@oracle.com>
Message-ID: <521F7BC9.4080503@oracle.com>

On 08/29/2013 12:03 AM, Alan Bateman wrote:
> On 28/08/2013 22:28, Xueming Shen wrote:
>> Alan,
>>
>> My mailbox suggests that you have already reviewed this one back to the
>> past May, somehow I dropped the ball some where. Here is the webrev and
>> CCC again (the change is a trivial spec clarification, which I should have
>> done 8 years ago).
>>
>> http://cr.openjdk.java.net/~sherman/6341345
> The wording looks okay, maybe it should be "read methods" as Reader defines more than on read method. You should probably use {@code ...} around both Reader and read too.
>
> -Alan

Thanks! webrev has been updated accordingly.


From daniel.fuchs at oracle.com  Thu Aug 29 16:46:53 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 29 Aug 2013 18:46:53 +0200
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: <521F6B08.4000902@oracle.com>
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>,
	,
	<521F47DD.2020502@oracle.com>
	
	<521F6B08.4000902@oracle.com>
Message-ID: <521F7AFD.3050703@oracle.com>

On 8/29/13 5:38 PM, Daniel Fuchs wrote:
> Hi Jason,
>
> Yes - that makes sense. I think we want the setter to use the
> same lock than e.g. publish because we don't want the level
> (or filter or encoding or whatever) to be changed while
> publish is executing.
>
> However I see no harm in allowing other threads to read the
> variables values while setters/publish are executing - since
> all the writes (I means setters) only write 1 single value.
>
> OK - unless I hear an objection to that I'll prepare a new
> changeset where the variables will be volatile, the getters
> will not be synchronized, but the setters will.
>
> Thanks for your feedback!

Here is the new webrev implementing Jason's suggestion.
Compared to previous webrev only Handler.java & StreamHandler.java
have changed.



best regards,

-- daniel


>
> -- daniel
>
> On 8/29/13 5:29 PM, Jason Mehrens wrote:
>>  > Yes - this is a possibility I envisaged too.
>>  > But would that be better?
>>  >
>>  > I didn't want to remove any synchronized blocks because I'm
>>  > really not sure of what consequences it might have.
>>  > getLevel()/setLevel() are already synchronized on Handler.
>>  > It is my belief that most operation already need to call
>>  > getLevel(). So synchronizing on getFilter/setFilter etc.
>>  > should not be such a big issue.
>> The only reason that I can think of for synchronizing any of the
>> j.u.Handler methods is that the code was created prior to the JMM
>> revision of volatile in JDK 1.5.  The lock policy is required for the 3
>> abstract methods so that a single LogRecord is published all or
>> nothing.  The level, filter, error manager, encoding could all be
>> declared volatile with no locking.  For the subclasses the locking for
>> publish is too coarse.  The isLoggable method should be called outside
>> the lock.
>>
>>  > Also - synchronizing on 'this' has the advantage that the lock
>>  > can be shared with subclasses - I mean - that's what a
>>  > subclass would usually expect...
>> The same was true for COWList
>> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6282140) but, the
>> lock policy changed over time.   This is bug is about thread safety
>> issues so subclass should have little expectations.
>>
>>
>>  > But if I hear strong opinions that 'volatile' is definitely better
>>  > for this case I'm prepared to alter my patch.
>>  > I personally tend to use 'volatile' only sparsely - when it's clear
>>  > that it's the better solution.
>> The common case is that Handler.getFoo are a hot methods and
>> Handler.setFoo are cold.  You could always declare the level, filter,
>> error manager, and encoding volatile and have only the setFoo methods
>> synchronize when setting the property.
>> Jason
>



From Alan.Bateman at oracle.com  Thu Aug 29 16:52:40 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 29 Aug 2013 17:52:40 +0100
Subject: RFR: JDK-6341345: (spec) Console.reader() should make it clear
	that the reader requires line termination
In-Reply-To: <521F7BC9.4080503@oracle.com>
References: <521E6B92.4030703@oracle.com> <521EF245.2040800@oracle.com>
	<521F7BC9.4080503@oracle.com>
Message-ID: <521F7C58.9040706@oracle.com>

On 29/08/2013 17:50, Xueming Shen wrote:
>
> Thanks! webrev has been updated accordingly.
Looks good.

-Alan


From brian.burkhalter at oracle.com  Thu Aug 29 17:13:01 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 29 Aug 2013 10:13:01 -0700
Subject: Java 8 RFR 8010430: Math.round has surprising behavior for odd
	values of ulp 1
In-Reply-To: 
References: 
	
	<8A126477-C00A-4833-962D-BA1DE1BA0930@oracle.com>
	<521EA862.9060008@oracle.com>
	
Message-ID: <9700875D-DB39-45C1-851A-EDBF77F7879D@oracle.com>

All right, so I've updated the webrev

http://cr.openjdk.java.net/~bpb/8010430/

which will need final JDK 8 Reviewer approval, I think.

Do the changes at lines 649 and 687 (in the new version) require CCC approval?

Thanks,

Brian

From dan.xu at oracle.com  Thu Aug 29 17:44:20 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Thu, 29 Aug 2013 17:44:20 +0000
Subject: hg: jdk8/tl/jdk: 4792059: test/java/io/pathNames/GeneralSolaris.java
	fails on symbolic links
Message-ID: <20130829174445.5008B623C7@hg.openjdk.java.net>

Changeset: 5bf4f2eeee85
Author:    dxu
Date:      2013-08-29 10:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bf4f2eeee85

4792059: test/java/io/pathNames/GeneralSolaris.java fails on symbolic links
Summary: Exclude the possible usage of linked files or directories in the test
Reviewed-by: alanb

! test/java/io/pathNames/General.java



From mandy.chung at oracle.com  Thu Aug 29 17:58:54 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 29 Aug 2013 10:58:54 -0700
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: <521F7AFD.3050703@oracle.com>
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>,
	,
	<521F47DD.2020502@oracle.com>
	
	<521F6B08.4000902@oracle.com> <521F7AFD.3050703@oracle.com>
Message-ID: <521F8BDE.8050304@oracle.com>

On 8/29/13 9:46 AM, Daniel Fuchs wrote:
> Here is the new webrev implementing Jason's suggestion.
> Compared to previous webrev only Handler.java & StreamHandler.java
> have changed.
>
> 
>

Looks good.  I also agree that making those fields to be volatile is a 
good suggestion and only requires writer to acquire the lock.

A minor comment:  The setter methods in Handler class are synchronized 
at the method entry whereas StreamHandler.setPushLevel synchronizes 
after checkPermission() is called.  checkPermission doesn't need to be 
synchronized.  Either way is fine with me and it'd be good to do it 
consistently.

Mandy

> best regards,
>
> -- daniel
>
>
>>
>> -- daniel
>>
>> On 8/29/13 5:29 PM, Jason Mehrens wrote:
>>>  > Yes - this is a possibility I envisaged too.
>>>  > But would that be better?
>>>  >
>>>  > I didn't want to remove any synchronized blocks because I'm
>>>  > really not sure of what consequences it might have.
>>>  > getLevel()/setLevel() are already synchronized on Handler.
>>>  > It is my belief that most operation already need to call
>>>  > getLevel(). So synchronizing on getFilter/setFilter etc.
>>>  > should not be such a big issue.
>>> The only reason that I can think of for synchronizing any of the
>>> j.u.Handler methods is that the code was created prior to the JMM
>>> revision of volatile in JDK 1.5.  The lock policy is required for the 3
>>> abstract methods so that a single LogRecord is published all or
>>> nothing.  The level, filter, error manager, encoding could all be
>>> declared volatile with no locking.  For the subclasses the locking for
>>> publish is too coarse.  The isLoggable method should be called outside
>>> the lock.
>>>
>>>  > Also - synchronizing on 'this' has the advantage that the lock
>>>  > can be shared with subclasses - I mean - that's what a
>>>  > subclass would usually expect...
>>> The same was true for COWList
>>> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6282140) but, the
>>> lock policy changed over time.   This is bug is about thread safety
>>> issues so subclass should have little expectations.
>>>
>>>
>>>  > But if I hear strong opinions that 'volatile' is definitely better
>>>  > for this case I'm prepared to alter my patch.
>>>  > I personally tend to use 'volatile' only sparsely - when it's clear
>>>  > that it's the better solution.
>>> The common case is that Handler.getFoo are a hot methods and
>>> Handler.setFoo are cold.  You could always declare the level, filter,
>>> error manager, and encoding volatile and have only the setFoo methods
>>> synchronize when setting the property.
>>> Jason
>>
>



From daniel.fuchs at oracle.com  Thu Aug 29 18:04:49 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 29 Aug 2013 20:04:49 +0200
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: <521F8BDE.8050304@oracle.com>
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>,
	,
	<521F47DD.2020502@oracle.com>
	
	<521F6B08.4000902@oracle.com> <521F7AFD.3050703@oracle.com>
	<521F8BDE.8050304@oracle.com>
Message-ID: <521F8D41.1010302@oracle.com>

On 8/29/13 7:58 PM, Mandy Chung wrote:
> On 8/29/13 9:46 AM, Daniel Fuchs wrote:
>> Here is the new webrev implementing Jason's suggestion.
>> Compared to previous webrev only Handler.java & StreamHandler.java
>> have changed.
>>
>> 
>>
>
> Looks good.  I also agree that making those fields to be volatile is a
> good suggestion and only requires writer to acquire the lock.
>
> A minor comment:  The setter methods in Handler class are synchronized
> at the method entry whereas StreamHandler.setPushLevel synchronizes
> after checkPermission() is called.  checkPermission doesn't need to be
> synchronized.  Either way is fine with me and it'd be good to do it
> consistently.

Hi Mandy,

Are you suggesting I should put checkPermission() within
the synchronized block? It might be more consistent with
what the other setters do. Although as you state it does
not matter much.

(its' MemoryHandler - not StreamHandler BTW)

best regards,

-- daniel



>
> Mandy
>
>> best regards,
>>
>> -- daniel
>>
>>
>>>
>>> -- daniel
>>>
>>> On 8/29/13 5:29 PM, Jason Mehrens wrote:
>>>>  > Yes - this is a possibility I envisaged too.
>>>>  > But would that be better?
>>>>  >
>>>>  > I didn't want to remove any synchronized blocks because I'm
>>>>  > really not sure of what consequences it might have.
>>>>  > getLevel()/setLevel() are already synchronized on Handler.
>>>>  > It is my belief that most operation already need to call
>>>>  > getLevel(). So synchronizing on getFilter/setFilter etc.
>>>>  > should not be such a big issue.
>>>> The only reason that I can think of for synchronizing any of the
>>>> j.u.Handler methods is that the code was created prior to the JMM
>>>> revision of volatile in JDK 1.5.  The lock policy is required for the 3
>>>> abstract methods so that a single LogRecord is published all or
>>>> nothing.  The level, filter, error manager, encoding could all be
>>>> declared volatile with no locking.  For the subclasses the locking for
>>>> publish is too coarse.  The isLoggable method should be called outside
>>>> the lock.
>>>>
>>>>  > Also - synchronizing on 'this' has the advantage that the lock
>>>>  > can be shared with subclasses - I mean - that's what a
>>>>  > subclass would usually expect...
>>>> The same was true for COWList
>>>> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6282140) but, the
>>>> lock policy changed over time.   This is bug is about thread safety
>>>> issues so subclass should have little expectations.
>>>>
>>>>
>>>>  > But if I hear strong opinions that 'volatile' is definitely better
>>>>  > for this case I'm prepared to alter my patch.
>>>>  > I personally tend to use 'volatile' only sparsely - when it's clear
>>>>  > that it's the better solution.
>>>> The common case is that Handler.getFoo are a hot methods and
>>>> Handler.setFoo are cold.  You could always declare the level, filter,
>>>> error manager, and encoding volatile and have only the setFoo methods
>>>> synchronize when setting the property.
>>>> Jason
>>>
>>
>



From jason_mehrens at hotmail.com  Thu Aug 29 18:07:12 2013
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 29 Aug 2013 13:07:12 -0500
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: <521F7AFD.3050703@oracle.com>
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>, ,
	, ,
	<521F47DD.2020502@oracle.com>,
	,
	<521F6B08.4000902@oracle.com>, <521F7AFD.3050703@oracle.com>
Message-ID: 

Looks good.  Shouldn't 'boolean sealed' be declared volatile?
 
Jason
 
> Date: Thu, 29 Aug 2013 18:46:53 +0200
> From: daniel.fuchs at oracle.com
> To: core-libs-dev at openjdk.java.net
> Subject: Re: RFR: JDK-6823527: java.util.logging.Handler has thread safety	issues
> 
> On 8/29/13 5:38 PM, Daniel Fuchs wrote:
> > Hi Jason,
> >
> > Yes - that makes sense. I think we want the setter to use the
> > same lock than e.g. publish because we don't want the level
> > (or filter or encoding or whatever) to be changed while
> > publish is executing.
> >
> > However I see no harm in allowing other threads to read the
> > variables values while setters/publish are executing - since
> > all the writes (I means setters) only write 1 single value.
> >
> > OK - unless I hear an objection to that I'll prepare a new
> > changeset where the variables will be volatile, the getters
> > will not be synchronized, but the setters will.
> >
> > Thanks for your feedback!
> 
> Here is the new webrev implementing Jason's suggestion.
> Compared to previous webrev only Handler.java & StreamHandler.java
> have changed.
> 
> 
> 
> best regards,
> 
> -- daniel
> 
> 
> >
> > -- daniel
> >
> > On 8/29/13 5:29 PM, Jason Mehrens wrote:
> >>  > Yes - this is a possibility I envisaged too.
> >>  > But would that be better?
> >>  >
> >>  > I didn't want to remove any synchronized blocks because I'm
> >>  > really not sure of what consequences it might have.
> >>  > getLevel()/setLevel() are already synchronized on Handler.
> >>  > It is my belief that most operation already need to call
> >>  > getLevel(). So synchronizing on getFilter/setFilter etc.
> >>  > should not be such a big issue.
> >> The only reason that I can think of for synchronizing any of the
> >> j.u.Handler methods is that the code was created prior to the JMM
> >> revision of volatile in JDK 1.5.  The lock policy is required for the 3
> >> abstract methods so that a single LogRecord is published all or
> >> nothing.  The level, filter, error manager, encoding could all be
> >> declared volatile with no locking.  For the subclasses the locking for
> >> publish is too coarse.  The isLoggable method should be called outside
> >> the lock.
> >>
> >>  > Also - synchronizing on 'this' has the advantage that the lock
> >>  > can be shared with subclasses - I mean - that's what a
> >>  > subclass would usually expect...
> >> The same was true for COWList
> >> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6282140) but, the
> >> lock policy changed over time.   This is bug is about thread safety
> >> issues so subclass should have little expectations.
> >>
> >>
> >>  > But if I hear strong opinions that 'volatile' is definitely better
> >>  > for this case I'm prepared to alter my patch.
> >>  > I personally tend to use 'volatile' only sparsely - when it's clear
> >>  > that it's the better solution.
> >> The common case is that Handler.getFoo are a hot methods and
> >> Handler.setFoo are cold.  You could always declare the level, filter,
> >> error manager, and encoding volatile and have only the setFoo methods
> >> synchronize when setting the property.
> >> Jason
> >
> 
 		 	   		  

From dan.xu at oracle.com  Thu Aug 29 18:08:59 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Thu, 29 Aug 2013 11:08:59 -0700
Subject: RFR: JDK-8023765 -- Improve MaxPathLength.java testcase and reduce
	its test load
In-Reply-To: <521EF655.7070605@oracle.com>
References: <521BF05A.1090805@oracle.com> <521C5173.4070701@oracle.com>
	<521CB46C.5060307@oracle.com> <521E8C90.1090504@oracle.com>
	<521EF655.7070605@oracle.com>
Message-ID: <521F8E3B.5030002@oracle.com>


On 08/29/2013 12:20 AM, Alan Bateman wrote:
> On 29/08/2013 00:49, Dan Xu wrote:
>> :
>>
>> Stuart brought a very good point for this test failure in the main 
>> bug, JDK-7160013. According to his comment, "Bottom line is that a 
>> Windows daemon (not an anti-virus scanner) may hold a file in 
>> delete-pending state for a short amount of time after it's been 
>> deleted. While it's in this state, if you ask if the file exists, the 
>> system will say that it does not. However, if you try to create a new 
>> file with the same name, you get an access denied error."
>>
>> And I re-checked remarks in the Windows APIs used for deleting file 
>> in [1] and directory in [2]. According to the spec, these APIs only 
>> mark a file/directory for deletion on close. And the delete operation 
>> does not occur until the last handle to it is closed. Therefore, if a 
>> Windows daemon opens a handle towards those newly-created directories 
>> (I think anti-virus on-access scanner may do a similar thing), the 
>> delete operation will be put in delete-pending state, and the next 
>> immediate call to create the same directory structure will fail.
>>
>> Based on the above information, I updated this testcase to make it 
>> create different directory structure in each loop, so that the 
>> next-create operation will not conflict with previous pending delete 
>> operation. I also follow Alan's suggestion to use 
>> Files.deleteIfExists in the latest change. Please review it at 
>> http://cr.openjdk.java.net/~dxu/8023765/webrev.01/. Thanks!
> If we want stable and fast test execution on Windows machines then I 
> think we have to remove these sources of interference. In my view this 
> means disabling the services that snoop on your usage so that they 
> aren't opening files that are trying to move or remove. It also means 
> configuring the AV software to exclude some area of the file system 
> that we can use as the test work tree.
>
> Anyway, the patch looks okay, it's just the new comment on L60 might 
> be a bit mis-leading.
>
> -Alan.

I tried to run this test on all platforms by removing L61. But it fails 
on the second while loop on Solaris and Mac platforms. The reason is 
that the testing path, which contains 20-level directory, is too long 
for them to handle. That is why I added a new comment in L60.

I agree that we need a clean testing environment. David DeHaven found 
"Application Experience" service interference at the end of last year, 
but unfortunately that service cannot be stopped in Windows. And I am 
also wondering whether we need clarify the Windows special behaviour in 
our spec for the file/directory delete methods. For example, in 
File.delete(), it currently says,

    1019      * @return  true if and only if the file or 
directory is
    1020      *          successfully deleted; false otherwise

Thanks!

-Dan




From daniel.fuchs at oracle.com  Thu Aug 29 18:10:31 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 29 Aug 2013 20:10:31 +0200
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: 
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>, ,
	, ,
	<521F47DD.2020502@oracle.com>,
	,
	<521F6B08.4000902@oracle.com>, <521F7AFD.3050703@oracle.com>
	
Message-ID: <521F8E97.1050107@oracle.com>

On 8/29/13 8:07 PM, Jason Mehrens wrote:
> Looks good.  Shouldn't 'boolean sealed' be declared volatile?

I don't think so because it's only mutated from within the
constructor. Once the Handler is built - 'sealed' never changes.

-- daniel

>
> Jason
>
>  > Date: Thu, 29 Aug 2013 18:46:53 +0200
>  > From: daniel.fuchs at oracle.com
>  > To: core-libs-dev at openjdk.java.net
>  > Subject: Re: RFR: JDK-6823527: java.util.logging.Handler has thread
> safety issues
>  >
>  > On 8/29/13 5:38 PM, Daniel Fuchs wrote:
>  > > Hi Jason,
>  > >
>  > > Yes - that makes sense. I think we want the setter to use the
>  > > same lock than e.g. publish because we don't want the level
>  > > (or filter or encoding or whatever) to be changed while
>  > > publish is executing.
>  > >
>  > > However I see no harm in allowing other threads to read the
>  > > variables values while setters/publish are executing - since
>  > > all the writes (I means setters) only write 1 single value.
>  > >
>  > > OK - unless I hear an objection to that I'll prepare a new
>  > > changeset where the variables will be volatile, the getters
>  > > will not be synchronized, but the setters will.
>  > >
>  > > Thanks for your feedback!
>  >
>  > Here is the new webrev implementing Jason's suggestion.
>  > Compared to previous webrev only Handler.java & StreamHandler.java
>  > have changed.
>  >
>  > 
>  >
>  > best regards,
>  >
>  > -- daniel
>  >
>  >
>  > >
>  > > -- daniel
>  > >
>  > > On 8/29/13 5:29 PM, Jason Mehrens wrote:
>  > >> > Yes - this is a possibility I envisaged too.
>  > >> > But would that be better?
>  > >> >
>  > >> > I didn't want to remove any synchronized blocks because I'm
>  > >> > really not sure of what consequences it might have.
>  > >> > getLevel()/setLevel() are already synchronized on Handler.
>  > >> > It is my belief that most operation already need to call
>  > >> > getLevel(). So synchronizing on getFilter/setFilter etc.
>  > >> > should not be such a big issue.
>  > >> The only reason that I can think of for synchronizing any of the
>  > >> j.u.Handler methods is that the code was created prior to the JMM
>  > >> revision of volatile in JDK 1.5. The lock policy is required for the 3
>  > >> abstract methods so that a single LogRecord is published all or
>  > >> nothing. The level, filter, error manager, encoding could all be
>  > >> declared volatile with no locking. For the subclasses the locking for
>  > >> publish is too coarse. The isLoggable method should be called outside
>  > >> the lock.
>  > >>
>  > >> > Also - synchronizing on 'this' has the advantage that the lock
>  > >> > can be shared with subclasses - I mean - that's what a
>  > >> > subclass would usually expect...
>  > >> The same was true for COWList
>  > >> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6282140) but, the
>  > >> lock policy changed over time. This is bug is about thread safety
>  > >> issues so subclass should have little expectations.
>  > >>
>  > >>
>  > >> > But if I hear strong opinions that 'volatile' is definitely better
>  > >> > for this case I'm prepared to alter my patch.
>  > >> > I personally tend to use 'volatile' only sparsely - when it's clear
>  > >> > that it's the better solution.
>  > >> The common case is that Handler.getFoo are a hot methods and
>  > >> Handler.setFoo are cold. You could always declare the level, filter,
>  > >> error manager, and encoding volatile and have only the setFoo methods
>  > >> synchronize when setting the property.
>  > >> Jason
>  > >
>  >



From xueming.shen at oracle.com  Thu Aug 29 18:19:30 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 29 Aug 2013 11:19:30 -0700
Subject: RFR: JDK-7186632: NLS t13y issue on jar.properties file
Message-ID: <521F90B2.9000608@oracle.com>

Hi,

Please help review the change for #7186632.

http://cr.openjdk.java.net/~sherman/7186632/webrev

The proposed change here is to remove the backslash before the word
"inflated:". While based on j.u.Properties spec it is absolutely legal and
harmless to have a backslash before a non-valid escape character in this
case (the backslash is silently dropped), it appears it may cause confusion
to the non-j.u.Properties-expert localization translator. Given this backslash
brings no real benefit to the properties file, I decided to just remove it.
(fyi, the reason to insert space character(s) here for "created:" and "inflated:"
is to keep the output of "created:", "extracted:" and "inflated:" aligned on
a command line terminal, when "v" option is used, for example jar xvf foo.jar)

Thanks!
-Sherman


From jonathan.gibbons at oracle.com  Thu Aug 29 18:42:43 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 29 Aug 2013 18:42:43 +0000
Subject: hg: jdk8/tl/langtools: 8001669: javadoc internal DocletAbortException
	should set cause when appropriate
Message-ID: <20130829184250.9071D623CF@hg.openjdk.java.net>

Changeset: 0e6577980181
Author:    jjg
Date:      2013-08-29 11:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0e6577980181

8001669: javadoc internal DocletAbortException should set cause when appropriate
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletAbortException.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java



From jonathan.gibbons at oracle.com  Thu Aug 29 18:58:03 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 29 Aug 2013 18:58:03 +0000
Subject: hg: jdk8/tl/langtools: 8023522:
	tools/javac/tree/TypeAnnotationsPretty.java test cases with @TA
	newline fail on windows only
Message-ID: <20130829185809.5FF98623D3@hg.openjdk.java.net>

Changeset: b0b25c1f6cbd
Author:    jjg
Date:      2013-08-29 11:57 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b0b25c1f6cbd

8023522: tools/javac/tree/TypeAnnotationsPretty.java test cases with @TA newline fail on windows only
Reviewed-by: darcy

! test/tools/javac/tree/TypeAnnotationsPretty.java



From jonathan.gibbons at oracle.com  Thu Aug 29 19:04:23 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 29 Aug 2013 19:04:23 +0000
Subject: hg: jdk8/tl/langtools: 8013384: Potential infinite loop in javadoc
Message-ID: <20130829190432.B1D57623D8@hg.openjdk.java.net>

Changeset: 9c0e192c0926
Author:    jjg
Date:      2013-08-29 12:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9c0e192c0926

8013384: Potential infinite loop in javadoc
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java



From jonathan.gibbons at oracle.com  Thu Aug 29 19:12:25 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 29 Aug 2013 19:12:25 +0000
Subject: hg: jdk8/tl/langtools: 8022744: javac -Xpkginfo command's
	documentation is sparse
Message-ID: <20130829191232.EF632623DA@hg.openjdk.java.net>

Changeset: 96b6865eda94
Author:    jjg
Date:      2013-08-29 12:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/96b6865eda94

8022744: javac -Xpkginfo command's documentation is sparse
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/main/Option.java



From Alan.Bateman at oracle.com  Thu Aug 29 19:38:46 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 29 Aug 2013 20:38:46 +0100
Subject: Review: lamda expressions and bulk data operations on collections.
In-Reply-To: <521F93F8.50809@oracle.com>
References: <521F93F8.50809@oracle.com>
Message-ID: <521FA346.9090603@oracle.com>

On 29/08/2013 19:33, Andrey Nazarov wrote:
> Hi guys,
>
> We want to push our demo code for lambda expression and bulk data 
> operations.
> Could you please review this code? Webrev is attached.
>
>
> --Andrey.
Your mail didn't have an attachment, it probably was dropped by the mail 
server. Can you publish on a HTTP server so that it can be browsed?

-Alan.


From mandy.chung at oracle.com  Thu Aug 29 19:45:57 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 29 Aug 2013 12:45:57 -0700
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: <521F8D41.1010302@oracle.com>
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>,
	,
	<521F47DD.2020502@oracle.com>
	
	<521F6B08.4000902@oracle.com> <521F7AFD.3050703@oracle.com>
	<521F8BDE.8050304@oracle.com> <521F8D41.1010302@oracle.com>
Message-ID: <521FA4F5.8060103@oracle.com>

On 8/29/13 11:04 AM, Daniel Fuchs wrote:
> On 8/29/13 7:58 PM, Mandy Chung wrote:
>> On 8/29/13 9:46 AM, Daniel Fuchs wrote:
>>> Here is the new webrev implementing Jason's suggestion.
>>> Compared to previous webrev only Handler.java & StreamHandler.java
>>> have changed.
>>>
>>> 
>>>
>>
>> Looks good.  I also agree that making those fields to be volatile is a
>> good suggestion and only requires writer to acquire the lock.
>>
>> A minor comment:  The setter methods in Handler class are synchronized
>> at the method entry whereas StreamHandler.setPushLevel synchronizes
>> after checkPermission() is called.  checkPermission doesn't need to be
>> synchronized.  Either way is fine with me and it'd be good to do it
>> consistently.
>
> Hi Mandy,
>
> Are you suggesting I should put checkPermission() within
> the synchronized block? It might be more consistent with
> what the other setters do. Although as you state it does
> not matter much.

Having a second thought - do the setters really need to be 
synchronized?   My guess is that StreamHandler.publish is synchronized 
so as to ensure that the log messages are sequential and not interpersed 
when multiple threads are publishing.  The spec is unclear.  Perhaps it 
worths looking into this further?

One more minor note: MemoryHandler.pushLevel can also be made volatile.
L262: look like the log manager is not needed in the existing code.

Mandy



From daniel.fuchs at oracle.com  Thu Aug 29 19:54:50 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 29 Aug 2013 21:54:50 +0200
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: <521FA4F5.8060103@oracle.com>
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>,
	,
	<521F47DD.2020502@oracle.com>
	
	<521F6B08.4000902@oracle.com> <521F7AFD.3050703@oracle.com>
	<521F8BDE.8050304@oracle.com> <521F8D41.1010302@oracle.com>
	<521FA4F5.8060103@oracle.com>
Message-ID: <521FA70A.9030908@oracle.com>

On 8/29/13 9:45 PM, Mandy Chung wrote:
> On 8/29/13 11:04 AM, Daniel Fuchs wrote:
>> On 8/29/13 7:58 PM, Mandy Chung wrote:
>>> On 8/29/13 9:46 AM, Daniel Fuchs wrote:
>>>> Here is the new webrev implementing Jason's suggestion.
>>>> Compared to previous webrev only Handler.java & StreamHandler.java
>>>> have changed.
>>>>
>>>> 
>>>>
>>>
>>> Looks good.  I also agree that making those fields to be volatile is a
>>> good suggestion and only requires writer to acquire the lock.
>>>
>>> A minor comment:  The setter methods in Handler class are synchronized
>>> at the method entry whereas StreamHandler.setPushLevel synchronizes
>>> after checkPermission() is called.  checkPermission doesn't need to be
>>> synchronized.  Either way is fine with me and it'd be good to do it
>>> consistently.
>>
>> Hi Mandy,
>>
>> Are you suggesting I should put checkPermission() within
>> the synchronized block? It might be more consistent with
>> what the other setters do. Although as you state it does
>> not matter much.
>
> Having a second thought - do the setters really need to be
> synchronized?   My guess is that StreamHandler.publish is synchronized
> so as to ensure that the log messages are sequential and not interpersed
> when multiple threads are publishing.  The spec is unclear.  Perhaps it
> worths looking into this further?

I believe at least setEncodings() needs synchronization.
setLevel() had it - so are we going to cause subtle race conditions
if we remove it?

My own feeling is that keeping setters synchronized might be better.

We could of course say that a subclass which needs to prevent
e.g. setFormatter() from being called concurrently with publish()
should override setFormatter just for the purpose of synchronizing
it...

> One more minor note: MemoryHandler.pushLevel can also be made volatile.
> L262: look like the log manager is not needed in the existing code.

hmmm. Right. It's already called once in the super class so removing
this call should have no effect. I will remove it.

-- daniel

>
> Mandy
>



From daniel.fuchs at oracle.com  Thu Aug 29 20:13:51 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 29 Aug 2013 22:13:51 +0200
Subject: RFR: 8019853 - Break logging and AWT circular dependency
Message-ID: <521FAB7F.7020704@oracle.com>

Hi,

Please find below a changeset that will fix:

8019853 - Break logging and AWT circular dependency

(which also duplicates
  8023258 Logger.getLogger() after ImageIO.read() returns
          different logger instance)



The new code makes sure that JavaAWTAccess.getAppletContext() returns
null when the LogManager's default userContext should be used, thus
solving 8023258 (Logger.getLogger() after ImageIO.read() returns
different logger instance).
Although LogManager still needs to get the applet context it will no
longer trigger the creation of the 'mainAppContext' - thus breaking
the circular dependency.

best regards,

-- daniel


From mike.duigou at oracle.com  Thu Aug 29 23:05:12 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Thu, 29 Aug 2013 23:05:12 +0000
Subject: hg: jdk8/tl: 8023892: test/Makefile shouldn't try to tell
	langtools/test/Makefile where to put output.
Message-ID: <20130829230512.8E950623FC@hg.openjdk.java.net>

Changeset: 51a61778a99d
Author:    mduigou
Date:      2013-08-29 16:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/51a61778a99d

8023892: test/Makefile shouldn't try to tell langtools/test/Makefile where to put output.
Reviewed-by: erikj, vromero, henryjen

! test/Makefile



From mike.duigou at oracle.com  Fri Aug 30 00:13:14 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 29 Aug 2013 17:13:14 -0700
Subject: RFR: 8024014 & 8024015 : (xs) TEST.groups updates
Message-ID: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com>

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_concurrent. The main advantage is that it's easier/quicker to test individual components. The intent is that the test groups are aligned with bug database sub-components.

The second change moves some important lambda related tests from languishing in obscurity in the jdk_other group to the jdk_lang group to reflect their importance and relation to other tests. These tests are contained in the jdk/lambda directory.

The combined webrev is here:

http://cr.openjdk.java.net/~mduigou/JDK-8024015/0/webrev/

The effect of these changes won't be visible to most people until JDK-8015068 is integrated.

Thanks,

Mike

From mandy.chung at oracle.com  Fri Aug 30 01:21:20 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 29 Aug 2013 18:21:20 -0700
Subject: RFR: 8024014 & 8024015 : (xs) TEST.groups updates
In-Reply-To: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com>
References: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com>
Message-ID: <521FF390.3050108@oracle.com>

On 8/29/2013 5:13 PM, 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_concurrent. The main advantage is that it's easier/quicker to test individual components. The intent is that the test groups are aligned with bug database sub-components.
>
> The second change moves some important lambda related tests from languishing in obscurity in the jdk_other group to the jdk_lang group to reflect their importance and relation to other tests. These tests are contained in the jdk/lambda directory.
>
> The combined webrev is here:
>
> http://cr.openjdk.java.net/~mduigou/JDK-8024015/0/webrev/

This change looks good to me.  It's good to break jdk_util into 
sub-groups.  Is there a way to avoid listing the rest of java/util/* not 
covered by these new sub-groups (i.e. something like this:
    :jdk_collections \
    :jdk_concurrent \
    :jdk_stream \
    java/util \
    sun/util

so that new subdirectory added under java/util will be included? I have 
seen cases that new tests in a new directory added but not listed in the 
old test/Makefile were never run but unnoticed (you cleaned up that 
logic in JDK-8015068 - thanks).

Mandy

> The effect of these changes won't be visible to most people until JDK-8015068 is integrated.
>
> Thanks,
>
> Mike



From david.holmes at oracle.com  Fri Aug 30 01:27:52 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 30 Aug 2013 11:27:52 +1000
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: <521FA70A.9030908@oracle.com>
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>,
	,
	<521F47DD.2020502@oracle.com>
	
	<521F6B08.4000902@oracle.com> <521F7AFD.3050703@oracle.com>
	<521F8BDE.8050304@oracle.com> <521F8D41.1010302@oracle.com>
	<521FA4F5.8060103@oracle.com> <521FA70A.9030908@oracle.com>
Message-ID: <521FF518.7060803@oracle.com>

Hi Daniel,

As usual with these kinds of changes we start by trying to complete an 
incomplete/incorrect synchronization pattern and get diverted into 
changing the synchronization pattern. :) The latter of course has more 
risk than the former.

Making everything synchronized has the benefit that we don't need to 
analyse the "real" methods to check what would happen if one of these 
data values changed mid-method. Might be harmless, might not. Atomicity 
makes things easy to reason about.

Making the fields volatile and un-sync'ing the getters is a potential 
optimization for readers. But are these fields that are read frequently 
by multiple threads? The downside of doing so is a negative performance 
impact inside the "real" methods where every volatile field access 
requires (platform-dependent) memory barriers.

David

On 30/08/2013 5:54 AM, Daniel Fuchs wrote:
> On 8/29/13 9:45 PM, Mandy Chung wrote:
>> On 8/29/13 11:04 AM, Daniel Fuchs wrote:
>>> On 8/29/13 7:58 PM, Mandy Chung wrote:
>>>> On 8/29/13 9:46 AM, Daniel Fuchs wrote:
>>>>> Here is the new webrev implementing Jason's suggestion.
>>>>> Compared to previous webrev only Handler.java & StreamHandler.java
>>>>> have changed.
>>>>>
>>>>> 
>>>>>
>>>>
>>>> Looks good.  I also agree that making those fields to be volatile is a
>>>> good suggestion and only requires writer to acquire the lock.
>>>>
>>>> A minor comment:  The setter methods in Handler class are synchronized
>>>> at the method entry whereas StreamHandler.setPushLevel synchronizes
>>>> after checkPermission() is called.  checkPermission doesn't need to be
>>>> synchronized.  Either way is fine with me and it'd be good to do it
>>>> consistently.
>>>
>>> Hi Mandy,
>>>
>>> Are you suggesting I should put checkPermission() within
>>> the synchronized block? It might be more consistent with
>>> what the other setters do. Although as you state it does
>>> not matter much.
>>
>> Having a second thought - do the setters really need to be
>> synchronized?   My guess is that StreamHandler.publish is synchronized
>> so as to ensure that the log messages are sequential and not interpersed
>> when multiple threads are publishing.  The spec is unclear.  Perhaps it
>> worths looking into this further?
>
> I believe at least setEncodings() needs synchronization.
> setLevel() had it - so are we going to cause subtle race conditions
> if we remove it?
>
> My own feeling is that keeping setters synchronized might be better.
>
> We could of course say that a subclass which needs to prevent
> e.g. setFormatter() from being called concurrently with publish()
> should override setFormatter just for the purpose of synchronizing
> it...
>
>> One more minor note: MemoryHandler.pushLevel can also be made volatile.
>> L262: look like the log manager is not needed in the existing code.
>
> hmmm. Right. It's already called once in the super class so removing
> this call should have no effect. I will remove it.
>
> -- daniel
>
>>
>> Mandy
>>
>


From david.holmes at oracle.com  Fri Aug 30 01:37:28 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 30 Aug 2013 11:37:28 +1000
Subject: RFR: 8024014 & 8024015 : (xs) TEST.groups updates
In-Reply-To: <521FF390.3050108@oracle.com>
References: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com>
	<521FF390.3050108@oracle.com>
Message-ID: <521FF758.5000303@oracle.com>

On 30/08/2013 11:21 AM, Mandy Chung wrote:
> On 8/29/2013 5:13 PM, 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_concurrent. The main
>> advantage is that it's easier/quicker to test individual components.
>> The intent is that the test groups are aligned with bug database
>> sub-components.

Interesting choice. Perhaps the tests themselves should be restructured 
around this classification too?

>> The second change moves some important lambda related tests from
>> languishing in obscurity in the jdk_other group to the jdk_lang group
>> to reflect their importance and relation to other tests. These tests
>> are contained in the jdk/lambda directory.
>>
>> The combined webrev is here:
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-8024015/0/webrev/
>
> This change looks good to me.  It's good to break jdk_util into
> sub-groups.  Is there a way to avoid listing the rest of java/util/* not
> covered by these new sub-groups (i.e. something like this:
>     :jdk_collections \
>     :jdk_concurrent \
>     :jdk_stream \
>     java/util \
>     sun/util

Something like but not quite:

jdk_util_other = \
   java/util \
   sun/util \
  -:jdk_collections \
  -:jdk_concurrent \
  -:jdk_stream

jdk_util = \
   :jdk_util_other \
   :jdk_collections \
   :jdk_concurrent \
   :jdk_stream

David
-----

> so that new subdirectory added under java/util will be included? I have
> seen cases that new tests in a new directory added but not listed in the
> old test/Makefile were never run but unnoticed (you cleaned up that
> logic in JDK-8015068 - thanks).
>
> Mandy
>
>> The effect of these changes won't be visible to most people until
>> JDK-8015068 is integrated.
>>
>> Thanks,
>>
>> Mike
>


From jonathan.gibbons at oracle.com  Fri Aug 30 02:20:32 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 30 Aug 2013 02:20:32 +0000
Subject: hg: jdk8/tl/langtools: 8023833: Replace direct use of AnnotatedType
	in javadoc code
Message-ID: <20130830022040.35E3D62403@hg.openjdk.java.net>

Changeset: 23f0f3c9c44a
Author:    jjg
Date:      2013-08-29 19:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/23f0f3c9c44a

8023833: Replace direct use of AnnotatedType in javadoc code
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javadoc/AnnotatedTypeImpl.java
! src/share/classes/com/sun/tools/javadoc/TypeMaker.java
! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java



From xuelei.fan at oracle.com  Fri Aug 30 01:59:41 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Fri, 30 Aug 2013 01:59:41 +0000
Subject: hg: jdk8/tl/jdk: 8023881: IDN.USE_STD3_ASCII_RULES option is too
	strict to use Unicode in IDN.toASCII
Message-ID: <20130830015953.C9E4362401@hg.openjdk.java.net>

Changeset: cdf68747b0fb
Author:    xuelei
Date:      2013-08-29 18:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdf68747b0fb

8023881: IDN.USE_STD3_ASCII_RULES option is too strict to use Unicode in IDN.toASCII
Reviewed-by: michaelm

! src/share/classes/java/net/IDN.java
+ test/java/net/IDN/UseSTD3ASCIIRules.java



From mandy.chung at oracle.com  Fri Aug 30 03:14:50 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 29 Aug 2013 20:14:50 -0700
Subject: RFR: 8019853 - Break logging and AWT circular dependency
In-Reply-To: <521FAB7F.7020704@oracle.com>
References: <521FAB7F.7020704@oracle.com>
Message-ID: <52200E2A.9090509@oracle.com>

Hi Daniel,

Thanks for getting this fixed.  The change looks good.  The 
JavaAWTContext.getAppletContext implementation looks good and clean 
(thanks to your comments).  It'd be good to get AWT team to review 
AppContext.java change (cc'ing Artem).

Mandy

On 8/29/2013 1:13 PM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a changeset that will fix:
>
> 8019853 - Break logging and AWT circular dependency
>
> (which also duplicates
>  8023258 Logger.getLogger() after ImageIO.read() returns
>          different logger instance)
>
> 
>
> The new code makes sure that JavaAWTAccess.getAppletContext() returns
> null when the LogManager's default userContext should be used, thus
> solving 8023258 (Logger.getLogger() after ImageIO.read() returns
> different logger instance).
> Although LogManager still needs to get the applet context it will no
> longer trigger the creation of the 'mainAppContext' - thus breaking
> the circular dependency.
>
> best regards,
>
> -- daniel



From mike.duigou at oracle.com  Fri Aug 30 05:24:45 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 29 Aug 2013 22:24:45 -0700
Subject: RFR: 8024014 & 8024015 : (xs) TEST.groups updates
In-Reply-To: <521FF758.5000303@oracle.com>
References: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com>
	<521FF390.3050108@oracle.com> <521FF758.5000303@oracle.com>
Message-ID: <2FC1F750-BBCC-45F5-BA7C-56742E024D6C@oracle.com>


On Aug 29 2013, at 18:37 , David Holmes wrote:

> On 30/08/2013 11:21 AM, Mandy Chung wrote:
>> On 8/29/2013 5:13 PM, 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_concurrent. The main
>>> advantage is that it's easier/quicker to test individual components.
>>> The intent is that the test groups are aligned with bug database
>>> sub-components.
> 
> Interesting choice. Perhaps the tests themselves should be restructured around this classification too?

I think there would be some resistance to moving files. Most package boundaries match the sub-component categories (I could be wrong on this point).

If it is not too much disruption I think we should try to place tests where they properly belong.

>>> The second change moves some important lambda related tests from
>>> languishing in obscurity in the jdk_other group to the jdk_lang group
>>> to reflect their importance and relation to other tests. These tests
>>> are contained in the jdk/lambda directory.
>>> 
>>> The combined webrev is here:
>>> 
>>> http://cr.openjdk.java.net/~mduigou/JDK-8024015/0/webrev/
>> 
>> This change looks good to me.  It's good to break jdk_util into
>> sub-groups.  Is there a way to avoid listing the rest of java/util/* not
>> covered by these new sub-groups (i.e. something like this:
>>    :jdk_collections \
>>    :jdk_concurrent \
>>    :jdk_stream \
>>    java/util \
>>    sun/util
> 
> Something like but not quite:
> 
> jdk_util_other = \
>  java/util \
>  sun/util \
> -:jdk_collections \
> -:jdk_concurrent \
> -:jdk_stream
> 
> jdk_util = \
>  :jdk_util_other \
>  :jdk_collections \
>  :jdk_concurrent \
>  :jdk_stream
> 

I think this is an excellent suggestion. I was really bothered by what felt like a recreation of the despised (by me anyway) FILES_JAVA.gmk. This is much better.

> David
> -----
> 
>> so that new subdirectory added under java/util will be included? I have
>> seen cases that new tests in a new directory added but not listed in the
>> old test/Makefile were never run but unnoticed (you cleaned up that
>> logic in JDK-8015068 - thanks).
>> 
>> Mandy
>> 
>>> The effect of these changes won't be visible to most people until
>>> JDK-8015068 is integrated.
>>> 
>>> Thanks,
>>> 
>>> Mike
>> 



From Alan.Bateman at oracle.com  Fri Aug 30 05:37:44 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 30 Aug 2013 06:37:44 +0100
Subject: RFR: 8024014 & 8024015 : (xs) TEST.groups updates
In-Reply-To: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com>
References: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com>
Message-ID: <52202FA8.1010405@oracle.com>

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_concurrent. The main advantage is that it's easier/quicker to test individual components. The intent is that the test groups are aligned with bug database sub-components.
>
> The second change moves some important lambda related tests from languishing in obscurity in the jdk_other group to the jdk_lang group to reflect their importance and relation to other tests. These tests are contained in the jdk/lambda directory.
>
> The combined webrev is here:
>
> http://cr.openjdk.java.net/~mduigou/JDK-8024015/0/webrev/
>
> The effect of these changes won't be visible to most people until JDK-8015068 is integrated.
>
> Thanks,
>
> Mike
The jdk_other group was initially created to match the existing 
jdk_other make file target so this is why jdk/lambda is there. I agree 
with moving it as it is somewhat obscure.

I'm not sure about splitting up jdk_util as proposed as it doesn't look 
very maintainable. Have you considered just limiting this to simple 
groups for java/util/stream/** and java/util/concurrent/** and not try 
carve up the tests in java/util? If someone is changing something in the 
collection classes then is it a big deal to run all of the java/util/** 
tests? If there are good reasons then maybe it's time to look at how the 
tests are organized instead.

-Alan.


From martinrb at google.com  Fri Aug 30 06:22:36 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 29 Aug 2013 23:22:36 -0700
Subject: RFR: 8024014 & 8024015 : (xs) TEST.groups updates
In-Reply-To: <52202FA8.1010405@oracle.com>
References: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com>
	<52202FA8.1010405@oracle.com>
Message-ID: 

I used to run collection/concurrency tests regularly.
It's hard to separate collections and concurrency, unless perhaps you make
concurrent a subset of collections.  You can come pretty close to testing
just collections by running all tests in util with names matching
Map|List|Collection|Queue|Deque|Set (and I've probably forgotten some).  I
agree it's hard to maintain.


On Thu, Aug 29, 2013 at 10:37 PM, 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_concurrent. The main advantage is that
>> it's easier/quicker to test individual components. The intent is that the
>> test groups are aligned with bug database sub-components.
>>
>> The second change moves some important lambda related tests from
>> languishing in obscurity in the jdk_other group to the jdk_lang group to
>> reflect their importance and relation to other tests. These tests are
>> contained in the jdk/lambda directory.
>>
>> The combined webrev is here:
>>
>> http://cr.openjdk.java.net/~**mduigou/JDK-8024015/0/webrev/
>>
>> The effect of these changes won't be visible to most people until
>> JDK-8015068 is integrated.
>>
>> Thanks,
>>
>> Mike
>>
> The jdk_other group was initially created to match the existing jdk_other
> make file target so this is why jdk/lambda is there. I agree with moving it
> as it is somewhat obscure.
>
> I'm not sure about splitting up jdk_util as proposed as it doesn't look
> very maintainable. Have you considered just limiting this to simple groups
> for java/util/stream/** and java/util/concurrent/** and not try carve up
> the tests in java/util? If someone is changing something in the collection
> classes then is it a big deal to run all of the java/util/** tests? If
> there are good reasons then maybe it's time to look at how the tests are
> organized instead.
>
> -Alan.
>


From henry.jen at oracle.com  Fri Aug 30 06:44:26 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 29 Aug 2013 23:44:26 -0700
Subject: RFR: 8023997 : j.l.String.join(java.lang.CharSequence,
	java.lang.Iterable) sample doesn't compile and is incorrect
Message-ID: <52203F4A.102@oracle.com>

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/

Cheers,
Henry


From daniel.fuchs at oracle.com  Fri Aug 30 06:45:21 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 30 Aug 2013 08:45:21 +0200
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: <521FF518.7060803@oracle.com>
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>,
	,
	<521F47DD.2020502@oracle.com>
	
	<521F6B08.4000902@oracle.com> <521F7AFD.3050703@oracle.com>
	<521F8BDE.8050304@oracle.com> <521F8D41.1010302@oracle.com>
	<521FA4F5.8060103@oracle.com> <521FA70A.9030908@oracle.com>
	<521FF518.7060803@oracle.com>
Message-ID: <52203F81.8080903@oracle.com>

On 8/30/13 3:27 AM, David Holmes wrote:
> Hi Daniel,
>
> As usual with these kinds of changes we start by trying to complete an 
> incomplete/incorrect synchronization pattern and get diverted into 
> changing the synchronization pattern. :) The latter of course has more 
> risk than the former.
>
> Making everything synchronized has the benefit that we don't need to 
> analyse the "real" methods to check what would happen if one of these 
> data values changed mid-method. Might be harmless, might not. 
> Atomicity makes things easy to reason about.
Agreed. We can analyze the 'real methods' of Handler classes in the JDK. 
But I'm sure there are plenty of
subclasses of handlers in applications out there that we don't know 
about. So we can't really be sure
what the effect of changing synchronization might have on those subclasses.

> Making the fields volatile and un-sync'ing the getters is a potential 
> optimization for readers. But are these fields that are read 
> frequently by multiple threads? 

At least three of them are accessed by isLoggable() which I believe is 
called very frequently by
multiple threads (level, filter, and writer).

> The downside of doing so is a negative performance impact inside the 
> "real" methods where every volatile field access requires 
> (platform-dependent) memory barriers.
That - I think - should not be such an issue since the fields are private.
I mean - we can see whether there are methods that do multiple access to 
the fields in the
classes that define these fields - and fix that if necessary.
For subclasses, they will have to call the getter, which will require 
synchronization anyway.
I mean - for subclasses - isn't the fact that the getter accesses a 
volatile field or the fact that the
getter is synchronized equivalent in terms of performance?

JDK 8 is a major version of the JDK - so I think if we want to fix this 
bug it's
probably better to do it now rather than in a minor update.

It seems we have 5 choices:

a. Not fixing
b. Using regular 'synchronized' pattern [1]
c. Using volatiles, synchronize setters only [2]
d. Using volatiles, only synchronize setters when obviously necessary
e. other? (like introducing new private locks - but I don't think 
anybody would want that)

[1] 
[2] 

My own preference would lean to either b) or c).

-- daniel


>
> David
>
> On 30/08/2013 5:54 AM, Daniel Fuchs wrote:
>> On 8/29/13 9:45 PM, Mandy Chung wrote:
>>> On 8/29/13 11:04 AM, Daniel Fuchs wrote:
>>>> On 8/29/13 7:58 PM, Mandy Chung wrote:
>>>>> On 8/29/13 9:46 AM, Daniel Fuchs wrote:
>>>>>> Here is the new webrev implementing Jason's suggestion.
>>>>>> Compared to previous webrev only Handler.java & StreamHandler.java
>>>>>> have changed.
>>>>>>
>>>>>> 
>>>>>>
>>>>>
>>>>> Looks good.  I also agree that making those fields to be volatile 
>>>>> is a
>>>>> good suggestion and only requires writer to acquire the lock.
>>>>>
>>>>> A minor comment:  The setter methods in Handler class are 
>>>>> synchronized
>>>>> at the method entry whereas StreamHandler.setPushLevel synchronizes
>>>>> after checkPermission() is called.  checkPermission doesn't need 
>>>>> to be
>>>>> synchronized.  Either way is fine with me and it'd be good to do it
>>>>> consistently.
>>>>
>>>> Hi Mandy,
>>>>
>>>> Are you suggesting I should put checkPermission() within
>>>> the synchronized block? It might be more consistent with
>>>> what the other setters do. Although as you state it does
>>>> not matter much.
>>>
>>> Having a second thought - do the setters really need to be
>>> synchronized?   My guess is that StreamHandler.publish is synchronized
>>> so as to ensure that the log messages are sequential and not 
>>> interpersed
>>> when multiple threads are publishing.  The spec is unclear. Perhaps it
>>> worths looking into this further?
>>
>> I believe at least setEncodings() needs synchronization.
>> setLevel() had it - so are we going to cause subtle race conditions
>> if we remove it?
>>
>> My own feeling is that keeping setters synchronized might be better.
>>
>> We could of course say that a subclass which needs to prevent
>> e.g. setFormatter() from being called concurrently with publish()
>> should override setFormatter just for the purpose of synchronizing
>> it...
>>
>>> One more minor note: MemoryHandler.pushLevel can also be made volatile.
>>> L262: look like the log manager is not needed in the existing code.
>>
>> hmmm. Right. It's already called once in the super class so removing
>> this call should have no effect. I will remove it.
>>
>> -- daniel
>>
>>>
>>> Mandy
>>>
>>



From david.holmes at oracle.com  Fri Aug 30 07:21:00 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 30 Aug 2013 17:21:00 +1000
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: <52203F81.8080903@oracle.com>
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>,
	,
	<521F47DD.2020502@oracle.com>
	
	<521F6B08.4000902@oracle.com> <521F7AFD.3050703@oracle.com>
	<521F8BDE.8050304@oracle.com> <521F8D41.1010302@oracle.com>
	<521FA4F5.8060103@oracle.com> <521FA70A.9030908@oracle.com>
	<521FF518.7060803@oracle.com> <52203F81.8080903@oracle.com>
Message-ID: <522047DC.4030502@oracle.com>

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:

reportError doesn't need changing now that the field is volatile and you 
aren't doing sync.

MemoryHandler.java:

pushLevel should/could be volatile and the sync removed from getPushLevel.

In setPushLevel this seems to be unused code:

  262         LogManager manager = LogManager.getLogManager();

unless there is some obscure side-effect in calling getLogManager ??

setPushLevel might as well also be synchronized at the method level. All 
the Handler methods already include checkPermission inside the 
sync-block. Though I'm actually more inclined to change all the existing 
code to use sync-blocks so that checkPermission is done outside the lock 
region. But a consistent approach either way would be preferable.

StreamHandler.java

writer doesn't need to be volatile - AFAICS it is only accessed within 
synchronized methods.

Thanks,
David

On 30/08/2013 4:45 PM, Daniel Fuchs wrote:
> On 8/30/13 3:27 AM, David Holmes wrote:
>> Hi Daniel,
>>
>> As usual with these kinds of changes we start by trying to complete an
>> incomplete/incorrect synchronization pattern and get diverted into
>> changing the synchronization pattern. :) The latter of course has more
>> risk than the former.
>>
>> Making everything synchronized has the benefit that we don't need to
>> analyse the "real" methods to check what would happen if one of these
>> data values changed mid-method. Might be harmless, might not.
>> Atomicity makes things easy to reason about.
> Agreed. We can analyze the 'real methods' of Handler classes in the JDK.
> But I'm sure there are plenty of
> subclasses of handlers in applications out there that we don't know
> about. So we can't really be sure
> what the effect of changing synchronization might have on those subclasses.
>
>> Making the fields volatile and un-sync'ing the getters is a potential
>> optimization for readers. But are these fields that are read
>> frequently by multiple threads?
>
> At least three of them are accessed by isLoggable() which I believe is
> called very frequently by
> multiple threads (level, filter, and writer).
>
>> The downside of doing so is a negative performance impact inside the
>> "real" methods where every volatile field access requires
>> (platform-dependent) memory barriers.
> That - I think - should not be such an issue since the fields are private.
> I mean - we can see whether there are methods that do multiple access to
> the fields in the
> classes that define these fields - and fix that if necessary.
> For subclasses, they will have to call the getter, which will require
> synchronization anyway.
> I mean - for subclasses - isn't the fact that the getter accesses a
> volatile field or the fact that the
> getter is synchronized equivalent in terms of performance?
>
> JDK 8 is a major version of the JDK - so I think if we want to fix this
> bug it's
> probably better to do it now rather than in a minor update.
>
> It seems we have 5 choices:
>
> a. Not fixing
> b. Using regular 'synchronized' pattern [1]
> c. Using volatiles, synchronize setters only [2]
> d. Using volatiles, only synchronize setters when obviously necessary
> e. other? (like introducing new private locks - but I don't think
> anybody would want that)
>
> [1] 
> [2] 
>
> My own preference would lean to either b) or c).
>
> -- daniel
>
>
>>
>> David
>>
>> On 30/08/2013 5:54 AM, Daniel Fuchs wrote:
>>> On 8/29/13 9:45 PM, Mandy Chung wrote:
>>>> On 8/29/13 11:04 AM, Daniel Fuchs wrote:
>>>>> On 8/29/13 7:58 PM, Mandy Chung wrote:
>>>>>> On 8/29/13 9:46 AM, Daniel Fuchs wrote:
>>>>>>> Here is the new webrev implementing Jason's suggestion.
>>>>>>> Compared to previous webrev only Handler.java & StreamHandler.java
>>>>>>> have changed.
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>
>>>>>> Looks good.  I also agree that making those fields to be volatile
>>>>>> is a
>>>>>> good suggestion and only requires writer to acquire the lock.
>>>>>>
>>>>>> A minor comment:  The setter methods in Handler class are
>>>>>> synchronized
>>>>>> at the method entry whereas StreamHandler.setPushLevel synchronizes
>>>>>> after checkPermission() is called.  checkPermission doesn't need
>>>>>> to be
>>>>>> synchronized.  Either way is fine with me and it'd be good to do it
>>>>>> consistently.
>>>>>
>>>>> Hi Mandy,
>>>>>
>>>>> Are you suggesting I should put checkPermission() within
>>>>> the synchronized block? It might be more consistent with
>>>>> what the other setters do. Although as you state it does
>>>>> not matter much.
>>>>
>>>> Having a second thought - do the setters really need to be
>>>> synchronized?   My guess is that StreamHandler.publish is synchronized
>>>> so as to ensure that the log messages are sequential and not
>>>> interpersed
>>>> when multiple threads are publishing.  The spec is unclear. Perhaps it
>>>> worths looking into this further?
>>>
>>> I believe at least setEncodings() needs synchronization.
>>> setLevel() had it - so are we going to cause subtle race conditions
>>> if we remove it?
>>>
>>> My own feeling is that keeping setters synchronized might be better.
>>>
>>> We could of course say that a subclass which needs to prevent
>>> e.g. setFormatter() from being called concurrently with publish()
>>> should override setFormatter just for the purpose of synchronizing
>>> it...
>>>
>>>> One more minor note: MemoryHandler.pushLevel can also be made volatile.
>>>> L262: look like the log manager is not needed in the existing code.
>>>
>>> hmmm. Right. It's already called once in the super class so removing
>>> this call should have no effect. I will remove it.
>>>
>>> -- daniel
>>>
>>>>
>>>> Mandy
>>>>
>>>
>


From Alan.Bateman at oracle.com  Fri Aug 30 07:53:22 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 30 Aug 2013 08:53:22 +0100
Subject: RFR: 8023997 : j.l.String.join(java.lang.CharSequence,
	java.lang.Iterable) sample doesn't compile and is incorrect
In-Reply-To: <52203F4A.102@oracle.com>
References: <52203F4A.102@oracle.com>
Message-ID: <52204F72.90802@oracle.com>

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 
that doesn't seem right (at least I've always thought of examples/code 
fragments in the javadoc as just helpful, but non-normative, text). So 
maybe the bug report is also looking for @apiNote to be added?

-Alan.


From daniel.fuchs at oracle.com  Fri Aug 30 08:38:11 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 30 Aug 2013 10:38:11 +0200
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: <522047DC.4030502@oracle.com>
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>,
	,
	<521F47DD.2020502@oracle.com>
	
	<521F6B08.4000902@oracle.com> <521F7AFD.3050703@oracle.com>
	<521F8BDE.8050304@oracle.com> <521F8D41.1010302@oracle.com>
	<521FA4F5.8060103@oracle.com> <521FA70A.9030908@oracle.com>
	<521FF518.7060803@oracle.com> <52203F81.8080903@oracle.com>
	<522047DC.4030502@oracle.com>
Message-ID: <522059F3.7040408@oracle.com>

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 comments on [2]:
>
> Handler.java:
>
> reportError doesn't need changing now that the field is volatile and you
> aren't doing sync.

right. I will revert to original code.

> MemoryHandler.java:
>
> pushLevel should/could be volatile and the sync removed from getPushLevel.

right. thanks - I missed that.

> In setPushLevel this seems to be unused code:
>
>   262         LogManager manager = LogManager.getLogManager();
>
> unless there is some obscure side-effect in calling getLogManager ??

Well - yes it triggers the initialization of the logging system.
However the super class will already have called getLogManager() -
so this call should have no effect.  I will remove it.

> setPushLevel might as well also be synchronized at the method level. All
> the Handler methods already include checkPermission inside the
> sync-block. Though I'm actually more inclined to change all the existing
> code to use sync-blocks so that checkPermission is done outside the lock
> region. But a consistent approach either way would be preferable.

Agreed. Once I have removed the call to LogManager then the method can
be synchronized at method level.

> 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 regular synchronization was to allow isLoggable()
to be called concurrently with e.g. publish() - so I would think
it's better to make writer volatile too.

Thanks for the valuable comments! I will update the webrev and send out
a new revision...

best regards,

-- daniel

>
> Thanks,
> David
>
> On 30/08/2013 4:45 PM, Daniel Fuchs wrote:
>> On 8/30/13 3:27 AM, David Holmes wrote:
>>> Hi Daniel,
>>>
>>> As usual with these kinds of changes we start by trying to complete an
>>> incomplete/incorrect synchronization pattern and get diverted into
>>> changing the synchronization pattern. :) The latter of course has more
>>> risk than the former.
>>>
>>> Making everything synchronized has the benefit that we don't need to
>>> analyse the "real" methods to check what would happen if one of these
>>> data values changed mid-method. Might be harmless, might not.
>>> Atomicity makes things easy to reason about.
>> Agreed. We can analyze the 'real methods' of Handler classes in the JDK.
>> But I'm sure there are plenty of
>> subclasses of handlers in applications out there that we don't know
>> about. So we can't really be sure
>> what the effect of changing synchronization might have on those
>> subclasses.
>>
>>> Making the fields volatile and un-sync'ing the getters is a potential
>>> optimization for readers. But are these fields that are read
>>> frequently by multiple threads?
>>
>> At least three of them are accessed by isLoggable() which I believe is
>> called very frequently by
>> multiple threads (level, filter, and writer).
>>
>>> The downside of doing so is a negative performance impact inside the
>>> "real" methods where every volatile field access requires
>>> (platform-dependent) memory barriers.
>> That - I think - should not be such an issue since the fields are
>> private.
>> I mean - we can see whether there are methods that do multiple access to
>> the fields in the
>> classes that define these fields - and fix that if necessary.
>> For subclasses, they will have to call the getter, which will require
>> synchronization anyway.
>> I mean - for subclasses - isn't the fact that the getter accesses a
>> volatile field or the fact that the
>> getter is synchronized equivalent in terms of performance?
>>
>> JDK 8 is a major version of the JDK - so I think if we want to fix this
>> bug it's
>> probably better to do it now rather than in a minor update.
>>
>> It seems we have 5 choices:
>>
>> a. Not fixing
>> b. Using regular 'synchronized' pattern [1]
>> c. Using volatiles, synchronize setters only [2]
>> d. Using volatiles, only synchronize setters when obviously necessary
>> e. other? (like introducing new private locks - but I don't think
>> anybody would want that)
>>
>> [1] 
>> [2] 
>>
>> My own preference would lean to either b) or c).
>>
>> -- daniel
>>
>>
>>>
>>> David
>>>
>>> On 30/08/2013 5:54 AM, Daniel Fuchs wrote:
>>>> On 8/29/13 9:45 PM, Mandy Chung wrote:
>>>>> On 8/29/13 11:04 AM, Daniel Fuchs wrote:
>>>>>> On 8/29/13 7:58 PM, Mandy Chung wrote:
>>>>>>> On 8/29/13 9:46 AM, Daniel Fuchs wrote:
>>>>>>>> Here is the new webrev implementing Jason's suggestion.
>>>>>>>> Compared to previous webrev only Handler.java & StreamHandler.java
>>>>>>>> have changed.
>>>>>>>>
>>>>>>>> 
>>>>>>>>
>>>>>>>
>>>>>>> Looks good.  I also agree that making those fields to be volatile
>>>>>>> is a
>>>>>>> good suggestion and only requires writer to acquire the lock.
>>>>>>>
>>>>>>> A minor comment:  The setter methods in Handler class are
>>>>>>> synchronized
>>>>>>> at the method entry whereas StreamHandler.setPushLevel synchronizes
>>>>>>> after checkPermission() is called.  checkPermission doesn't need
>>>>>>> to be
>>>>>>> synchronized.  Either way is fine with me and it'd be good to do it
>>>>>>> consistently.
>>>>>>
>>>>>> Hi Mandy,
>>>>>>
>>>>>> Are you suggesting I should put checkPermission() within
>>>>>> the synchronized block? It might be more consistent with
>>>>>> what the other setters do. Although as you state it does
>>>>>> not matter much.
>>>>>
>>>>> Having a second thought - do the setters really need to be
>>>>> synchronized?   My guess is that StreamHandler.publish is synchronized
>>>>> so as to ensure that the log messages are sequential and not
>>>>> interpersed
>>>>> when multiple threads are publishing.  The spec is unclear. Perhaps it
>>>>> worths looking into this further?
>>>>
>>>> I believe at least setEncodings() needs synchronization.
>>>> setLevel() had it - so are we going to cause subtle race conditions
>>>> if we remove it?
>>>>
>>>> My own feeling is that keeping setters synchronized might be better.
>>>>
>>>> We could of course say that a subclass which needs to prevent
>>>> e.g. setFormatter() from being called concurrently with publish()
>>>> should override setFormatter just for the purpose of synchronizing
>>>> it...
>>>>
>>>>> One more minor note: MemoryHandler.pushLevel can also be made
>>>>> volatile.
>>>>> L262: look like the log manager is not needed in the existing code.
>>>>
>>>> hmmm. Right. It's already called once in the super class so removing
>>>> this call should have no effect. I will remove it.
>>>>
>>>> -- daniel
>>>>
>>>>>
>>>>> Mandy
>>>>>
>>>>
>>



From paul.sandoz at oracle.com  Fri Aug 30 09:07:08 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 30 Aug 2013 11:07:08 +0200
Subject: Potential issue with CHM.toArray
In-Reply-To: <521F3430.4050802@cs.oswego.edu>
References: <41149C78-1097-4B86-9E3F-147CA859697B@oracle.com>
	<521DF795.8070905@gmail.com> <521F3430.4050802@cs.oswego.edu>
Message-ID: <3F252F94-A60C-4000-A835-26172726C16D@oracle.com>


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 in "forward" direction, leading to from smaller to
>> larger tables?
> 
> They aren't required to be -- to preserve nonblockingness of traversal,
> they can revert to old versions of table. This is legal but disconcerting
> and surprising. I now think that giving up on pure non-blockingness
> (only in the case of concurrent resizes) and helping to transfer
> (which can block), thus forcing monotonicity,  is  a better policy.

OK.


> An update is forthcoming. (Thanks to Paul for finding a use case
> leading to this better policy!)
> 

I can't take credit for that. 

The test code i pasted was slightly modified version of a JDK test written a while ago by Martin and which has recently been intermittently failing. I just tweaked that test to increase the probability of failure.

Paul.

From david.holmes at oracle.com  Fri Aug 30 10:13:33 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 30 Aug 2013 20:13:33 +1000
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: <522059F3.7040408@oracle.com>
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>,
	,
	<521F47DD.2020502@oracle.com>
	
	<521F6B08.4000902@oracle.com> <521F7AFD.3050703@oracle.com>
	<521F8BDE.8050304@oracle.com> <521F8D41.1010302@oracle.com>
	<521FA4F5.8060103@oracle.com> <521FA70A.9030908@oracle.com>
	<521FF518.7060803@oracle.com> <52203F81.8080903@oracle.com>
	<522047DC.4030502@oracle.com> <522059F3.7040408@oracle.com>
Message-ID: <5220704D.1040108@oracle.com>

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 regular synchronization was to allow isLoggable()
> to be called concurrently with e.g. publish() - so I would think
> it's better to make writer volatile too.

Agreed. I simply didn't spot writer in isLoggable.

David

> Thanks for the valuable comments! I will update the webrev and send out
> a new revision...
>
> best regards,
>
> -- daniel
>
>>
>> Thanks,
>> David
>>
>> On 30/08/2013 4:45 PM, Daniel Fuchs wrote:
>>> On 8/30/13 3:27 AM, David Holmes wrote:
>>>> Hi Daniel,
>>>>
>>>> As usual with these kinds of changes we start by trying to complete an
>>>> incomplete/incorrect synchronization pattern and get diverted into
>>>> changing the synchronization pattern. :) The latter of course has more
>>>> risk than the former.
>>>>
>>>> Making everything synchronized has the benefit that we don't need to
>>>> analyse the "real" methods to check what would happen if one of these
>>>> data values changed mid-method. Might be harmless, might not.
>>>> Atomicity makes things easy to reason about.
>>> Agreed. We can analyze the 'real methods' of Handler classes in the JDK.
>>> But I'm sure there are plenty of
>>> subclasses of handlers in applications out there that we don't know
>>> about. So we can't really be sure
>>> what the effect of changing synchronization might have on those
>>> subclasses.
>>>
>>>> Making the fields volatile and un-sync'ing the getters is a potential
>>>> optimization for readers. But are these fields that are read
>>>> frequently by multiple threads?
>>>
>>> At least three of them are accessed by isLoggable() which I believe is
>>> called very frequently by
>>> multiple threads (level, filter, and writer).
>>>
>>>> The downside of doing so is a negative performance impact inside the
>>>> "real" methods where every volatile field access requires
>>>> (platform-dependent) memory barriers.
>>> That - I think - should not be such an issue since the fields are
>>> private.
>>> I mean - we can see whether there are methods that do multiple access to
>>> the fields in the
>>> classes that define these fields - and fix that if necessary.
>>> For subclasses, they will have to call the getter, which will require
>>> synchronization anyway.
>>> I mean - for subclasses - isn't the fact that the getter accesses a
>>> volatile field or the fact that the
>>> getter is synchronized equivalent in terms of performance?
>>>
>>> JDK 8 is a major version of the JDK - so I think if we want to fix this
>>> bug it's
>>> probably better to do it now rather than in a minor update.
>>>
>>> It seems we have 5 choices:
>>>
>>> a. Not fixing
>>> b. Using regular 'synchronized' pattern [1]
>>> c. Using volatiles, synchronize setters only [2]
>>> d. Using volatiles, only synchronize setters when obviously necessary
>>> e. other? (like introducing new private locks - but I don't think
>>> anybody would want that)
>>>
>>> [1] 
>>> [2] 
>>>
>>> My own preference would lean to either b) or c).
>>>
>>> -- daniel
>>>
>>>
>>>>
>>>> David
>>>>
>>>> On 30/08/2013 5:54 AM, Daniel Fuchs wrote:
>>>>> On 8/29/13 9:45 PM, Mandy Chung wrote:
>>>>>> On 8/29/13 11:04 AM, Daniel Fuchs wrote:
>>>>>>> On 8/29/13 7:58 PM, Mandy Chung wrote:
>>>>>>>> On 8/29/13 9:46 AM, Daniel Fuchs wrote:
>>>>>>>>> Here is the new webrev implementing Jason's suggestion.
>>>>>>>>> Compared to previous webrev only Handler.java & StreamHandler.java
>>>>>>>>> have changed.
>>>>>>>>>
>>>>>>>>> 
>>>>>>>>>
>>>>>>>>
>>>>>>>> Looks good.  I also agree that making those fields to be volatile
>>>>>>>> is a
>>>>>>>> good suggestion and only requires writer to acquire the lock.
>>>>>>>>
>>>>>>>> A minor comment:  The setter methods in Handler class are
>>>>>>>> synchronized
>>>>>>>> at the method entry whereas StreamHandler.setPushLevel synchronizes
>>>>>>>> after checkPermission() is called.  checkPermission doesn't need
>>>>>>>> to be
>>>>>>>> synchronized.  Either way is fine with me and it'd be good to do it
>>>>>>>> consistently.
>>>>>>>
>>>>>>> Hi Mandy,
>>>>>>>
>>>>>>> Are you suggesting I should put checkPermission() within
>>>>>>> the synchronized block? It might be more consistent with
>>>>>>> what the other setters do. Although as you state it does
>>>>>>> not matter much.
>>>>>>
>>>>>> Having a second thought - do the setters really need to be
>>>>>> synchronized?   My guess is that StreamHandler.publish is
>>>>>> synchronized
>>>>>> so as to ensure that the log messages are sequential and not
>>>>>> interpersed
>>>>>> when multiple threads are publishing.  The spec is unclear.
>>>>>> Perhaps it
>>>>>> worths looking into this further?
>>>>>
>>>>> I believe at least setEncodings() needs synchronization.
>>>>> setLevel() had it - so are we going to cause subtle race conditions
>>>>> if we remove it?
>>>>>
>>>>> My own feeling is that keeping setters synchronized might be better.
>>>>>
>>>>> We could of course say that a subclass which needs to prevent
>>>>> e.g. setFormatter() from being called concurrently with publish()
>>>>> should override setFormatter just for the purpose of synchronizing
>>>>> it...
>>>>>
>>>>>> One more minor note: MemoryHandler.pushLevel can also be made
>>>>>> volatile.
>>>>>> L262: look like the log manager is not needed in the existing code.
>>>>>
>>>>> hmmm. Right. It's already called once in the super class so removing
>>>>> this call should have no effect. I will remove it.
>>>>>
>>>>> -- daniel
>>>>>
>>>>>>
>>>>>> Mandy
>>>>>>
>>>>>
>>>
>


From shanliang.jiang at oracle.com  Fri Aug 30 11:16:26 2013
From: shanliang.jiang at oracle.com (shanliang.jiang at oracle.com)
Date: Fri, 30 Aug 2013 11:16:26 +0000
Subject: hg: jdk8/tl/jdk: 6566891: RMIConnector: map value referencing map key
	in WeakHashMap prevents map entry to be removed
Message-ID: <20130830111652.648B762418@hg.openjdk.java.net>

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

! src/share/classes/javax/management/remote/rmi/RMIConnector.java
+ test/javax/management/remote/mandatory/connection/RMIConnectorInternalMapTest.java
+ test/javax/management/remote/mandatory/connection/RMIConnectorNullSubjectConnTest.java



From daniel.fuchs at oracle.com  Fri Aug 30 11:50:56 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 30 Aug 2013 13:50:56 +0200
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: <522059F3.7040408@oracle.com>
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>,
	,
	<521F47DD.2020502@oracle.com>
	
	<521F6B08.4000902@oracle.com> <521F7AFD.3050703@oracle.com>
	<521F8BDE.8050304@oracle.com> <521F8D41.1010302@oracle.com>
	<521FA4F5.8060103@oracle.com> <521FA70A.9030908@oracle.com>
	<521FF518.7060803@oracle.com> <52203F81.8080903@oracle.com>
	<522047DC.4030502@oracle.com> <522059F3.7040408@oracle.com>
Message-ID: <52208720.90305@oracle.com>

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 [2]
 >>> d. Using volatiles, only synchronize setters when obviously necessary
 >>> e. other? (like introducing new private locks - but I don't think
 >>> anybody would want that)
 >>>
 >>> [1] 
 >>> [2] 
 >>>
 >>> My own preference would lean to either b) or c).



On 8/30/13 10:38 AM, Daniel Fuchs wrote:
> 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 comments on [2]:
>>
>> Handler.java:
>>
>> reportError doesn't need changing now that the field is volatile and you
>> aren't doing sync.
>
> right. I will revert to original code.
>
>> MemoryHandler.java:
>>
>> pushLevel should/could be volatile and the sync removed from
>> getPushLevel.
>
> right. thanks - I missed that.
>
>> In setPushLevel this seems to be unused code:
>>
>>   262         LogManager manager = LogManager.getLogManager();
>>
>> unless there is some obscure side-effect in calling getLogManager ??
>
> Well - yes it triggers the initialization of the logging system.
> However the super class will already have called getLogManager() -
> so this call should have no effect.  I will remove it.
>
>> setPushLevel might as well also be synchronized at the method level. All
>> the Handler methods already include checkPermission inside the
>> sync-block. Though I'm actually more inclined to change all the existing
>> code to use sync-blocks so that checkPermission is done outside the lock
>> region. But a consistent approach either way would be preferable.
>
> Agreed. Once I have removed the call to LogManager then the method can
> be synchronized at method level.
>
>> 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 regular synchronization was to allow isLoggable()
> to be called concurrently with e.g. publish() - so I would think
> it's better to make writer volatile too.
>
> Thanks for the valuable comments! I will update the webrev and send out
> a new revision...
>
> best regards,
>
> -- daniel
>
>>
>> Thanks,
>> David
>>
>> On 30/08/2013 4:45 PM, Daniel Fuchs wrote:
>>> On 8/30/13 3:27 AM, David Holmes wrote:
>>>> Hi Daniel,
>>>>
>>>> As usual with these kinds of changes we start by trying to complete an
>>>> incomplete/incorrect synchronization pattern and get diverted into
>>>> changing the synchronization pattern. :) The latter of course has more
>>>> risk than the former.
>>>>
>>>> Making everything synchronized has the benefit that we don't need to
>>>> analyse the "real" methods to check what would happen if one of these
>>>> data values changed mid-method. Might be harmless, might not.
>>>> Atomicity makes things easy to reason about.
>>> Agreed. We can analyze the 'real methods' of Handler classes in the JDK.
>>> But I'm sure there are plenty of
>>> subclasses of handlers in applications out there that we don't know
>>> about. So we can't really be sure
>>> what the effect of changing synchronization might have on those
>>> subclasses.
>>>
>>>> Making the fields volatile and un-sync'ing the getters is a potential
>>>> optimization for readers. But are these fields that are read
>>>> frequently by multiple threads?
>>>
>>> At least three of them are accessed by isLoggable() which I believe is
>>> called very frequently by
>>> multiple threads (level, filter, and writer).
>>>
>>>> The downside of doing so is a negative performance impact inside the
>>>> "real" methods where every volatile field access requires
>>>> (platform-dependent) memory barriers.
>>> That - I think - should not be such an issue since the fields are
>>> private.
>>> I mean - we can see whether there are methods that do multiple access to
>>> the fields in the
>>> classes that define these fields - and fix that if necessary.
>>> For subclasses, they will have to call the getter, which will require
>>> synchronization anyway.
>>> I mean - for subclasses - isn't the fact that the getter accesses a
>>> volatile field or the fact that the
>>> getter is synchronized equivalent in terms of performance?
>>>
>>> JDK 8 is a major version of the JDK - so I think if we want to fix this
>>> bug it's
>>> probably better to do it now rather than in a minor update.
>>>
>>> It seems we have 5 choices:
>>>
>>> a. Not fixing
>>> b. Using regular 'synchronized' pattern [1]
>>> c. Using volatiles, synchronize setters only [2]
>>> d. Using volatiles, only synchronize setters when obviously necessary
>>> e. other? (like introducing new private locks - but I don't think
>>> anybody would want that)
>>>
>>> [1] 
>>> [2] 
>>>
>>> My own preference would lean to either b) or c).
>>>
>>> -- daniel
>>>
>>>
>>>>
>>>> David
>>>>
>>>> On 30/08/2013 5:54 AM, Daniel Fuchs wrote:
>>>>> On 8/29/13 9:45 PM, Mandy Chung wrote:
>>>>>> On 8/29/13 11:04 AM, Daniel Fuchs wrote:
>>>>>>> On 8/29/13 7:58 PM, Mandy Chung wrote:
>>>>>>>> On 8/29/13 9:46 AM, Daniel Fuchs wrote:
>>>>>>>>> Here is the new webrev implementing Jason's suggestion.
>>>>>>>>> Compared to previous webrev only Handler.java & StreamHandler.java
>>>>>>>>> have changed.
>>>>>>>>>
>>>>>>>>> 
>>>>>>>>>
>>>>>>>>
>>>>>>>> Looks good.  I also agree that making those fields to be volatile
>>>>>>>> is a
>>>>>>>> good suggestion and only requires writer to acquire the lock.
>>>>>>>>
>>>>>>>> A minor comment:  The setter methods in Handler class are
>>>>>>>> synchronized
>>>>>>>> at the method entry whereas StreamHandler.setPushLevel synchronizes
>>>>>>>> after checkPermission() is called.  checkPermission doesn't need
>>>>>>>> to be
>>>>>>>> synchronized.  Either way is fine with me and it'd be good to do it
>>>>>>>> consistently.
>>>>>>>
>>>>>>> Hi Mandy,
>>>>>>>
>>>>>>> Are you suggesting I should put checkPermission() within
>>>>>>> the synchronized block? It might be more consistent with
>>>>>>> what the other setters do. Although as you state it does
>>>>>>> not matter much.
>>>>>>
>>>>>> Having a second thought - do the setters really need to be
>>>>>> synchronized?   My guess is that StreamHandler.publish is
>>>>>> synchronized
>>>>>> so as to ensure that the log messages are sequential and not
>>>>>> interpersed
>>>>>> when multiple threads are publishing.  The spec is unclear.
>>>>>> Perhaps it
>>>>>> worths looking into this further?
>>>>>
>>>>> I believe at least setEncodings() needs synchronization.
>>>>> setLevel() had it - so are we going to cause subtle race conditions
>>>>> if we remove it?
>>>>>
>>>>> My own feeling is that keeping setters synchronized might be better.
>>>>>
>>>>> We could of course say that a subclass which needs to prevent
>>>>> e.g. setFormatter() from being called concurrently with publish()
>>>>> should override setFormatter just for the purpose of synchronizing
>>>>> it...
>>>>>
>>>>>> One more minor note: MemoryHandler.pushLevel can also be made
>>>>>> volatile.
>>>>>> L262: look like the log manager is not needed in the existing code.
>>>>>
>>>>> hmmm. Right. It's already called once in the super class so removing
>>>>> this call should have no effect. I will remove it.
>>>>>
>>>>> -- daniel
>>>>>
>>>>>>
>>>>>> Mandy
>>>>>>
>>>>>
>>>
>



From jhuxhorn at googlemail.com  Fri Aug 30 14:01:54 2013
From: jhuxhorn at googlemail.com (=?UTF-8?Q?J=C3=B6rn_Huxhorn?=)
Date: Fri, 30 Aug 2013 16:01:54 +0200
Subject: State of Reflection.getCallerClass replacement in Java 8
Message-ID: 

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 mail I'm aware of is?http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019488.html

What's the state of this discussion?

Cheers,
J?rn.


From Alan.Bateman at oracle.com  Fri Aug 30 14:12:56 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 30 Aug 2013 15:12:56 +0100
Subject: State of Reflection.getCallerClass replacement in Java 8
In-Reply-To: 
References: 
Message-ID: <5220A868.9020104@oracle.com>

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 alternatives are way slower.
>
> The latest mail I'm aware of is http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019488.html
>
> What's the state of this discussion?
>
You are on the right list. Mandy Chung is planning to re-start the 
discussion with a proposal very soon.

-Alan.


From nicholas+openjdk at nicholaswilliams.net  Fri Aug 30 14:56:28 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Fri, 30 Aug 2013 09:56:28 -0500
Subject: State of Reflection.getCallerClass replacement in Java 8
In-Reply-To: <5220A868.9020104@oracle.com>
References: 
	<5220A868.9020104@oracle.com>
Message-ID: <9D8C1447-E5E8-4021-A7F6-27F175DD3BA4@nicholaswilliams.net>


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 has also been some discussion about doing a proper public API since all alternatives are way slower.
>> 
>> The latest mail I'm aware of is http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019488.html
>> 
>> What's the state of this discussion?
>> 
> You are on the right list. Mandy Chung is planning to re-start the discussion with a proposal very soon.

And I have a patch that I will be proposing over the weekend.

Nick

From jason_mehrens at hotmail.com  Fri Aug 30 17:04:31 2013
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Fri, 30 Aug 2013 12:04:31 -0500
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: <52208720.90305@oracle.com>
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>, ,
	, ,
	<521F47DD.2020502@oracle.com>,
	,
	<521F6B08.4000902@oracle.com>
	<521F7AFD.3050703@oracle.com>,<521F8BDE.8050304@oracle.com>
	<521F8D41.1010302@oracle.com>,<521FA4F5.8060103@oracle.com>
	<521FA70A.9030908@oracle.com>,<521FF518.7060803@oracle.com>
	<52203F81.8080903@oracle.com>,<522047DC.4030502@oracle.com>
	<522059F3.7040408@oracle.com>,<52208720.90305@oracle.com>
Message-ID: 

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.fuchs at oracle.com
> To: david.holmes at oracle.com
> Subject: Re: RFR: JDK-6823527: java.util.logging.Handler has thread safety	issues
> CC: core-libs-dev at openjdk.java.net
> 
> Hi,
> 
> Please find below an updated patch for solution (c)
> 
> 
> 
> best regards,
> 
> -- daniel
> 
 		 	   		  

From daniel.fuchs at oracle.com  Fri Aug 30 17:12:28 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 30 Aug 2013 19:12:28 +0200
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: 
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>, ,
	, ,
	<521F47DD.2020502@oracle.com>,
	,
	<521F6B08.4000902@oracle.com> <521F7AFD.3050703@oracle.com>,
	<521F8BDE.8050304@oracle.com> <521F8D41.1010302@oracle.com>,
	<521FA4F5.8060103@oracle.com> <521FA70A.9030908@oracle.com>,
	<521FF518.7060803@oracle.com> <52203F81.8080903@oracle.com>,
	<522047DC.4030502@oracle.com> <522059F3.7040408@oracle.com>,
	<52208720.90305@oracle.com>
	
Message-ID: <5220D27C.2080405@oracle.com>

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 code
have a tendency to come back and bite you ;-(...

isLoggable() is not synchronized and no longer calls synchronized
methods since we're now using volatiles.

So it can now be called by Thread A even if Thread B has locked
the handler.

Or did I miss something?

best regards,

-- daniel


>
> Jason
>
>  > Date: Fri, 30 Aug 2013 13:50:56 +0200
>  > From: daniel.fuchs at oracle.com
>  > To: david.holmes at oracle.com
>  > Subject: Re: RFR: JDK-6823527: java.util.logging.Handler has thread
> safety issues
>  > CC: core-libs-dev at openjdk.java.net
>  >
>  > Hi,
>  >
>  > Please find below an updated patch for solution (c)
>  >
>  > 
>  >
>  > best regards,
>  >
>  > -- daniel
>  >



From jason_mehrens at hotmail.com  Fri Aug 30 17:30:52 2013
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Fri, 30 Aug 2013 12:30:52 -0500
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: <5220D27C.2080405@oracle.com>
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>, ,
	, ,
	<521F47DD.2020502@oracle.com>,
	,
	<521F6B08.4000902@oracle.com>
	<521F7AFD.3050703@oracle.com>,<521F8BDE.8050304@oracle.com>
	<521F8D41.1010302@oracle.com>,<521FA4F5.8060103@oracle.com>
	<521FA70A.9030908@oracle.com>,<521FF518.7060803@oracle.com>
	<52203F81.8080903@oracle.com>,<522047DC.4030502@oracle.com>
	<522059F3.7040408@oracle.com>,<52208720.90305@oracle.com>
	,
	<5220D27C.2080405@oracle.com>
Message-ID: 

> 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 volatiles.
> 
> So it can now be called by Thread A even if Thread B has locked
> the handler.
> 
> Or did I miss something?
 
Yes and no.  Place this code in the actual context it is used (Logger.log(LogRecord)) and you'll find that Thread A and B will only call publish->isLoggable not isLoggable->publish->isLoggable.  It is written that way to avoid double filtering.
 
Jason
 		 	   		  

From jhuxhorn at googlemail.com  Fri Aug 30 17:56:58 2013
From: jhuxhorn at googlemail.com (=?UTF-8?Q?J=C3=B6rn_Huxhorn?=)
Date: Fri, 30 Aug 2013 19:56:58 +0200
Subject: =?UTF-8?Q?Re=3A_State_of_Reflection.getCallerClass_replacement_in_Java_8?=
In-Reply-To: <9D8C1447-E5E8-4021-A7F6-27F175DD3BA4@nicholaswilliams.net>
References: 
	<5220A868.9020104@oracle.com>
	<9D8C1447-E5E8-4021-A7F6-27F175DD3BA4@nicholaswilliams.net>
Message-ID: 

On 30. August 2013 at 16:56:31, Nick Williams (nicholas+openjdk at 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 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 mail I'm aware of is http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019488.html?
>>?
>> What's the state of this discussion??
>>?
> You are on the right list. Mandy Chung is planning to re-start the discussion with a proposal very soon.?

And I have a patch that I will be proposing over the weekend.?

Nick
Ah, nice. Thanks. :)

Just wanted to make sure that something is still going on. A j8 without a good solution would be a nightmare?



J?rn


From jonathan.gibbons at oracle.com  Fri Aug 30 18:50:05 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 30 Aug 2013 18:50:05 +0000
Subject: hg: jdk8/tl/langtools: 8023700: Use non breaking space in various
	labels
Message-ID: <20130830185013.C200E6243A@hg.openjdk.java.net>

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.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! test/com/sun/javadoc/testNavigation/TestNavigation.java
! test/com/sun/javadoc/testProfiles/TestProfiles.java



From mandy.chung at oracle.com  Fri Aug 30 19:47:06 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 30 Aug 2013 12:47:06 -0700
Subject: State of Reflection.getCallerClass replacement in Java 8
In-Reply-To: <9D8C1447-E5E8-4021-A7F6-27F175DD3BA4@nicholaswilliams.net>
References: 
	<5220A868.9020104@oracle.com>
	<9D8C1447-E5E8-4021-A7F6-27F175DD3BA4@nicholaswilliams.net>
Message-ID: <5220F6BA.10804@oracle.com>

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 and any change done for JDK 8 by the API interface 
freeze (i.e. 10/10) [1].  I'll spend some of my time next few weeks on 
this work.

> And I have a patch that I will be proposing over the weekend.
>
> Nick

Nick - good to know that your patch will be ready for discussion. That 
was one thing I plan to ask.

Mandy
[1] http://openjdk.java.net/projects/jdk8/milestones#API_Interface_Freeze


From mike.duigou at oracle.com  Fri Aug 30 20:30:38 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 30 Aug 2013 13:30:38 -0700
Subject: RFR: 8024014 & 8024015 : (xs) TEST.groups updates
In-Reply-To: <52202FA8.1010405@oracle.com>
References: <1BF45EA9-0AD8-4E8E-85F6-20E13D2C9E2F@oracle.com>
	<52202FA8.1010405@oracle.com>
Message-ID: <71E57086-0BAF-41D6-BB1E-6815DC3FF922@oracle.com>


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_concurrent. The main advantage is that it's easier/quicker to test individual components. The intent is that the test groups are aligned with bug database sub-components.
>> 
>> The second change moves some important lambda related tests from languishing in obscurity in the jdk_other group to the jdk_lang group to reflect their importance and relation to other tests. These tests are contained in the jdk/lambda directory.
>> 
>> The combined webrev is here:
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8024015/0/webrev/
>> 
>> The effect of these changes won't be visible to most people until JDK-8015068 is integrated.
>> 
>> Thanks,
>> 
>> Mike
> The jdk_other group was initially created to match the existing jdk_other make file target so this is why jdk/lambda is there. I agree with moving it as it is somewhat obscure.
> 
> I'm not sure about splitting up jdk_util as proposed as it doesn't look very maintainable. Have you considered just limiting this to simple groups for java/util/stream/** and java/util/concurrent/** and not try carve up the tests in java/util?

Did you see David Holmes' suggestion? Do you think it's adequate? I agree about the maintainability aspect as I really felt guilty re-creating FILES_JAVA.gmk...

> If someone is changing something in the collection classes then is it a big deal to run all of the java/util/** tests?

Having a smaller subset (larger than a singleton) is always of some value. Collections by itself is about 30% of total util so there is a nice turn around reduction for iterative dev/test.

> If there are good reasons then maybe it's time to look at how the tests are organized instead.
> 
> -Alan.



From jonathan.gibbons at oracle.com  Fri Aug 30 22:16:09 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 30 Aug 2013 22:16:09 +0000
Subject: hg: jdk8/tl/langtools: 8024093: Two *.rej files checked in to
	langtools/test directory
Message-ID: <20130830221612.C01AF62443@hg.openjdk.java.net>

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/javac/diags/examples/MrefStat1.java.rej



From bhavesh.x.patel at oracle.com  Fri Aug 30 23:00:17 2013
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Fri, 30 Aug 2013 23:00:17 +0000
Subject: hg: jdk8/tl/langtools: 7198273: RFE : Javadoc Accessibility :
	Hyperlinks should contain text or an image with alt text
Message-ID: <20130830230023.2444562447@hg.openjdk.java.net>

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/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css
! test/com/sun/javadoc/AccessSkipNav/AccessSkipNav.java
! test/com/sun/javadoc/testNavigation/TestNavigation.java



From bhavesh.x.patel at oracle.com  Fri Aug 30 23:18:07 2013
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Fri, 30 Aug 2013 23:18:07 +0000
Subject: hg: jdk8/tl/langtools: 8015882: Javadoc prints NPE when using Taglet
Message-ID: <20130830231814.D085462448@hg.openjdk.java.net>

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
! test/com/sun/javadoc/testLegacyTaglet/C.java
+ test/com/sun/javadoc/testLegacyTaglet/Check.java
! test/com/sun/javadoc/testLegacyTaglet/TestLegacyTaglet.java



From jonathan.gibbons at oracle.com  Fri Aug 30 23:27:42 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 30 Aug 2013 23:27:42 +0000
Subject: hg: jdk8/tl/langtools: 8008367: Sub-packages missing from Profiles
	javadoc
Message-ID: <20130830232747.8DC6E6244C@hg.openjdk.java.net>

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



From bhavesh.x.patel at oracle.com  Fri Aug 30 23:40:18 2013
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Fri, 30 Aug 2013 23:40:18 +0000
Subject: hg: jdk8/tl/langtools: 8022738: doclet should only generate
	functional interface text if source >= 8
Message-ID: <20130830234023.0A39A6244D@hg.openjdk.java.net>

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/ClassDocImpl.java
! src/share/classes/com/sun/tools/javadoc/DocEnv.java
! test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java
+ test/com/sun/javadoc/testLambdaFeature/pkg1/FuncInf.java



From jonathan.gibbons at oracle.com  Sat Aug 31 00:37:22 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Sat, 31 Aug 2013 00:37:22 +0000
Subject: hg: jdk8/tl/langtools: 8015663: Need to supply tests to provide
	javadoc for profiles support code coverage
Message-ID: <20130831003729.303AE62453@hg.openjdk.java.net>

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.stepanova at oracle.com

! test/com/sun/javadoc/testProfiles/TestProfiles.java
+ test/com/sun/javadoc/testProfiles/TestProfilesConfiguration.java
! test/com/sun/javadoc/testProfiles/pkg2/Class1Pkg2.java
+ test/com/sun/javadoc/testProfiles/pkg2/ClassError.java
+ test/com/sun/javadoc/testProfiles/pkg2/ClassException.java
+ test/com/sun/javadoc/testProfiles/pkgDeprecated/Class1PkgDeprecated.java
+ test/com/sun/javadoc/testProfiles/pkgDeprecated/package-info.java
! test/com/sun/javadoc/testProfiles/profile-rtjar-includes.txt



From dan.xu at oracle.com  Fri Aug 30 23:46:11 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Fri, 30 Aug 2013 23:46:11 +0000
Subject: hg: jdk8/tl/jdk: 8023765: Improve MaxPathLength.java testcase and
	reduce its test load; ...
Message-ID: <20130830234645.ED4336244F@hg.openjdk.java.net>

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.txt
! test/java/io/File/MaxPathLength.java



From ali.ebrahimi1781 at gmail.com  Sat Aug 31 06:25:50 2013
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Sat, 31 Aug 2013 10:55:50 +0430
Subject: Review: lamda expressions and bulk data operations on collections.
In-Reply-To: <5220F467.8020209@oracle.com>
References: <521F93F8.50809@oracle.com> <521FA346.9090603@oracle.com>
	<5220F467.8020209@oracle.com>
Message-ID: 

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 following names:
mapR   ==== map  (R === Reference Type)
mapI    ==== mapToInt
mapL   ==== mapToLong
mapD  ==== mapToDouble

comparingR   ==== comparing
comparingI    ==== comparingInt
comparingL   ==== comparingLong
comparingD  ==== comparingDouble

All method names have same length.


Best Regards,
Ali Ebrahmi


On Sat, Aug 31, 2013 at 12:07 AM, Andrey Nazarov <
andrey.x.nazarov at oracle.com> wrote:

> Webrev is here
> http://cr.openjdk.java.net/~anazarov/jdk8-demo-bulkoperations/webrev.00/
> <
> http://cr.openjdk.java.net/%7Eanazarov/jdk8-demo-bulkoperations/webrev.00/
> >
> Mail server removes attachments.
>
> --Andrey
> On 29.08.2013 23:38, Alan Bateman wrote:
> > On 29/08/2013 19:33, Andrey Nazarov wrote:
> >> Hi guys,
> >>
> >> We want to push our demo code for lambda expression and bulk data
> >> operations.
> >> Could you please review this code? Webrev is attached.
> >>
> >>
> >> --Andrey.
> > Your mail didn't have an attachment, it probably was dropped by the
> > mail server. Can you publish on a HTTP server so that it can be browsed?
> >
> > -Alan.
>
>
>


From david.holmes at oracle.com  Sat Aug 31 12:05:16 2013
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 31 Aug 2013 22:05:16 +1000
Subject: RFR: JDK-6823527: java.util.logging.Handler has thread safety
	issues
In-Reply-To: 
References: <521F2592.4060604@oracle.com>, <521F3173.1050801@oracle.com>, ,
	, ,
	<521F47DD.2020502@oracle.com>,
	,
	<521F6B08.4000902@oracle.com> <521F7AFD.3050703@oracle.com>,
	<521F8BDE.8050304@oracle.com> <521F8D41.1010302@oracle.com>,
	<521FA4F5.8060103@oracle.com> <521FA70A.9030908@oracle.com>,
	<521FF518.7060803@oracle.com> <52203F81.8080903@oracle.com>,
	<522047DC.4030502@oracle.com> <522059F3.7040408@oracle.com>,
	<52208720.90305@oracle.com>
	
Message-ID: <5221DBFC.8020109@oracle.com>

On 31/08/2013 3:04 AM, 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.

I'm not sure I'd agree with that. If you moved isLoggable outside the 
sync region you could get inconsistent logging results if the log level 
is changed after the check - eg thread A is logging while the level is 
'high' and has checked isLoggable and it returned true and it gets 
preempted. Thread B changes the log level and adds a record to the log 
indicating that. Thread A then continues and you appear to get a "wrong" 
log entry.

Anyway definitely a future RFE not something to be modified for this issue.

Cheers,
David

> Jason
>
>> Date: Fri, 30 Aug 2013 13:50:56 +0200
>> From: daniel.fuchs at oracle.com
>> To: david.holmes at oracle.com
>> Subject: Re: RFR: JDK-6823527: java.util.logging.Handler has thread safety	issues
>> CC: core-libs-dev at openjdk.java.net
>>
>> Hi,
>>
>> Please find below an updated patch for solution (c)
>>
>> 
>>
>> best regards,
>>
>> -- daniel
>>
>   		 	   		
>


From mike.duigou at oracle.com  Sat Aug 31 21:13:15 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Sat, 31 Aug 2013 14:13:15 -0700
Subject: StringJoiner: detect or fix delimiter collision?
In-Reply-To: <52218FE6.7000804@bluewin.ch>
References: <51673A45.8060908@oracle.com>
	<1374608627412-145039.post@n7.nabble.com>
	
	<52218FE6.7000804@bluewin.ch>
Message-ID: 


On Aug 30 2013, at 23:40 , Philip Hodges wrote:
> ...
> 
> Why is there such a bandwagon rolling for this "convenience" feature?

Perhaps others just don't agree with you. The choice of functionality offered in the JDK 8 StringJoiner was not arbitrary or haphazardly chosen. If it doesn't meet your particular needs, I am sorry to hear that. Our belief as the proposers is that it offers a reasonable mix of functionality and simplicity to cover useful number of requirements. Our intent was certainly not to create the kitchen magician [1] of string joiners that attempted to incorporate every conceivable option. In particular your concerns about escaping are out of scope for the joiner in part because

Collection strings;

String concat = strings.stream().map(MyUtils::escape).collect(Collections.joining(","));

seems like an adequate and flexible solution to most people.

> We already have joiners in apache commons and guava.

This is the reason that StringJoiner was considered for JDK--that many others were "rolling their own".

> At first I thought they were cool. Then I tried to use them in anger.
> And was forced to roll my own.

I would encourage you to share your implementation or the javadocs as grist for discussion.  An actual alternative is the *only* thing that is likely to be persuasive.

> That can't be right.

Sometimes it is. The JDK doesn't make any attempt to satisfy everyone (or anyone). We all end up writing lots of non-business logic utility functions to bridge gaps in what JDK offers. This is normal. And, if it turns out to be something lots of people need then it's entirely possible that it could be added to the JDK.

Mike

[1] https://www.youtube.com/watch?v=cGVG9xLHb84

> 
> A more elaborate offically blessed feature that
> only does half the job is worse than useless.
> Without the extra complex ability to detect or avoid collisions
> it is neither "nice", nor a "Good Thing".
> 
> Phil
> 
> http://www.techempower.com/blog/2013/03/26/everything-about-java-8/
> 
> "StringJoiner and String.join(...) are long, long overdue. They are so long overdue that the vast majority of Java developers likely have already written or have found utilities for joining strings, but it is nice for the JDK to finally provide this itself. Everyone has encountered situations where joining strings is required, and it is a Good Thing? that we can now express that through a standard API that every Java developer (eventually) will know. "
> 
> 
> On 2013-07-23 22:09, Mike Duigou wrote:
>> 
>> On Jul 23 2013, at 12:43 , ph wrote:
>> 
>>> didn't see delimiter collision mentioned anywhere - are you really offering
>>> an interface that only joins a list of entries without escaping or quoting
>>> or even checking for separators (or escape or quote sequences) that might
>>> occur in the entries?
>> 
>> Correct. StringJoiner makes no effort to address escaping/quoting.
> > Doing so would add a lot of complexity that would not
> > useful interesting to most users and probably still wouldn't satisfy everyone.
> 
>> If you wish some form of escaping or quoting you can pre-processed entries however you like before joining them.
>> 
>> Mike
>> 



From philip.hodges at bluewin.ch  Sat Aug 31 06:40:38 2013
From: philip.hodges at bluewin.ch (Philip Hodges)
Date: Sat, 31 Aug 2013 08:40:38 +0200
Subject: StringJoiner: detect or fix delimiter collision?
In-Reply-To: 
References: <51673A45.8060908@oracle.com>
	<1374608627412-145039.post@n7.nabble.com>
	
Message-ID: <52218FE6.7000804@bluewin.ch>

Are we really going ahead with an implementation that:
- checks even string literal parameters for null
- does it again when String.join calls StringJoiner
- makes defensive copies of just some of the arguments
- creates a StringBuilder with only the default capacity

People would be better off taking a look at
AbstractCollection.toString or Arrays.toString and then,
if they haven't already, roll their own, enhanced with a
StringBuilder capacity, and without all the defensive baggage.

To come back to my original point about why it is a toy interface:

The only worthwhile value that StringJoiner can possibly add is a way
to force programmers to make a conscious decision to waive checking
to see if the separator (or prefix or suffix) can or does occur
in any of the elements, and to apply an escaper/quoter if needed.

Please add some failing round trip unit tests with split to
help raise awareness of the issue of delimiter collision.

The original String elements cannot be extracted from the result
if there are no elements, one empty element, any null elements,
or if the separator occurs in any of the elements.

Please add a test of String.join with delimiter and no varargs elements,
and another test with one null varargs element. I don't feel comfortable
with a signature that does not clearly separate the delimiter from the elements.

Please put an example with escaping in the javadoc.

You might want to change that ridiculous "Java-is-cool" example.
Of course there are a lot of cool things about Java, and even
String.join cannot compete with acknowledged uncool features
such as Calendar, mutable Dates and unthreadsafe Formatters.
Nevertheless, the example text risks becoming ironic.

Please take a proper critical look at whether there is any
genuine need to dump this half-baked toy into everyone's jdk.
There are some good ideas in Java 8. This is not one of them.

It will soon be starring behind the scenes in CERT advisories.
Once people start using it, even if you do accept and try to fix the
flaws, you will then have two versions in circulation for many years.
And then I will be able to say "I told you so", instead of
"thank goodness we woke up and stopped it so we could get it right first time".

Why is there such a bandwagon rolling for this "convenience" feature?

It is not "long overdue".
Arrays.toString and AbstractCollection.toString have been there for years.
We already have joiners in apache commons and guava.
At first I thought they were cool. Then I tried to use them in anger.
And was forced to roll my own. That can't be right.

A more elaborate offically blessed feature that
only does half the job is worse than useless.
Without the extra complex ability to detect or avoid collisions
it is neither "nice", nor a "Good Thing".

Phil

http://www.techempower.com/blog/2013/03/26/everything-about-java-8/

"StringJoiner and String.join(...) are long, long overdue. They are so long overdue that the vast majority of Java 
developers likely have already written or have found utilities for joining strings, but it is nice for the JDK to 
finally provide this itself. Everyone has encountered situations where joining strings is required, and it is a Good 
Thing? that we can now express that through a standard API that every Java developer (eventually) will know. "


On 2013-07-23 22:09, Mike Duigou wrote:
>
> On Jul 23 2013, at 12:43 , ph wrote:
>
>> didn't see delimiter collision mentioned anywhere - are you really offering
>> an interface that only joins a list of entries without escaping or quoting
>> or even checking for separators (or escape or quote sequences) that might
>> occur in the entries?
>
> Correct. StringJoiner makes no effort to address escaping/quoting.
 > Doing so would add a lot of complexity that would not
 > useful interesting to most users and probably still wouldn't satisfy everyone.

> If you wish some form of escaping or quoting you can pre-processed entries however you like before joining them.
>
> Mike
>


From philip.hodges at bluewin.ch  Sat Aug 31 22:57:31 2013
From: philip.hodges at bluewin.ch (Philip Hodges)
Date: Sun, 1 Sep 2013 00:57:31 +0200
Subject: StringJoiner: detect or fix delimiter collision?
In-Reply-To: 
References: <51673A45.8060908@oracle.com>
	<1374608627412-145039.post@n7.nabble.com>
	
	<52218FE6.7000804@bluewin.ch>
	
Message-ID: <7916219F-E651-4939-BFB2-7D7CC38C9EEF@bluewin.ch>

I don't think my needs are in any way particular or unusual. This is the third attempt at a StringJoiner that has not stopped me having to roll my own. Arrays.toString and AbstractCollection.toString already meet logging needs and serve as simple useful examples for where people don't care about delimiter collision.

Your strings/stream/map/escape/collect/joining idiom is impressive and might well be adequate and flexible. It is also quite beyond incomprehensible to many. Even I don't immediately see what the stream and collect methods contribute to the processing, I will look it up later.

A lot of those will simply not think about delimiter collision until it bites them in production, because your joiner does not by default insist on either a waiver or an escaper or a checker for separators in the collection where you wrote map(escape). Maybe they will join some numbers first, then copy that code to join some identifiers, and then copy that code to join some names, and it will "work fine". Until one of the names contains an apostrophe or comma. Or they will quickly join a few lines for a web page, separated by a 
 tag, and forget to convert the lines to HTML, or verify that each line is a valid and safe HTML subset fragment.

This feature as it stands adds precious little convenience value, while making it easier for people to forget to provide any escaping at all. You are missing a golden opportunity to ensure that the code only compiles if it is complete with a waiver, detector or escaper. I've seen the consequences of escaping being left out all too often.

My own rolled code consists of a looper, an appender, and a replacer. I found it best if the appender method that chooses and injects the separator also inserts the quotes and chooses and calls the escaper (replacer). The code is clear apart from the replacer implementation, which has to use the charAt idiom instead of foreach to iterate the string without the defensive copy, and has inline code to escape the escape character itself as well as the quote character. If I was doing it over again, I would try to estimate and pass an initial capacity for the StringBuilder, and see if I really have to break the append chain in order to pass that same StringBuilder to the replacer instead of letting it create its own. I would also change the "TODO use guava joiner" comment to just say *see* guava joiner and see StringJoiner since java 1.8 :( It's more than persuasive enough to drive me to keep trying to pass on my doubts in this forum, but I would rather spare you the javadocs and implementation.

Phil

To quote Joshua Bloch on good API design: 'When in doubt leave it out' (or 'You can always add, but you can never remove').



On 31 Aug 2013, at 23:13, Mike Duigou  wrote:


On Aug 30 2013, at 23:40 , Philip Hodges wrote:
> ...
> 
> Why is there such a bandwagon rolling for this "convenience" feature?

Perhaps others just don't agree with you. The choice of functionality offered in the JDK 8 StringJoiner was not arbitrary or haphazardly chosen. If it doesn't meet your particular needs, I am sorry to hear that. Our belief as the proposers is that it offers a reasonable mix of functionality and simplicity to cover useful number of requirements. Our intent was certainly not to create the kitchen magician [1] of string joiners that attempted to incorporate every conceivable option. In particular your concerns about escaping are out of scope for the joiner in part because

Collection strings;

String concat = strings.stream().map(MyUtils::escape).collect(Collections.joining(","));

seems like an adequate and flexible solution to most people.

> We already have joiners in apache commons and guava.

This is the reason that StringJoiner was considered for JDK--that many others were "rolling their own".

> At first I thought they were cool. Then I tried to use them in anger.
> And was forced to roll my own.

I would encourage you to share your implementation or the javadocs as grist for discussion.  An actual alternative is the *only* thing that is likely to be persuasive.

> That can't be right.

Sometimes it is. The JDK doesn't make any attempt to satisfy everyone (or anyone). We all end up writing lots of non-business logic utility functions to bridge gaps in what JDK offers. This is normal. And, if it turns out to be something lots of people need then it's entirely possible that it could be added to the JDK.

Mike

[1] https://www.youtube.com/watch?v=cGVG9xLHb84

> 
> A more elaborate offically blessed feature that
> only does half the job is worse than useless.
> Without the extra complex ability to detect or avoid collisions
> it is neither "nice", nor a "Good Thing".
> 
> Phil
> 
> http://www.techempower.com/blog/2013/03/26/everything-about-java-8/
> 
> "StringJoiner and String.join(...) are long, long overdue. They are so long overdue that the vast majority of Java developers likely have already written or have found utilities for joining strings, but it is nice for the JDK to finally provide this itself. Everyone has encountered situations where joining strings is required, and it is a Good Thing? that we can now express that through a standard API that every Java developer (eventually) will know. "
> 
> 
> On 2013-07-23 22:09, Mike Duigou wrote:
>> 
>> On Jul 23 2013, at 12:43 , ph wrote:
>> 
>>> didn't see delimiter collision mentioned anywhere - are you really offering
>>> an interface that only joins a list of entries without escaping or quoting
>>> or even checking for separators (or escape or quote sequences) that might
>>> occur in the entries?
>> 
>> Correct. StringJoiner makes no effort to address escaping/quoting.
>> Doing so would add a lot of complexity that would not
>> useful interesting to most users and probably still wouldn't satisfy everyone.
> 
>> If you wish some form of escaping or quoting you can pre-processed entries however you like before joining them.
>> 
>> Mike
>>