From paul.sandoz at oracle.com  Wed Feb  1 00:03:28 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 31 Jan 2017 16:03:28 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <CA+kOe0-sN8sbQ9mW5saPeAtbQN7zsDaxk446BNWFdfQ6dMqKOQ@mail.gmail.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
	<2EAFB6CB-F9A3-409E-81EB-02DCAB5AB152@oracle.com>
	<CA+kOe0-sN8sbQ9mW5saPeAtbQN7zsDaxk446BNWFdfQ6dMqKOQ@mail.gmail.com>
Message-ID: <95658EF2-D340-4031-8437-F63F9EF69992@oracle.com>


> On 31 Jan 2017, at 14:55, Martin Buchholz <martinrb at google.com> wrote:
> 
> 
> 
> On Tue, Jan 31, 2017 at 12:32 PM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
> 
> 1057     static final VarHandle ITEM;
> 1058     static final VarHandle NEXT;
> 
> Suggest a comment as to why they are package private, due to access via a nested class. (Same in LinkedTransferQueue).
> 
> 
> package private is almost always used for nestmates in j.u.c.; a comment doesn't seem worthwhile.
> 

Ok, may i suggest renaming to NODE_ITEM and NODE_NEXT?


> 
> ConcurrentSkipListSet
> ?
> 
>   76  * <p>Bulk operations that add, remove, or examine multiple elements,
>   77  * such as {@link #addAll}, {@link #removeIf} or {@link #forEach},
>   78  * are <em>not</em> guaranteed to be performed atomically.
>   79  * For example, a {@code forEach} traversal concurrent with an {@code
>   80  * addAll} operation might observe only some of the added elements.
> 
> toArray was removed, and it?s not atomic. Same for many other cases.
> 
> We tried to maintain complete lists of non-atomic operations, but those became stale as new methods got added to  superclasses/superintterfaces.  Even toString is non-atomic!  Give up or be pedantically exhaustive?

The removal ?toArray? is arguably a specification change, and it?s removal could be misconstrued as implying it is now atomic. So i would just leave the existing documentation as is.

Paul.

From martinrb at google.com  Wed Feb  1 00:16:11 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 31 Jan 2017 16:16:11 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <95658EF2-D340-4031-8437-F63F9EF69992@oracle.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
	<2EAFB6CB-F9A3-409E-81EB-02DCAB5AB152@oracle.com>
	<CA+kOe0-sN8sbQ9mW5saPeAtbQN7zsDaxk446BNWFdfQ6dMqKOQ@mail.gmail.com>
	<95658EF2-D340-4031-8437-F63F9EF69992@oracle.com>
Message-ID: <CA+kOe08Kb_SApj6fobjAPihmsKKYMpb=F1YDPM8HapnXgz4wLQ@mail.gmail.com>

On Tue, Jan 31, 2017 at 4:03 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
>> ConcurrentSkipListSet
>> ?
>>
>>   76  * <p>Bulk operations that add, remove, or examine multiple elements,
>>   77  * such as {@link #addAll}, {@link #removeIf} or {@link #forEach},
>>   78  * are <em>not</em> guaranteed to be performed atomically.
>>   79  * For example, a {@code forEach} traversal concurrent with an {@code
>>   80  * addAll} operation might observe only some of the added elements.
>>
>> toArray was removed, and it?s not atomic. Same for many other cases.
>>
>
> We tried to maintain complete lists of non-atomic operations, but those
> became stale as new methods got added to  superclasses/superintterfaces.
> Even toString is non-atomic!  Give up or be pedantically exhaustive?
>
>
> The removal ?toArray? is arguably a specification change, and it?s removal
> could be misconstrued as implying it is now atomic. So i would just leave
> the existing documentation as is.
>

But ... the problem is that the docs implied that all the other operations
*were* guaranteed atomic, which became untrue when y'all added forEach and
friends.  That is, this is supposed to be a doc bug fix.  And toString was
always missing from the list.

 * Additionally, the bulk operations {@code addAll},
 * {@code removeAll}, {@code retainAll}, {@code containsAll},
 * {@code equals}, and {@code toArray} are <em>not</em> guaranteed
 * to be performed atomically. For example, an iterator operating

From stuart.marks at oracle.com  Wed Feb  1 00:22:12 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 31 Jan 2017 16:22:12 -0800
Subject: RFR(s): 8044626 & 8165649 RMI spec changes for modularization
Message-ID: <b8f84d16-aff3-3565-618c-8af807e3b89a@oracle.com>

Hi all,

Please review these small spec changes that adjust RMI specifications for the 
modular environment in Java 9. RMI does some reflection to handle stubs and to 
activate objects. The changes specify what kind of accessibility (package 
exports/opens, and class/method/constructor accessibility) is required for RMI 
to work.

Note that any existing RMI applications will end up in an unnamed module in Java 
9. Since unnamed modules export and open all packages, there should be no 
compatibility impact.

Bugs:

	8044626: Update RMI specifications to reflect modularization changes
	https://bugs.openjdk.java.net/browse/JDK-8044626

	8165649: Re-examine if Activatable object can be created from non-public class
	https://bugs.openjdk.java.net/browse/JDK-8165649

Diffs below.

thanks,

s'marks



# HG changeset patch
# User smarks
# Date 1485907664 28800
#      Tue Jan 31 16:07:44 2017 -0800
# Node ID b84c67d49349b56e6c95307cd1a4c0d64c48a817
# Parent  0e0e0fbc5bf325ce0fc4d8cc2776c2038fbe6aa3
8044626: Update RMI specifications to reflect modularization changes
8165649: Re-examine if Activatable object can be created from non-public class 
and/or constructor
Reviewed-by: XXX

diff -r 0e0e0fbc5bf3 -r b84c67d49349 
src/java.rmi/share/classes/java/rmi/activation/ActivationInstantiator.java
--- a/src/java.rmi/share/classes/java/rmi/activation/ActivationInstantiator.java 
Fri Jan 13 12:35:53 2017 -0800
+++ b/src/java.rmi/share/classes/java/rmi/activation/ActivationInstantiator.java 
Tue Jan 31 16:07:44 2017 -0800
@@ -60,7 +60,19 @@
      * initialization data, and
      *
      * <li> returning a MarshalledObject containing the stub for the
-    * remote object it created </ul>
+    * remote object it created.</ul>
+    *
+    * <p>In order for activation to be successful, one of the following 
requirements
+    * must be met, otherwise {@link ActivationException} is thrown.
+    *
+    * <ul><li>If the class to be activated and the special activation 
contructor are both public,
+    * the class must reside in a package that is exported or open to the
+    * {@code java.rmi} module.
+    *
+    * <li>If either the class to be activated or the special activation constructor
+    * is non-public, the class must reside in a package that is open to the
+    * {@code java.rmi} module.
+    * </ul>
      *
      * @param id the object's activation identifier
      * @param desc the object's descriptor
diff -r 0e0e0fbc5bf3 -r b84c67d49349 
src/java.rmi/share/classes/java/rmi/activation/Activator.java
--- a/src/java.rmi/share/classes/java/rmi/activation/Activator.java	Fri Jan 13 
12:35:53 2017 -0800
+++ b/src/java.rmi/share/classes/java/rmi/activation/Activator.java	Tue Jan 31 
16:07:44 2017 -0800
@@ -48,7 +48,7 @@
   * The <code>Activator</code> works closely with
   * <code>ActivationSystem</code>, which provides a means for registering
   * groups and objects within those groups, and <code>ActivationMonitor</code>,
- * which recives information about active and inactive objects and inactive
+ * which receives information about active and inactive objects and inactive
   * groups. <p>
   *
   * The activator is responsible for monitoring and detecting when
diff -r 0e0e0fbc5bf3 -r b84c67d49349 
src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java
--- a/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java	Fri 
Jan 13 12:35:53 2017 -0800
+++ b/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java	Tue 
Jan 31 16:07:44 2017 -0800
@@ -107,8 +107,9 @@
   * the binary name of the root class with the suffix {@code _Stub}.
   *
   * <li>The stub class is loaded by name using the class loader of the root
- * class. The stub class must extend {@link RemoteStub} and must have a
- * public constructor that has one parameter of type {@link RemoteRef}.
+ * class. The stub class must be public, it must extend {@link RemoteStub}, it must
+ * reside in a package that is exported to the {@code java.rmi} module, and it
+ * must have a public constructor that has one parameter of type {@link RemoteRef}.
   *
   * <li>Finally, an instance of the stub class is constructed with a
   * {@link RemoteRef}.
@@ -124,12 +125,20 @@
   *
   * <ul>
   *
- * <li>The proxy's class is defined by the class loader of the remote
- * object's class.
+ * <li>The proxy's class is defined according to the specifications for the
+ * <a href="{@docRoot}/java/lang/reflect/Proxy.html#membership">
+ * {@code Proxy}
+ * </a>
+ * class, using the class loader of the remote object's class.
   *
   * <li>The proxy implements all the remote interfaces implemented by the
   * remote object's class.
   *
+ * <li>If all remote interfaces are public, they must reside in packages that
+ * are either exported or open to the {@code java.rmi} module. Or, if one or more
+ * of the remote interfaces are non-public, they must reside in a package that
+ * is open to the {@code java.rmi} module.
+ *
   * <li>The proxy's invocation handler is a {@link
   * RemoteObjectInvocationHandler} instance constructed with a
   * {@link RemoteRef}.


From paul.sandoz at oracle.com  Wed Feb  1 00:30:22 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 31 Jan 2017 16:30:22 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <CA+kOe08Kb_SApj6fobjAPihmsKKYMpb=F1YDPM8HapnXgz4wLQ@mail.gmail.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
	<2EAFB6CB-F9A3-409E-81EB-02DCAB5AB152@oracle.com>
	<CA+kOe0-sN8sbQ9mW5saPeAtbQN7zsDaxk446BNWFdfQ6dMqKOQ@mail.gmail.com>
	<95658EF2-D340-4031-8437-F63F9EF69992@oracle.com>
	<CA+kOe08Kb_SApj6fobjAPihmsKKYMpb=F1YDPM8HapnXgz4wLQ@mail.gmail.com>
Message-ID: <B1EA6547-F29C-48FE-A2C1-859EA34B3AAC@oracle.com>


> On 31 Jan 2017, at 16:16, Martin Buchholz <martinrb at google.com> wrote:
> 
> 
> 
> On Tue, Jan 31, 2017 at 4:03 PM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
>> 
>> ConcurrentSkipListSet
>> ?
>> 
>>   76  * <p>Bulk operations that add, remove, or examine multiple elements,
>>   77  * such as {@link #addAll}, {@link #removeIf} or {@link #forEach},
>>   78  * are <em>not</em> guaranteed to be performed atomically.
>>   79  * For example, a {@code forEach} traversal concurrent with an {@code
>>   80  * addAll} operation might observe only some of the added elements.
>> 
>> toArray was removed, and it?s not atomic. Same for many other cases.
>> 
>> We tried to maintain complete lists of non-atomic operations, but those became stale as new methods got added to  superclasses/superintterfaces.  Even toString is non-atomic!  Give up or be pedantically exhaustive?
> 
> The removal ?toArray? is arguably a specification change, and it?s removal could be misconstrued as implying it is now atomic. So i would just leave the existing documentation as is.
> 
> But ... the problem is that the docs implied that all the other operations *were* guaranteed atomic, which became untrue when y'all added forEach and friends.  That is, this is supposed to be a doc bug fix.  And toString was always missing from the list.
> 

Is not toString a bulk operation that examines multiple elements?

I know toArray fits within that remit, but i just prefer to keep to the original documentation, since the change might be incorrectly perceived as a change in behaviour.

It?s a very mild objection, please override if you feel i am being overly conservative here!

Paul.



>  * Additionally, the bulk operations {@code addAll},
>  * {@code removeAll}, {@code retainAll}, {@code containsAll},
>  * {@code equals}, and {@code toArray} are <em>not</em> guaranteed
>  * to be performed atomically. For example, an iterator operating
> 
> 


From martinrb at google.com  Wed Feb  1 00:40:26 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 31 Jan 2017 16:40:26 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <B1EA6547-F29C-48FE-A2C1-859EA34B3AAC@oracle.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
	<2EAFB6CB-F9A3-409E-81EB-02DCAB5AB152@oracle.com>
	<CA+kOe0-sN8sbQ9mW5saPeAtbQN7zsDaxk446BNWFdfQ6dMqKOQ@mail.gmail.com>
	<95658EF2-D340-4031-8437-F63F9EF69992@oracle.com>
	<CA+kOe08Kb_SApj6fobjAPihmsKKYMpb=F1YDPM8HapnXgz4wLQ@mail.gmail.com>
	<B1EA6547-F29C-48FE-A2C1-859EA34B3AAC@oracle.com>
Message-ID: <CA+kOe08XX8336j=iP=pCy+TBi55zf-4eLFahDw=TV8S+VhwMyQ@mail.gmail.com>

On Tue, Jan 31, 2017 at 4:30 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> On 31 Jan 2017, at 16:16, Martin Buchholz <martinrb at google.com> wrote:
>
>
>
> On Tue, Jan 31, 2017 at 4:03 PM, Paul Sandoz <paul.sandoz at oracle.com>
> wrote:
>
>>
>>> ConcurrentSkipListSet
>>> ?
>>>
>>>   76  * <p>Bulk operations that add, remove, or examine multiple
>>> elements,
>>>   77  * such as {@link #addAll}, {@link #removeIf} or {@link #forEach},
>>>   78  * are <em>not</em> guaranteed to be performed atomically.
>>>   79  * For example, a {@code forEach} traversal concurrent with an
>>> {@code
>>>   80  * addAll} operation might observe only some of the added elements.
>>>
>>> toArray was removed, and it?s not atomic. Same for many other cases.
>>>
>>
>> We tried to maintain complete lists of non-atomic operations, but those
>> became stale as new methods got added to  superclasses/superintterfaces.
>> Even toString is non-atomic!  Give up or be pedantically exhaustive?
>>
>>
>> The removal ?toArray? is arguably a specification change, and it?s
>> removal could be misconstrued as implying it is now atomic. So i would just
>> leave the existing documentation as is.
>>
>
> But ... the problem is that the docs implied that all the other operations
> *were* guaranteed atomic, which became untrue when y'all added forEach and
> friends.  That is, this is supposed to be a doc bug fix.  And toString was
> always missing from the list.
>
>
> Is not toString a bulk operation that examines multiple elements?
>
>
Yes!


> I know toArray fits within that remit, but i just prefer to keep to the
> original documentation, since the change might be incorrectly perceived as
> a change in behaviour.
>
>
I'm trying to expand the list of non-atomic methods without exhaustively
listing all its members.


> It?s a very mild objection, please override if you feel i am being overly
> conservative here!
>

Would having exhaustive lists of methods make you happier?  That would be
more precise, but too pedantic for my taste.

From xueming.shen at oracle.com  Wed Feb  1 01:15:15 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 1 Feb 2017 09:15:15 +0800
Subject: RFR: 8171524: jar --help doesn't provide information that stdout
	and stdin can be used as output and input for tool
In-Reply-To: <52B6BACF-00BB-486C-ACD3-C80E3CECB799@oracle.com>
References: <52B6BACF-00BB-486C-ACD3-C80E3CECB799@oracle.com>
Message-ID: <B7CC0445-3B21-4109-BAAC-675A329C03D3@oracle.com>

Looks good.

On Feb 1, 2017, at 7:40 AM, Henry Jen <henry.jen at oracle.com> wrote:

Hi,

Please review a trivial fix[1] for JDK-8171524.

The fix added a short paragraph about @argfile. Clarify stdin or stdout is used if ?file is omitted.

It also correct that -h, not -? is for the short option for ?help.

Cheers,
Henry

[1] http://cr.openjdk.java.net/~henryjen/jdk9/8171524/0/webrev/

From mandy.chung at oracle.com  Wed Feb  1 05:11:23 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 31 Jan 2017 21:11:23 -0800
Subject: RFR: 8173607: JMX RMI connector should be in its own module
In-Reply-To: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com>
References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com>
Message-ID: <BD7108DF-69F6-4807-88BC-57D3C7D47CAC@oracle.com>


> On Jan 31, 2017, at 10:26 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a patch for:
> 
> 8173607: JMX RMI connector should be in its own module
> https://bugs.openjdk.java.net/browse/JDK-8173607
> 
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05
> 

This mostly looks good.  I?d like to see an updated webrev after you sync with JDK-8173608.  I believe you can revert test/sun/management/jdp and test/sun/management/jmxremote tests change and ConnectorBootstrap.java as you noted.  Also you can run jdeps ?-check on java.rmi, java.management, and jdk.management.agent to update its requires and qualified exports.  java.management should no longer require java.rmi and the qualified exports from java.rmi is not needed.

java.management.rmi module-info.java
  32  * @see javax.management.remote.rmi

This @see is not needed.  This package is listed in the exported packages table.

JMXConnectorFactory.java
   I like the ProviderFinder approach to look up the custom providers and platform providers; and shared code used by both JMXConnectorFactory and JMXConnectorServerFactory which is good.

   Nit: line 481-491 - this is javadoc and probably /* .. */ comment block is more appropriate here.

> 
> Some further cleanup of java.base and java.rmi module-info.java
> should become possible once JDK-8173608 is in (as well as moving
> RMIExporter to java.management.rmi - which is not possible yet).
> 

Yes.

> Further cleanup of @modules in tests might become possible as
> well.
> 

Hope there will be a bulk @modules cleanup some time.

Thanks
Mandy

From mandy.chung at oracle.com  Wed Feb  1 06:08:56 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 31 Jan 2017 22:08:56 -0800
Subject: RFR(s): 8044626 & 8165649 RMI spec changes for modularization
In-Reply-To: <b8f84d16-aff3-3565-618c-8af807e3b89a@oracle.com>
References: <b8f84d16-aff3-3565-618c-8af807e3b89a@oracle.com>
Message-ID: <EC709353-6B9B-42DB-A2EC-10ADFFDC68F3@oracle.com>


> On Jan 31, 2017, at 4:22 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> diff -r 0e0e0fbc5bf3 -r b84c67d49349 src/java.rmi/share/classes/java/rmi/activation/ActivationInstantiator.java
> --- a/src/java.rmi/share/classes/java/rmi/activation/ActivationInstantiator.java Fri Jan 13 12:35:53 2017 -0800
> +++ b/src/java.rmi/share/classes/java/rmi/activation/ActivationInstantiator.java Tue Jan 31 16:07:44 2017 -0800
> @@ -60,7 +60,19 @@
>     * initialization data, and
>     *
>     * <li> returning a MarshalledObject containing the stub for the
> -    * remote object it created </ul>
> +    * remote object it created.</ul>
> +    *
> +    * <p>In order for activation to be successful, one of the following requirements
> +    * must be met, otherwise {@link ActivationException} is thrown.
> +    *
> +    * <ul><li>If the class to be activated and the special activation contructor are both public,
> +    * the class must reside in a package that is exported or open to the
> +    * {@code java.rmi} module.
> +    *
> +    * <li>If either the class to be activated or the special activation constructor
> +    * is non-public, the class must reside in a package that is open to the
> +    * {@code java.rmi} module.
> +    * </ul>
>     *
>     * @param id the object's activation identifier
>     * @param desc the object's descriptor

Except a typo ?contructor?,  looks okay. 

> diff -r 0e0e0fbc5bf3 -r b84c67d49349 src/java.rmi/share/classes/java/rmi/activation/Activator.java
> --- a/src/java.rmi/share/classes/java/rmi/activation/Activator.java	Fri Jan 13 12:35:53 2017 -0800
> +++ b/src/java.rmi/share/classes/java/rmi/activation/Activator.java	Tue Jan 31 16:07:44 2017 -0800
> @@ -48,7 +48,7 @@
>  * The <code>Activator</code> works closely with
>  * <code>ActivationSystem</code>, which provides a means for registering
>  * groups and objects within those groups, and <code>ActivationMonitor</code>,
> - * which recives information about active and inactive objects and inactive
> + * which receives information about active and inactive objects and inactive
>  * groups. <p>
>  *
>  * The activator is responsible for monitoring and detecting when
> diff -r 0e0e0fbc5bf3 -r b84c67d49349 src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java
> --- a/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java	Fri Jan 13 12:35:53 2017 -0800
> +++ b/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java	Tue Jan 31 16:07:44 2017 -0800
> @@ -107,8 +107,9 @@
>  * the binary name of the root class with the suffix {@code _Stub}.
>  *
>  * <li>The stub class is loaded by name using the class loader of the root
> - * class. The stub class must extend {@link RemoteStub} and must have a
> - * public constructor that has one parameter of type {@link RemoteRef}.
> + * class. The stub class must be public, it must extend {@link RemoteStub}, it must
> + * reside in a package that is exported to the {@code java.rmi} module, and it
> + * must have a public constructor that has one parameter of type {@link RemoteRef}.
>  *
>  * <li>Finally, an instance of the stub class is constructed with a
>  * {@link RemoteRef}.
> @@ -124,12 +125,20 @@
>  *
>  * <ul>
>  *
> - * <li>The proxy's class is defined by the class loader of the remote
> - * object's class.
> + * <li>The proxy's class is defined according to the specifications for the
> + * <a href="{@docRoot}/java/lang/reflect/Proxy.html#membership">
> + * {@code Proxy}
> + * </a>
> + * class, using the class loader of the remote object's class.
>  *
>  * <li>The proxy implements all the remote interfaces implemented by the
>  * remote object's class.
>  *
> + * <li>If all remote interfaces are public, they must reside in packages that
> + * are either exported or open to the {@code java.rmi} module. Or, if one or more
> + * of the remote interfaces are non-public, they must reside in a package that
> + * is open to the {@code java.rmi} module.
> + *
>  * <li>The proxy's invocation handler is a {@link
>  * RemoteObjectInvocationHandler} instance constructed with a
>  * {@link RemoteRef}.
> 

Looks okay too.

Mandy


From Alan.Bateman at oracle.com  Wed Feb  1 08:25:33 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 1 Feb 2017 08:25:33 +0000
Subject: RFR: 8075617, 8075616 Create tests to check wsgen, schemagen work
	with multi-version jar
In-Reply-To: <97E00806-D7A7-4A37-B445-64D7C1F8F7FD@oracle.com>
References: <CBABED4B-B8A2-4A80-9BD2-8039A055F5AD@oracle.com>
	<86914c18-9d41-6778-4a4d-66acff3442ac@oracle.com>
	<FADC68EB-89AF-4CCA-AEE2-EBF55212D3FC@oracle.com>
	<ff92bd6a-559e-6206-0e23-5d141a4441cf@oracle.com>
	<D0BAB791-CBE0-4BFA-928E-A7405860BE18@oracle.com>
	<75C6ACF3-28E8-4475-B871-049601D1FE79@oracle.com>
	<A26F3D5A-F5C6-4877-9FDB-DDC47AD2DD7A@oracle.com>
	<97E00806-D7A7-4A37-B445-64D7C1F8F7FD@oracle.com>
Message-ID: <ba2edf50-77af-4c52-ded2-496869c4f233@oracle.com>

On 31/01/2017 21:45, Lance Andersen wrote:

> Hi Andrey,
>
> The test looks reasonable.
>
> Assuming Alan has blessed the location and we have run these on all platforms via JPRT, you should be good to go.
>
I was busy with other things and didn't see Andrey's updated webrev 
proposing to put the tests in tools/jaxws. My only concern with that is 
that `schemegen` is JAXB so I assume the locations should be tools/wsgen 
and tools/schemagen.

-Alan

From Alan.Bateman at oracle.com  Wed Feb  1 08:33:17 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 1 Feb 2017 08:33:17 +0000
Subject: RFR(s): 8044626 & 8165649 RMI spec changes for modularization
In-Reply-To: <b8f84d16-aff3-3565-618c-8af807e3b89a@oracle.com>
References: <b8f84d16-aff3-3565-618c-8af807e3b89a@oracle.com>
Message-ID: <6032cf24-fddb-e9a9-45f0-83f6177be6d2@oracle.com>

On 01/02/2017 00:22, Stuart Marks wrote:

>
> +    *
> +    * <ul><li>If the class to be activated and the special activation 
> contructor are both public,
> +    * the class must reside in a package that is exported or open to the
> +    * {@code java.rmi} module.
I think it would be better to just say "exported" rather than "exported 
or open" and have it link to Module#isExported(String,Module).


> +    *
> +    * <li>If either the class to be activated or the special 
> activation constructor
> +    * is non-public, the class must reside in a package that is open 
> to the
> +    * {@code java.rmi} module.
> +    * </ul>
and for completeness, have "open" link to Module#isOpen(String,Module).

Otherwise looks good to me.

-Alan

From erik.joelsson at oracle.com  Wed Feb  1 11:56:59 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 1 Feb 2017 12:56:59 +0100
Subject: RFR: 8173607: JMX RMI connector should be in its own module
In-Reply-To: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com>
References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com>
Message-ID: <32acdd4e-0ec3-d76d-fd17-cb2514570f5d@oracle.com>

Build changes look ok.

/Erik


On 2017-01-31 19:26, Daniel Fuchs wrote:
> Hi,
>
> Please find below a patch for:
>
> 8173607: JMX RMI connector should be in its own module
> https://bugs.openjdk.java.net/browse/JDK-8173607
>
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05
>
> This patch makes it possible to remove the requires transitive
> java.rmi from the java.management module.
>
> For convenience here is the HTML module-level API documentation
> produced by javadoc for the new java.management.rmi module:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05/java.management.rmi-summary.html 
>
>
> The patch has some temporary hacks (mainly ConnectorBootstrap.java)
> that we will be able to revert when
> JDK-8173608 Separate JDK management agent from java.management module
> is pushed.
>
> The changes were mainly mechanical except for:
>
> ConnectorBootstrap.java: see above
> JMXConnectorFactory.java/JMXConnectorServerFactory.java:
>    ServiceLoader is now used to load the default RMI Connector provider
>    as a service. There should however be no observable behavior change
>    to existing application.
> ProxyRef.java, Unmarshal.java: are moved to a new
>    com.sun.jmx.remote.internal.rmi package in the new module.
> ClientNotifForwarder.java: is modified to no longer depend on
>    java.rmi.UnmarshalException - NotSerializableException is used
>    instead
> RMIConnector.java: fetchNotif is updated to throw
>    NotSerializableException instead of UnmarshalException
>    The PRef serialization bytes are updated to accomodate the
>    new ProxyRef package name.
>
> Some further cleanup of java.base and java.rmi module-info.java
> should become possible once JDK-8173608 is in (as well as moving
> RMIExporter to java.management.rmi - which is not possible yet).
>
> Further cleanup of @modules in tests might become possible as
> well.
>
> Note:
> JCK tests for api/javax_management and api/java_lang/management
> are passing with this change.
>
> best regards,
>
> -- daniel
>


From chris.hegarty at oracle.com  Wed Feb  1 12:25:50 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 1 Feb 2017 12:25:50 +0000
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
Message-ID: <C83BE9D3-5D4C-4488-9BB8-F5159D641EFA@oracle.com>


> On 31 Jan 2017, at 16:58, Martin Buchholz <martinrb at google.com> wrote:
> 
> ...
> 
> common-pool has a fix for unwanted ClassLoader retention via an inaccessible thread context class loader.
> 
> This differs from Chris' approach of setting the internal TCCL to null.  Instead, it unifies the handling in the default FJTF and the innocuous FJTF by simply setting the TCCL to the system class loader.  Except that the innocuous TCCL cannot be reset by a task.

Thanks Martin. These changes look ok to me.

-Chris.

From ramanand.patil at oracle.com  Wed Feb  1 12:59:35 2017
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Wed, 1 Feb 2017 04:59:35 -0800 (PST)
Subject: RFR: 8167063: spurious message "A JNI error has occurred" if
	start-class cannot be initialized
In-Reply-To: <6b43aba8-f880-1adb-4e52-46cb95b92c89@oracle.com>
References: <1b279d2c-e4e6-4bc2-b365-ed3ad5aa5629@default>
	<07c4c8b9-695b-6ba8-2cf8-09423e467379@oracle.com>
	<18089cd3-4cfb-4e55-b02b-e11cb637daa9@default>
	<58867365.5070608@oracle.com>
	<cdafe37b-7d8a-46a0-ac89-1c013764a030@default>
	<5888CB80.6050107@oracle.com>
	<065eab06-3a3b-4a6a-8cbe-c892f5017ece@default>
	<357873c3-e37c-0c8f-8aa5-370ad4c680d7@oracle.com>
	<a01a7f5f-7a48-4c58-a034-820adcacd322@default>
	<a59cadf9-7f50-01a3-6399-8e5faa98ecc9@oracle.com>
	<6b43aba8-f880-1adb-4e52-46cb95b92c89@oracle.com>
Message-ID: <55b2213e-6758-47d8-b659-1b405f72e1fb@default>

Thank you Kumar and Alan.
Just pushed the fix. All the related tests from "core" and "pit" testset are passed.

Regards,
Ramanand.

-----Original Message-----
From: Kumar Srinivasan 
Sent: Tuesday, January 31, 2017 9:53 PM
To: Ramanand Patil <ramanand.patil at oracle.com>
Cc: Alan Bateman <alan.bateman at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: RFR: 8167063: spurious message "A JNI error has occurred" if start-class cannot be initialized


Approved, please make sure you have run all the jprt -testset pit tests.

Kumar

On 1/30/2017 5:05 AM, Alan Bateman wrote:
> On 30/01/2017 12:11, Ramanand Patil wrote:
>
>> Thank you Alan.
>>
>> I have eliminated the inner catch block for LinkageError. Here is the 
>> updated webrev:
>> http://cr.openjdk.java.net/~rpatil/8167063/webrev.04
>>
>>
> I think this looks right now.
>
> -Alan

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


From daniel.fuchs at oracle.com  Wed Feb  1 15:29:22 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 1 Feb 2017 15:29:22 +0000
Subject: RFR: 8173607: JMX RMI connector should be in its own module
In-Reply-To: <BD7108DF-69F6-4807-88BC-57D3C7D47CAC@oracle.com>
References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com>
	<BD7108DF-69F6-4807-88BC-57D3C7D47CAC@oracle.com>
Message-ID: <5ad3fe2b-be04-24c7-98bb-8bab61c3aa15@oracle.com>

Hi Mandy,

On 01/02/17 05:11, Mandy Chung wrote:
>
>> On Jan 31, 2017, at 10:26 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> Hi,
>>
>> Please find below a patch for:
>>
>> 8173607: JMX RMI connector should be in its own module
>> https://bugs.openjdk.java.net/browse/JDK-8173607
>>
>> webrev:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05
>>
>
> This mostly looks good.  I?d like to see an updated webrev after you sync with JDK-8173608.  I believe you can revert test/sun/management/jdp and test/sun/management/jmxremote tests change and ConnectorBootstrap.java as you noted.  Also you can run jdeps ?-check on java.rmi, java.management, and jdk.management.agent to update its requires and qualified exports.  java.management should no longer require java.rmi and the qualified exports from java.rmi is not needed.

Here is the updated webrev, rebased after pulling JDK-8173608, and with
your feedback below integrated.

I am pleased to report that java.management no longer requires
java.rmi or java.naming :-)

Compared to previous version, then RMIExporter has been moved
to java.management.rmi, various module-info.java have been
cleaned up, some @modules in tests have been updated (mostly
due to the RMIExporter move).

I have also improved some javadoc comments in JMXConnectorFactory.java
No changes in build files compared to webrev.05

http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06
http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06/java.management.rmi-summary.html

best regards,

-- daniel

>
> java.management.rmi module-info.java
>   32  * @see javax.management.remote.rmi
>
> This @see is not needed.  This package is listed in the exported packages table.
>
> JMXConnectorFactory.java
>    I like the ProviderFinder approach to look up the custom providers and platform providers; and shared code used by both JMXConnectorFactory and JMXConnectorServerFactory which is good.
>
>    Nit: line 481-491 - this is javadoc and probably /* .. */ comment block is more appropriate here.
>
>>
>> Some further cleanup of java.base and java.rmi module-info.java
>> should become possible once JDK-8173608 is in (as well as moving
>> RMIExporter to java.management.rmi - which is not possible yet).
>>
>
> Yes.
>
>> Further cleanup of @modules in tests might become possible as
>> well.
>>
>
> Hope there will be a bulk @modules cleanup some time.
>
> Thanks
> Mandy
>


From martinrb at google.com  Wed Feb  1 15:41:19 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 1 Feb 2017 07:41:19 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <95658EF2-D340-4031-8437-F63F9EF69992@oracle.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
	<2EAFB6CB-F9A3-409E-81EB-02DCAB5AB152@oracle.com>
	<CA+kOe0-sN8sbQ9mW5saPeAtbQN7zsDaxk446BNWFdfQ6dMqKOQ@mail.gmail.com>
	<95658EF2-D340-4031-8437-F63F9EF69992@oracle.com>
Message-ID: <CA+kOe08dajJYCm385wrnE6zd-GwqfyTEB34AHaMYWVT_1XpyAA@mail.gmail.com>

On Tue, Jan 31, 2017 at 4:03 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> On Tue, Jan 31, 2017 at 12:32 PM, Paul Sandoz <paul.sandoz at oracle.com>
> wrote:
>
>>
>> 1057     static final VarHandle ITEM;
>> 1058     static final VarHandle NEXT;
>>
>> Suggest a comment as to why they are package private, due to access via a
>> nested class. (Same in LinkedTransferQueue).
>>
>>
> package private is almost always used for nestmates in j.u.c.; a comment
> doesn't seem worthwhile.
>
>
>
> Ok, may i suggest renaming to NODE_ITEM and NODE_NEXT?
>

We prefer the shorter ITEM and NEXT, especially for nestmates where no
ambiguity is present.  There's a stronger case for your own  THREAD_PROBE,
although we might have happily stuck with PROBE.

From paul.sandoz at oracle.com  Wed Feb  1 15:44:25 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 1 Feb 2017 07:44:25 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <CA+kOe08XX8336j=iP=pCy+TBi55zf-4eLFahDw=TV8S+VhwMyQ@mail.gmail.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
	<2EAFB6CB-F9A3-409E-81EB-02DCAB5AB152@oracle.com>
	<CA+kOe0-sN8sbQ9mW5saPeAtbQN7zsDaxk446BNWFdfQ6dMqKOQ@mail.gmail.com>
	<95658EF2-D340-4031-8437-F63F9EF69992@oracle.com>
	<CA+kOe08Kb_SApj6fobjAPihmsKKYMpb=F1YDPM8HapnXgz4wLQ@mail.gmail.com>
	<B1EA6547-F29C-48FE-A2C1-859EA34B3AAC@oracle.com>
	<CA+kOe08XX8336j=iP=pCy+TBi55zf-4eLFahDw=TV8S+VhwMyQ@mail.gmail.com>
Message-ID: <AE180A98-1712-49D6-BECD-143346207AA1@oracle.com>


> On 31 Jan 2017, at 16:40, Martin Buchholz <martinrb at google.com> wrote:
> 
> 
> 
> On Tue, Jan 31, 2017 at 4:30 PM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
> 
>> On 31 Jan 2017, at 16:16, Martin Buchholz <martinrb at google.com <mailto:martinrb at google.com>> wrote:
>> 
>> 
>> 
>> On Tue, Jan 31, 2017 at 4:03 PM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
>>> 
>>> ConcurrentSkipListSet
>>> ?
>>> 
>>>   76  * <p>Bulk operations that add, remove, or examine multiple elements,
>>>   77  * such as {@link #addAll}, {@link #removeIf} or {@link #forEach},
>>>   78  * are <em>not</em> guaranteed to be performed atomically.
>>>   79  * For example, a {@code forEach} traversal concurrent with an {@code
>>>   80  * addAll} operation might observe only some of the added elements.
>>> 
>>> toArray was removed, and it?s not atomic. Same for many other cases.
>>> 
>>> We tried to maintain complete lists of non-atomic operations, but those became stale as new methods got added to  superclasses/superintterfaces.  Even toString is non-atomic!  Give up or be pedantically exhaustive?
>> 
>> The removal ?toArray? is arguably a specification change, and it?s removal could be misconstrued as implying it is now atomic. So i would just leave the existing documentation as is.
>> 
>> But ... the problem is that the docs implied that all the other operations *were* guaranteed atomic, which became untrue when y'all added forEach and friends.  That is, this is supposed to be a doc bug fix.  And toString was always missing from the list.
>> 
> 
> Is not toString a bulk operation that examines multiple elements?
> 
> 
> Yes!
> 
> I know toArray fits within that remit, but i just prefer to keep to the original documentation, since the change might be incorrectly perceived as a change in behaviour.
> 
> 
> I'm trying to expand the list of non-atomic methods without exhaustively listing all its members.
> 
> It?s a very mild objection, please override if you feel i am being overly conservative here!
> 
> Would having exhaustive lists of methods make you happier?  That would be more precise, but too pedantic for my taste.

I think that would be too pedantic as well. At this late stage in 9 i prefer to leave things as they are and not fiddle. Revise for 10?

Paul.

From martinrb at google.com  Wed Feb  1 16:44:55 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 1 Feb 2017 08:44:55 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <AE180A98-1712-49D6-BECD-143346207AA1@oracle.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
	<2EAFB6CB-F9A3-409E-81EB-02DCAB5AB152@oracle.com>
	<CA+kOe0-sN8sbQ9mW5saPeAtbQN7zsDaxk446BNWFdfQ6dMqKOQ@mail.gmail.com>
	<95658EF2-D340-4031-8437-F63F9EF69992@oracle.com>
	<CA+kOe08Kb_SApj6fobjAPihmsKKYMpb=F1YDPM8HapnXgz4wLQ@mail.gmail.com>
	<B1EA6547-F29C-48FE-A2C1-859EA34B3AAC@oracle.com>
	<CA+kOe08XX8336j=iP=pCy+TBi55zf-4eLFahDw=TV8S+VhwMyQ@mail.gmail.com>
	<AE180A98-1712-49D6-BECD-143346207AA1@oracle.com>
Message-ID: <CA+kOe0_So3eYwBpds4v2YcFr8VdivamDfe=n-42XHoVjWpeL2A@mail.gmail.com>

On Wed, Feb 1, 2017 at 7:44 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> I think that would be too pedantic as well. At this late stage in 9 i
> prefer to leave things as they are and not fiddle. Revise for 10?
>

We could, but jsr166 primitive version control technology doesn't have a
mechanism to maintain such distinctions.

I still think the jdk9 docs are misleading and we should do something to
fix them.  The high-level bit for users is "Bulk operations are
non-atomic"!  Maybe we should include that sentence?!

From andrey.x.nazarov at oracle.com  Wed Feb  1 16:46:22 2017
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Wed, 1 Feb 2017 19:46:22 +0300
Subject: RFR: 8075617, 8075616 Create tests to check wsgen, schemagen work
	with multi-version jar
In-Reply-To: <ba2edf50-77af-4c52-ded2-496869c4f233@oracle.com>
References: <CBABED4B-B8A2-4A80-9BD2-8039A055F5AD@oracle.com>
	<86914c18-9d41-6778-4a4d-66acff3442ac@oracle.com>
	<FADC68EB-89AF-4CCA-AEE2-EBF55212D3FC@oracle.com>
	<ff92bd6a-559e-6206-0e23-5d141a4441cf@oracle.com>
	<D0BAB791-CBE0-4BFA-928E-A7405860BE18@oracle.com>
	<75C6ACF3-28E8-4475-B871-049601D1FE79@oracle.com>
	<A26F3D5A-F5C6-4877-9FDB-DDC47AD2DD7A@oracle.com>
	<97E00806-D7A7-4A37-B445-64D7C1F8F7FD@oracle.com>
	<ba2edf50-77af-4c52-ded2-496869c4f233@oracle.com>
Message-ID: <06AF7A37-21E3-4BC5-9F19-DDBB704D49BB@oracle.com>

Hi Alan,

I moved tests to suggested locations. http://cr.openjdk.java.net/~anazarov/8075617/webrev.02/webrev/

?Andrey
> On 1 Feb 2017, at 11:25, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 31/01/2017 21:45, Lance Andersen wrote:
> 
>> Hi Andrey,
>> 
>> The test looks reasonable.
>> 
>> Assuming Alan has blessed the location and we have run these on all platforms via JPRT, you should be good to go.
>> 
> I was busy with other things and didn't see Andrey's updated webrev proposing to put the tests in tools/jaxws. My only concern with that is that `schemegen` is JAXB so I assume the locations should be tools/wsgen and tools/schemagen.
> 
> -Alan


From Alan.Bateman at oracle.com  Wed Feb  1 16:47:13 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 1 Feb 2017 16:47:13 +0000
Subject: RFR: 8075617, 8075616 Create tests to check wsgen, schemagen work
	with multi-version jar
In-Reply-To: <06AF7A37-21E3-4BC5-9F19-DDBB704D49BB@oracle.com>
References: <CBABED4B-B8A2-4A80-9BD2-8039A055F5AD@oracle.com>
	<86914c18-9d41-6778-4a4d-66acff3442ac@oracle.com>
	<FADC68EB-89AF-4CCA-AEE2-EBF55212D3FC@oracle.com>
	<ff92bd6a-559e-6206-0e23-5d141a4441cf@oracle.com>
	<D0BAB791-CBE0-4BFA-928E-A7405860BE18@oracle.com>
	<75C6ACF3-28E8-4475-B871-049601D1FE79@oracle.com>
	<A26F3D5A-F5C6-4877-9FDB-DDC47AD2DD7A@oracle.com>
	<97E00806-D7A7-4A37-B445-64D7C1F8F7FD@oracle.com>
	<ba2edf50-77af-4c52-ded2-496869c4f233@oracle.com>
	<06AF7A37-21E3-4BC5-9F19-DDBB704D49BB@oracle.com>
Message-ID: <cb1d68ae-52bd-eaaa-c811-2653aa7832bf@oracle.com>



On 01/02/2017 16:46, Andrey Nazarov wrote:
> Hi Alan,
>
> I moved tests to suggested locations. http://cr.openjdk.java.net/~anazarov/8075617/webrev.02/webrev/
>
>
Thanks, I'm happy with these locations.

-Alan

From claes.redestad at oracle.com  Wed Feb  1 17:00:56 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 1 Feb 2017 18:00:56 +0100
Subject: RFR: 8160302: Reduce number of lambdas created when loading
	java.util.regex.Pattern
Message-ID: <9af9ec5e-0e54-6f45-7c17-fd929aa8abb1@oracle.com>

Hi,

changes to java.util.regex in 9+119 has been cause for a number of startup
regressions due to early use of lambdas, which has both helped motivate
work to reduce the overall cost of lambda initialization[1], while in other
cases the use of regexes could be reconsidered (VersionProps).

While this work and workarounds has helped a lot, the changes to
java.util.regex can still be the cause of noticeable regressions[2] when
using regular expressions that depend on predicates defined in
java.util.regex.CharPredicate, simply because of how this class eagerly
creates a substantial amount of lambdas during clinit.

This patch makes the initialization lazy, which improves startup metrics
without affecting performance of regular use.

Bug: https://bugs.openjdk.java.net/browse/JDK-8160302
Webrev: http://cr.openjdk.java.net/~redestad/8160302/webrev.01/

Thanks!

/Claes

PS. Yes, I know final is redundant on static methods, and realized I forgot
to remove them after turning constants into methods, but looking at again
it seems there's a convention of defining static methods final in this code
already, so unless there is a lot of outrage I'd like to defer cleaning 
up this
particular bikeshed.

[1] https://bugs.openjdk.java.net/browse/JDK-8086045
[2] 12-15ms startup regressions due to generating and loading up to 60
loaded classes, more early JIT compilations etc..

From paul.sandoz at oracle.com  Wed Feb  1 17:18:43 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 1 Feb 2017 09:18:43 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <CA+kOe0_So3eYwBpds4v2YcFr8VdivamDfe=n-42XHoVjWpeL2A@mail.gmail.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
	<2EAFB6CB-F9A3-409E-81EB-02DCAB5AB152@oracle.com>
	<CA+kOe0-sN8sbQ9mW5saPeAtbQN7zsDaxk446BNWFdfQ6dMqKOQ@mail.gmail.com>
	<95658EF2-D340-4031-8437-F63F9EF69992@oracle.com>
	<CA+kOe08Kb_SApj6fobjAPihmsKKYMpb=F1YDPM8HapnXgz4wLQ@mail.gmail.com>
	<B1EA6547-F29C-48FE-A2C1-859EA34B3AAC@oracle.com>
	<CA+kOe08XX8336j=iP=pCy+TBi55zf-4eLFahDw=TV8S+VhwMyQ@mail.gmail.com>
	<AE180A98-1712-49D6-BECD-143346207AA1@oracle.com>
	<CA+kOe0_So3eYwBpds4v2YcFr8VdivamDfe=n-42XHoVjWpeL2A@mail.gmail.com>
Message-ID: <41E61396-B9A6-4158-8A89-8CB79DA8A8F2@oracle.com>


> On 1 Feb 2017, at 08:44, Martin Buchholz <martinrb at google.com> wrote:
> 
> 
> 
> On Wed, Feb 1, 2017 at 7:44 AM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
> 
> I think that would be too pedantic as well. At this late stage in 9 i prefer to leave things as they are and not fiddle. Revise for 10?
> 
> We could, but jsr166 primitive version control technology doesn't have a mechanism to maintain such distinctions.
> 

Ok. Sorry for being so conservative, just concerned given the schedule.


> I still think the jdk9 docs are misleading and we should do something to fix them.  The high-level bit for users is "Bulk operations are non-atomic"!  Maybe we should include that sentence?!


Ok.

Paul.


From martinrb at google.com  Wed Feb  1 19:48:28 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 1 Feb 2017 11:48:28 -0800
Subject: RFR: 8160302: Reduce number of lambdas created when loading
	java.util.regex.Pattern
In-Reply-To: <9af9ec5e-0e54-6f45-7c17-fd929aa8abb1@oracle.com>
References: <9af9ec5e-0e54-6f45-7c17-fd929aa8abb1@oracle.com>
Message-ID: <CA+kOe0-hzK6iFXFkZ+jwBun5HW_ChrqKaQFGkFcgErxFi5b-5Q@mail.gmail.com>

I agree with the startup improvement goal.
The need to do:

+            case "ALPHA": return ALPHABETIC();

is pretty horrible (but we do worse in the name of performance).  We'd like
to be able to simply do:
return Character::isAlphabetic;
but probably we're stymied by hotspot's eagerness being per-method, not
per-statement. Is the long-term solution to make hotspot's lambda
initialization even lazier?



On Wed, Feb 1, 2017 at 9:00 AM, Claes Redestad <claes.redestad at oracle.com>
wrote:

> Hi,
>
> changes to java.util.regex in 9+119 has been cause for a number of startup
> regressions due to early use of lambdas, which has both helped motivate
> work to reduce the overall cost of lambda initialization[1], while in other
> cases the use of regexes could be reconsidered (VersionProps).
>
> While this work and workarounds has helped a lot, the changes to
> java.util.regex can still be the cause of noticeable regressions[2] when
> using regular expressions that depend on predicates defined in
> java.util.regex.CharPredicate, simply because of how this class eagerly
> creates a substantial amount of lambdas during clinit.
>
> This patch makes the initialization lazy, which improves startup metrics
> without affecting performance of regular use.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8160302
> Webrev: http://cr.openjdk.java.net/~redestad/8160302/webrev.01/
>
> Thanks!
>
> /Claes
>
> PS. Yes, I know final is redundant on static methods, and realized I forgot
> to remove them after turning constants into methods, but looking at again
> it seems there's a convention of defining static methods final in this code
> already, so unless there is a lot of outrage I'd like to defer cleaning up
> this
> particular bikeshed.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8086045
> [2] 12-15ms startup regressions due to generating and loading up to 60
> loaded classes, more early JIT compilations etc..
>

From rob.mckenna at oracle.com  Wed Feb  1 20:05:50 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 1 Feb 2017 20:05:50 +0000
Subject: [RFR] 8160768: Add capability to custom resolve host/domain
	names within the default JDNI LDAP provider
In-Reply-To: <20170126040326.GA3544@vimes>
References: <20170125163141.GB3628@tecra> <20170125174453.GE3628@tecra>
	<f81eb731-358e-a680-0788-05230af9ce07@oracle.com>
	<20170126040326.GA3544@vimes>
Message-ID: <20170201200550.GH2829@vimes>

New webrev with updated test here:

http://cr.openjdk.java.net/~robm/8160768/webrev.03/

    -Rob

On 26/01/17 04:03, Rob McKenna wrote:
> Ack, apologies, thats what I get for rushing. (which I suppose I'm doing
> again) That code was actually supposed to be in the getDnsUrls method.
> Updated in place:
> 
> http://cr.openjdk.java.net/~robm/8160768/webrev.02/
> 
> I'll add a couple of tests for the SecurityManager along with some input
> checking tests too.
> 
>     -Rob
> 
> On 25/01/17 05:50, Daniel Fuchs wrote:
> > Hi Rob,
> > 
> > I believe you should move the security check to before
> > the class is actually loaded, before the call to
> >  171             List<String> urls = getDnsUrls(url, env);
> > 
> > best regards,
> > 
> > -- daniel
> > 
> > On 25/01/17 17:44, Rob McKenna wrote:
> > >I neglected to include a security check so I've cribbed the one from
> > >OBJECT_FACTORIES (NamingManager.setObjectFactoryBuilder()) - see:
> > >
> > >http://cr.openjdk.java.net/~robm/8160768/webrev.02/
> > >
> > >Note, this wraps the SecurityException in a NamingException. Presumably
> > >its better to throw something than simply leave the default value in
> > >place, but feedback appreciated!
> > >
> > >    -Rob
> > >
> > >On 25/01/17 04:31, Rob McKenna wrote:
> > >>Hi folks,
> > >>
> > >>I'm looking for feedback on this suggested fix for the following bug:
> > >>
> > >>https://bugs.openjdk.java.net/browse/JDK-816076
> > >>http://cr.openjdk.java.net/~robm/8160768/webrev.01/
> > >>
> > >>This is something that has come up a few times. Basically in certain
> > >>environments (e.g. MS Active Directory) there is a dependence on
> > >>DNS records to provide a pointer to the actual ldap server to be used
> > >>for a given LdapCtx.PROVIDER_URL where the url itself simply points to the
> > >>domain name.
> > >>
> > >>This fix add a new Ldap context property which allows a user to specify a
> > >>class (implementing BiFunction) which can perform any necessary extra steps
> > >>to derive the ldap servers hostname/port from the PROVIDER_URL.
> > >>
> > >>    -Rob
> > >>
> > 

From stuart.marks at oracle.com  Wed Feb  1 20:35:06 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 1 Feb 2017 12:35:06 -0800
Subject: RFR(s): 8044626 & 8165649 RMI spec changes for modularization
In-Reply-To: <EC709353-6B9B-42DB-A2EC-10ADFFDC68F3@oracle.com>
References: <b8f84d16-aff3-3565-618c-8af807e3b89a@oracle.com>
	<EC709353-6B9B-42DB-A2EC-10ADFFDC68F3@oracle.com>
Message-ID: <fb1a4ea5-c77d-0a70-eb96-129709a2f654@oracle.com>

On 1/31/17 10:08 PM, Mandy Chung wrote:
> Except a typo ?contructor?,  looks okay.

Oh yes, thanks, I'll fix this.

s'marks

From stuart.marks at oracle.com  Wed Feb  1 20:47:22 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 1 Feb 2017 12:47:22 -0800
Subject: RFR(s): 8044626 & 8165649 RMI spec changes for modularization
In-Reply-To: <6032cf24-fddb-e9a9-45f0-83f6177be6d2@oracle.com>
References: <b8f84d16-aff3-3565-618c-8af807e3b89a@oracle.com>
	<6032cf24-fddb-e9a9-45f0-83f6177be6d2@oracle.com>
Message-ID: <60b7934e-b1ae-ab33-b7c1-6a168c9aab25@oracle.com>



On 2/1/17 12:33 AM, Alan Bateman wrote:
> On 01/02/2017 00:22, Stuart Marks wrote:
>> +    *
>> +    * <ul><li>If the class to be activated and the special activation
>> contructor are both public,
>> +    * the class must reside in a package that is exported or open to the
>> +    * {@code java.rmi} module.
> I think it would be better to just say "exported" rather than "exported or open"
> and have it link to Module#isExported(String,Module).
>
>> +    *
>> +    * <li>If either the class to be activated or the special activation
>> constructor
>> +    * is non-public, the class must reside in a package that is open to the
>> +    * {@code java.rmi} module.
>> +    * </ul>
> and for completeness, have "open" link to Module#isOpen(String,Module).

I think the "open" in the first item is necessary, given that the second item 
restricts itself to the non-public cases. However, the latter restriction isn't 
necessary! I wrote out all 16 cases in a truth table (open, exported, pub-class, 
pub-constructor) and minimized it -- though not using a Karnaugh map -- and the 
result is simply:

     (exported && public-class && public-constructor) || open

This simplifies things somewhat.

The situation with dynamic stubs in UnicastRemoteObject is similar. The logic is 
the same, but there can be a mixture of remote interfaces, which complicates 
things a bit. Nonetheless I think the rewording came well.

I've also added links per your suggestion, and fixed some typos.

Revised diff below.

s'marks

diff -r 0e0e0fbc5bf3 
src/java.rmi/share/classes/java/rmi/activation/ActivationInstantiator.java
--- a/src/java.rmi/share/classes/java/rmi/activation/ActivationInstantiator.java 
Fri Jan 13 12:35:53 2017 -0800
+++ b/src/java.rmi/share/classes/java/rmi/activation/ActivationInstantiator.java 
Wed Feb 01 12:44:24 2017 -0800
@@ -60,7 +60,20 @@
      * initialization data, and
      *
      * <li> returning a MarshalledObject containing the stub for the
-    * remote object it created </ul>
+    * remote object it created.</ul>
+    *
+    * <p>In order for activation to be successful, one of the following 
requirements
+    * must be met, otherwise {@link ActivationException} is thrown:
+    *
+    * <ul><li>The class to be activated and the special activation constructor 
are both public,
+    * and the class resides in a package that is
+    * {@linkplain 
java.lang.reflect.Module#isExported(String,java.lang.reflect.Module) exported}
+    * to the {@code java.rmi} module; or
+    *
+    * <li>The class to be activated resides in a package that is
+    * {@linkplain 
java.lang.reflect.Module#isOpen(String,java.lang.reflect.Module) open}
+    * to the {@code java.rmi} module.
+    * </ul>
      *
      * @param id the object's activation identifier
      * @param desc the object's descriptor
diff -r 0e0e0fbc5bf3 src/java.rmi/share/classes/java/rmi/activation/Activator.java
--- a/src/java.rmi/share/classes/java/rmi/activation/Activator.java	Fri Jan 13 
12:35:53 2017 -0800
+++ b/src/java.rmi/share/classes/java/rmi/activation/Activator.java	Wed Feb 01 
12:44:24 2017 -0800
@@ -48,7 +48,7 @@
   * The <code>Activator</code> works closely with
   * <code>ActivationSystem</code>, which provides a means for registering
   * groups and objects within those groups, and <code>ActivationMonitor</code>,
- * which recives information about active and inactive objects and inactive
+ * which receives information about active and inactive objects and inactive
   * groups. <p>
   *
   * The activator is responsible for monitoring and detecting when
diff -r 0e0e0fbc5bf3 
src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java
--- a/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java	Fri 
Jan 13 12:35:53 2017 -0800
+++ b/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java	Wed 
Feb 01 12:44:24 2017 -0800
@@ -107,8 +107,9 @@
   * the binary name of the root class with the suffix {@code _Stub}.
   *
   * <li>The stub class is loaded by name using the class loader of the root
- * class. The stub class must extend {@link RemoteStub} and must have a
- * public constructor that has one parameter of type {@link RemoteRef}.
+ * class. The stub class must be public, it must extend {@link RemoteStub}, it must
+ * reside in a package that is exported to the {@code java.rmi} module, and it
+ * must have a public constructor that has one parameter of type {@link RemoteRef}.
   *
   * <li>Finally, an instance of the stub class is constructed with a
   * {@link RemoteRef}.
@@ -124,12 +125,21 @@
   *
   * <ul>
   *
- * <li>The proxy's class is defined by the class loader of the remote
- * object's class.
+ * <li>The proxy's class is defined according to the specifications for the
+ * <a href="{@docRoot}/java/lang/reflect/Proxy.html#membership">
+ * {@code Proxy}
+ * </a>
+ * class, using the class loader of the remote object's class.
   *
   * <li>The proxy implements all the remote interfaces implemented by the
   * remote object's class.
   *
+ * <li>Each remote interface must either be public and reside in a package that is
+ * {@linkplain 
java.lang.reflect.Module#isExported(String,java.lang.reflect.Module) exported}
+ * to the {@code java.rmi} module, or it must reside in a package that is
+ * {@linkplain java.lang.reflect.Module#isOpen(String,java.lang.reflect.Module) 
open}
+ * to the {@code java.rmi} module.
+ *
   * <li>The proxy's invocation handler is a {@link
   * RemoteObjectInvocationHandler} instance constructed with a
   * {@link RemoteRef}.

From martinrb at google.com  Wed Feb  1 20:52:46 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 1 Feb 2017 12:52:46 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
Message-ID: <CA+kOe09XDwdm3U5Gv8uJjLwcqjrNF_7Mm_Y3g77LbV87CWApsw@mail.gmail.com>

Wave 14 now contains a bug fix for a minor mistake in a previous wave.
https://bugs.openjdk.java.net/browse/JDK-8173706
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/Vector-setSize/

From claes.redestad at oracle.com  Wed Feb  1 21:12:39 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 1 Feb 2017 22:12:39 +0100
Subject: RFR: 8160302: Reduce number of lambdas created when loading
	java.util.regex.Pattern
In-Reply-To: <CA+kOe0-hzK6iFXFkZ+jwBun5HW_ChrqKaQFGkFcgErxFi5b-5Q@mail.gmail.com>
References: <9af9ec5e-0e54-6f45-7c17-fd929aa8abb1@oracle.com>
	<CA+kOe0-hzK6iFXFkZ+jwBun5HW_ChrqKaQFGkFcgErxFi5b-5Q@mail.gmail.com>
Message-ID: <ee6714b1-019f-3e6e-0a4f-02a008fccd8d@oracle.com>

Hi Martin!

On 2017-02-01 20:48, Martin Buchholz wrote:
> I agree with the startup improvement goal.
> The need to do:
>
> + case "ALPHA": return ALPHABETIC();
>
> is pretty horrible (but we do worse in the name of performance).  We'd
> like to be able to simply do:
> return Character::isAlphabetic;
> but probably we're stymied by hotspot's eagerness being per-method, not
> per-statement.

I'm not sure I agree it's *that* horrible, but maybe I've grown
accustomed to somewhat horrible code... :-)

And no, while hotspot might the bytecode for a method eagerly, I'm
pretty sure the bootstrap method, which does the actual lambda
initialization and replace the instruction at the callsite, is not run
until executing the statement.

So, while I guess we could write "case "ALPHA": return
Character::isAlphabetic;" and get the same net result, I haven't
checked if that means we'd go through the hoop of spinning up that call
site at each location (ending up with the same thing) or if javac helps
ensure it'll be done at most once here.

As tests have been thoroughly run on this and time is running out,
I'd prefer contemplating cleaner/nicer ways of writing this particular
patch for 10 if you don't mind.

> Is the long-term solution to make hotspot's lambda initialization even lazier?

I guess it'd be interesting to try make lambdas like these (which
aren't used just after initialization) even lazier by emitting, say,
some thin MutableCallSite that defers real initialization to first use,
but not sure if feasible or if it'd even pay off except for cases like
these where you generate a lot of lambdas / method references but don't
use them right away. I'm sure others have thought more about this than
me.

Somewhat orthogonally I do have plans to continue work on the static
pre-generation jlink plugin I introduced as part of 8086045, along with
other micro-optimizations to the involved java.lang.invoke code. This
helps make each call site lighter to spin up.

AOT might help, too, but stumbles once we actually have to generate a 
new class dynamically, so it's not competing with the things we can
do with jlink currently...

All in all I'm sure we can inch closer and closer to negligible startup
overhead given time and dedication.

/Claes

>
>
>
> On Wed, Feb 1, 2017 at 9:00 AM, Claes Redestad
> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>
>     Hi,
>
>     changes to java.util.regex in 9+119 has been cause for a number of
>     startup
>     regressions due to early use of lambdas, which has both helped motivate
>     work to reduce the overall cost of lambda initialization[1], while
>     in other
>     cases the use of regexes could be reconsidered (VersionProps).
>
>     While this work and workarounds has helped a lot, the changes to
>     java.util.regex can still be the cause of noticeable regressions[2] when
>     using regular expressions that depend on predicates defined in
>     java.util.regex.CharPredicate, simply because of how this class eagerly
>     creates a substantial amount of lambdas during clinit.
>
>     This patch makes the initialization lazy, which improves startup metrics
>     without affecting performance of regular use.
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8160302
>     <https://bugs.openjdk.java.net/browse/JDK-8160302>
>     Webrev: http://cr.openjdk.java.net/~redestad/8160302/webrev.01/
>     <http://cr.openjdk.java.net/~redestad/8160302/webrev.01/>
>
>     Thanks!
>
>     /Claes
>
>     PS. Yes, I know final is redundant on static methods, and realized I
>     forgot
>     to remove them after turning constants into methods, but looking at
>     again
>     it seems there's a convention of defining static methods final in
>     this code
>     already, so unless there is a lot of outrage I'd like to defer
>     cleaning up this
>     particular bikeshed.
>
>     [1] https://bugs.openjdk.java.net/browse/JDK-8086045
>     <https://bugs.openjdk.java.net/browse/JDK-8086045>
>     [2] 12-15ms startup regressions due to generating and loading up to 60
>     loaded classes, more early JIT compilations etc..
>
>

From paul.sandoz at oracle.com  Wed Feb  1 21:18:04 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 1 Feb 2017 13:18:04 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <CA+kOe09XDwdm3U5Gv8uJjLwcqjrNF_7Mm_Y3g77LbV87CWApsw@mail.gmail.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
	<CA+kOe09XDwdm3U5Gv8uJjLwcqjrNF_7Mm_Y3g77LbV87CWApsw@mail.gmail.com>
Message-ID: <25691C09-CAFC-45E4-B1A8-23C03C3A225E@oracle.com>


> On 1 Feb 2017, at 12:52, Martin Buchholz <martinrb at google.com> wrote:
> 
> Wave 14 now contains a bug fix for a minor mistake in a previous wave.
> https://bugs.openjdk.java.net/browse/JDK-8173706 <https://bugs.openjdk.java.net/browse/JDK-8173706>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/Vector-setSize/ <http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/Vector-setSize/>

+1

Paul.


From stuart.marks at oracle.com  Wed Feb  1 21:23:25 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 1 Feb 2017 13:23:25 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <CA+kOe09XDwdm3U5Gv8uJjLwcqjrNF_7Mm_Y3g77LbV87CWApsw@mail.gmail.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
	<CA+kOe09XDwdm3U5Gv8uJjLwcqjrNF_7Mm_Y3g77LbV87CWApsw@mail.gmail.com>
Message-ID: <4da55157-ec60-2702-9e5f-d83cec8d1382@oracle.com>

On 2/1/17 12:52 PM, Martin Buchholz wrote:
> Wave 14 now contains a bug fix for a minor mistake in a previous wave.
> https://bugs.openjdk.java.net/browse/JDK-8173706
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/Vector-setSize/

Hi Martin, thanks for picking this up.

The Vector change and corresponding test change look good.

One observation I have (which might have contributed to the bug) is that the 
method relies on the array access within the for-loop to throw AIOOBE if the new 
size is negative. This is pretty obscure.

Conventionally, the precondition would be checked at the top of the method. (But 
that might increase the method size beyond the inlining limit. (But who cares 
about Vector anyway?))

An alternative might be simply to put a comment noting this at the location of 
the array index. This adds some clutter; I'm not sure it's worth it.

Or maybe do nothing, and let this remain as one of the "things you have to look 
out for" when deailng with collections code.

I don't have strong opinions favoring any of these, but if you have thoughts I'd 
be interested in hearing them.

s'marks

From martinrb at google.com  Thu Feb  2 00:02:57 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 1 Feb 2017 16:02:57 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <4da55157-ec60-2702-9e5f-d83cec8d1382@oracle.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
	<CA+kOe09XDwdm3U5Gv8uJjLwcqjrNF_7Mm_Y3g77LbV87CWApsw@mail.gmail.com>
	<4da55157-ec60-2702-9e5f-d83cec8d1382@oracle.com>
Message-ID: <CA+kOe0-uxC_BPAvKVTgFZG4A5HMAttjPVuT-6=Wth1jiJZA0jw@mail.gmail.com>

Doug and I seem to be more performance focused than others when working on
core libraries.

I like relying on tests to catch mistakes, and leave source code spartan,
when possible.  OTOH the really tricky stuff is well documented in the
j.u.c. sources, as you can see elsewhere in this wave.

It would have been helpful if the jck tests were run earlier, e.g. before I
submitted.  Surely Oracle has the resources to run the jck at least once
for every jdk9 master integration.  This bug should never have gotten into
the jdk9 master.

We should keep taking good care of Vector.

On Wed, Feb 1, 2017 at 1:23 PM, Stuart Marks <stuart.marks at oracle.com>
wrote:

> On 2/1/17 12:52 PM, Martin Buchholz wrote:
>
>> Wave 14 now contains a bug fix for a minor mistake in a previous wave.
>> https://bugs.openjdk.java.net/browse/JDK-8173706
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-
>> jdk9-integration/Vector-setSize/
>>
>
> Hi Martin, thanks for picking this up.
>
> The Vector change and corresponding test change look good.
>
> One observation I have (which might have contributed to the bug) is that
> the method relies on the array access within the for-loop to throw AIOOBE
> if the new size is negative. This is pretty obscure.
>
> Conventionally, the precondition would be checked at the top of the
> method. (But that might increase the method size beyond the inlining limit.
> (But who cares about Vector anyway?))
>
> An alternative might be simply to put a comment noting this at the
> location of the array index. This adds some clutter; I'm not sure it's
> worth it.
>
> Or maybe do nothing, and let this remain as one of the "things you have to
> look out for" when deailng with collections code.
>
> I don't have strong opinions favoring any of these, but if you have
> thoughts I'd be interested in hearing them.
>
> s'marks
>

From martinrb at google.com  Thu Feb  2 00:21:14 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 1 Feb 2017 16:21:14 -0800
Subject: RFR: 8160302: Reduce number of lambdas created when loading
	java.util.regex.Pattern
In-Reply-To: <ee6714b1-019f-3e6e-0a4f-02a008fccd8d@oracle.com>
References: <9af9ec5e-0e54-6f45-7c17-fd929aa8abb1@oracle.com>
	<CA+kOe0-hzK6iFXFkZ+jwBun5HW_ChrqKaQFGkFcgErxFi5b-5Q@mail.gmail.com>
	<ee6714b1-019f-3e6e-0a4f-02a008fccd8d@oracle.com>
Message-ID: <CA+kOe0-3pim3vqXTdtwhjq1u14bnga3_dT_gLSCGNE1Q7LO7wg@mail.gmail.com>

Looks good to me!

On Wed, Feb 1, 2017 at 1:12 PM, Claes Redestad <claes.redestad at oracle.com>
wrote:

> Hi Martin!
>
> On 2017-02-01 20:48, Martin Buchholz wrote:
>
>> I agree with the startup improvement goal.
>> The need to do:
>>
>> + case "ALPHA": return ALPHABETIC();
>>
>> is pretty horrible (but we do worse in the name of performance).  We'd
>> like to be able to simply do:
>> return Character::isAlphabetic;
>> but probably we're stymied by hotspot's eagerness being per-method, not
>> per-statement.
>>
>
> I'm not sure I agree it's *that* horrible, but maybe I've grown
> accustomed to somewhat horrible code... :-)
>
> And no, while hotspot might the bytecode for a method eagerly, I'm
> pretty sure the bootstrap method, which does the actual lambda
> initialization and replace the instruction at the callsite, is not run
> until executing the statement.
>
> So, while I guess we could write "case "ALPHA": return
> Character::isAlphabetic;" and get the same net result, I haven't
> checked if that means we'd go through the hoop of spinning up that call
> site at each location (ending up with the same thing) or if javac helps
> ensure it'll be done at most once here.
>
> As tests have been thoroughly run on this and time is running out,
> I'd prefer contemplating cleaner/nicer ways of writing this particular
> patch for 10 if you don't mind.
>
> Is the long-term solution to make hotspot's lambda initialization even
>> lazier?
>>
>
> I guess it'd be interesting to try make lambdas like these (which
> aren't used just after initialization) even lazier by emitting, say,
> some thin MutableCallSite that defers real initialization to first use,
> but not sure if feasible or if it'd even pay off except for cases like
> these where you generate a lot of lambdas / method references but don't
> use them right away. I'm sure others have thought more about this than
> me.
>
> Somewhat orthogonally I do have plans to continue work on the static
> pre-generation jlink plugin I introduced as part of 8086045, along with
> other micro-optimizations to the involved java.lang.invoke code. This
> helps make each call site lighter to spin up.
>
> AOT might help, too, but stumbles once we actually have to generate a new
> class dynamically, so it's not competing with the things we can
> do with jlink currently...
>
> All in all I'm sure we can inch closer and closer to negligible startup
> overhead given time and dedication.
>
> /Claes
>
>
>>
>>
>> On Wed, Feb 1, 2017 at 9:00 AM, Claes Redestad
>> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>>
>>     Hi,
>>
>>     changes to java.util.regex in 9+119 has been cause for a number of
>>     startup
>>     regressions due to early use of lambdas, which has both helped
>> motivate
>>     work to reduce the overall cost of lambda initialization[1], while
>>     in other
>>     cases the use of regexes could be reconsidered (VersionProps).
>>
>>     While this work and workarounds has helped a lot, the changes to
>>     java.util.regex can still be the cause of noticeable regressions[2]
>> when
>>     using regular expressions that depend on predicates defined in
>>     java.util.regex.CharPredicate, simply because of how this class
>> eagerly
>>     creates a substantial amount of lambdas during clinit.
>>
>>     This patch makes the initialization lazy, which improves startup
>> metrics
>>     without affecting performance of regular use.
>>
>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8160302
>>     <https://bugs.openjdk.java.net/browse/JDK-8160302>
>>     Webrev: http://cr.openjdk.java.net/~redestad/8160302/webrev.01/
>>     <http://cr.openjdk.java.net/~redestad/8160302/webrev.01/>
>>
>>     Thanks!
>>
>>     /Claes
>>
>>     PS. Yes, I know final is redundant on static methods, and realized I
>>     forgot
>>     to remove them after turning constants into methods, but looking at
>>     again
>>     it seems there's a convention of defining static methods final in
>>     this code
>>     already, so unless there is a lot of outrage I'd like to defer
>>     cleaning up this
>>     particular bikeshed.
>>
>>     [1] https://bugs.openjdk.java.net/browse/JDK-8086045
>>     <https://bugs.openjdk.java.net/browse/JDK-8086045>
>>     [2] 12-15ms startup regressions due to generating and loading up to 60
>>     loaded classes, more early JIT compilations etc..
>>
>>
>>

From maurizio.cimadamore at oracle.com  Thu Feb  2 00:39:49 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 2 Feb 2017 00:39:49 +0000
Subject: RFR: 8160302: Reduce number of lambdas created when loading
	java.util.regex.Pattern
In-Reply-To: <ee6714b1-019f-3e6e-0a4f-02a008fccd8d@oracle.com>
References: <9af9ec5e-0e54-6f45-7c17-fd929aa8abb1@oracle.com>
	<CA+kOe0-hzK6iFXFkZ+jwBun5HW_ChrqKaQFGkFcgErxFi5b-5Q@mail.gmail.com>
	<ee6714b1-019f-3e6e-0a4f-02a008fccd8d@oracle.com>
Message-ID: <0ce36861-aa38-9040-9c08-e0cbb2655cbe@oracle.com>



On 01/02/17 21:12, Claes Redestad wrote:
> As tests have been thoroughly run on this and time is running out,
> I'd prefer contemplating cleaner/nicer ways of writing this particular
> patch for 10 if you don't mind. 
I believe an enum could do quite well in this particular situation - 
when we revisit the code in 10, and lead to a more 'declarative' version 
of the same code. For example, each enum constant could have strings for 
storing posix/unix predicates, and a method that returns your lazy 
method reference. That should clean up the code quite a bit.

Cheers
Maurizio

From mandy.chung at oracle.com  Thu Feb  2 02:41:42 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 1 Feb 2017 18:41:42 -0800
Subject: RFR: 8173607: JMX RMI connector should be in its own module
In-Reply-To: <5ad3fe2b-be04-24c7-98bb-8bab61c3aa15@oracle.com>
References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com>
	<BD7108DF-69F6-4807-88BC-57D3C7D47CAC@oracle.com>
	<5ad3fe2b-be04-24c7-98bb-8bab61c3aa15@oracle.com>
Message-ID: <3788E0D3-FEDE-4C32-9C04-B54A619AFFE3@oracle.com>


> On Feb 1, 2017, at 7:29 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Here is the updated webrev, rebased after pulling JDK-8173608, and with
> your feedback below integrated.
> 
> I am pleased to report that java.management no longer requires
> java.rmi or java.naming :-)
> 

This is great!

> Compared to previous version, then RMIExporter has been moved
> to java.management.rmi, various module-info.java have been
> cleaned up, some @modules in tests have been updated (mostly
> due to the RMIExporter move).
> 
> I have also improved some javadoc comments in JMXConnectorFactory.java
> No changes in build files compared to webrev.05
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06

Does java.management still depend on java.base/jdk.internal.module?

> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06/java.management.rmi-summary.html
> 

Maybe the first sentence of @provides could be simplified to:

A provider of JMXConnectorProvider for the RMI protocol.
A provider of JMXConnectorServerProvider for the RMI protocol.

Otherwise looks good.
Mandy




From xueming.shen at oracle.com  Thu Feb  2 03:53:57 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 1 Feb 2017 19:53:57 -0800
Subject: RFR: 8160302: Reduce number of lambdas created when loading
	java.util.regex.Pattern
In-Reply-To: <9af9ec5e-0e54-6f45-7c17-fd929aa8abb1@oracle.com>
References: <9af9ec5e-0e54-6f45-7c17-fd929aa8abb1@oracle.com>
Message-ID: <53A7C409-78E7-4367-ADE8-A7C2A372AD24@oracle.com>

+1

On Feb 1, 2017, at 9:00 AM, Claes Redestad <claes.redestad at oracle.com> wrote:

Hi,

changes to java.util.regex in 9+119 has been cause for a number of startup
regressions due to early use of lambdas, which has both helped motivate
work to reduce the overall cost of lambda initialization[1], while in other
cases the use of regexes could be reconsidered (VersionProps).

While this work and workarounds has helped a lot, the changes to
java.util.regex can still be the cause of noticeable regressions[2] when
using regular expressions that depend on predicates defined in
java.util.regex.CharPredicate, simply because of how this class eagerly
creates a substantial amount of lambdas during clinit.

This patch makes the initialization lazy, which improves startup metrics
without affecting performance of regular use.

Bug: https://bugs.openjdk.java.net/browse/JDK-8160302
Webrev: http://cr.openjdk.java.net/~redestad/8160302/webrev.01/

Thanks!

/Claes

PS. Yes, I know final is redundant on static methods, and realized I forgot
to remove them after turning constants into methods, but looking at again
it seems there's a convention of defining static methods final in this code
already, so unless there is a lot of outrage I'd like to defer cleaning up this
particular bikeshed.

[1] https://bugs.openjdk.java.net/browse/JDK-8086045
[2] 12-15ms startup regressions due to generating and loading up to 60
loaded classes, more early JIT compilations etc..


From daniel.fuchs at oracle.com  Thu Feb  2 11:01:52 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 2 Feb 2017 11:01:52 +0000
Subject: [RFR] 8160768: Add capability to custom resolve host/domain names
	within the default JDNI LDAP provider
In-Reply-To: <20170201200550.GH2829@vimes>
References: <20170125163141.GB3628@tecra> <20170125174453.GE3628@tecra>
	<f81eb731-358e-a680-0788-05230af9ce07@oracle.com>
	<20170126040326.GA3544@vimes> <20170201200550.GH2829@vimes>
Message-ID: <f6b229bf-292b-2fc1-278c-a4acaa869968@oracle.com>

Hi Rob,

This is not a code I know well - but here are a couple
of comments:

LdapCtxFactory.java:

168         NamingException ne = new NamingException();
232         NamingException ne = new NamingException();

Creating an exception is somewhat costly as it records the
backtrace in the Throwable constructor. I don't know if
it's an issue there but I thought I'd mention it. It might
be better to create the exception only if you're actually
going to throw it.

  186         } catch (Exception e) {
  187             ne.setRootCause(e);
  188         }

This will catch the NamingException thrown at line 173
and set it at the cause of another NamingException that
has no message. Maybe it would be better to have two
catch clauses:

  186         } catch (NamingException e) {
  187             throw e;
  186         } catch (Exception e) {
                  ... transform it to NamingException ...

In getDnsUrls:

  198         if (env.containsKey(LdapCtx.DNS_PROVIDER)
  199                 && env.get(LdapCtx.DNS_PROVIDER) != null
  200                 && !env.get(LdapCtx.DNS_PROVIDER).equals(""))

I'd suggest to simplify this and make a single lookup:

              String providerClass = env.get(LdapCtx.DNS_PROVIDER);
              if (providerClass != null && !providerClass.isEmpty()) {
                  ...
                  Class<?> cls = Class.forName(providerClass, true, cl);

best regards,

-- daniel


On 01/02/17 20:05, Rob McKenna wrote:
> New webrev with updated test here:
>
> http://cr.openjdk.java.net/~robm/8160768/webrev.03/
>
>     -Rob
>
> On 26/01/17 04:03, Rob McKenna wrote:
>> Ack, apologies, thats what I get for rushing. (which I suppose I'm doing
>> again) That code was actually supposed to be in the getDnsUrls method.
>> Updated in place:
>>
>> http://cr.openjdk.java.net/~robm/8160768/webrev.02/
>>
>> I'll add a couple of tests for the SecurityManager along with some input
>> checking tests too.
>>
>>     -Rob
>>
>> On 25/01/17 05:50, Daniel Fuchs wrote:
>>> Hi Rob,
>>>
>>> I believe you should move the security check to before
>>> the class is actually loaded, before the call to
>>>  171             List<String> urls = getDnsUrls(url, env);
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> On 25/01/17 17:44, Rob McKenna wrote:
>>>> I neglected to include a security check so I've cribbed the one from
>>>> OBJECT_FACTORIES (NamingManager.setObjectFactoryBuilder()) - see:
>>>>
>>>> http://cr.openjdk.java.net/~robm/8160768/webrev.02/
>>>>
>>>> Note, this wraps the SecurityException in a NamingException. Presumably
>>>> its better to throw something than simply leave the default value in
>>>> place, but feedback appreciated!
>>>>
>>>>    -Rob
>>>>
>>>> On 25/01/17 04:31, Rob McKenna wrote:
>>>>> Hi folks,
>>>>>
>>>>> I'm looking for feedback on this suggested fix for the following bug:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-816076
>>>>> http://cr.openjdk.java.net/~robm/8160768/webrev.01/
>>>>>
>>>>> This is something that has come up a few times. Basically in certain
>>>>> environments (e.g. MS Active Directory) there is a dependence on
>>>>> DNS records to provide a pointer to the actual ldap server to be used
>>>>> for a given LdapCtx.PROVIDER_URL where the url itself simply points to the
>>>>> domain name.
>>>>>
>>>>> This fix add a new Ldap context property which allows a user to specify a
>>>>> class (implementing BiFunction) which can perform any necessary extra steps
>>>>> to derive the ldap servers hostname/port from the PROVIDER_URL.
>>>>>
>>>>>    -Rob
>>>>>
>>>


From Alan.Bateman at oracle.com  Thu Feb  2 11:23:39 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 Feb 2017 11:23:39 +0000
Subject: RFR(s): 8044626 & 8165649 RMI spec changes for modularization
In-Reply-To: <60b7934e-b1ae-ab33-b7c1-6a168c9aab25@oracle.com>
References: <b8f84d16-aff3-3565-618c-8af807e3b89a@oracle.com>
	<6032cf24-fddb-e9a9-45f0-83f6177be6d2@oracle.com>
	<60b7934e-b1ae-ab33-b7c1-6a168c9aab25@oracle.com>
Message-ID: <73b6e189-25a3-51a9-644d-177e0f8fd01f@oracle.com>

On 01/02/2017 20:47, Stuart Marks wrote:

>
> The situation with dynamic stubs in UnicastRemoteObject is similar. 
> The logic is the same, but there can be a mixture of remote 
> interfaces, which complicates things a bit. Nonetheless I think the 
> rewording came well.
>
> I've also added links per your suggestion, and fixed some typos.
>
> Revised diff below.
The updated wording looks okay and for completeness then I would say 
"exported to at least java.rmi" and "open to at least java.rmi".

-Alan.

From claes.redestad at oracle.com  Thu Feb  2 12:05:09 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 2 Feb 2017 13:05:09 +0100
Subject: RFR: 8160302: Reduce number of lambdas created when loading
	java.util.regex.Pattern
In-Reply-To: <0ce36861-aa38-9040-9c08-e0cbb2655cbe@oracle.com>
References: <9af9ec5e-0e54-6f45-7c17-fd929aa8abb1@oracle.com>
	<CA+kOe0-hzK6iFXFkZ+jwBun5HW_ChrqKaQFGkFcgErxFi5b-5Q@mail.gmail.com>
	<ee6714b1-019f-3e6e-0a4f-02a008fccd8d@oracle.com>
	<0ce36861-aa38-9040-9c08-e0cbb2655cbe@oracle.com>
Message-ID: <9f02046e-f3ce-f41c-34da-9cc3695126ec@oracle.com>

Sherman, Martin, Maurizio, thanks for reviews and suggestions!

I've filed https://bugs.openjdk.java.net/browse/JDK-8173820 to deal with 
this cleanup at a later date.

/Claes

On 02/02/2017 01:39 AM, Maurizio Cimadamore wrote:
>
>
> On 01/02/17 21:12, Claes Redestad wrote:
>> As tests have been thoroughly run on this and time is running out,
>> I'd prefer contemplating cleaner/nicer ways of writing this particular
>> patch for 10 if you don't mind. 
> I believe an enum could do quite well in this particular situation - 
> when we revisit the code in 10, and lead to a more 'declarative' 
> version of the same code. For example, each enum constant could have 
> strings for storing posix/unix predicates, and a method that returns 
> your lazy method reference. That should clean up the code quite a bit.
>
> Cheers
> Maurizio


From daniel.fuchs at oracle.com  Thu Feb  2 12:37:55 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 2 Feb 2017 12:37:55 +0000
Subject: RFR: 8173607: JMX RMI connector should be in its own module
In-Reply-To: <3788E0D3-FEDE-4C32-9C04-B54A619AFFE3@oracle.com>
References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com>
	<BD7108DF-69F6-4807-88BC-57D3C7D47CAC@oracle.com>
	<5ad3fe2b-be04-24c7-98bb-8bab61c3aa15@oracle.com>
	<3788E0D3-FEDE-4C32-9C04-B54A619AFFE3@oracle.com>
Message-ID: <b4e9aaba-9347-3347-2cec-0b8b92a18049@oracle.com>

Hi Mandy,

On 02/02/17 02:41, Mandy Chung wrote:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06
>
> Does java.management still depend on java.base/jdk.internal.module?

Well spotted! It doesn't. I have updated module-info.java for java.base.

http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.07

>> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06/java.management.rmi-summary.html
>>
>
> Maybe the first sentence of @provides could be simplified to:
>
> A provider of JMXConnectorProvider for the RMI protocol.
> A provider of JMXConnectorServerProvider for the RMI protocol.

Done. But I think you meant A provider of JMXConnector[Server] for the 
RMI protocol.

http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.07/java.management.rmi-summary.html

best regards,

-- daniel

>
> Otherwise looks good.
> Mandy
>
>
>


From mandy.chung at oracle.com  Thu Feb  2 16:02:11 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 2 Feb 2017 08:02:11 -0800
Subject: RFR: 8173607: JMX RMI connector should be in its own module
In-Reply-To: <b4e9aaba-9347-3347-2cec-0b8b92a18049@oracle.com>
References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com>
	<BD7108DF-69F6-4807-88BC-57D3C7D47CAC@oracle.com>
	<5ad3fe2b-be04-24c7-98bb-8bab61c3aa15@oracle.com>
	<3788E0D3-FEDE-4C32-9C04-B54A619AFFE3@oracle.com>
	<b4e9aaba-9347-3347-2cec-0b8b92a18049@oracle.com>
Message-ID: <FBCB9EE7-8846-4B2D-B807-CF1A71DBC111@oracle.com>


> On Feb 2, 2017, at 4:37 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Mandy,
> 
> On 02/02/17 02:41, Mandy Chung wrote:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06
>> 
>> Does java.management still depend on java.base/jdk.internal.module?
> 
> Well spotted! It doesn't. I have updated module-info.java for java.base.
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.07

Looks good.

Mandy


From daniel.fuchs at oracle.com  Thu Feb  2 17:14:44 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 2 Feb 2017 17:14:44 +0000
Subject: Heads up: Fwd: hg: jdk9/dev/jdk: 8173607: JMX RMI connector should be
	in its own module
In-Reply-To: <201702021653.v12GrvPL028871@aojmv0008.oracle.com>
References: <201702021653.v12GrvPL028871@aojmv0008.oracle.com>
Message-ID: <8e7a89d7-0db0-d610-2b70-2722ec8ddec0@oracle.com>

Hi,

A direct consequence of this change is that you may have
to either blow up your ./build directory, or run
'make clean-java' after pulling this fix.

Otherwise you may see strange build failures like below:

Error occurred during initialization of VM
java.lang.RuntimeException: Package com.sun.jmx.remote.protocol.rmi in 
both module java.management.rmi and module java.management
	at 
jdk.internal.module.ModuleBootstrap.fail(java.base/ModuleBootstrap.java:699)
	at 
jdk.internal.module.ModuleBootstrap.boot(java.base/ModuleBootstrap.java:329)
	at java.lang.System.initPhase2(java.base/System.java:1928)


best regards,

-- daniel
-------------- next part --------------
An embedded message was scrubbed...
From: daniel.fuchs at oracle.com
Subject: hg: jdk9/dev/jdk: 8173607: JMX RMI connector should be in its own	module
Date: Thu, 02 Feb 2017 16:53:57 +0000
Size: 11018
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20170202/34af5447/JMXRMIconnectorshouldbeinitsownmodule.eml>

From henry.jen at oracle.com  Thu Feb  2 18:58:41 2017
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 2 Feb 2017 10:58:41 -0800
Subject: RFR: 8171522: Jar prints error message with old (non gnu-style
	options).
Message-ID: <AB16571B-573A-4FE8-A065-05FA9E43B975@oracle.com>

Hi,

Please review a trivial patch for JDK-8171522, basically we just add two missing main operations into the message. This message is appropriate for both compatible style or new gnu style.

Cheers,
Henry

diff -r 0e2935453091 src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties
--- a/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties      Wed Feb 01 11:05:33 2017 -0800
+++ b/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties      Thu Feb 02 10:48:11 2017 -0800
@@ -36,7 +36,7 @@
 error.bad.file.arg=\
      Error parsing file arguments
 error.bad.option=\
-        One of options -{ctxu} must be specified.
+        One of the option -{ctxuid} must be specified.
 error.bad.cflag=\
         'c' flag requires manifest or input files to be specified!
 error.bad.uflag=\

From henry.jen at oracle.com  Thu Feb  2 19:02:00 2017
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 2 Feb 2017 11:02:00 -0800
Subject: RFR: 8171522: Jar prints error message with old (non gnu-style
	options).
In-Reply-To: <AB16571B-573A-4FE8-A065-05FA9E43B975@oracle.com>
References: <AB16571B-573A-4FE8-A065-05FA9E43B975@oracle.com>
Message-ID: <00BFA68B-2970-4F90-B7D1-2433F45AABB6@oracle.com>

Sorry, please ignore previous email, this one is correct.

diff -r 0e2935453091 src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties
--- a/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties      Wed Feb 01 11:05:33 2017 -0800
+++ b/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties      Thu Feb 02 11:00:36 2017 -0800
@@ -36,7 +36,7 @@
 error.bad.file.arg=\
      Error parsing file arguments
 error.bad.option=\
-        One of options -{ctxu} must be specified.
+        One of options -{ctxuid} must be specified.
 error.bad.cflag=\
         'c' flag requires manifest or input files to be specified!
 error.bad.uflag=\

Cheers,
Henry


> On Feb 2, 2017, at 10:58 AM, Henry Jen <henry.jen at oracle.com> wrote:
> 
> Hi,
> 
> Please review a trivial patch for JDK-8171522, basically we just add two missing main operations into the message. This message is appropriate for both compatible style or new gnu style.
> 
> Cheers,
> Henry
> 
> diff -r 0e2935453091 src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties
> --- a/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties      Wed Feb 01 11:05:33 2017 -0800
> +++ b/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties      Thu Feb 02 10:48:11 2017 -0800
> @@ -36,7 +36,7 @@
> error.bad.file.arg=\
>      Error parsing file arguments
> error.bad.option=\
> -        One of options -{ctxu} must be specified.
> +        One of the option -{ctxuid} must be specified.
> error.bad.cflag=\
>         'c' flag requires manifest or input files to be specified!
> error.bad.uflag=\


From rob.mckenna at oracle.com  Thu Feb  2 22:14:15 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 2 Feb 2017 22:14:15 +0000
Subject: [RFR] 8160768: Add capability to custom resolve host/domain
	names within the default JDNI LDAP provider
In-Reply-To: <f6b229bf-292b-2fc1-278c-a4acaa869968@oracle.com>
References: <20170125163141.GB3628@tecra> <20170125174453.GE3628@tecra>
	<f81eb731-358e-a680-0788-05230af9ce07@oracle.com>
	<20170126040326.GA3544@vimes> <20170201200550.GH2829@vimes>
	<f6b229bf-292b-2fc1-278c-a4acaa869968@oracle.com>
Message-ID: <20170202221415.GD2648@vimes>

Thanks Daniel,

New webrev at http://cr.openjdk.java.net/~robm/8160768/webrev.04/

In addition to your comments below I've added the package access check
we discussed.

Note: when a provider returns multiple results we create an LdapCtx
based on the first of those. I think it might be useful to extend
LdapClient to accept a list of addresses which can be iterated over in the
event of a connection failure but I'll tackle that separately.

    -Rob

On 02/02/17 11:01, Daniel Fuchs wrote:
> Hi Rob,
> 
> This is not a code I know well - but here are a couple
> of comments:
> 
> LdapCtxFactory.java:
> 
> 168         NamingException ne = new NamingException();
> 232         NamingException ne = new NamingException();
> 
> Creating an exception is somewhat costly as it records the
> backtrace in the Throwable constructor. I don't know if
> it's an issue there but I thought I'd mention it. It might
> be better to create the exception only if you're actually
> going to throw it.
> 
>  186         } catch (Exception e) {
>  187             ne.setRootCause(e);
>  188         }
> 
> This will catch the NamingException thrown at line 173
> and set it at the cause of another NamingException that
> has no message. Maybe it would be better to have two
> catch clauses:
> 
>  186         } catch (NamingException e) {
>  187             throw e;
>  186         } catch (Exception e) {
>                  ... transform it to NamingException ...
> 
> In getDnsUrls:
> 
>  198         if (env.containsKey(LdapCtx.DNS_PROVIDER)
>  199                 && env.get(LdapCtx.DNS_PROVIDER) != null
>  200                 && !env.get(LdapCtx.DNS_PROVIDER).equals(""))
> 
> I'd suggest to simplify this and make a single lookup:
> 
>              String providerClass = env.get(LdapCtx.DNS_PROVIDER);
>              if (providerClass != null && !providerClass.isEmpty()) {
>                  ...
>                  Class<?> cls = Class.forName(providerClass, true, cl);
> 
> best regards,
> 
> -- daniel
> 
> 
> On 01/02/17 20:05, Rob McKenna wrote:
> >New webrev with updated test here:
> >
> >http://cr.openjdk.java.net/~robm/8160768/webrev.03/
> >
> >    -Rob
> >
> >On 26/01/17 04:03, Rob McKenna wrote:
> >>Ack, apologies, thats what I get for rushing. (which I suppose I'm doing
> >>again) That code was actually supposed to be in the getDnsUrls method.
> >>Updated in place:
> >>
> >>http://cr.openjdk.java.net/~robm/8160768/webrev.02/
> >>
> >>I'll add a couple of tests for the SecurityManager along with some input
> >>checking tests too.
> >>
> >>    -Rob
> >>
> >>On 25/01/17 05:50, Daniel Fuchs wrote:
> >>>Hi Rob,
> >>>
> >>>I believe you should move the security check to before
> >>>the class is actually loaded, before the call to
> >>> 171             List<String> urls = getDnsUrls(url, env);
> >>>
> >>>best regards,
> >>>
> >>>-- daniel
> >>>
> >>>On 25/01/17 17:44, Rob McKenna wrote:
> >>>>I neglected to include a security check so I've cribbed the one from
> >>>>OBJECT_FACTORIES (NamingManager.setObjectFactoryBuilder()) - see:
> >>>>
> >>>>http://cr.openjdk.java.net/~robm/8160768/webrev.02/
> >>>>
> >>>>Note, this wraps the SecurityException in a NamingException. Presumably
> >>>>its better to throw something than simply leave the default value in
> >>>>place, but feedback appreciated!
> >>>>
> >>>>   -Rob
> >>>>
> >>>>On 25/01/17 04:31, Rob McKenna wrote:
> >>>>>Hi folks,
> >>>>>
> >>>>>I'm looking for feedback on this suggested fix for the following bug:
> >>>>>
> >>>>>https://bugs.openjdk.java.net/browse/JDK-816076
> >>>>>http://cr.openjdk.java.net/~robm/8160768/webrev.01/
> >>>>>
> >>>>>This is something that has come up a few times. Basically in certain
> >>>>>environments (e.g. MS Active Directory) there is a dependence on
> >>>>>DNS records to provide a pointer to the actual ldap server to be used
> >>>>>for a given LdapCtx.PROVIDER_URL where the url itself simply points to the
> >>>>>domain name.
> >>>>>
> >>>>>This fix add a new Ldap context property which allows a user to specify a
> >>>>>class (implementing BiFunction) which can perform any necessary extra steps
> >>>>>to derive the ldap servers hostname/port from the PROVIDER_URL.
> >>>>>
> >>>>>   -Rob
> >>>>>
> >>>
> 

From stuart.marks at oracle.com  Thu Feb  2 22:15:38 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 2 Feb 2017 14:15:38 -0800
Subject: RFR(s): 8044626 & 8165649 RMI spec changes for modularization
In-Reply-To: <73b6e189-25a3-51a9-644d-177e0f8fd01f@oracle.com>
References: <b8f84d16-aff3-3565-618c-8af807e3b89a@oracle.com>
	<6032cf24-fddb-e9a9-45f0-83f6177be6d2@oracle.com>
	<60b7934e-b1ae-ab33-b7c1-6a168c9aab25@oracle.com>
	<73b6e189-25a3-51a9-644d-177e0f8fd01f@oracle.com>
Message-ID: <3f3b5958-07e8-1868-17eb-fd624c3edf54@oracle.com>



On 2/2/17 3:23 AM, Alan Bateman wrote:
> On 01/02/2017 20:47, Stuart Marks wrote:
>> The situation with dynamic stubs in UnicastRemoteObject is similar. The logic
>> is the same, but there can be a mixture of remote interfaces, which
>> complicates things a bit. Nonetheless I think the rewording came well.
>>
>> I've also added links per your suggestion, and fixed some typos.
>>
>> Revised diff below.
> The updated wording looks okay and for completeness then I would say "exported
> to at least java.rmi" and "open to at least java.rmi".

Sounds reasonable; I'll put in "at least" in the right places.

Thanks!

s'marks

From amy.lu at oracle.com  Fri Feb  3 04:54:07 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Fri, 3 Feb 2017 12:54:07 +0800
Subject: JDK 9 RFR of JDK-8173864: Problem list
	src/jdk/nashorn/api/tree/test/ParseAPITest.java for some platforms
Message-ID: <3e4187f1-a09d-168a-8047-be4b7ae1efdb@oracle.com>

src/jdk/nashorn/api/tree/test/ParseAPITest.java

This nashorn test keeps failing at linux-i586, windows-i586 and 
solaris-sparcv9 (JDK-8173863)

Please review this patch to put the test to problem list until issues 
addressed.

bug: https://bugs.openjdk.java.net/browse/JDK-8173864
webrev: http://cr.openjdk.java.net/~amlu/8173864/webrev.00/

Thanks,
Amy


--- old/test/ProblemList.txt	2017-02-03 12:45:00.000000000 +0800
+++ new/test/ProblemList.txt	2017-02-03 12:44:59.000000000 +0800
@@ -23,4 +23,4 @@
  #
  ###########################################################################
  
-# No nashorn tests are on the problem list.
+src/jdk/nashorn/api/tree/test/ParseAPITest.java    8173863 linux-i586,windows-i586,solaris-sparcv9


From vyom.tewari at oracle.com  Fri Feb  3 08:14:31 2017
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Fri, 3 Feb 2017 13:44:31 +0530
Subject: [RFR] 8160768: Add capability to custom resolve host/domain names
	within the default JDNI LDAP provider
In-Reply-To: <20170202221415.GD2648@vimes>
References: <20170125163141.GB3628@tecra> <20170125174453.GE3628@tecra>
	<f81eb731-358e-a680-0788-05230af9ce07@oracle.com>
	<20170126040326.GA3544@vimes> <20170201200550.GH2829@vimes>
	<f6b229bf-292b-2fc1-278c-a4acaa869968@oracle.com>
	<20170202221415.GD2648@vimes>
Message-ID: <4ed39a66-f594-d4aa-adce-56f05315d771@oracle.com>

Hi Rob,

Most of the code changes looks fine except new code will throw NPE if 
"ServiceLocator.mapDnToDomainName(ldapUrl.getDN())" is not able to map. 
you have to check for null in LdapCtxFactory.java class as follows.

if(ServiceLocator.mapDnToDomainName(ldapUrl.getDN())!=null){
                 ((LdapCtx) ctx).setDomainName(
ServiceLocator.mapDnToDomainName(ldapUrl.getDN()));
                 }


##############################

Exception in thread "main" java.lang.NullPointerException
     at java.base/java.util.Hashtable.put(Hashtable.java:474)
     at 
java.naming/com.sun.jndi.ldap.LdapCtx.setDomainName(LdapCtx.java:2346)
     at 
java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
################################

Thanks,

Vyom


On Friday 03 February 2017 03:44 AM, Rob McKenna wrote:
> Thanks Daniel,
>
> New webrev at http://cr.openjdk.java.net/~robm/8160768/webrev.04/
>
> In addition to your comments below I've added the package access check
> we discussed.
>
> Note: when a provider returns multiple results we create an LdapCtx
> based on the first of those. I think it might be useful to extend
> LdapClient to accept a list of addresses which can be iterated over in the
> event of a connection failure but I'll tackle that separately.
>
>      -Rob
>
> On 02/02/17 11:01, Daniel Fuchs wrote:
>> Hi Rob,
>>
>> This is not a code I know well - but here are a couple
>> of comments:
>>
>> LdapCtxFactory.java:
>>
>> 168         NamingException ne = new NamingException();
>> 232         NamingException ne = new NamingException();
>>
>> Creating an exception is somewhat costly as it records the
>> backtrace in the Throwable constructor. I don't know if
>> it's an issue there but I thought I'd mention it. It might
>> be better to create the exception only if you're actually
>> going to throw it.
>>
>>   186         } catch (Exception e) {
>>   187             ne.setRootCause(e);
>>   188         }
>>
>> This will catch the NamingException thrown at line 173
>> and set it at the cause of another NamingException that
>> has no message. Maybe it would be better to have two
>> catch clauses:
>>
>>   186         } catch (NamingException e) {
>>   187             throw e;
>>   186         } catch (Exception e) {
>>                   ... transform it to NamingException ...
>>
>> In getDnsUrls:
>>
>>   198         if (env.containsKey(LdapCtx.DNS_PROVIDER)
>>   199                 && env.get(LdapCtx.DNS_PROVIDER) != null
>>   200                 && !env.get(LdapCtx.DNS_PROVIDER).equals(""))
>>
>> I'd suggest to simplify this and make a single lookup:
>>
>>               String providerClass = env.get(LdapCtx.DNS_PROVIDER);
>>               if (providerClass != null && !providerClass.isEmpty()) {
>>                   ...
>>                   Class<?> cls = Class.forName(providerClass, true, cl);
>>
>> best regards,
>>
>> -- daniel
>>
>>
>> On 01/02/17 20:05, Rob McKenna wrote:
>>> New webrev with updated test here:
>>>
>>> http://cr.openjdk.java.net/~robm/8160768/webrev.03/
>>>
>>>     -Rob
>>>
>>> On 26/01/17 04:03, Rob McKenna wrote:
>>>> Ack, apologies, thats what I get for rushing. (which I suppose I'm doing
>>>> again) That code was actually supposed to be in the getDnsUrls method.
>>>> Updated in place:
>>>>
>>>> http://cr.openjdk.java.net/~robm/8160768/webrev.02/
>>>>
>>>> I'll add a couple of tests for the SecurityManager along with some input
>>>> checking tests too.
>>>>
>>>>     -Rob
>>>>
>>>> On 25/01/17 05:50, Daniel Fuchs wrote:
>>>>> Hi Rob,
>>>>>
>>>>> I believe you should move the security check to before
>>>>> the class is actually loaded, before the call to
>>>>> 171             List<String> urls = getDnsUrls(url, env);
>>>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>>>
>>>>> On 25/01/17 17:44, Rob McKenna wrote:
>>>>>> I neglected to include a security check so I've cribbed the one from
>>>>>> OBJECT_FACTORIES (NamingManager.setObjectFactoryBuilder()) - see:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~robm/8160768/webrev.02/
>>>>>>
>>>>>> Note, this wraps the SecurityException in a NamingException. Presumably
>>>>>> its better to throw something than simply leave the default value in
>>>>>> place, but feedback appreciated!
>>>>>>
>>>>>>    -Rob
>>>>>>
>>>>>> On 25/01/17 04:31, Rob McKenna wrote:
>>>>>>> Hi folks,
>>>>>>>
>>>>>>> I'm looking for feedback on this suggested fix for the following bug:
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-816076
>>>>>>> http://cr.openjdk.java.net/~robm/8160768/webrev.01/
>>>>>>>
>>>>>>> This is something that has come up a few times. Basically in certain
>>>>>>> environments (e.g. MS Active Directory) there is a dependence on
>>>>>>> DNS records to provide a pointer to the actual ldap server to be used
>>>>>>> for a given LdapCtx.PROVIDER_URL where the url itself simply points to the
>>>>>>> domain name.
>>>>>>>
>>>>>>> This fix add a new Ldap context property which allows a user to specify a
>>>>>>> class (implementing BiFunction) which can perform any necessary extra steps
>>>>>>> to derive the ldap servers hostname/port from the PROVIDER_URL.
>>>>>>>
>>>>>>>    -Rob
>>>>>>>


From sundararajan.athijegannathan at oracle.com  Fri Feb  3 08:57:47 2017
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 03 Feb 2017 14:27:47 +0530
Subject: JDK 9 RFR of JDK-8173864: Problem list
	src/jdk/nashorn/api/tree/test/ParseAPITest.java for some platforms
In-Reply-To: <3e4187f1-a09d-168a-8047-be4b7ae1efdb@oracle.com>
References: <3e4187f1-a09d-168a-8047-be4b7ae1efdb@oracle.com>
Message-ID: <5894460B.40802@oracle.com>

+1

-Sundar

On 03/02/17, 10:24 AM, Amy Lu wrote:
> src/jdk/nashorn/api/tree/test/ParseAPITest.java
>
> This nashorn test keeps failing at linux-i586, windows-i586 and 
> solaris-sparcv9 (JDK-8173863)
>
> Please review this patch to put the test to problem list until issues 
> addressed.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8173864
> webrev: http://cr.openjdk.java.net/~amlu/8173864/webrev.00/
>
> Thanks,
> Amy
>
>
> --- old/test/ProblemList.txt    2017-02-03 12:45:00.000000000 +0800
> +++ new/test/ProblemList.txt    2017-02-03 12:44:59.000000000 +0800
> @@ -23,4 +23,4 @@
>  #
>  ########################################################################### 
>
>
> -# No nashorn tests are on the problem list.
> +src/jdk/nashorn/api/tree/test/ParseAPITest.java    8173863 
> linux-i586,windows-i586,solaris-sparcv9
>

From hannes.wallnoefer at oracle.com  Fri Feb  3 08:58:36 2017
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Fri, 3 Feb 2017 09:58:36 +0100
Subject: JDK 9 RFR of JDK-8173864: Problem list
	src/jdk/nashorn/api/tree/test/ParseAPITest.java for some platforms
In-Reply-To: <5894460B.40802@oracle.com>
References: <3e4187f1-a09d-168a-8047-be4b7ae1efdb@oracle.com>
	<5894460B.40802@oracle.com>
Message-ID: <7E1341AA-616C-450D-8475-D3D6C85BDBFD@oracle.com>

+1

Hannes

> Am 03.02.2017 um 09:57 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
> 
> +1
> 
> -Sundar
> 
> On 03/02/17, 10:24 AM, Amy Lu wrote:
>> src/jdk/nashorn/api/tree/test/ParseAPITest.java
>> 
>> This nashorn test keeps failing at linux-i586, windows-i586 and solaris-sparcv9 (JDK-8173863)
>> 
>> Please review this patch to put the test to problem list until issues addressed.
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8173864
>> webrev: http://cr.openjdk.java.net/~amlu/8173864/webrev.00/
>> 
>> Thanks,
>> Amy
>> 
>> 
>> --- old/test/ProblemList.txt    2017-02-03 12:45:00.000000000 +0800
>> +++ new/test/ProblemList.txt    2017-02-03 12:44:59.000000000 +0800
>> @@ -23,4 +23,4 @@
>> #
>> ########################################################################### 
>> 
>> -# No nashorn tests are on the problem list.
>> +src/jdk/nashorn/api/tree/test/ParseAPITest.java    8173863 linux-i586,windows-i586,solaris-sparcv9
>> 


From christoph.langer at sap.com  Fri Feb  3 10:11:34 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 3 Feb 2017 10:11:34 +0000
Subject: Ping: [JAXP] RFR: 8173602: TESTBUG:
	javax/xml/jaxp/unittest/transform/TransformerTest.java needs
	refactoring
Message-ID: <4e2bf25b589146e086fb9f306156b861@derote13de46.global.corp.sap>

Hi,

Ping - anyone out there who could have a look at my JAXP test update?

Thanks
Christoph

From: Langer, Christoph
Sent: Montag, 30. Januar 2017 15:28
To: core-libs-dev at openjdk.java.net
Subject: [JAXP] RFR: 8173602: TESTBUG: javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring

Hi,

please review a test fix for javax/xml/jaxp/unittest/transform/TransformerTest.java:
Bug: https://bugs.openjdk.java.net/browse/JDK-8173602
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8173602.0/

The main motivation for this refactoring is to remove the dependency to the JDK internal classes com.sun.org.apache.xml.internal.serialize.OutputFormat and com.sun.org.apache.xml.internal.serialize.XMLSerializer.

Generally, TransformerTest.java contains several subtests which do similar things (test XALAN transformations) but the implementations differ. I created a common template with helper methods which all tests take advantage of now. I also introduced data sources to some tests to make them more readable and adaptable.

Thanks
Christoph


From daniel.fuchs at oracle.com  Fri Feb  3 11:40:07 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 3 Feb 2017 11:40:07 +0000
Subject: [RFR] 8160768: Add capability to custom resolve host/domain names
	within the default JDNI LDAP provider
In-Reply-To: <20170202221415.GD2648@vimes>
References: <20170125163141.GB3628@tecra> <20170125174453.GE3628@tecra>
	<f81eb731-358e-a680-0788-05230af9ce07@oracle.com>
	<20170126040326.GA3544@vimes> <20170201200550.GH2829@vimes>
	<f6b229bf-292b-2fc1-278c-a4acaa869968@oracle.com>
	<20170202221415.GD2648@vimes>
Message-ID: <86247402-9b49-f89a-ffbc-bf490937f5be@oracle.com>

Hi Rob,

On 02/02/17 22:14, Rob McKenna wrote:
> Thanks Daniel,
>
> New webrev at http://cr.openjdk.java.net/~robm/8160768/webrev.04/
>
> In addition to your comments below I've added the package access check
> we discussed.
>
> Note: when a provider returns multiple results we create an LdapCtx
> based on the first of those. I think it might be useful to extend
> LdapClient to accept a list of addresses which can be iterated over in the
> event of a connection failure but I'll tackle that separately.

AFAICS the new webrev looks good to me.
I'm not too aware of the specifics of the JNDI LDAP bridge
though. I see that Vyom has taken a look at your patch and
suggested a change too and that is good :-)

best regards,

-- daniel

>
>     -Rob
>
> On 02/02/17 11:01, Daniel Fuchs wrote:
>> Hi Rob,
>>
>> This is not a code I know well - but here are a couple
>> of comments:
>>
>> LdapCtxFactory.java:
>>
>> 168         NamingException ne = new NamingException();
>> 232         NamingException ne = new NamingException();
>>
>> Creating an exception is somewhat costly as it records the
>> backtrace in the Throwable constructor. I don't know if
>> it's an issue there but I thought I'd mention it. It might
>> be better to create the exception only if you're actually
>> going to throw it.
>>
>>  186         } catch (Exception e) {
>>  187             ne.setRootCause(e);
>>  188         }
>>
>> This will catch the NamingException thrown at line 173
>> and set it at the cause of another NamingException that
>> has no message. Maybe it would be better to have two
>> catch clauses:
>>
>>  186         } catch (NamingException e) {
>>  187             throw e;
>>  186         } catch (Exception e) {
>>                  ... transform it to NamingException ...
>>
>> In getDnsUrls:
>>
>>  198         if (env.containsKey(LdapCtx.DNS_PROVIDER)
>>  199                 && env.get(LdapCtx.DNS_PROVIDER) != null
>>  200                 && !env.get(LdapCtx.DNS_PROVIDER).equals(""))
>>
>> I'd suggest to simplify this and make a single lookup:
>>
>>              String providerClass = env.get(LdapCtx.DNS_PROVIDER);
>>              if (providerClass != null && !providerClass.isEmpty()) {
>>                  ...
>>                  Class<?> cls = Class.forName(providerClass, true, cl);
>>
>> best regards,
>>
>> -- daniel
>>
>>
>> On 01/02/17 20:05, Rob McKenna wrote:
>>> New webrev with updated test here:
>>>
>>> http://cr.openjdk.java.net/~robm/8160768/webrev.03/
>>>
>>>    -Rob
>>>
>>> On 26/01/17 04:03, Rob McKenna wrote:
>>>> Ack, apologies, thats what I get for rushing. (which I suppose I'm doing
>>>> again) That code was actually supposed to be in the getDnsUrls method.
>>>> Updated in place:
>>>>
>>>> http://cr.openjdk.java.net/~robm/8160768/webrev.02/
>>>>
>>>> I'll add a couple of tests for the SecurityManager along with some input
>>>> checking tests too.
>>>>
>>>>    -Rob
>>>>
>>>> On 25/01/17 05:50, Daniel Fuchs wrote:
>>>>> Hi Rob,
>>>>>
>>>>> I believe you should move the security check to before
>>>>> the class is actually loaded, before the call to
>>>>> 171             List<String> urls = getDnsUrls(url, env);
>>>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>>>
>>>>> On 25/01/17 17:44, Rob McKenna wrote:
>>>>>> I neglected to include a security check so I've cribbed the one from
>>>>>> OBJECT_FACTORIES (NamingManager.setObjectFactoryBuilder()) - see:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~robm/8160768/webrev.02/
>>>>>>
>>>>>> Note, this wraps the SecurityException in a NamingException. Presumably
>>>>>> its better to throw something than simply leave the default value in
>>>>>> place, but feedback appreciated!
>>>>>>
>>>>>>   -Rob
>>>>>>
>>>>>> On 25/01/17 04:31, Rob McKenna wrote:
>>>>>>> Hi folks,
>>>>>>>
>>>>>>> I'm looking for feedback on this suggested fix for the following bug:
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-816076
>>>>>>> http://cr.openjdk.java.net/~robm/8160768/webrev.01/
>>>>>>>
>>>>>>> This is something that has come up a few times. Basically in certain
>>>>>>> environments (e.g. MS Active Directory) there is a dependence on
>>>>>>> DNS records to provide a pointer to the actual ldap server to be used
>>>>>>> for a given LdapCtx.PROVIDER_URL where the url itself simply points to the
>>>>>>> domain name.
>>>>>>>
>>>>>>> This fix add a new Ldap context property which allows a user to specify a
>>>>>>> class (implementing BiFunction) which can perform any necessary extra steps
>>>>>>> to derive the ldap servers hostname/port from the PROVIDER_URL.
>>>>>>>
>>>>>>>   -Rob
>>>>>>>
>>>>>
>>


From daniel.fuchs at oracle.com  Fri Feb  3 12:54:22 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 3 Feb 2017 12:54:22 +0000
Subject: Ping: [JAXP] RFR: 8173602: TESTBUG:
	javax/xml/jaxp/unittest/transform/TransformerTest.java needs
	refactoring
In-Reply-To: <4e2bf25b589146e086fb9f306156b861@derote13de46.global.corp.sap>
References: <4e2bf25b589146e086fb9f306156b861@derote13de46.global.corp.sap>
Message-ID: <0f29cf4c-43ec-04f9-ec2f-4d16b7f4c5c7@oracle.com>

Hi Christoph,

I had a look at your patch, it seems OK.
I didn't know that testng supported @Test
annotations on methods of inner classes, but
that looks useful.

The patch is a bit difficult to review because the diff
seems a bit lost sometime - but as far as I could see
what was there before seems to be there after too :-)

I noticed you changed the calls for pretty-printing
the results - using public APIs now. Hopefully that
doesn't matter to test (I mean that's hopefully not
what the test was testing).

I ran your new test locally on my machine, and sent it
through our test system as well, and everything passed,
so I guess that's a +1 for me.

Will you push that to the new 10 forest or did you
plan to push it in 9?

best regards,

-- daniel

On 03/02/17 10:11, Langer, Christoph wrote:
> Hi,
>
> Ping - anyone out there who could have a look at my JAXP test update?
>
> Thanks
> Christoph
>
> From: Langer, Christoph
> Sent: Montag, 30. Januar 2017 15:28
> To: core-libs-dev at openjdk.java.net
> Subject: [JAXP] RFR: 8173602: TESTBUG: javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring
>
> Hi,
>
> please review a test fix for javax/xml/jaxp/unittest/transform/TransformerTest.java:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8173602
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8173602.0/
>
> The main motivation for this refactoring is to remove the dependency to the JDK internal classes com.sun.org.apache.xml.internal.serialize.OutputFormat and com.sun.org.apache.xml.internal.serialize.XMLSerializer.
>
> Generally, TransformerTest.java contains several subtests which do similar things (test XALAN transformations) but the implementations differ. I created a common template with helper methods which all tests take advantage of now. I also introduced data sources to some tests to make them more readable and adaptable.
>
> Thanks
> Christoph
>


From christoph.langer at sap.com  Fri Feb  3 13:01:47 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 3 Feb 2017 13:01:47 +0000
Subject: Ping: [JAXP] RFR: 8173602: TESTBUG:
	javax/xml/jaxp/unittest/transform/TransformerTest.java needs
	refactoring
In-Reply-To: <0f29cf4c-43ec-04f9-ec2f-4d16b7f4c5c7@oracle.com>
References: <4e2bf25b589146e086fb9f306156b861@derote13de46.global.corp.sap>
	<0f29cf4c-43ec-04f9-ec2f-4d16b7f4c5c7@oracle.com>
Message-ID: <6a7c7ee4ede342f58b0841f18d6c60f5@derote13de46.global.corp.sap>

Hi Daniel,

thanks for taking care of this.

As for the pretty printing: That's not something which is explicitly tested here. I think it was me who introduced this for new tests I had added. I found it quite useful when analyzing test results. So now with the public APIs I guess this code is more independent and portable to other Java versions.

I was only looking at JDK9 with that so far. My understanding was that pushing test fixes is still ok. Let me know if you have objections.

Best regards
Christoph

> -----Original Message-----
> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> Sent: Freitag, 3. Februar 2017 13:54
> To: Langer, Christoph <christoph.langer at sap.com>; core-libs-
> dev at openjdk.java.net
> Subject: Re: Ping: [JAXP] RFR: 8173602: TESTBUG:
> javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring
> 
> Hi Christoph,
> 
> I had a look at your patch, it seems OK.
> I didn't know that testng supported @Test
> annotations on methods of inner classes, but
> that looks useful.
> 
> The patch is a bit difficult to review because the diff
> seems a bit lost sometime - but as far as I could see
> what was there before seems to be there after too :-)
> 
> I noticed you changed the calls for pretty-printing
> the results - using public APIs now. Hopefully that
> doesn't matter to test (I mean that's hopefully not
> what the test was testing).
> 
> I ran your new test locally on my machine, and sent it
> through our test system as well, and everything passed,
> so I guess that's a +1 for me.
> 
> Will you push that to the new 10 forest or did you
> plan to push it in 9?
> 
> best regards,
> 
> -- daniel
> 
> On 03/02/17 10:11, Langer, Christoph wrote:
> > Hi,
> >
> > Ping - anyone out there who could have a look at my JAXP test update?
> >
> > Thanks
> > Christoph
> >
> > From: Langer, Christoph
> > Sent: Montag, 30. Januar 2017 15:28
> > To: core-libs-dev at openjdk.java.net
> > Subject: [JAXP] RFR: 8173602: TESTBUG:
> javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring
> >
> > Hi,
> >
> > please review a test fix for
> javax/xml/jaxp/unittest/transform/TransformerTest.java:
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8173602
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8173602.0/
> >
> > The main motivation for this refactoring is to remove the dependency to the
> JDK internal classes com.sun.org.apache.xml.internal.serialize.OutputFormat
> and com.sun.org.apache.xml.internal.serialize.XMLSerializer.
> >
> > Generally, TransformerTest.java contains several subtests which do similar
> things (test XALAN transformations) but the implementations differ. I created a
> common template with helper methods which all tests take advantage of now. I
> also introduced data sources to some tests to make them more readable and
> adaptable.
> >
> > Thanks
> > Christoph
> >


From daniel.fuchs at oracle.com  Fri Feb  3 13:55:44 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 3 Feb 2017 13:55:44 +0000
Subject: Ping: [JAXP] RFR: 8173602: TESTBUG:
	javax/xml/jaxp/unittest/transform/TransformerTest.java needs
	refactoring
In-Reply-To: <6a7c7ee4ede342f58b0841f18d6c60f5@derote13de46.global.corp.sap>
References: <4e2bf25b589146e086fb9f306156b861@derote13de46.global.corp.sap>
	<0f29cf4c-43ec-04f9-ec2f-4d16b7f4c5c7@oracle.com>
	<6a7c7ee4ede342f58b0841f18d6c60f5@derote13de46.global.corp.sap>
Message-ID: <67619df3-d9b0-c303-544a-0fa52d20fdde@oracle.com>

Hi Christoph,

No objections.

best regards,

-- daniel

On 03/02/17 13:01, Langer, Christoph wrote:
> Hi Daniel,
>
> thanks for taking care of this.
>
> As for the pretty printing: That's not something which is explicitly tested here. I think it was me who introduced this for new tests I had added. I found it quite useful when analyzing test results. So now with the public APIs I guess this code is more independent and portable to other Java versions.
>
> I was only looking at JDK9 with that so far. My understanding was that pushing test fixes is still ok. Let me know if you have objections.
>
> Best regards
> Christoph
>
>> -----Original Message-----
>> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
>> Sent: Freitag, 3. Februar 2017 13:54
>> To: Langer, Christoph <christoph.langer at sap.com>; core-libs-
>> dev at openjdk.java.net
>> Subject: Re: Ping: [JAXP] RFR: 8173602: TESTBUG:
>> javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring
>>
>> Hi Christoph,
>>
>> I had a look at your patch, it seems OK.
>> I didn't know that testng supported @Test
>> annotations on methods of inner classes, but
>> that looks useful.
>>
>> The patch is a bit difficult to review because the diff
>> seems a bit lost sometime - but as far as I could see
>> what was there before seems to be there after too :-)
>>
>> I noticed you changed the calls for pretty-printing
>> the results - using public APIs now. Hopefully that
>> doesn't matter to test (I mean that's hopefully not
>> what the test was testing).
>>
>> I ran your new test locally on my machine, and sent it
>> through our test system as well, and everything passed,
>> so I guess that's a +1 for me.
>>
>> Will you push that to the new 10 forest or did you
>> plan to push it in 9?
>>
>> best regards,
>>
>> -- daniel
>>
>> On 03/02/17 10:11, Langer, Christoph wrote:
>>> Hi,
>>>
>>> Ping - anyone out there who could have a look at my JAXP test update?
>>>
>>> Thanks
>>> Christoph
>>>
>>> From: Langer, Christoph
>>> Sent: Montag, 30. Januar 2017 15:28
>>> To: core-libs-dev at openjdk.java.net
>>> Subject: [JAXP] RFR: 8173602: TESTBUG:
>> javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring
>>>
>>> Hi,
>>>
>>> please review a test fix for
>> javax/xml/jaxp/unittest/transform/TransformerTest.java:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173602
>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8173602.0/
>>>
>>> The main motivation for this refactoring is to remove the dependency to the
>> JDK internal classes com.sun.org.apache.xml.internal.serialize.OutputFormat
>> and com.sun.org.apache.xml.internal.serialize.XMLSerializer.
>>>
>>> Generally, TransformerTest.java contains several subtests which do similar
>> things (test XALAN transformations) but the implementations differ. I created a
>> common template with helper methods which all tests take advantage of now. I
>> also introduced data sources to some tests to make them more readable and
>> adaptable.
>>>
>>> Thanks
>>> Christoph
>>>
>


From xueming.shen at oracle.com  Fri Feb  3 17:22:32 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 03 Feb 2017 09:22:32 -0800
Subject: RFR: 8171522: Jar prints error message with old (non gnu-style
	options).
In-Reply-To: <00BFA68B-2970-4F90-B7D1-2433F45AABB6@oracle.com>
References: <AB16571B-573A-4FE8-A065-05FA9E43B975@oracle.com>
	<00BFA68B-2970-4F90-B7D1-2433F45AABB6@oracle.com>
Message-ID: <5894BC58.3010501@oracle.com>

+1

On 02/02/2017 11:02 AM, Henry Jen wrote:
> Sorry, please ignore previous email, this one is correct.
>
> diff -r 0e2935453091 src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties
> --- a/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties      Wed Feb 01 11:05:33 2017 -0800
> +++ b/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties      Thu Feb 02 11:00:36 2017 -0800
> @@ -36,7 +36,7 @@
>   error.bad.file.arg=\
>        Error parsing file arguments
>   error.bad.option=\
> -        One of options -{ctxu} must be specified.
> +        One of options -{ctxuid} must be specified.
>   error.bad.cflag=\
>           'c' flag requires manifest or input files to be specified!
>   error.bad.uflag=\
>
> Cheers,
> Henry
>
>
>> On Feb 2, 2017, at 10:58 AM, Henry Jen<henry.jen at oracle.com>  wrote:
>>
>> Hi,
>>
>> Please review a trivial patch for JDK-8171522, basically we just add two missing main operations into the message. This message is appropriate for both compatible style or new gnu style.
>>
>> Cheers,
>> Henry
>>
>> diff -r 0e2935453091 src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties
>> --- a/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties      Wed Feb 01 11:05:33 2017 -0800
>> +++ b/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties      Thu Feb 02 10:48:11 2017 -0800
>> @@ -36,7 +36,7 @@
>> error.bad.file.arg=\
>>       Error parsing file arguments
>> error.bad.option=\
>> -        One of options -{ctxu} must be specified.
>> +        One of the option -{ctxuid} must be specified.
>> error.bad.cflag=\
>>          'c' flag requires manifest or input files to be specified!
>> error.bad.uflag=\


From gunnar at hibernate.org  Fri Feb  3 17:56:57 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 3 Feb 2017 18:56:57 +0100
Subject: Guaranteed order of annotations?
In-Reply-To: <49ec5a37-11e5-0c9c-d17b-9784a34ae0b3@oracle.com>
References: <CADGJaX8xu+6XbjxU8G7no31KA17WW9P6hjgh-vvC0Ezg7qgTMg@mail.gmail.com>
	<ABC6F6B1F6CA734A9B233369A3750F1531093392@MBX021-W3-CA-4.exch021.domain.local>
	<CADGJaX8HfFX7Q2YK-_tpcf6xdMTzrrasAtVbBgGSss8e_uWz3A@mail.gmail.com>
	<587ECF2C.6000505@oracle.com>
	<CADGJaX9-_KTwNcVYnp7dGN0fbj09FeBLCV3AZWn4jeXZBFA56A@mail.gmail.com>
	<49ec5a37-11e5-0c9c-d17b-9784a34ae0b3@oracle.com>
Message-ID: <CADGJaX8P4FAWFacYo1Modzx_R3qyXHnHEQ2KVb0C2vc12pZ1YA@mail.gmail.com>

Hi Joe,

Thanks for your confirmation. Bean Validation may benefit from it, but
I understand that just a single request hardly justifies the change.

--Gunnar




2017-01-23 23:05 GMT+01:00 joe darcy <joe.darcy at oracle.com>:
> Hi Gunnar,
>
> Annotations went into the platform way back in Java SE 5.0, with a GA during
> 2004. When working on repeating annotations, I was surprised to find there
> weren't stronger ordering guarantees for annotations from core reflection.
> However, requests to tighten this aspect of the platform haven't come up
> very often in the interim and I don't like it is likely to happen at this
> point.
>
> HTH,
>
> -Joe
>
>
>
> On 1/17/2017 11:26 PM, Gunnar Morling wrote:
>>
>> Joseph, all,
>>
>> Thanks for the clarification.
>>
>> Are there chances to establish such guaranteed ordering in a future
>> Java version? As pointed out, it'd be very helpful to Bean Validation
>> and I reckon other cases, too.
>>
>> Thanks,
>>
>> --Gunnar
>>
>>
>>
>> 2017-01-18 3:13 GMT+01:00 Joseph D. Darcy <joe.darcy at oracle.com>:
>>>
>>> Hello,
>>>
>>> Following up on Joel's message, IIRC this ordering issue did come up
>>> during
>>> the design and testing of repeating annotations.
>>>
>>> As noted previously in the thread, while the ordering of the annotations
>>> in
>>> a container annotation is guaranteed, there is *not* a general ordering
>>> constraint on the annotations returned by the methods of the
>>> AnnotatedElement interface.
>>>
>>> HTH,
>>>
>>> -Joe
>>>
>>>
>>> On 1/13/2017 1:16 PM, Gunnar Morling wrote:
>>>>
>>>> Hi Yuri,
>>>>
>>>> Thanks for the pointer.
>>>>
>>>> But do you see any clear description of an order mandated for
>>>> getDeclaredAnnotations()? The only references to an order I can find
>>>> there are for repeatable annotations (where source code order is
>>>> maintained when retrieving them via the container annotation type).
>>>> But I cannot find any guaranteed order when obtaining all declared
>>>> annotations from an element.
>>>>
>>>> The reason why I'm asking is Bean Validation, where we've seen
>>>> requests of people that wish to validate the constraints of an element
>>>> in a fixed order, aborting after the first failed constraint:
>>>>
>>>>       @NotNull
>>>>       @Email
>>>>       String email;
>>>>
>>>> Here one may want to first validate @NotNull and don't proceed with
>>>> validating @Email if the field is null.
>>>>
>>>> Relying on source order would be a very natural way to express the
>>>> order of constraints. Without a guaranteed ordering of annotations
>>>> we'd have to add some other means of ordering, e.g. an attribute with
>>>> the index (@NotNull(order=0) @Email(order=1)) which is more verbose of
>>>> course.
>>>>
>>>> --Gunnar
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2017-01-13 21:15 GMT+01:00 Yuri Gaevsky <ygaevsky at azulsystems.com>:
>>>>>
>>>>> Hi Gunnar,
>>>>>
>>>>> Please take a look at JDK-8010679 'Clarify "present" and annotation
>>>>> ordering in Core Reflection for Annotations' [*].
>>>>>
>>>>> Best regards,
>>>>> -Yuri
>>>>>
>>>>> [*] https://bugs.openjdk.java.net/browse/JDK-8010679
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
>>>>> Behalf Of Gunnar Morling
>>>>> Sent: Friday, January 13, 2017 08:14 PM
>>>>> To: core-libs-dev at openjdk.java.net
>>>>> Subject: Guaranteed order of annotations?
>>>>>
>>>>> Hi,
>>>>>
>>>>> Is there any order guaranteed in which an element's annotations are
>>>>> returned by AnnotatedElement#getDeclaredAnnotations()? Specifically,
>>>>> is this the order in which the annotations are given in the source
>>>>> code?
>>>>>
>>>>> Section 9.7.5. of the JLS ("Multiple Annotations of the Same Type")
>>>>> makes a statement of the source order being considered by the array of
>>>>> the implicit container annotation created for a repeatable annotation
>>>>> ("[...] all the base annotations in the left-to-right order in which
>>>>> they appeared in the context").
>>>>>
>>>>> But I couldn't find any authoritative description on the ordering
>>>>> behaviour of getDeclaredAnnotations(). Should we assume that we cannot
>>>>> rely on the order in the source?
>>>>>
>>>>> Thanks for any pointers,
>>>>>
>>>>> --Gunnar
>>>
>>>
>

From joe.darcy at oracle.com  Fri Feb  3 19:21:16 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 3 Feb 2017 11:21:16 -0800
Subject: JDK 10 RFR of JDK-8173903: Update various tests to pass under JDK 10
Message-ID: <b372228d-f4a4-2a03-7554-c8cc6ca72781@oracle.com>

Hello,

After the version update to "10" in JDK 10 ( JDK-8029942 ), various 
libraries tests failed including:

     java/lang/module/MultiReleaseJarTest.java
     java/security/Provider/ProviderVersionCheck.java
sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java

These tests need to be updated for the new JDK. When it is clear how to 
do so, I've updated the tests in a way so that they don't need to be 
updated again for JDK 11.

Webrev:

     http://cr.openjdk.java.net/~darcy/8173903.0/

and patch below. I'll update the other copyrights before pushing.

Thanks,

-Joe


diff -r 72f33dbfcf3b test/java/lang/module/MultiReleaseJarTest.java
--- a/test/java/lang/module/MultiReleaseJarTest.java    Tue Jan 31 
19:26:10 2017 -0500
+++ b/test/java/lang/module/MultiReleaseJarTest.java    Fri Feb 03 
11:18:23 2017 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2016, 2017, 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
@@ -65,7 +65,7 @@

      private static final String MODULE_INFO = "module-info.class";

-    private static final int RELEASE = Runtime.version().major();
+    private static final String RELEASE = "" + Runtime.version().major();

      // are multi-release JARs enabled?
      private static final boolean MULTI_RELEASE;
@@ -88,8 +88,8 @@
                  .moduleInfo("module-info.class", descriptor)
                  .resource("p/Main.class")
                  .resource("p/Helper.class")
-                .resource("META-INF/versions/9/p/Helper.class")
- .resource("META-INF/versions/9/p/internal/Helper9.class")
+                .resource("META-INF/versions/" + RELEASE + 
"/p/Helper.class")
+                .resource("META-INF/versions/" + RELEASE + 
"/p/internal/HelperNew.class")
                  .build();

          // find the module
@@ -131,9 +131,9 @@
                  .moduleInfo(MODULE_INFO, descriptor1)
                  .resource("p/Main.class")
                  .resource("p/Helper.class")
-                .moduleInfo("META-INF/versions/9/" + MODULE_INFO, 
descriptor2)
-                .resource("META-INF/versions/9/p/Helper.class")
- .resource("META-INF/versions/9/p/internal/Helper9.class")
+                .moduleInfo("META-INF/versions/" + RELEASE + "/" + 
MODULE_INFO, descriptor2)
+                .resource("META-INF/versions/" + RELEASE + 
"/p/Helper.class")
+                .resource("META-INF/versions/" + RELEASE + 
"/p/internal/HelperNew.class")
                  .build();

          // find the module
@@ -161,8 +161,8 @@
          Path jar = new JarBuilder(name)
                  .resource("p/Main.class")
                  .resource("p/Helper.class")
-                .resource("META-INF/versions/9/p/Helper.class")
- .resource("META-INF/versions/9/p/internal/Helper9.class")
+                .resource("META-INF/versions/" + RELEASE + 
"/p/Helper.class")
+                .resource("META-INF/versions/" + RELEASE + 
"/p/internal/HelperNew.class")
                  .build();

          // find the module
@@ -200,7 +200,7 @@

          Path jar = new JarBuilder(name)
                  .moduleInfo(MODULE_INFO, descriptor1)
-                .moduleInfo("META-INF/versions/9/" + MODULE_INFO, 
descriptor2)
+                .moduleInfo("META-INF/versions/" + RELEASE + "/" + 
MODULE_INFO, descriptor2)
                  .build();

          // find the module
diff -r 72f33dbfcf3b test/java/security/Provider/ProviderVersionCheck.java
--- a/test/java/security/Provider/ProviderVersionCheck.java    Tue Jan 
31 19:26:10 2017 -0500
+++ b/test/java/security/Provider/ProviderVersionCheck.java    Fri Feb 
03 11:18:23 2017 -0800
@@ -42,7 +42,7 @@

          for (Provider p: Security.getProviders()) {
              System.out.print(p.getName() + " ");
-            if (p.getVersion() != 9.0d) {
+            if (p.getVersion() != 10.0d) {
                  System.out.println("failed. " + "Version received was " +
                          p.getVersion());
                  failure = true;
diff -r 72f33dbfcf3b 
test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java
--- 
a/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java 
Tue Jan 31 19:26:10 2017 -0500
+++ 
b/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java 
Fri Feb 03 11:18:23 2017 -0800
@@ -74,7 +74,8 @@
      private static final String KEYPASS = "changeit";
      private static final String SIGNED_JAR = "Signed.jar";
      private static final String POLICY_FILE = "SignedJar.policy";
-    private static final String VERSION_MESSAGE = "I am running on 
version 9";
+    private static final String VERSION = "" + Runtime.version().major();
+    private static final String VERSION_MESSAGE = "I am running on 
version " + VERSION;

      public static void main(String[] args) throws Throwable {
          // compile java files in jarContent directory


From lance.andersen at oracle.com  Fri Feb  3 19:23:54 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 3 Feb 2017 14:23:54 -0500
Subject: JDK 10 RFR of JDK-8173903: Update various tests to pass under JDK
	10
In-Reply-To: <b372228d-f4a4-2a03-7554-c8cc6ca72781@oracle.com>
References: <b372228d-f4a4-2a03-7554-c8cc6ca72781@oracle.com>
Message-ID: <AA86B247-B404-41F5-A75D-093F1E6FB3E2@oracle.com>

Look good Joe
> On Feb 3, 2017, at 2:21 PM, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> After the version update to "10" in JDK 10 ( JDK-8029942 ), various libraries tests failed including:
> 
>    java/lang/module/MultiReleaseJarTest.java
>    java/security/Provider/ProviderVersionCheck.java
> sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java
> 
> These tests need to be updated for the new JDK. When it is clear how to do so, I've updated the tests in a way so that they don't need to be updated again for JDK 11.
> 
> Webrev:
> 
>    http://cr.openjdk.java.net/~darcy/8173903.0/
> 
> and patch below. I'll update the other copyrights before pushing.
> 
> Thanks,
> 
> -Joe
> 
> 
> diff -r 72f33dbfcf3b test/java/lang/module/MultiReleaseJarTest.java
> --- a/test/java/lang/module/MultiReleaseJarTest.java    Tue Jan 31 19:26:10 2017 -0500
> +++ b/test/java/lang/module/MultiReleaseJarTest.java    Fri Feb 03 11:18:23 2017 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2016, 2017, 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
> @@ -65,7 +65,7 @@
> 
>     private static final String MODULE_INFO = "module-info.class";
> 
> -    private static final int RELEASE = Runtime.version().major();
> +    private static final String RELEASE = "" + Runtime.version().major();
> 
>     // are multi-release JARs enabled?
>     private static final boolean MULTI_RELEASE;
> @@ -88,8 +88,8 @@
>                 .moduleInfo("module-info.class", descriptor)
>                 .resource("p/Main.class")
>                 .resource("p/Helper.class")
> -                .resource("META-INF/versions/9/p/Helper.class")
> - .resource("META-INF/versions/9/p/internal/Helper9.class")
> +                .resource("META-INF/versions/" + RELEASE + "/p/Helper.class")
> +                .resource("META-INF/versions/" + RELEASE + "/p/internal/HelperNew.class")
>                 .build();
> 
>         // find the module
> @@ -131,9 +131,9 @@
>                 .moduleInfo(MODULE_INFO, descriptor1)
>                 .resource("p/Main.class")
>                 .resource("p/Helper.class")
> -                .moduleInfo("META-INF/versions/9/" + MODULE_INFO, descriptor2)
> -                .resource("META-INF/versions/9/p/Helper.class")
> - .resource("META-INF/versions/9/p/internal/Helper9.class")
> +                .moduleInfo("META-INF/versions/" + RELEASE + "/" + MODULE_INFO, descriptor2)
> +                .resource("META-INF/versions/" + RELEASE + "/p/Helper.class")
> +                .resource("META-INF/versions/" + RELEASE + "/p/internal/HelperNew.class")
>                 .build();
> 
>         // find the module
> @@ -161,8 +161,8 @@
>         Path jar = new JarBuilder(name)
>                 .resource("p/Main.class")
>                 .resource("p/Helper.class")
> -                .resource("META-INF/versions/9/p/Helper.class")
> - .resource("META-INF/versions/9/p/internal/Helper9.class")
> +                .resource("META-INF/versions/" + RELEASE + "/p/Helper.class")
> +                .resource("META-INF/versions/" + RELEASE + "/p/internal/HelperNew.class")
>                 .build();
> 
>         // find the module
> @@ -200,7 +200,7 @@
> 
>         Path jar = new JarBuilder(name)
>                 .moduleInfo(MODULE_INFO, descriptor1)
> -                .moduleInfo("META-INF/versions/9/" + MODULE_INFO, descriptor2)
> +                .moduleInfo("META-INF/versions/" + RELEASE + "/" + MODULE_INFO, descriptor2)
>                 .build();
> 
>         // find the module
> diff -r 72f33dbfcf3b test/java/security/Provider/ProviderVersionCheck.java
> --- a/test/java/security/Provider/ProviderVersionCheck.java    Tue Jan 31 19:26:10 2017 -0500
> +++ b/test/java/security/Provider/ProviderVersionCheck.java    Fri Feb 03 11:18:23 2017 -0800
> @@ -42,7 +42,7 @@
> 
>         for (Provider p: Security.getProviders()) {
>             System.out.print(p.getName() + " ");
> -            if (p.getVersion() != 9.0d) {
> +            if (p.getVersion() != 10.0d) {
>                 System.out.println("failed. " + "Version received was " +
>                         p.getVersion());
>                 failure = true;
> diff -r 72f33dbfcf3b test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java
> --- a/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java Tue Jan 31 19:26:10 2017 -0500
> +++ b/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java Fri Feb 03 11:18:23 2017 -0800
> @@ -74,7 +74,8 @@
>     private static final String KEYPASS = "changeit";
>     private static final String SIGNED_JAR = "Signed.jar";
>     private static final String POLICY_FILE = "SignedJar.policy";
> -    private static final String VERSION_MESSAGE = "I am running on version 9";
> +    private static final String VERSION = "" + Runtime.version().major();
> +    private static final String VERSION_MESSAGE = "I am running on version " + VERSION;
> 
>     public static void main(String[] args) throws Throwable {
>         // compile java files in jarContent directory
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From lance.andersen at oracle.com  Fri Feb  3 19:28:59 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 3 Feb 2017 14:28:59 -0500
Subject: RFR 8173604: Proposal to move java.annotations.common ->
	java.xml.ws.annoations
Message-ID: <28958060-C9B8-41BD-AA75-C8B7924EC92F@oracle.com>

Hi all,

Attached is the webrev for  renaming the module  javax.annotation.commons   to java.xml.ws.annotations: http://cr.openjdk.java.net/~lancea/8173604/ <http://cr.openjdk.java.net/~lancea/8173604/>

JPRT has  been run showing no issues.

Best
Lance
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From daniel.fuchs at oracle.com  Fri Feb  3 19:51:42 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 3 Feb 2017 19:51:42 +0000
Subject: RFR: 8173898: StackWalker.walk throws InternalError if called from a
	constructor invoked through reflection.
Message-ID: <951dc6d5-8fce-6af7-eda6-bcacfdb60b52@oracle.com>

Hi,

Please find below a simple fix for:

8173898: StackWalker.walk throws InternalError if called
          from a constructor invoked through reflection.
https://bugs.openjdk.java.net/browse/JDK-8173898

http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.00/

best regards,

-- daniel

From paul.sandoz at oracle.com  Fri Feb  3 20:28:50 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 3 Feb 2017 12:28:50 -0800
Subject: JDK 10 RFR of JDK-8173903: Update various tests to pass under JDK
	10
In-Reply-To: <b372228d-f4a4-2a03-7554-c8cc6ca72781@oracle.com>
References: <b372228d-f4a4-2a03-7554-c8cc6ca72781@oracle.com>
Message-ID: <75DD5C54-C507-4A77-89BE-901A4B2DE6EC@oracle.com>

+1

Paul.

> On 3 Feb 2017, at 11:21, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> After the version update to "10" in JDK 10 ( JDK-8029942 ), various libraries tests failed including:
> 
>    java/lang/module/MultiReleaseJarTest.java
>    java/security/Provider/ProviderVersionCheck.java
> sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java
> 
> These tests need to be updated for the new JDK. When it is clear how to do so, I've updated the tests in a way so that they don't need to be updated again for JDK 11.
> 
> Webrev:
> 
>    http://cr.openjdk.java.net/~darcy/8173903.0/
> 
> and patch below. I'll update the other copyrights before pushing.
> 
> Thanks,
> 
> -Joe
> 
> 
> diff -r 72f33dbfcf3b test/java/lang/module/MultiReleaseJarTest.java
> --- a/test/java/lang/module/MultiReleaseJarTest.java    Tue Jan 31 19:26:10 2017 -0500
> +++ b/test/java/lang/module/MultiReleaseJarTest.java    Fri Feb 03 11:18:23 2017 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2016, 2017, 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
> @@ -65,7 +65,7 @@
> 
>     private static final String MODULE_INFO = "module-info.class";
> 
> -    private static final int RELEASE = Runtime.version().major();
> +    private static final String RELEASE = "" + Runtime.version().major();
> 
>     // are multi-release JARs enabled?
>     private static final boolean MULTI_RELEASE;
> @@ -88,8 +88,8 @@
>                 .moduleInfo("module-info.class", descriptor)
>                 .resource("p/Main.class")
>                 .resource("p/Helper.class")
> -                .resource("META-INF/versions/9/p/Helper.class")
> - .resource("META-INF/versions/9/p/internal/Helper9.class")
> +                .resource("META-INF/versions/" + RELEASE + "/p/Helper.class")
> +                .resource("META-INF/versions/" + RELEASE + "/p/internal/HelperNew.class")
>                 .build();
> 
>         // find the module
> @@ -131,9 +131,9 @@
>                 .moduleInfo(MODULE_INFO, descriptor1)
>                 .resource("p/Main.class")
>                 .resource("p/Helper.class")
> -                .moduleInfo("META-INF/versions/9/" + MODULE_INFO, descriptor2)
> -                .resource("META-INF/versions/9/p/Helper.class")
> - .resource("META-INF/versions/9/p/internal/Helper9.class")
> +                .moduleInfo("META-INF/versions/" + RELEASE + "/" + MODULE_INFO, descriptor2)
> +                .resource("META-INF/versions/" + RELEASE + "/p/Helper.class")
> +                .resource("META-INF/versions/" + RELEASE + "/p/internal/HelperNew.class")
>                 .build();
> 
>         // find the module
> @@ -161,8 +161,8 @@
>         Path jar = new JarBuilder(name)
>                 .resource("p/Main.class")
>                 .resource("p/Helper.class")
> -                .resource("META-INF/versions/9/p/Helper.class")
> - .resource("META-INF/versions/9/p/internal/Helper9.class")
> +                .resource("META-INF/versions/" + RELEASE + "/p/Helper.class")
> +                .resource("META-INF/versions/" + RELEASE + "/p/internal/HelperNew.class")
>                 .build();
> 
>         // find the module
> @@ -200,7 +200,7 @@
> 
>         Path jar = new JarBuilder(name)
>                 .moduleInfo(MODULE_INFO, descriptor1)
> -                .moduleInfo("META-INF/versions/9/" + MODULE_INFO, descriptor2)
> +                .moduleInfo("META-INF/versions/" + RELEASE + "/" + MODULE_INFO, descriptor2)
>                 .build();
> 
>         // find the module
> diff -r 72f33dbfcf3b test/java/security/Provider/ProviderVersionCheck.java
> --- a/test/java/security/Provider/ProviderVersionCheck.java    Tue Jan 31 19:26:10 2017 -0500
> +++ b/test/java/security/Provider/ProviderVersionCheck.java    Fri Feb 03 11:18:23 2017 -0800
> @@ -42,7 +42,7 @@
> 
>         for (Provider p: Security.getProviders()) {
>             System.out.print(p.getName() + " ");
> -            if (p.getVersion() != 9.0d) {
> +            if (p.getVersion() != 10.0d) {
>                 System.out.println("failed. " + "Version received was " +
>                         p.getVersion());
>                 failure = true;
> diff -r 72f33dbfcf3b test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java
> --- a/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java Tue Jan 31 19:26:10 2017 -0500
> +++ b/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java Fri Feb 03 11:18:23 2017 -0800
> @@ -74,7 +74,8 @@
>     private static final String KEYPASS = "changeit";
>     private static final String SIGNED_JAR = "Signed.jar";
>     private static final String POLICY_FILE = "SignedJar.policy";
> -    private static final String VERSION_MESSAGE = "I am running on version 9";
> +    private static final String VERSION = "" + Runtime.version().major();
> +    private static final String VERSION_MESSAGE = "I am running on version " + VERSION;
> 
>     public static void main(String[] args) throws Throwable {
>         // compile java files in jarContent directory
> 


From joe.darcy at oracle.com  Fri Feb  3 20:42:21 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 3 Feb 2017 12:42:21 -0800
Subject: JDK 10 RFR of JDK-8173908: Problem list
	tools/jar/multiRelease/RuntimeTest.java until JDK-8173905 is fixed
Message-ID: <344fc49a-5e93-6c61-6bcd-e4eb36938708@oracle.com>

Hello,

Until JDK-8173905 is fixed, the test

tools/jar/multiRelease/RuntimeTest.java

should be problem listed so we can get clean test runs on JDK 10.

Patch below.

Thanks,

-Joe

diff -r 829a62c56e9c test/ProblemList.txt
--- a/test/ProblemList.txt    Fri Feb 03 12:36:42 2017 -0800
+++ b/test/ProblemList.txt    Fri Feb 03 12:40:45 2017 -0800
@@ -260,6 +260,8 @@

  tools/jmod/JmodTest.java 8172870 windows-all

+tools/jar/multiRelease/RuntimeTest.java 8173905 generic-all
+
  ############################################################################

  # jdk_jdi


From lance.andersen at oracle.com  Fri Feb  3 20:47:32 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 3 Feb 2017 15:47:32 -0500
Subject: JDK 10 RFR of JDK-8173908: Problem list
	tools/jar/multiRelease/RuntimeTest.java until JDK-8173905 is fixed
In-Reply-To: <344fc49a-5e93-6c61-6bcd-e4eb36938708@oracle.com>
References: <344fc49a-5e93-6c61-6bcd-e4eb36938708@oracle.com>
Message-ID: <4B526B81-0CCF-42D1-8B90-6BEDA724A80F@oracle.com>

+1
> On Feb 3, 2017, at 3:42 PM, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> Until JDK-8173905 is fixed, the test
> 
> tools/jar/multiRelease/RuntimeTest.java
> 
> should be problem listed so we can get clean test runs on JDK 10.
> 
> Patch below.
> 
> Thanks,
> 
> -Joe
> 
> diff -r 829a62c56e9c test/ProblemList.txt
> --- a/test/ProblemList.txt    Fri Feb 03 12:36:42 2017 -0800
> +++ b/test/ProblemList.txt    Fri Feb 03 12:40:45 2017 -0800
> @@ -260,6 +260,8 @@
> 
> tools/jmod/JmodTest.java 8172870 windows-all
> 
> +tools/jar/multiRelease/RuntimeTest.java 8173905 generic-all
> +
> ############################################################################
> 
> # jdk_jdi
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From paul.sandoz at oracle.com  Fri Feb  3 21:17:13 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 3 Feb 2017 13:17:13 -0800
Subject: JDK 10 RFR of JDK-8173908: Problem list
	tools/jar/multiRelease/RuntimeTest.java until JDK-8173905 is fixed
In-Reply-To: <344fc49a-5e93-6c61-6bcd-e4eb36938708@oracle.com>
References: <344fc49a-5e93-6c61-6bcd-e4eb36938708@oracle.com>
Message-ID: <1E28F528-5085-4AF6-A899-8D61606EF9C9@oracle.com>

+1
Paul.

> On 3 Feb 2017, at 12:42, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> Until JDK-8173905 is fixed, the test
> 
> tools/jar/multiRelease/RuntimeTest.java
> 
> should be problem listed so we can get clean test runs on JDK 10.
> 
> Patch below.
> 
> Thanks,
> 
> -Joe
> 
> diff -r 829a62c56e9c test/ProblemList.txt
> --- a/test/ProblemList.txt    Fri Feb 03 12:36:42 2017 -0800
> +++ b/test/ProblemList.txt    Fri Feb 03 12:40:45 2017 -0800
> @@ -260,6 +260,8 @@
> 
> tools/jmod/JmodTest.java 8172870 windows-all
> 
> +tools/jar/multiRelease/RuntimeTest.java 8173905 generic-all
> +
> ############################################################################
> 
> # jdk_jdi
> 


From daniel.fuchs at oracle.com  Fri Feb  3 21:18:22 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 3 Feb 2017 21:18:22 +0000
Subject: RFR: 8173898: StackWalker.walk throws InternalError if called
	from a constructor invoked through reflection.
In-Reply-To: <951dc6d5-8fce-6af7-eda6-bcacfdb60b52@oracle.com>
References: <951dc6d5-8fce-6af7-eda6-bcacfdb60b52@oracle.com>
Message-ID: <b6d29572-8935-0517-65ab-3bff1b670cdf@oracle.com>

Hi,

Please find below a new webrev. Part of the fix was mising
in the previous one. I also took the opportunity to replace
the test's assertEquals with those from org.testng.Assert.

http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.01

best regards,

-- daniel

On 03/02/17 19:51, Daniel Fuchs wrote:
> Hi,
>
> Please find below a simple fix for:
>
> 8173898: StackWalker.walk throws InternalError if called
>          from a constructor invoked through reflection.
> https://bugs.openjdk.java.net/browse/JDK-8173898
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.00/
>
> best regards,
>
> -- daniel


From paul.sandoz at oracle.com  Fri Feb  3 21:54:50 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 3 Feb 2017 13:54:50 -0800
Subject: RFR: 8173898: StackWalker.walk throws InternalError if called
	from a constructor invoked through reflection.
In-Reply-To: <951dc6d5-8fce-6af7-eda6-bcacfdb60b52@oracle.com>
References: <951dc6d5-8fce-6af7-eda6-bcacfdb60b52@oracle.com>
Message-ID: <16B0C05E-64A4-4B1C-A8F6-ED877A170543@oracle.com>


> On 3 Feb 2017, at 11:51, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a simple fix for:
> 
> 8173898: StackWalker.walk throws InternalError if called
>         from a constructor invoked through reflection.
> https://bugs.openjdk.java.net/browse/JDK-8173898
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.00/
> 

Looks ok.

Do you need invoke Dummy.create via reflection?

  71         List<String> found = ((Dummy)Dummy.class.getMethod("create")
  72                              .invoke(null)).found;

Paul.


> best regards,
> 
> -- daniel


From paul.sandoz at oracle.com  Fri Feb  3 23:16:06 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 3 Feb 2017 15:16:06 -0800
Subject: RFR 8173604: Proposal to move java.annotations.common ->
	java.xml.ws.annoations
In-Reply-To: <28958060-C9B8-41BD-AA75-C8B7924EC92F@oracle.com>
References: <28958060-C9B8-41BD-AA75-C8B7924EC92F@oracle.com>
Message-ID: <3C1CE523-2A6F-43C1-8ECE-E1BB399631CB@oracle.com>

+1
Paul.

> On 3 Feb 2017, at 11:28, Lance Andersen <lance.andersen at oracle.com> wrote:
> 
> Hi all,
> 
> Attached is the webrev for  renaming the module  javax.annotation.commons   to java.xml.ws.annotations: http://cr.openjdk.java.net/~lancea/8173604/ <http://cr.openjdk.java.net/~lancea/8173604/>
> 
> JPRT has  been run showing no issues.
> 
> Best
> Lance
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>
> 
> 
> 


From daniel.fuchs at oracle.com  Fri Feb  3 23:27:44 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 3 Feb 2017 23:27:44 +0000
Subject: RFR: 8173898: StackWalker.walk throws InternalError if called
	from a constructor invoked through reflection.
In-Reply-To: <16B0C05E-64A4-4B1C-A8F6-ED877A170543@oracle.com>
References: <951dc6d5-8fce-6af7-eda6-bcacfdb60b52@oracle.com>
	<16B0C05E-64A4-4B1C-A8F6-ED877A170543@oracle.com>
Message-ID: <d618d67a-b76d-aaaa-0a73-36edc0eb6c03@oracle.com>

Hi Paul,

On 03/02/17 21:54, Paul Sandoz wrote:
>
>> On 3 Feb 2017, at 11:51, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> Hi,
>>
>> Please find below a simple fix for:
>>
>> 8173898: StackWalker.walk throws InternalError if called
>>         from a constructor invoked through reflection.
>> https://bugs.openjdk.java.net/browse/JDK-8173898
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.00/
>>
>
> Looks ok.
>
> Do you need invoke Dummy.create via reflection?
>
>   71         List<String> found = ((Dummy)Dummy.class.getMethod("create")
>   72                              .invoke(null)).found;

No. But since the bug is about reflection frames not
being filtered out correctly I added it for good measure.

best regards,

-- daniel

>
> Paul.
>
>
>> best regards,
>>
>> -- daniel
>


From mandy.chung at oracle.com  Fri Feb  3 23:29:27 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 3 Feb 2017 15:29:27 -0800
Subject: RFR 8173604: Proposal to move java.annotations.common ->
	java.xml.ws.annoations
In-Reply-To: <28958060-C9B8-41BD-AA75-C8B7924EC92F@oracle.com>
References: <28958060-C9B8-41BD-AA75-C8B7924EC92F@oracle.com>
Message-ID: <0540CA3B-A85F-4074-A226-A8F9530ED9D7@oracle.com>


> On Feb 3, 2017, at 11:28 AM, Lance Andersen <lance.andersen at oracle.com> wrote:
> 
> Hi all,
> 
> Attached is the webrev for  renaming the module  javax.annotation.commons   to java.xml.ws.annotations: http://cr.openjdk.java.net/~lancea/8173604/ <http://cr.openjdk.java.net/~lancea/8173604/>

<top>/configure - no change in this change.  You may want to revert it if it has any whitespace change?

The description of the module may need some update to reflect its relationship with JAX-WS but it?s okay to update it separately as overall docs update.

Otherwise, looks okay.  

Mandy

From lance.andersen at oracle.com  Fri Feb  3 23:36:50 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 3 Feb 2017 18:36:50 -0500
Subject: RFR 8173604: Proposal to move java.annotations.common ->
	java.xml.ws.annoations
In-Reply-To: <0540CA3B-A85F-4074-A226-A8F9530ED9D7@oracle.com>
References: <28958060-C9B8-41BD-AA75-C8B7924EC92F@oracle.com>
	<0540CA3B-A85F-4074-A226-A8F9530ED9D7@oracle.com>
Message-ID: <2922D569-BA2B-4D9D-A133-5E951532A629@oracle.com>


> On Feb 3, 2017, at 6:29 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
>> On Feb 3, 2017, at 11:28 AM, Lance Andersen <lance.andersen at oracle.com> wrote:
>> 
>> Hi all,
>> 
>> Attached is the webrev for  renaming the module  javax.annotation.commons   to java.xml.ws.annotations: http://cr.openjdk.java.net/~lancea/8173604/ <http://cr.openjdk.java.net/~lancea/8173604/>
> 
> <top>/configure - no change in this change.  You may want to revert it if it has any whitespace change?

there is no change here, It got picked up due to my chmod (I believe) but I will not be pushing it.

Daniel also asked me about that...
> 
> The description of the module may need some update to reflect its relationship with JAX-WS but it?s okay to update it separately as overall docs update.

Yes a project for another day :-)
> 
> Otherwise, looks okay.  

Thank you
> 
> Mandy

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From paul.sandoz at oracle.com  Fri Feb  3 23:40:01 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 3 Feb 2017 15:40:01 -0800
Subject: RFR: 8173898: StackWalker.walk throws InternalError if called
	from a constructor invoked through reflection.
In-Reply-To: <d618d67a-b76d-aaaa-0a73-36edc0eb6c03@oracle.com>
References: <951dc6d5-8fce-6af7-eda6-bcacfdb60b52@oracle.com>
	<16B0C05E-64A4-4B1C-A8F6-ED877A170543@oracle.com>
	<d618d67a-b76d-aaaa-0a73-36edc0eb6c03@oracle.com>
Message-ID: <7A150226-DB84-4205-9183-99568FC51C0E@oracle.com>


> On 3 Feb 2017, at 15:27, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Paul,
> 
> On 03/02/17 21:54, Paul Sandoz wrote:
>> 
>>> On 3 Feb 2017, at 11:51, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Please find below a simple fix for:
>>> 
>>> 8173898: StackWalker.walk throws InternalError if called
>>>        from a constructor invoked through reflection.
>>> https://bugs.openjdk.java.net/browse/JDK-8173898
>>> 
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.00/
>>> 
>> 
>> Looks ok.
>> 
>> Do you need invoke Dummy.create via reflection?
>> 
>>  71         List<String> found = ((Dummy)Dummy.class.getMethod("create")
>>  72                              .invoke(null)).found;
> 
> No. But since the bug is about reflection frames not
> being filtered out correctly I added it for good measure.
> 

Ok, i see now, it?s testing both cases in one, thanks,
Paul.

From mandy.chung at oracle.com  Sat Feb  4 00:14:44 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 3 Feb 2017 16:14:44 -0800
Subject: Review Request: JDK-8173412 @Test in java/lang/annotation and
	java/lang/reflect/Proxy tests not run
Message-ID: <35756A86-B26F-48DA-97DE-FD2B5BBD0810@oracle.com>

Fix @Test tests to be public.

Mandy

diff --git a/test/java/lang/annotation/AnnotationWithLambda.java b/test/java/lang/annotation/AnnotationWithLambda.java
--- a/test/java/lang/annotation/AnnotationWithLambda.java
+++ b/test/java/lang/annotation/AnnotationWithLambda.java
@@ -43,7 +43,7 @@
 public class AnnotationWithLambda {
 
     @Test
-    void testAnnotationWithLambda() {
+    public void testAnnotationWithLambda() {
         Method[] methods = AnnotationWithLambda.MethodsWithAnnotations.class.getDeclaredMethods();
         for (Method method : methods) {
             assertTrue((method.isAnnotationPresent(LambdaWithParameter.class)) &&
diff --git a/test/java/lang/reflect/Proxy/ProxyForMethodHandle.java b/test/java/lang/reflect/Proxy/ProxyForMethodHandle.java
--- a/test/java/lang/reflect/Proxy/ProxyForMethodHandle.java
+++ b/test/java/lang/reflect/Proxy/ProxyForMethodHandle.java
@@ -46,7 +46,7 @@
      * to a dynamic module
      */
     @Test
-    static void testRunnableMethodHandle() throws Exception {
+    public static void testRunnableMethodHandle() throws Exception {
         MethodHandles.Lookup lookup = MethodHandles.lookup();
         MethodType mt = MethodType.methodType(void.class);
         MethodHandle mh = lookup.findStatic(ProxyForMethodHandle.class, "runForRunnable", mt);

From claes.redestad at oracle.com  Sat Feb  4 00:26:12 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 4 Feb 2017 01:26:12 +0100
Subject: Review Request: JDK-8173412 @Test in java/lang/annotation and
	java/lang/reflect/Proxy tests not run
In-Reply-To: <35756A86-B26F-48DA-97DE-FD2B5BBD0810@oracle.com>
References: <35756A86-B26F-48DA-97DE-FD2B5BBD0810@oracle.com>
Message-ID: <4fd2743d-f728-54bb-3d9f-5358898a108a@oracle.com>

+1

On 2017-02-04 01:14, Mandy Chung wrote:
> Fix @Test tests to be public.
>
> Mandy
>
> diff --git a/test/java/lang/annotation/AnnotationWithLambda.java b/test/java/lang/annotation/AnnotationWithLambda.java
> --- a/test/java/lang/annotation/AnnotationWithLambda.java
> +++ b/test/java/lang/annotation/AnnotationWithLambda.java
> @@ -43,7 +43,7 @@
>  public class AnnotationWithLambda {
>
>      @Test
> -    void testAnnotationWithLambda() {
> +    public void testAnnotationWithLambda() {
>          Method[] methods = AnnotationWithLambda.MethodsWithAnnotations.class.getDeclaredMethods();
>          for (Method method : methods) {
>              assertTrue((method.isAnnotationPresent(LambdaWithParameter.class)) &&
> diff --git a/test/java/lang/reflect/Proxy/ProxyForMethodHandle.java b/test/java/lang/reflect/Proxy/ProxyForMethodHandle.java
> --- a/test/java/lang/reflect/Proxy/ProxyForMethodHandle.java
> +++ b/test/java/lang/reflect/Proxy/ProxyForMethodHandle.java
> @@ -46,7 +46,7 @@
>       * to a dynamic module
>       */
>      @Test
> -    static void testRunnableMethodHandle() throws Exception {
> +    public static void testRunnableMethodHandle() throws Exception {
>          MethodHandles.Lookup lookup = MethodHandles.lookup();
>          MethodType mt = MethodType.methodType(void.class);
>          MethodHandle mh = lookup.findStatic(ProxyForMethodHandle.class, "runForRunnable", mt);
>

From brent.christian at oracle.com  Sat Feb  4 01:02:09 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 03 Feb 2017 17:02:09 -0800
Subject: RFR: 8173898: StackWalker.walk throws InternalError if called
	from a constructor invoked through reflection.
In-Reply-To: <951dc6d5-8fce-6af7-eda6-bcacfdb60b52@oracle.com>
References: <951dc6d5-8fce-6af7-eda6-bcacfdb60b52@oracle.com>
Message-ID: <58952811.1090004@oracle.com>

This looks fine to me, Daniel.

Fun test case. :)

Thanks,
-Brent
On 02/03/2017 11:51 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a simple fix for:
>
> 8173898: StackWalker.walk throws InternalError if called
>           from a constructor invoked through reflection.
> https://bugs.openjdk.java.net/browse/JDK-8173898
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.00/
>
> best regards,
>
> -- daniel


From david.holmes at oracle.com  Sat Feb  4 01:44:09 2017
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 4 Feb 2017 11:44:09 +1000
Subject: RFR: 8167063: spurious message "A JNI error has occurred" if
	start-class cannot be initialized
In-Reply-To: <55b2213e-6758-47d8-b659-1b405f72e1fb@default>
References: <55b2213e-6758-47d8-b659-1b405f72e1fb@default>
Message-ID: <1918bc7a-9b6d-6b90-b97f-87f3bbe5b528@oracle.com>

This seems to have caused a number of failures in hotspot testing as 
thrown ClassFormatErrors seem to have been replaced by LinkageError.

https://bugs.openjdk.java.net/browse/JDK-8173915

David

> Thank you Kumar and Alan.
> Just pushed the fix. All the related tests from "core" and "pit" testset are passed.
>
> Regards,
> Ramanand.
>
> -----Original Message-----
> From: Kumar Srinivasan
> Sent: Tuesday, January 31, 2017 9:53 PM
> To: Ramanand Patil <ramanand.patil at oracle.com>
> Cc: Alan Bateman <alan.bateman at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: 8167063: spurious message "A JNI error has occurred" if start-class cannot be initialized
>
>
> Approved, please make sure you have run all the jprt -testset pit tests.
>
> Kumar
>
> On 1/30/2017 5:05 AM, Alan Bateman wrote:
>> On 30/01/2017 12:11, Ramanand Patil wrote:
>>
>>> Thank you Alan.
>>>
>>> I have eliminated the inner catch block for LinkageError. Here is the
>>> updated webrev:
>>> http://cr.openjdk.java.net/~rpatil/8167063/webrev.04
>>>
>>>
>> I think this looks right now.
>>
>> -Alan

From Alan.Bateman at oracle.com  Sat Feb  4 06:22:47 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 4 Feb 2017 06:22:47 +0000
Subject: RFR 8173604: Proposal to move java.annotations.common ->
	java.xml.ws.annoations
In-Reply-To: <28958060-C9B8-41BD-AA75-C8B7924EC92F@oracle.com>
References: <28958060-C9B8-41BD-AA75-C8B7924EC92F@oracle.com>
Message-ID: <519839b0-ac12-3dcf-b603-40b150ff8c18@oracle.com>

On 03/02/2017 19:28, Lance Andersen wrote:

> Hi all,
>
> Attached is the webrev for  renaming the module  javax.annotation.commons   to java.xml.ws.annotations: http://cr.openjdk.java.net/~lancea/8173604/ <http://cr.openjdk.java.net/~lancea/8173604/>
>
The rename looks good but I think an update to java.xml.ws.annotation's 
module description is needed. It doesn't matter if there is a separate 
issue for this but the existing description doesn't match the new module 
name.

-Alan

From peter.levart at gmail.com  Sun Feb  5 15:41:14 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 5 Feb 2017 16:41:14 +0100
Subject: RFR: 8173607: JMX RMI connector should be in its own module
In-Reply-To: <5ad3fe2b-be04-24c7-98bb-8bab61c3aa15@oracle.com>
References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com>
	<BD7108DF-69F6-4807-88BC-57D3C7D47CAC@oracle.com>
	<5ad3fe2b-be04-24c7-98bb-8bab61c3aa15@oracle.com>
Message-ID: <7552b27f-0226-a1d0-6fd4-7e514b245849@gmail.com>

Hi Daniel, Mandy,

It seems that this change has caused regression in jconsole tool. It 
doesn't want to list local JVMs to attach to any more. The following 
fixes the issue:

--- old/src/jdk.jconsole/share/classes/sun/tools/jconsole/JConsole.java 
2017-02-05 16:37:26.768771419 +0100
+++ new/src/jdk.jconsole/share/classes/sun/tools/jconsole/JConsole.java 
2017-02-05 16:37:26.597774358 +0100
@@ -954,7 +954,7 @@
          boolean supported;
          try {
              Class.forName("com.sun.tools.attach.VirtualMachine");
-            Class.forName("sun.management.ConnectorAddressLink");
+ Class.forName("jdk.internal.agent.ConnectorAddressLink");
              supported = true;
          } catch (NoClassDefFoundError x) {
              supported = false;


Regards, Peter

On 02/01/2017 04:29 PM, Daniel Fuchs wrote:
> Hi Mandy,
>
> On 01/02/17 05:11, Mandy Chung wrote:
>>
>>> On Jan 31, 2017, at 10:26 AM, Daniel Fuchs <daniel.fuchs at oracle.com> 
>>> wrote:
>>>
>>> Hi,
>>>
>>> Please find below a patch for:
>>>
>>> 8173607: JMX RMI connector should be in its own module
>>> https://bugs.openjdk.java.net/browse/JDK-8173607
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05
>>>
>>
>> This mostly looks good.  I?d like to see an updated webrev after you 
>> sync with JDK-8173608.  I believe you can revert 
>> test/sun/management/jdp and test/sun/management/jmxremote tests 
>> change and ConnectorBootstrap.java as you noted.  Also you can run 
>> jdeps ?-check on java.rmi, java.management, and jdk.management.agent 
>> to update its requires and qualified exports.  java.management should 
>> no longer require java.rmi and the qualified exports from java.rmi is 
>> not needed.
>
> Here is the updated webrev, rebased after pulling JDK-8173608, and with
> your feedback below integrated.
>
> I am pleased to report that java.management no longer requires
> java.rmi or java.naming :-)
>
> Compared to previous version, then RMIExporter has been moved
> to java.management.rmi, various module-info.java have been
> cleaned up, some @modules in tests have been updated (mostly
> due to the RMIExporter move).
>
> I have also improved some javadoc comments in JMXConnectorFactory.java
> No changes in build files compared to webrev.05
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06
> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06/java.management.rmi-summary.html 
>
>
> best regards,
>
> -- daniel
>
>>
>> java.management.rmi module-info.java
>>   32  * @see javax.management.remote.rmi
>>
>> This @see is not needed.  This package is listed in the exported 
>> packages table.
>>
>> JMXConnectorFactory.java
>>    I like the ProviderFinder approach to look up the custom providers 
>> and platform providers; and shared code used by both 
>> JMXConnectorFactory and JMXConnectorServerFactory which is good.
>>
>>    Nit: line 481-491 - this is javadoc and probably /* .. */ comment 
>> block is more appropriate here.
>>
>>>
>>> Some further cleanup of java.base and java.rmi module-info.java
>>> should become possible once JDK-8173608 is in (as well as moving
>>> RMIExporter to java.management.rmi - which is not possible yet).
>>>
>>
>> Yes.
>>
>>> Further cleanup of @modules in tests might become possible as
>>> well.
>>>
>>
>> Hope there will be a bulk @modules cleanup some time.
>>
>> Thanks
>> Mandy
>>
>


From mandy.chung at oracle.com  Sun Feb  5 16:01:54 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sun, 5 Feb 2017 08:01:54 -0800
Subject: RFR: 8173607: JMX RMI connector should be in its own module
In-Reply-To: <7552b27f-0226-a1d0-6fd4-7e514b245849@gmail.com>
References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com>
	<BD7108DF-69F6-4807-88BC-57D3C7D47CAC@oracle.com>
	<5ad3fe2b-be04-24c7-98bb-8bab61c3aa15@oracle.com>
	<7552b27f-0226-a1d0-6fd4-7e514b245849@gmail.com>
Message-ID: <A8CEB879-A924-4147-A8C7-30DA96A5B4DD@oracle.com>

Thanks for catching this.  I?ll file a bug and fix it.  We can drop Class.forName since jdk.jconsole requires jdk.attach and jdk.management.agent.

Mandy

> On Feb 5, 2017, at 7:41 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi Daniel, Mandy,
> 
> It seems that this change has caused regression in jconsole tool. It doesn't want to list local JVMs to attach to any more. The following fixes the issue:
> 
> --- old/src/jdk.jconsole/share/classes/sun/tools/jconsole/JConsole.java    2017-02-05 16:37:26.768771419 +0100
> +++ new/src/jdk.jconsole/share/classes/sun/tools/jconsole/JConsole.java    2017-02-05 16:37:26.597774358 +0100
> @@ -954,7 +954,7 @@
>          boolean supported;
>          try {
>              Class.forName("com.sun.tools.attach.VirtualMachine");
> -            Class.forName("sun.management.ConnectorAddressLink");
> +            Class.forName("jdk.internal.agent.ConnectorAddressLink");
>              supported = true;
>          } catch (NoClassDefFoundError x) {
>              supported = false;
> 
> 
> Regards, Peter
> 
> On 02/01/2017 04:29 PM, Daniel Fuchs wrote:
>> Hi Mandy, 
>> 
>> On 01/02/17 05:11, Mandy Chung wrote: 
>>> 
>>>> On Jan 31, 2017, at 10:26 AM, Daniel Fuchs <daniel.fuchs at oracle.com> <mailto:daniel.fuchs at oracle.com> wrote: 
>>>> 
>>>> Hi, 
>>>> 
>>>> Please find below a patch for: 
>>>> 
>>>> 8173607: JMX RMI connector should be in its own module 
>>>> https://bugs.openjdk.java.net/browse/JDK-8173607 <https://bugs.openjdk.java.net/browse/JDK-8173607> 
>>>> 
>>>> webrev: 
>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05 <http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05> 
>>>> 
>>> 
>>> This mostly looks good.  I?d like to see an updated webrev after you sync with JDK-8173608.  I believe you can revert test/sun/management/jdp and test/sun/management/jmxremote tests change and ConnectorBootstrap.java as you noted.  Also you can run jdeps ?-check on java.rmi, java.management, and jdk.management.agent to update its requires and qualified exports.  java.management should no longer require java.rmi and the qualified exports from java.rmi is not needed. 
>> 
>> Here is the updated webrev, rebased after pulling JDK-8173608, and with 
>> your feedback below integrated. 
>> 
>> I am pleased to report that java.management no longer requires 
>> java.rmi or java.naming :-) 
>> 
>> Compared to previous version, then RMIExporter has been moved 
>> to java.management.rmi, various module-info.java have been 
>> cleaned up, some @modules in tests have been updated (mostly 
>> due to the RMIExporter move). 
>> 
>> I have also improved some javadoc comments in JMXConnectorFactory.java 
>> No changes in build files compared to webrev.05 
>> 
>> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06 <http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06> 
>> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06/java.management.rmi-summary.html <http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06/java.management.rmi-summary.html> 
>> 
>> best regards, 
>> 
>> -- daniel 
>> 
>>> 
>>> java.management.rmi module-info.java 
>>>   32  * @see javax.management.remote.rmi 
>>> 
>>> This @see is not needed.  This package is listed in the exported packages table. 
>>> 
>>> JMXConnectorFactory.java 
>>>    I like the ProviderFinder approach to look up the custom providers and platform providers; and shared code used by both JMXConnectorFactory and JMXConnectorServerFactory which is good. 
>>> 
>>>    Nit: line 481-491 - this is javadoc and probably /* .. */ comment block is more appropriate here. 
>>> 
>>>> 
>>>> Some further cleanup of java.base and java.rmi module-info.java 
>>>> should become possible once JDK-8173608 is in (as well as moving 
>>>> RMIExporter to java.management.rmi - which is not possible yet). 
>>>> 
>>> 
>>> Yes. 
>>> 
>>>> Further cleanup of @modules in tests might become possible as 
>>>> well. 
>>>> 
>>> 
>>> Hope there will be a bulk @modules cleanup some time. 
>>> 
>>> Thanks 
>>> Mandy 
>>> 
>> 
> 


From ramanand.patil at oracle.com  Sun Feb  5 19:14:41 2017
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Sun, 5 Feb 2017 11:14:41 -0800 (PST)
Subject: RFR: 8173943: Change error reporting of LauncherHelper to include
	actual Error class name
Message-ID: <32e0a2e8-34a8-4bc2-8fbf-db1107995b33@default>

Hi all,
Please review the following trivial bug fix:
Bug: https://bugs.openjdk.java.net/browse/JDK-8173943
Webrev: http://cr.openjdk.java.net/~rpatil/8173943/webrev.00/

LinkageError message added by - https://bugs.openjdk.java.net/browse/JDK-8167063 is updated to include the Error Class name.

Regards,
Ramanand.


From david.holmes at oracle.com  Sun Feb  5 21:40:22 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 6 Feb 2017 07:40:22 +1000
Subject: RFR: 8173943: Change error reporting of LauncherHelper to include
	actual Error class name
In-Reply-To: <32e0a2e8-34a8-4bc2-8fbf-db1107995b33@default>
References: <32e0a2e8-34a8-4bc2-8fbf-db1107995b33@default>
Message-ID: <c9457b5a-bc69-82e8-e3a4-16e487eb2527@oracle.com>

Hi Ramanand,

On 6/02/2017 5:14 AM, Ramanand Patil wrote:
> Hi all,
> Please review the following trivial bug fix:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8173943
> Webrev: http://cr.openjdk.java.net/~rpatil/8173943/webrev.00/
>
> LinkageError message added by - https://bugs.openjdk.java.net/browse/JDK-8167063 is updated to include the Error Class name.

For changes like this it would be useful to show (in the RFR and/or the 
bug report) how the error messages appear before and after the change as 
that is what we need to verify. And in this case we need to compare 
against what was reported prior to JDK-8167063 being fixed.

Thanks,
David
-----

> Regards,
> Ramanand.
>

From mandy.chung at oracle.com  Mon Feb  6 00:16:40 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sun, 5 Feb 2017 16:16:40 -0800
Subject: RFR: 8173898: StackWalker.walk throws InternalError if called
	from a constructor invoked through reflection.
In-Reply-To: <951dc6d5-8fce-6af7-eda6-bcacfdb60b52@oracle.com>
References: <951dc6d5-8fce-6af7-eda6-bcacfdb60b52@oracle.com>
Message-ID: <FF6E35EA-7653-4AD9-BB6B-D1606D21FA75@oracle.com>

Hi Daniel,

Thanks for the patch and uncover that Constructor::newInstance is not covered by SHOW_REFLECT_FRAMES.  

The change looks okay.  The javadoc of SHOW_REFLECT_FRAMES can be clarified to include Constructor::newInstance.  As for the test, can you separate this in a new test to test showing and hiding reflecton frames and also getCallerClass?

Mandy

> On Feb 3, 2017, at 11:51 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a simple fix for:
> 
> 8173898: StackWalker.walk throws InternalError if called
>         from a constructor invoked through reflection.
> https://bugs.openjdk.java.net/browse/JDK-8173898
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.00/
> 
> best regards,
> 
> -- daniel


From david.holmes at oracle.com  Mon Feb  6 03:00:20 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 6 Feb 2017 13:00:20 +1000
Subject: JDK 10 RFR of JDK-8173903: Update various tests to pass under JDK
	10
In-Reply-To: <b372228d-f4a4-2a03-7554-c8cc6ca72781@oracle.com>
References: <b372228d-f4a4-2a03-7554-c8cc6ca72781@oracle.com>
Message-ID: <4092f26c-a928-d953-bf86-540817e9f8e2@oracle.com>

Hi Joe,

On 4/02/2017 5:21 AM, joe darcy wrote:
> Hello,
>
> After the version update to "10" in JDK 10 ( JDK-8029942 ), various
> libraries tests failed including:
>
>     java/lang/module/MultiReleaseJarTest.java
>     java/security/Provider/ProviderVersionCheck.java

Shouldn't the hardwired 10.0d (was 9.0d) be obtained from current 
runtime information?

Cheers,
David

> sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java
>
> These tests need to be updated for the new JDK. When it is clear how to
> do so, I've updated the tests in a way so that they don't need to be
> updated again for JDK 11.
>
> Webrev:
>
>     http://cr.openjdk.java.net/~darcy/8173903.0/
>
> and patch below. I'll update the other copyrights before pushing.
>
> Thanks,
>
> -Joe
>
>
> diff -r 72f33dbfcf3b test/java/lang/module/MultiReleaseJarTest.java
> --- a/test/java/lang/module/MultiReleaseJarTest.java    Tue Jan 31
> 19:26:10 2017 -0500
> +++ b/test/java/lang/module/MultiReleaseJarTest.java    Fri Feb 03
> 11:18:23 2017 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2016, 2017, 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
> @@ -65,7 +65,7 @@
>
>      private static final String MODULE_INFO = "module-info.class";
>
> -    private static final int RELEASE = Runtime.version().major();
> +    private static final String RELEASE = "" + Runtime.version().major();
>
>      // are multi-release JARs enabled?
>      private static final boolean MULTI_RELEASE;
> @@ -88,8 +88,8 @@
>                  .moduleInfo("module-info.class", descriptor)
>                  .resource("p/Main.class")
>                  .resource("p/Helper.class")
> -                .resource("META-INF/versions/9/p/Helper.class")
> - .resource("META-INF/versions/9/p/internal/Helper9.class")
> +                .resource("META-INF/versions/" + RELEASE +
> "/p/Helper.class")
> +                .resource("META-INF/versions/" + RELEASE +
> "/p/internal/HelperNew.class")
>                  .build();
>
>          // find the module
> @@ -131,9 +131,9 @@
>                  .moduleInfo(MODULE_INFO, descriptor1)
>                  .resource("p/Main.class")
>                  .resource("p/Helper.class")
> -                .moduleInfo("META-INF/versions/9/" + MODULE_INFO,
> descriptor2)
> -                .resource("META-INF/versions/9/p/Helper.class")
> - .resource("META-INF/versions/9/p/internal/Helper9.class")
> +                .moduleInfo("META-INF/versions/" + RELEASE + "/" +
> MODULE_INFO, descriptor2)
> +                .resource("META-INF/versions/" + RELEASE +
> "/p/Helper.class")
> +                .resource("META-INF/versions/" + RELEASE +
> "/p/internal/HelperNew.class")
>                  .build();
>
>          // find the module
> @@ -161,8 +161,8 @@
>          Path jar = new JarBuilder(name)
>                  .resource("p/Main.class")
>                  .resource("p/Helper.class")
> -                .resource("META-INF/versions/9/p/Helper.class")
> - .resource("META-INF/versions/9/p/internal/Helper9.class")
> +                .resource("META-INF/versions/" + RELEASE +
> "/p/Helper.class")
> +                .resource("META-INF/versions/" + RELEASE +
> "/p/internal/HelperNew.class")
>                  .build();
>
>          // find the module
> @@ -200,7 +200,7 @@
>
>          Path jar = new JarBuilder(name)
>                  .moduleInfo(MODULE_INFO, descriptor1)
> -                .moduleInfo("META-INF/versions/9/" + MODULE_INFO,
> descriptor2)
> +                .moduleInfo("META-INF/versions/" + RELEASE + "/" +
> MODULE_INFO, descriptor2)
>                  .build();
>
>          // find the module
> diff -r 72f33dbfcf3b test/java/security/Provider/ProviderVersionCheck.java
> --- a/test/java/security/Provider/ProviderVersionCheck.java    Tue Jan
> 31 19:26:10 2017 -0500
> +++ b/test/java/security/Provider/ProviderVersionCheck.java    Fri Feb
> 03 11:18:23 2017 -0800
> @@ -42,7 +42,7 @@
>
>          for (Provider p: Security.getProviders()) {
>              System.out.print(p.getName() + " ");
> -            if (p.getVersion() != 9.0d) {
> +            if (p.getVersion() != 10.0d) {
>                  System.out.println("failed. " + "Version received was " +
>                          p.getVersion());
>                  failure = true;
> diff -r 72f33dbfcf3b
> test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java
> ---
> a/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java
> Tue Jan 31 19:26:10 2017 -0500
> +++
> b/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java
> Fri Feb 03 11:18:23 2017 -0800
> @@ -74,7 +74,8 @@
>      private static final String KEYPASS = "changeit";
>      private static final String SIGNED_JAR = "Signed.jar";
>      private static final String POLICY_FILE = "SignedJar.policy";
> -    private static final String VERSION_MESSAGE = "I am running on
> version 9";
> +    private static final String VERSION = "" + Runtime.version().major();
> +    private static final String VERSION_MESSAGE = "I am running on
> version " + VERSION;
>
>      public static void main(String[] args) throws Throwable {
>          // compile java files in jarContent directory
>

From ramanand.patil at oracle.com  Mon Feb  6 03:22:41 2017
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Sun, 5 Feb 2017 19:22:41 -0800 (PST)
Subject: RFR: 8173943: Change error reporting of LauncherHelper to include
	actual Error class name
In-Reply-To: <c9457b5a-bc69-82e8-e3a4-16e487eb2527@oracle.com>
References: <32e0a2e8-34a8-4bc2-8fbf-db1107995b33@default>
	<c9457b5a-bc69-82e8-e3a4-16e487eb2527@oracle.com>
Message-ID: <05728762-b66e-47bc-a43d-e05533e01c76@default>

Hi David,

I have updated the bug report with the below sample output error message as suggested.

Here is the sample error output for comparison(taken from the test case of JDK-8167063):

1. Before Fixing JDK-8167063:
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.IllegalAccessError: superclass access check failed: class pkg.b.Bar (in module mod.b) cannot access class pkg.a.Foo (in module mod.a) because module mod.a does not export pkg.a to module mod.b
at java.lang.ClassLoader.defineClass1(java.base at 9-ea/Native Method)
at java.lang.ClassLoader.defineClass(java.base at 9-ea/ClassLoader.java:947)
at java.lang.ClassLoader.defineClass(java.base at 9-ea/ClassLoader.java:1024)
at java.security.SecureClassLoader.defineClass(java.base at 9-ea/SecureClassLoader.java:182)
at jdk.internal.loader.BuiltinClassLoader.defineClass(java.base at 9-ea/BuiltinClassLoader.java:512)
at jdk.internal.loader.BuiltinClassLoader.lambda$findClassInModuleOrNull$2(java.base at 9-ea/BuiltinClassLoader.java:449)
at java.security.AccessController.doPrivileged(java.base at 9-ea/Native Method)
at jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(java.base at 9-ea/BuiltinClassLoader.java:450)
at jdk.internal.loader.BuiltinClassLoader.findClass(java.base at 9-ea/BuiltinClassLoader.java:354)
at java.lang.ClassLoader.loadLocalClass(java.base at 9-ea/ClassLoader.java:536)
at java.lang.Class.forName(java.base at 9-ea/Class.java:446)
at sun.launcher.LauncherHelper.loadModuleMainClass(java.base at 9-ea/LauncherHelper.java:544)
at sun.launcher.LauncherHelper.checkAndLoadMain(java.base at 9-ea/LauncherHelper.java:496)

2. After Fixing JDK-8167063:
Error: Unable to load main class pkgB.ClassB from module mod.b
superclass access check failed: class pkgB.ClassB (in module mod.b) cannot access class pkgA.ClassA (in module mod.a) because module mod.a does not export pkgA to module mod.b

[Here the complete stacktrace was removed to be consistent with the error handling mechanism of LauncherHelper, where only the important error message is printed and the complete stack trace is shown in diagnostic ("-Xdiag") mode.]

3. After fixing the current Bug( JDK-8173943 ):
Error: Unable to load main class pkgB.ClassB from module mod.b
java.lang.IllegalAccessError: superclass access check failed: class pkgB.ClassB (in module mod.b) cannot access class pkgA.ClassA (in module mod.a) because module mod.a does not export pkgA to module mod.b


Regards,
Ramanand.
-----Original Message-----
From: David Holmes 
Sent: Monday, February 06, 2017 3:10 AM
To: Ramanand Patil <ramanand.patil at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: RFR: 8173943: Change error reporting of LauncherHelper to include actual Error class name

Hi Ramanand,

On 6/02/2017 5:14 AM, Ramanand Patil wrote:
> Hi all,
> Please review the following trivial bug fix:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8173943
> Webrev: http://cr.openjdk.java.net/~rpatil/8173943/webrev.00/
>
> LinkageError message added by - https://bugs.openjdk.java.net/browse/JDK-8167063 is updated to include the Error Class name.

For changes like this it would be useful to show (in the RFR and/or the bug report) how the error messages appear before and after the change as that is what we need to verify. And in this case we need to compare against what was reported prior to JDK-8167063 being fixed.

Thanks,
David
-----

> Regards,
> Ramanand.
>

From david.holmes at oracle.com  Mon Feb  6 03:34:01 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 6 Feb 2017 13:34:01 +1000
Subject: RFR: 8173943: Change error reporting of LauncherHelper to include
	actual Error class name
In-Reply-To: <05728762-b66e-47bc-a43d-e05533e01c76@default>
References: <32e0a2e8-34a8-4bc2-8fbf-db1107995b33@default>
	<c9457b5a-bc69-82e8-e3a4-16e487eb2527@oracle.com>
	<05728762-b66e-47bc-a43d-e05533e01c76@default>
Message-ID: <0e33dd25-a087-10f4-d792-252fa0e80350@oracle.com>

Hi Ramanand,

On 6/02/2017 1:22 PM, Ramanand Patil wrote:
> Hi David,
>
> I have updated the bug report with the below sample output error message as suggested.
>
> Here is the sample error output for comparison(taken from the test case of JDK-8167063):

Thanks. I expect this does fix the test failures, but to honest I much 
prefer the original

Exception in thread "main" ...

form of the message. I'm really not sure why that needed to change.


Thanks,
David

> 1. Before Fixing JDK-8167063:
> Error: A JNI error has occurred, please check your installation and try again
> Exception in thread "main" java.lang.IllegalAccessError: superclass access check failed: class pkg.b.Bar (in module mod.b) cannot access class pkg.a.Foo (in module mod.a) because module mod.a does not export pkg.a to module mod.b
> at java.lang.ClassLoader.defineClass1(java.base at 9-ea/Native Method)
> at java.lang.ClassLoader.defineClass(java.base at 9-ea/ClassLoader.java:947)
> at java.lang.ClassLoader.defineClass(java.base at 9-ea/ClassLoader.java:1024)
> at java.security.SecureClassLoader.defineClass(java.base at 9-ea/SecureClassLoader.java:182)
> at jdk.internal.loader.BuiltinClassLoader.defineClass(java.base at 9-ea/BuiltinClassLoader.java:512)
> at jdk.internal.loader.BuiltinClassLoader.lambda$findClassInModuleOrNull$2(java.base at 9-ea/BuiltinClassLoader.java:449)
> at java.security.AccessController.doPrivileged(java.base at 9-ea/Native Method)
> at jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(java.base at 9-ea/BuiltinClassLoader.java:450)
> at jdk.internal.loader.BuiltinClassLoader.findClass(java.base at 9-ea/BuiltinClassLoader.java:354)
> at java.lang.ClassLoader.loadLocalClass(java.base at 9-ea/ClassLoader.java:536)
> at java.lang.Class.forName(java.base at 9-ea/Class.java:446)
> at sun.launcher.LauncherHelper.loadModuleMainClass(java.base at 9-ea/LauncherHelper.java:544)
> at sun.launcher.LauncherHelper.checkAndLoadMain(java.base at 9-ea/LauncherHelper.java:496)
>
> 2. After Fixing JDK-8167063:
> Error: Unable to load main class pkgB.ClassB from module mod.b
> superclass access check failed: class pkgB.ClassB (in module mod.b) cannot access class pkgA.ClassA (in module mod.a) because module mod.a does not export pkgA to module mod.b
>
> [Here the complete stacktrace was removed to be consistent with the error handling mechanism of LauncherHelper, where only the important error message is printed and the complete stack trace is shown in diagnostic ("-Xdiag") mode.]
>
> 3. After fixing the current Bug( JDK-8173943 ):
> Error: Unable to load main class pkgB.ClassB from module mod.b
> java.lang.IllegalAccessError: superclass access check failed: class pkgB.ClassB (in module mod.b) cannot access class pkgA.ClassA (in module mod.a) because module mod.a does not export pkgA to module mod.b
>
>
> Regards,
> Ramanand.
> -----Original Message-----
> From: David Holmes
> Sent: Monday, February 06, 2017 3:10 AM
> To: Ramanand Patil <ramanand.patil at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: 8173943: Change error reporting of LauncherHelper to include actual Error class name
>
> Hi Ramanand,
>
> On 6/02/2017 5:14 AM, Ramanand Patil wrote:
>> Hi all,
>> Please review the following trivial bug fix:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173943
>> Webrev: http://cr.openjdk.java.net/~rpatil/8173943/webrev.00/
>>
>> LinkageError message added by - https://bugs.openjdk.java.net/browse/JDK-8167063 is updated to include the Error Class name.
>
> For changes like this it would be useful to show (in the RFR and/or the bug report) how the error messages appear before and after the change as that is what we need to verify. And in this case we need to compare against what was reported prior to JDK-8167063 being fixed.
>
> Thanks,
> David
> -----
>
>> Regards,
>> Ramanand.
>>

From christoph.langer at sap.com  Mon Feb  6 10:08:57 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 6 Feb 2017 10:08:57 +0000
Subject: Ping: [JAXP] RFR: 8173602: TESTBUG:
	javax/xml/jaxp/unittest/transform/TransformerTest.java needs
	refactoring
In-Reply-To: <67619df3-d9b0-c303-544a-0fa52d20fdde@oracle.com>
References: <4e2bf25b589146e086fb9f306156b861@derote13de46.global.corp.sap>
	<0f29cf4c-43ec-04f9-ec2f-4d16b7f4c5c7@oracle.com>
	<6a7c7ee4ede342f58b0841f18d6c60f5@derote13de46.global.corp.sap>
	<67619df3-d9b0-c303-544a-0fa52d20fdde@oracle.com>
Message-ID: <9fbfd0ef22ba4487a6b749f8348e97cb@derote13de46.global.corp.sap>

Thanks, Daniel.

I pushed it: http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/e930c373aaa4


> -----Original Message-----
> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> Sent: Freitag, 3. Februar 2017 14:56
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: Ping: [JAXP] RFR: 8173602: TESTBUG:
> javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring
> 
> Hi Christoph,
> 
> No objections.
> 
> best regards,
> 
> -- daniel
> 
> On 03/02/17 13:01, Langer, Christoph wrote:
> > Hi Daniel,
> >
> > thanks for taking care of this.
> >
> > As for the pretty printing: That's not something which is explicitly tested here.
> I think it was me who introduced this for new tests I had added. I found it quite
> useful when analyzing test results. So now with the public APIs I guess this code
> is more independent and portable to other Java versions.
> >
> > I was only looking at JDK9 with that so far. My understanding was that
> pushing test fixes is still ok. Let me know if you have objections.
> >
> > Best regards
> > Christoph
> >
> >> -----Original Message-----
> >> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> >> Sent: Freitag, 3. Februar 2017 13:54
> >> To: Langer, Christoph <christoph.langer at sap.com>; core-libs-
> >> dev at openjdk.java.net
> >> Subject: Re: Ping: [JAXP] RFR: 8173602: TESTBUG:
> >> javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring
> >>
> >> Hi Christoph,
> >>
> >> I had a look at your patch, it seems OK.
> >> I didn't know that testng supported @Test
> >> annotations on methods of inner classes, but
> >> that looks useful.
> >>
> >> The patch is a bit difficult to review because the diff
> >> seems a bit lost sometime - but as far as I could see
> >> what was there before seems to be there after too :-)
> >>
> >> I noticed you changed the calls for pretty-printing
> >> the results - using public APIs now. Hopefully that
> >> doesn't matter to test (I mean that's hopefully not
> >> what the test was testing).
> >>
> >> I ran your new test locally on my machine, and sent it
> >> through our test system as well, and everything passed,
> >> so I guess that's a +1 for me.
> >>
> >> Will you push that to the new 10 forest or did you
> >> plan to push it in 9?
> >>
> >> best regards,
> >>
> >> -- daniel
> >>
> >> On 03/02/17 10:11, Langer, Christoph wrote:
> >>> Hi,
> >>>
> >>> Ping - anyone out there who could have a look at my JAXP test update?
> >>>
> >>> Thanks
> >>> Christoph
> >>>
> >>> From: Langer, Christoph
> >>> Sent: Montag, 30. Januar 2017 15:28
> >>> To: core-libs-dev at openjdk.java.net
> >>> Subject: [JAXP] RFR: 8173602: TESTBUG:
> >> javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring
> >>>
> >>> Hi,
> >>>
> >>> please review a test fix for
> >> javax/xml/jaxp/unittest/transform/TransformerTest.java:
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173602
> >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8173602.0/
> >>>
> >>> The main motivation for this refactoring is to remove the dependency to
> the
> >> JDK internal classes com.sun.org.apache.xml.internal.serialize.OutputFormat
> >> and com.sun.org.apache.xml.internal.serialize.XMLSerializer.
> >>>
> >>> Generally, TransformerTest.java contains several subtests which do similar
> >> things (test XALAN transformations) but the implementations differ. I
> created a
> >> common template with helper methods which all tests take advantage of
> now. I
> >> also introduced data sources to some tests to make them more readable
> and
> >> adaptable.
> >>>
> >>> Thanks
> >>> Christoph
> >>>
> >


From denis.kononenko at oracle.com  Mon Feb  6 10:27:38 2017
From: denis.kononenko at oracle.com (Denis Kononenko)
Date: Mon, 6 Feb 2017 02:27:38 -0800 (PST)
Subject: [9] RFR 8170113: jimage extract to readonly directory causes
	MissingResourceException
Message-ID: <f625459e-16db-4777-a8d0-e0b1b53174be@default>


Hi,

Could someone please review this very small fix.

The class JImageTask (src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java) has references to an info message by 'err.cannot.create.dir' key. Unfortunately the corresponding resource file (src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties) doesn't contain this key. This results in long not user friendly stacktraces in output when jimage cannot create a directory. The fix is very small, I added the missing definition into the resource file.

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170113
WEBREV: http://cr.openjdk.java.net/~dkononenko/8170113/webrev.00

Thank you,
Denis.

From Alan.Bateman at oracle.com  Mon Feb  6 10:37:29 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 6 Feb 2017 10:37:29 +0000
Subject: [9] RFR 8170113: jimage extract to readonly directory causes
	MissingResourceException
In-Reply-To: <f625459e-16db-4777-a8d0-e0b1b53174be@default>
References: <f625459e-16db-4777-a8d0-e0b1b53174be@default>
Message-ID: <98894b1b-5e2f-81a4-a7ed-de217560ec94@oracle.com>

(cc'ing jigsaw-dev as that is where the jimage tool is maintained).

On 06/02/2017 10:27, Denis Kononenko wrote:
> Hi,
>
> Could someone please review this very small fix.
>
> The class JImageTask (src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java) has references to an info message by 'err.cannot.create.dir' key. Unfortunately the corresponding resource file (src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties) doesn't contain this key. This results in long not user friendly stacktraces in output when jimage cannot create a directory. The fix is very small, I added the missing definition into the resource file.
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170113
> WEBREV: http://cr.openjdk.java.net/~dkononenko/8170113/webrev.00
>
This looks okay as a short term fix but I think that extract need to 
be-implemented to use the new file system API so that the reasons why 
the directory can be printed too. Also there is an anomaly in errors 
related to the directory result in an error message whereas any errors 
extracting to the directory lead to an exception.

-Alan

From Alan.Bateman at oracle.com  Mon Feb  6 10:40:01 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 6 Feb 2017 10:40:01 +0000
Subject: RFR: 8173943: Change error reporting of LauncherHelper to include
	actual Error class name
In-Reply-To: <05728762-b66e-47bc-a43d-e05533e01c76@default>
References: <32e0a2e8-34a8-4bc2-8fbf-db1107995b33@default>
	<c9457b5a-bc69-82e8-e3a4-16e487eb2527@oracle.com>
	<05728762-b66e-47bc-a43d-e05533e01c76@default>
Message-ID: <05a5ffdb-21f5-d944-3c0c-342a4ef408ba@oracle.com>



On 06/02/2017 03:22, Ramanand Patil wrote:
> :
>
> 2. After Fixing JDK-8167063:
> Error: Unable to load main class pkgB.ClassB from module mod.b
> superclass access check failed: class pkgB.ClassB (in module mod.b) cannot access class pkgA.ClassA (in module mod.a) because module mod.a does not export pkgA to module mod.b
>
> [Here the complete stacktrace was removed to be consistent with the error handling mechanism of LauncherHelper, where only the important error message is printed and the complete stack trace is shown in diagnostic ("-Xdiag") mode.]
>
> 3. After fixing the current Bug( JDK-8173943 ):
> Error: Unable to load main class pkgB.ClassB from module mod.b
> java.lang.IllegalAccessError: superclass access check failed: class pkgB.ClassB (in module mod.b) cannot access class pkgA.ClassA (in module mod.a) because module mod.a does not export pkgA to module mod.b
>
This looks okay, I hadn't noticed that the error type has been lost with 
the changes in JDK-8167063.

-Alan

From jay.sridhar at gmail.com  Mon Feb  6 10:57:24 2017
From: jay.sridhar at gmail.com (Jay)
Date: Mon, 6 Feb 2017 16:27:24 +0530
Subject: ByteBuffer to CharBuffer
Message-ID: <CAMU_jUPGFY4smLzcjDs5h1C31tygFcVF9iTiGO+-+0--+1=E7w@mail.gmail.com>

java.nio.ByteBuffer provides a method asCharBuffer() which returns a
"view" of the ByteBuffer as a character buffer. It however does not
take any arguments. And there is no mention in the Javadocs as to how
it converts from bytes to chars.

1. There should be a method ByteBuffer.asCharBuffer(CharSet) and/or
ByteBuffer.asCharBuffer(String charSet) which allows the user to
explicitly specify the character set to be used for conversion.

2. The method ByteBuffer.asCharBuffer() should mention that this
method uses the platform default charset for bytes-to-chars
conversion.

I can provide a patch with these two changes. What do you guys think?
-- 
Regards
Jay

From pavel.rappo at oracle.com  Mon Feb  6 11:24:17 2017
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 6 Feb 2017 11:24:17 +0000
Subject: ByteBuffer to CharBuffer
In-Reply-To: <CAMU_jUPGFY4smLzcjDs5h1C31tygFcVF9iTiGO+-+0--+1=E7w@mail.gmail.com>
References: <CAMU_jUPGFY4smLzcjDs5h1C31tygFcVF9iTiGO+-+0--+1=E7w@mail.gmail.com>
Message-ID: <C727D0BB-DA28-4102-927C-B2429B4EE92A@oracle.com>

Hi Jay,

1. I don't know if you've forgotten to attach the patch you mentioned or it has
been stripped by the mail list. In any case, if it's not too big, please inline
it in your next email.

2. A more appropriate place for this discussion would be another list: 

    nio-dev at openjdk dot java dot net
    
Thanks,
-Pavel

> On 6 Feb 2017, at 10:57, Jay <jay.sridhar at gmail.com> wrote:
> 
> java.nio.ByteBuffer provides a method asCharBuffer() which returns a
> "view" of the ByteBuffer as a character buffer. It however does not
> take any arguments. And there is no mention in the Javadocs as to how
> it converts from bytes to chars.
> 
> 1. There should be a method ByteBuffer.asCharBuffer(CharSet) and/or
> ByteBuffer.asCharBuffer(String charSet) which allows the user to
> explicitly specify the character set to be used for conversion.
> 
> 2. The method ByteBuffer.asCharBuffer() should mention that this
> method uses the platform default charset for bytes-to-chars
> conversion.
> 
> I can provide a patch with these two changes. What do you guys think?
> -- 
> Regards
> Jay


From me at yawk.at  Mon Feb  6 13:35:05 2017
From: me at yawk.at (Jonas Konrad)
Date: Mon, 6 Feb 2017 14:35:05 +0100
Subject: ByteBuffer to CharBuffer
In-Reply-To: <CAMU_jUPGFY4smLzcjDs5h1C31tygFcVF9iTiGO+-+0--+1=E7w@mail.gmail.com>
References: <CAMU_jUPGFY4smLzcjDs5h1C31tygFcVF9iTiGO+-+0--+1=E7w@mail.gmail.com>
Message-ID: <33772099-d46d-9987-2b81-628e35be700d@yawk.at>

 From what I can tell, asCharBuffer behaves exactly like the other 
as*Buffer methods, meaning every char in the CharBuffer is represented 
by two bytes in the original ByteBuffer (big- or little-endian depending 
on ByteOrder of the ByteBuffer). This means bb.asCharBuffer().get() 
behaves like bb.getChar(). asCharBuffer does *not* decode using any 
Charset (not the platform charset either), it just interprets the bytes 
as 16-bit unsigned integers which happen to be the char type in java. I 
guess this technically counts as UTF-16? It doesn't do validity checks 
either, though.

If you wish to decode a ByteBuffer, you can use the CharsetDecoder API 
directly. I do not believe an asCharBuffer-like method which decodes on 
the fly is possible generally for all charsets, because decoding is not 
necessarily possible in a random-access buffer due to dynamic-width 
encoding.

- Jonas Konrad

On 02/06/2017 11:57 AM, Jay wrote:
> java.nio.ByteBuffer provides a method asCharBuffer() which returns a
> "view" of the ByteBuffer as a character buffer. It however does not
> take any arguments. And there is no mention in the Javadocs as to how
> it converts from bytes to chars.
>
> 1. There should be a method ByteBuffer.asCharBuffer(CharSet) and/or
> ByteBuffer.asCharBuffer(String charSet) which allows the user to
> explicitly specify the character set to be used for conversion.
>
> 2. The method ByteBuffer.asCharBuffer() should mention that this
> method uses the platform default charset for bytes-to-chars
> conversion.
>
> I can provide a patch with these two changes. What do you guys think?
>

From jan.lahoda at oracle.com  Mon Feb  6 15:53:58 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 6 Feb 2017 16:53:58 +0100
Subject: RFR JDK-8173777: Merge javac -Xmodule into javac--patch-module
Message-ID: <58989C16.80404@oracle.com>

Hi,

I'd like to ask for a review of a patch that merges the -Xmodule: 
functionality into --patch-module. After this patch, the input source 
files are matched against modules patched with --patch-module, and are 
compiled as-if they were part of the module they are patching. (In the 
multi-module mode, patches for more than one module can be compiled, in 
the single-module mode, patches for only one module can be compiled.)

Removal of the -Xmodule: option will need adjustments in several 
repositories, as tests in multiple repositories are currently using 
-Xmodule:, and also jtreg is using the option. The current patch hence 
preserves the existing -Xmodule: functionality, although the option is 
hidden and no longer announced in help. I think it would be good to push 
the javac/langtools change proposed below, and then continue with other 
repositories.

The langtools patch is here:
http://cr.openjdk.java.net/~jlahoda/8173777/langtools.00/

(note it also contains changes to jshell and javadoc).

Proposed jdk repository changes are here:
http://cr.openjdk.java.net/~jlahoda/8173777/jdk.00/

How does this look?

Any feedback is welcome.

Thanks,
      Jan

From kumar.x.srinivasan at oracle.com  Mon Feb  6 16:23:41 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 06 Feb 2017 08:23:41 -0800
Subject: RFR: 8173943: Change error reporting of LauncherHelper to include
	actual Error class name
In-Reply-To: <32e0a2e8-34a8-4bc2-8fbf-db1107995b33@default>
References: <32e0a2e8-34a8-4bc2-8fbf-db1107995b33@default>
Message-ID: <5898A30D.9010908@oracle.com>

+1

Kumar

On 2/5/2017 11:14 AM, Ramanand Patil wrote:
> Hi all,
> Please review the following trivial bug fix:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8173943
> Webrev: http://cr.openjdk.java.net/~rpatil/8173943/webrev.00/
>
> LinkageError message added by - https://bugs.openjdk.java.net/browse/JDK-8167063 is updated to include the Error Class name.
>
> Regards,
> Ramanand.
>


From jan.lahoda at oracle.com  Mon Feb  6 18:41:49 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 6 Feb 2017 19:41:49 +0100
Subject: RFR JDK-8173777: Merge javac -Xmodule into javac--patch-module
In-Reply-To: <58989C16.80404@oracle.com>
References: <58989C16.80404@oracle.com>
Message-ID: <5898C36D.30902@oracle.com>

I've updated the jdk repository webrev to wrap long lines:
http://cr.openjdk.java.net/~jlahoda/8173777/jdk.01/

Jan

On 6.2.2017 16:53, Jan Lahoda wrote:
> Hi,
>
> I'd like to ask for a review of a patch that merges the -Xmodule:
> functionality into --patch-module. After this patch, the input source
> files are matched against modules patched with --patch-module, and are
> compiled as-if they were part of the module they are patching. (In the
> multi-module mode, patches for more than one module can be compiled, in
> the single-module mode, patches for only one module can be compiled.)
>
> Removal of the -Xmodule: option will need adjustments in several
> repositories, as tests in multiple repositories are currently using
> -Xmodule:, and also jtreg is using the option. The current patch hence
> preserves the existing -Xmodule: functionality, although the option is
> hidden and no longer announced in help. I think it would be good to push
> the javac/langtools change proposed below, and then continue with other
> repositories.
>
> The langtools patch is here:
> http://cr.openjdk.java.net/~jlahoda/8173777/langtools.00/
>
> (note it also contains changes to jshell and javadoc).
>
> Proposed jdk repository changes are here:
> http://cr.openjdk.java.net/~jlahoda/8173777/jdk.00/
>
> How does this look?
>
> Any feedback is welcome.
>
> Thanks,
>       Jan

From lance.andersen at oracle.com  Mon Feb  6 18:55:04 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 6 Feb 2017 13:55:04 -0500
Subject: RFR 8169313: SecurityException,
	java.xml.ws not granted NetPermission("getProxySelector")
References: <JIRA.4906150.1478515908000.364582.1486389300153@Atlassian.JIRA>
Message-ID: <3A7E1806-7305-42BB-85A2-197D9BCA2C86@oracle.com>

Hi all,

Attached is the change to address 8169313

????
hg diff
diff -r 19aaaf6ee13e src/java.base/share/lib/security/default.policy
--- a/src/java.base/share/lib/security/default.policy	Sat Feb 04 14:04:28 2017 -0500
+++ b/src/java.base/share/lib/security/default.policy	Mon Feb 06 12:07:39 2017 -0500
@@ -102,6 +102,8 @@
 };
 
 grant codeBase "jrt:/java.xml.ws" {
+    permission java.net.NetPermission
+                   "getProxySelector";
     permission java.lang.RuntimePermission
                    "accessClassInPackage.com.sun.org.apache.xml.internal.resolver";
     permission java.lang.RuntimePermission
ljanders-mac:jdk ljanders$ 

-----------


 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From aleksej.efimov at oracle.com  Mon Feb  6 20:33:54 2017
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Mon, 6 Feb 2017 23:33:54 +0300
Subject: RFR 8169313: SecurityException, java.xml.ws not granted
	NetPermission("getProxySelector")
In-Reply-To: <3A7E1806-7305-42BB-85A2-197D9BCA2C86@oracle.com>
References: <JIRA.4906150.1478515908000.364582.1486389300153@Atlassian.JIRA>
	<3A7E1806-7305-42BB-85A2-197D9BCA2C86@oracle.com>
Message-ID: <8b33ea73-8363-5164-3eeb-be418ac42f4e@oracle.com>

Hi Lance,

Looks good to me (not a reviewer). It's good to have it as default policy.

Best Regards,
Aleksej

On 06/02/17 21:55, Lance Andersen wrote:
> Hi all,
>
> Attached is the change to address 8169313
>
> ????
> hg diff
> diff -r 19aaaf6ee13e src/java.base/share/lib/security/default.policy
> --- a/src/java.base/share/lib/security/default.policy	Sat Feb 04 14:04:28 2017 -0500
> +++ b/src/java.base/share/lib/security/default.policy	Mon Feb 06 12:07:39 2017 -0500
> @@ -102,6 +102,8 @@
>   };
>   
>   grant codeBase "jrt:/java.xml.ws" {
> +    permission java.net.NetPermission
> +                   "getProxySelector";
>       permission java.lang.RuntimePermission
>                      "accessClassInPackage.com.sun.org.apache.xml.internal.resolver";
>       permission java.lang.RuntimePermission
> ljanders-mac:jdk ljanders$
>
> -----------
>
>
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>
>
>
>


From mandy.chung at oracle.com  Mon Feb  6 20:34:37 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 6 Feb 2017 12:34:37 -0800
Subject: RFR 8169313: SecurityException,
	java.xml.ws not granted NetPermission("getProxySelector")
In-Reply-To: <3A7E1806-7305-42BB-85A2-197D9BCA2C86@oracle.com>
References: <JIRA.4906150.1478515908000.364582.1486389300153@Atlassian.JIRA>
	<3A7E1806-7305-42BB-85A2-197D9BCA2C86@oracle.com>
Message-ID: <BE20AFD4-9917-4927-924D-46B55C310E4C@oracle.com>

Looks okay.  We would need more tests to exercise the code paths triggering permission checks and it?d be appropriate to add in the test suites of the upstream projects.

Mandy

> On Feb 6, 2017, at 10:55 AM, Lance Andersen <lance.andersen at oracle.com> wrote:
> 
> Hi all,
> 
> Attached is the change to address 8169313
> 
> ????
> hg diff
> diff -r 19aaaf6ee13e src/java.base/share/lib/security/default.policy
> --- a/src/java.base/share/lib/security/default.policy	Sat Feb 04 14:04:28 2017 -0500
> +++ b/src/java.base/share/lib/security/default.policy	Mon Feb 06 12:07:39 2017 -0500
> @@ -102,6 +102,8 @@
> };
> 
> grant codeBase "jrt:/java.xml.ws" {
> +    permission java.net.NetPermission
> +                   "getProxySelector";
>     permission java.lang.RuntimePermission
>                    "accessClassInPackage.com.sun.org.apache.xml.internal.resolver";
>     permission java.lang.RuntimePermission
> ljanders-mac:jdk ljanders$ 
> 
> -----------
> 
> 
> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>
> 
> 
> 


From Alan.Bateman at oracle.com  Mon Feb  6 20:42:50 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 6 Feb 2017 20:42:50 +0000
Subject: RFR JDK-8173777: Merge javac -Xmodule into javac--patch-module
In-Reply-To: <5898C36D.30902@oracle.com>
References: <58989C16.80404@oracle.com> <5898C36D.30902@oracle.com>
Message-ID: <206f4364-1d18-fed8-840a-f655b235b943@oracle.com>



On 06/02/2017 18:41, Jan Lahoda wrote:
> I've updated the jdk repository webrev to wrap long lines:
> http://cr.openjdk.java.net/~jlahoda/8173777/jdk.01/
>
> Jan
This looks okay to me.

-Alan


From mark.sheppard at oracle.com  Mon Feb  6 21:20:16 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Mon, 6 Feb 2017 21:20:16 +0000
Subject: RFR: JDK-8049375 - Extend how the org.omg.CORBA.ORB handles the
	search for orb.properties
Message-ID: <82e9646a-a052-8707-54ae-fa1dd57ab9c1@oracle.com>

Hi,
    please oblige and review the following changes to the corba component

http://cr.openjdk.java.net/~msheppar/8049375/corba/webrev/
http://cr.openjdk.java.net/~msheppar/8049375/test/webrev/

which address the issue

https://bugs.openjdk.java.net/browse/JDK-8049375

the JDK9 rt image has changed structure to include a conf directory.
This will hold a component's properties file, if any, and as such the
corba component has amended the locating of the properties file with
a search in the ${java.home}/conf directory.

regards
Mark

From lance.andersen at oracle.com  Mon Feb  6 23:47:01 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 6 Feb 2017 18:47:01 -0500
Subject: RFR: JDK-8049375 - Extend how the org.omg.CORBA.ORB handles the
	search for orb.properties
In-Reply-To: <82e9646a-a052-8707-54ae-fa1dd57ab9c1@oracle.com>
References: <82e9646a-a052-8707-54ae-fa1dd57ab9c1@oracle.com>
Message-ID: <57313EEE-0E1E-44CB-A0DB-A095D0731768@oracle.com>

Hi Mark,

The change and test looks reasonable.  I might consider removing the ?TODO? comments from your test cases prior to pushing.

Maybe it is not needed, but should the test also be run with a SecurityManager or did you feel that was not needed?

HTH

Best
Lance
> On Feb 6, 2017, at 4:20 PM, Mark Sheppard <mark.sheppard at oracle.com> wrote:
> 
> Hi,
>   please oblige and review the following changes to the corba component
> 
> http://cr.openjdk.java.net/~msheppar/8049375/corba/webrev/
> http://cr.openjdk.java.net/~msheppar/8049375/test/webrev/
> 
> which address the issue
> 
> https://bugs.openjdk.java.net/browse/JDK-8049375
> 
> the JDK9 rt image has changed structure to include a conf directory.
> This will hold a component's properties file, if any, and as such the
> corba component has amended the locating of the properties file with
> a search in the ${java.home}/conf directory.
> 
> regards
> Mark

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From brian.burkhalter at oracle.com  Tue Feb  7 00:47:27 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 6 Feb 2017 16:47:27 -0800
Subject: ByteBuffer to CharBuffer
In-Reply-To: <33772099-d46d-9987-2b81-628e35be700d@yawk.at>
References: <CAMU_jUPGFY4smLzcjDs5h1C31tygFcVF9iTiGO+-+0--+1=E7w@mail.gmail.com>
	<33772099-d46d-9987-2b81-628e35be700d@yawk.at>
Message-ID: <EF5930B5-174D-4568-8BFB-F0BCD1CB4BBD@oracle.com>

Looping in nio-dev which, as Pavel noted, is the apt forum for this topic.

Jonas?s response is correct. The concept of ?view buffer? is specified by [1]. In particular the statement

"A view buffer is simply another buffer whose content is backed by the byte buffer."

at least to my interpretation signifies that the content of the view buffer is conceptually mapped bit-by-bit to / from the corresponding bits in the byte buffer. The details are of course subject to byte order and the like, and the interpretation of the bits for floating point values is according to IEEE 754. There is however no encoding or decoding applied.

- Brian

[1] http://download.java.net/java/jdk9/docs/api/java/nio/ByteBuffer.html#views

On Feb 6, 2017, at 5:35 AM, Jonas Konrad <me at yawk.at> wrote:

> From what I can tell, asCharBuffer behaves exactly like the other as*Buffer methods, meaning every char in the CharBuffer is represented by two bytes in the original ByteBuffer (big- or little-endian depending on ByteOrder of the ByteBuffer). This means bb.asCharBuffer().get() behaves like bb.getChar(). asCharBuffer does *not* decode using any Charset (not the platform charset either), it just interprets the bytes as 16-bit unsigned integers which happen to be the char type in java. I guess this technically counts as UTF-16? It doesn't do validity checks either, though.
> 
> If you wish to decode a ByteBuffer, you can use the CharsetDecoder API directly. I do not believe an asCharBuffer-like method which decodes on the fly is possible generally for all charsets, because decoding is not necessarily possible in a random-access buffer due to dynamic-width encoding.
> 
> - Jonas Konrad
> 
> On 02/06/2017 11:57 AM, Jay wrote:
>> java.nio.ByteBuffer provides a method asCharBuffer() which returns a
>> "view" of the ByteBuffer as a character buffer. It however does not
>> take any arguments. And there is no mention in the Javadocs as to how
>> it converts from bytes to chars.
>> 
>> 1. There should be a method ByteBuffer.asCharBuffer(CharSet) and/or
>> ByteBuffer.asCharBuffer(String charSet) which allows the user to
>> explicitly specify the character set to be used for conversion.
>> 
>> 2. The method ByteBuffer.asCharBuffer() should mention that this
>> method uses the platform default charset for bytes-to-chars
>> conversion.
>> 
>> I can provide a patch with these two changes. What do you guys think?
>> 


From Alan.Bateman at oracle.com  Tue Feb  7 07:04:49 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 7 Feb 2017 07:04:49 +0000
Subject: RFR: JDK-8049375 - Extend how the org.omg.CORBA.ORB handles the
	search for orb.properties
In-Reply-To: <82e9646a-a052-8707-54ae-fa1dd57ab9c1@oracle.com>
References: <82e9646a-a052-8707-54ae-fa1dd57ab9c1@oracle.com>
Message-ID: <4b911bfd-3e5a-31e5-251c-3d638b85f6ef@oracle.com>

On 06/02/2017 21:20, Mark Sheppard wrote:

> Hi,
>    please oblige and review the following changes to the corba component
>
> http://cr.openjdk.java.net/~msheppar/8049375/corba/webrev/
> http://cr.openjdk.java.net/~msheppar/8049375/test/webrev/
>
> which address the issue
>
> https://bugs.openjdk.java.net/browse/JDK-8049375
The addition to the @implNote looks okay but at L114 then I would hope 
there is enough wriggle room to change it to:

"check in the orb.properties file located in the run-time image (if any)"

and then follow-up with a bug to OMG.

-Alan

From jay.sridhar at gmail.com  Tue Feb  7 08:03:29 2017
From: jay.sridhar at gmail.com (Jay)
Date: Tue, 7 Feb 2017 13:33:29 +0530
Subject: ByteBuffer to CharBuffer
In-Reply-To: <EF5930B5-174D-4568-8BFB-F0BCD1CB4BBD@oracle.com>
References: <CAMU_jUPGFY4smLzcjDs5h1C31tygFcVF9iTiGO+-+0--+1=E7w@mail.gmail.com>
	<33772099-d46d-9987-2b81-628e35be700d@yawk.at>
	<EF5930B5-174D-4568-8BFB-F0BCD1CB4BBD@oracle.com>
Message-ID: <CAMU_jUPPrX9_-etGT8FLOZhHkJ=D=U7zQ1m3TdsGDQR4qB0JCg@mail.gmail.com>

As a view of the underlying contents, I guess it is correct that no
encoding is applied to coerce a ByteBuffer into a CharBuffer. Maybe
the javadoc for ByteBuffer.asCharBuffer() can emphasize this point. It
is a bit confusing that most places in the JDK where bytes are
converted to chars, a Charset is usually involved whereas here we have
a low level operation - coercing bytes into chars.


On Tue, Feb 7, 2017 at 6:17 AM, Brian Burkhalter
<brian.burkhalter at oracle.com> wrote:
> Looping in nio-dev which, as Pavel noted, is the apt forum for this topic.
>
> Jonas?s response is correct. The concept of ?view buffer? is specified by
> [1]. In particular the statement
>
> "A view buffer is simply another buffer whose content is backed by the byte
> buffer."
>
> at least to my interpretation signifies that the content of the view buffer
> is conceptually mapped bit-by-bit to / from the corresponding bits in the
> byte buffer. The details are of course subject to byte order and the like,
> and the interpretation of the bits for floating point values is according to
> IEEE 754. There is however no encoding or decoding applied.
>
> - Brian
>
> [1]
> http://download.java.net/java/jdk9/docs/api/java/nio/ByteBuffer.html#views
>
> On Feb 6, 2017, at 5:35 AM, Jonas Konrad <me at yawk.at> wrote:
>
> From what I can tell, asCharBuffer behaves exactly like the other as*Buffer
> methods, meaning every char in the CharBuffer is represented by two bytes in
> the original ByteBuffer (big- or little-endian depending on ByteOrder of the
> ByteBuffer). This means bb.asCharBuffer().get() behaves like bb.getChar().
> asCharBuffer does *not* decode using any Charset (not the platform charset
> either), it just interprets the bytes as 16-bit unsigned integers which
> happen to be the char type in java. I guess this technically counts as
> UTF-16? It doesn't do validity checks either, though.
>
> If you wish to decode a ByteBuffer, you can use the CharsetDecoder API
> directly. I do not believe an asCharBuffer-like method which decodes on the
> fly is possible generally for all charsets, because decoding is not
> necessarily possible in a random-access buffer due to dynamic-width
> encoding.
>
> - Jonas Konrad
>
> On 02/06/2017 11:57 AM, Jay wrote:
>
> java.nio.ByteBuffer provides a method asCharBuffer() which returns a
> "view" of the ByteBuffer as a character buffer. It however does not
> take any arguments. And there is no mention in the Javadocs as to how
> it converts from bytes to chars.
>
> 1. There should be a method ByteBuffer.asCharBuffer(CharSet) and/or
> ByteBuffer.asCharBuffer(String charSet) which allows the user to
> explicitly specify the character set to be used for conversion.
>
> 2. The method ByteBuffer.asCharBuffer() should mention that this
> method uses the platform default charset for bytes-to-chars
> conversion.
>
> I can provide a patch with these two changes. What do you guys think?
>
>



-- 
Regards
Jay

From mark.sheppard at oracle.com  Tue Feb  7 10:50:57 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Tue, 7 Feb 2017 10:50:57 +0000
Subject: RFR: JDK-8049375 - Extend how the org.omg.CORBA.ORB handles the
	search for orb.properties
In-Reply-To: <4b911bfd-3e5a-31e5-251c-3d638b85f6ef@oracle.com>
References: <82e9646a-a052-8707-54ae-fa1dd57ab9c1@oracle.com>
	<4b911bfd-3e5a-31e5-251c-3d638b85f6ef@oracle.com>
Message-ID: <e6011fbb-f176-09c2-2f0b-3ed4c02aa798@oracle.com>


thanks Alan .... yes, good spot,  I lost the L114 change somewhere 
between the CCC and my development environment!
I'll add that in

regards
Mark

On 07/02/2017 07:04, Alan Bateman wrote:
> On 06/02/2017 21:20, Mark Sheppard wrote:
>
>> Hi,
>>    please oblige and review the following changes to the corba component
>>
>> http://cr.openjdk.java.net/~msheppar/8049375/corba/webrev/
>> http://cr.openjdk.java.net/~msheppar/8049375/test/webrev/
>>
>> which address the issue
>>
>> https://bugs.openjdk.java.net/browse/JDK-8049375
> The addition to the @implNote looks okay but at L114 then I would hope 
> there is enough wriggle room to change it to:
>
> "check in the orb.properties file located in the run-time image (if any)"
>
> and then follow-up with a bug to OMG.
>
> -Alan


From mark.sheppard at oracle.com  Tue Feb  7 12:12:20 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Tue, 7 Feb 2017 12:12:20 +0000
Subject: RFR: JDK-8049375 - Extend how the org.omg.CORBA.ORB handles the
	search for orb.properties
In-Reply-To: <57313EEE-0E1E-44CB-A0DB-A095D0731768@oracle.com>
References: <82e9646a-a052-8707-54ae-fa1dd57ab9c1@oracle.com>
	<57313EEE-0E1E-44CB-A0DB-A095D0731768@oracle.com>
Message-ID: <d499987d-9280-fecc-1356-52bcf45333f5@oracle.com>


thanks Lance for the feedback

TODO auto-generated in eclipse, I'll delete them

yes, for completeness it would do no harm to add a test run with 
Security Manager

regards
Mark

On 06/02/2017 23:47, Lance Andersen wrote:
> Hi Mark,
>
> The change and test looks reasonable.  I might consider removing the 
> ?TODO? comments from your test cases prior to pushing.
>
> Maybe it is not needed, but should the test also be run with a 
> SecurityManager or did you feel that was not needed?
>
> HTH
>
> Best
> Lance
>> On Feb 6, 2017, at 4:20 PM, Mark Sheppard <mark.sheppard at oracle.com 
>> <mailto:mark.sheppard at oracle.com>> wrote:
>>
>> Hi,
>>   please oblige and review the following changes to the corba component
>>
>> http://cr.openjdk.java.net/~msheppar/8049375/corba/webrev/ 
>> <http://cr.openjdk.java.net/%7Emsheppar/8049375/corba/webrev/>
>> http://cr.openjdk.java.net/~msheppar/8049375/test/webrev/
>>
>> which address the issue
>>
>> https://bugs.openjdk.java.net/browse/JDK-8049375
>>
>> the JDK9 rt image has changed structure to include a conf directory.
>> This will hold a component's properties file, if any, and as such the
>> corba component has amended the locating of the properties file with
>> a search in the ${java.home}/conf directory.
>>
>> regards
>> Mark
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>
>
>
>


From daniel.fuchs at oracle.com  Tue Feb  7 13:10:34 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 7 Feb 2017 13:10:34 +0000
Subject: RFR: 8173898: StackWalker.walk throws InternalError if called
	from a constructor invoked through reflection.
In-Reply-To: <FF6E35EA-7653-4AD9-BB6B-D1606D21FA75@oracle.com>
References: <951dc6d5-8fce-6af7-eda6-bcacfdb60b52@oracle.com>
	<FF6E35EA-7653-4AD9-BB6B-D1606D21FA75@oracle.com>
Message-ID: <2e645742-5ffb-4fb9-c6f1-710585053de7@oracle.com>

Hi Mandy,

On 06/02/17 00:16, Mandy Chung wrote:
> Hi Daniel,
>
> Thanks for the patch and uncover that Constructor::newInstance is not covered by SHOW_REFLECT_FRAMES.
>
> The change looks okay.  The javadoc of SHOW_REFLECT_FRAMES can be clarified to include Constructor::newInstance.  As for the test, can you separate this in a new test to test showing and hiding reflecton frames and also getCallerClass?

Please find below a new webrev that incorporates your feedback.
I have added a new test, and also tweaked the API documentation
in StackWalker.java as you suggested:
http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.03/

For convenience here is the corresponding specdiff for the
API documentation tweaks in StackWalker.java:

- StackWalker.Option.SHOW_REFLECT_FRAMES:
http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.03/StackWalker.Option-report.html

- StackWalker::getCallerClass:
http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.03/StackWalker-report.html

best regards,

-- daniel


>
> Mandy
>
>> On Feb 3, 2017, at 11:51 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> Hi,
>>
>> Please find below a simple fix for:
>>
>> 8173898: StackWalker.walk throws InternalError if called
>>         from a constructor invoked through reflection.
>> https://bugs.openjdk.java.net/browse/JDK-8173898
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.00/
>>
>> best regards,
>>
>> -- daniel
>


From jan.lahoda at oracle.com  Tue Feb  7 18:11:16 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 7 Feb 2017 19:11:16 +0100
Subject: RFR JDK-8173777: Merge javac -Xmodule into javac--patch-module
In-Reply-To: <206f4364-1d18-fed8-840a-f655b235b943@oracle.com>
References: <58989C16.80404@oracle.com> <5898C36D.30902@oracle.com>
	<206f4364-1d18-fed8-840a-f655b235b943@oracle.com>
Message-ID: <589A0DC4.5020409@oracle.com>

Hi,

Thanks.

I did two small updates to the patches:
-for langtools repository, I added unwrapping to 
ClientCodeWrapper.WrappedJavaFileManager.getLocationForModule - the 
incoming JavaFileObject is unwrapped, so that we don't pass our wrappers 
to the client's code. Direct link:
http://cr.openjdk.java.net/~jlahoda/8173777/langtools.01/src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java.udiff.html

-for jdk repository, I fixed the:
test/javax/xml/jaxp/common/8035437/run.sh
to use a platform specific path separator. This is based on code from 
jdk/test/java/lang/instrument/appendToClassLoaderSearch/CommonSetup.sh
Direct link:
http://cr.openjdk.java.net/~jlahoda/8173777/jdk.02/test/javax/xml/jaxp/common/8035437/run.sh.udiff.html

(Sorry that I missed this before.)

Updated webrevs:
-langtools repository:
http://cr.openjdk.java.net/~jlahoda/8173777/langtools.01/
-jdk repository:
http://cr.openjdk.java.net/~jlahoda/8173777/jdk.02/

Thanks,
    Jan

On 6.2.2017 21:42, Alan Bateman wrote:
>
>
> On 06/02/2017 18:41, Jan Lahoda wrote:
>> I've updated the jdk repository webrev to wrap long lines:
>> http://cr.openjdk.java.net/~jlahoda/8173777/jdk.01/
>>
>> Jan
> This looks okay to me.
>
> -Alan
>

From lance.andersen at oracle.com  Tue Feb  7 19:32:52 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 7 Feb 2017 14:32:52 -0500
Subject: 8057795:  Update of the mimestypes.default for JAF
Message-ID: <5D4E765A-2D03-40D1-8188-B36E868082B4@oracle.com>

Hi all,

Attached is the diff to update the  mimetypes.default for JAF.  The standalone standalone JAF was updated with support for .png files some time ago.


???????
hg diff
diff -r 7c829eba7814 src/java.activation/share/classes/META-INF/mimetypes.default
--- a/src/java.activation/share/classes/META-INF/mimetypes.default	Sat Feb 04 14:03:15 2017 -0500
+++ b/src/java.activation/share/classes/META-INF/mimetypes.default	Tue Feb 07 14:23:23 2017 -0500
@@ -7,6 +7,7 @@
 image/ief		ief
 image/jpeg		jpeg jpg jpe JPG
 image/tiff		tiff tif
+image/png		png PNG
 image/x-xwindowdump	xwd
 application/postscript	ai eps ps
 application/rtf		rtf
ljanders-mac:jaxws ljanders$ 
??????????

Best,
Lance
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From brian.burkhalter at oracle.com  Tue Feb  7 19:56:17 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 7 Feb 2017 11:56:17 -0800
Subject: 8057795:  Update of the mimestypes.default for JAF
In-Reply-To: <5D4E765A-2D03-40D1-8188-B36E868082B4@oracle.com>
References: <5D4E765A-2D03-40D1-8188-B36E868082B4@oracle.com>
Message-ID: <1B123407-C890-4C25-A6BB-3E8E900DC33B@oracle.com>

Hi Lance,

+1

Good thing especially given that PNG is now two decades old. ;-)

Are there other now-common media types which should also be added, e.g., anything that QuickTime, WMP, VideoLAN, iTunes, Preview, etc. would typically handle? See, e.g., https://bugs.openjdk.java.net/browse/JDK-8162745 and others ...

Thanks,

Brian

On Feb 7, 2017, at 11:32 AM, Lance Andersen <lance.andersen at oracle.com> wrote:

> Attached is the diff to update the  mimetypes.default for JAF.  The standalone standalone JAF was updated with support for .png files some time ago.
> 
> 
> ???????
> hg diff
> diff -r 7c829eba7814 src/java.activation/share/classes/META-INF/mimetypes.default
> --- a/src/java.activation/share/classes/META-INF/mimetypes.default	Sat Feb 04 14:03:15 2017 -0500
> +++ b/src/java.activation/share/classes/META-INF/mimetypes.default	Tue Feb 07 14:23:23 2017 -0500
> @@ -7,6 +7,7 @@
> image/ief		ief
> image/jpeg		jpeg jpg jpe JPG
> image/tiff		tiff tif
> +image/png		png PNG
> image/x-xwindowdump	xwd
> application/postscript	ai eps ps
> application/rtf		rtf
> ljanders-mac:jaxws ljanders$ 
> ??????????


From lance.andersen at oracle.com  Tue Feb  7 20:01:12 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 7 Feb 2017 15:01:12 -0500
Subject: 8057795:  Update of the mimestypes.default for JAF
In-Reply-To: <1B123407-C890-4C25-A6BB-3E8E900DC33B@oracle.com>
References: <5D4E765A-2D03-40D1-8188-B36E868082B4@oracle.com>
	<1B123407-C890-4C25-A6BB-3E8E900DC33B@oracle.com>
Message-ID: <E31001A8-4540-448F-B360-B6E78252BCC4@oracle.com>

Hi Brian,

Thank you for the quick review.

I will defer to Bill on whether anything else should be added as it should be included in the standalone JAF RI as well.

Bill, let us know.  :-)

Best
Lance
> On Feb 7, 2017, at 2:56 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> Hi Lance,
> 
> +1
> 
> Good thing especially given that PNG is now two decades old. ;-)
> 
> Are there other now-common media types which should also be added, e.g., anything that QuickTime, WMP, VideoLAN, iTunes, Preview, etc. would typically handle? See, e.g., https://bugs.openjdk.java.net/browse/JDK-8162745 <https://bugs.openjdk.java.net/browse/JDK-8162745> and others ...
> 
> Thanks,
> 
> Brian
> 
> On Feb 7, 2017, at 11:32 AM, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
> 
>> Attached is the diff to update the  mimetypes.default for JAF.  The standalone standalone JAF was updated with support for .png files some time ago.
>> 
>> 
>> ???????
>> hg diff
>> diff -r 7c829eba7814 src/java.activation/share/classes/META-INF/mimetypes.default
>> --- a/src/java.activation/share/classes/META-INF/mimetypes.default	Sat Feb 04 14:03:15 2017 -0500
>> +++ b/src/java.activation/share/classes/META-INF/mimetypes.default	Tue Feb 07 14:23:23 2017 -0500
>> @@ -7,6 +7,7 @@
>> image/ief		ief
>> image/jpeg		jpeg jpg jpe JPG
>> image/tiff		tiff tif
>> +image/png		png PNG
>> image/x-xwindowdump	xwd
>> application/postscript	ai eps ps
>> application/rtf		rtf
>> ljanders-mac:jaxws ljanders$ 
>> ??????????
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From mandy.chung at oracle.com  Tue Feb  7 20:03:47 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 7 Feb 2017 12:03:47 -0800
Subject: RFR: 8173898: StackWalker.walk throws InternalError if called
	from a constructor invoked through reflection.
In-Reply-To: <2e645742-5ffb-4fb9-c6f1-710585053de7@oracle.com>
References: <951dc6d5-8fce-6af7-eda6-bcacfdb60b52@oracle.com>
	<FF6E35EA-7653-4AD9-BB6B-D1606D21FA75@oracle.com>
	<2e645742-5ffb-4fb9-c6f1-710585053de7@oracle.com>
Message-ID: <7DA4047D-4ED5-43A8-ACC6-33B6A98C4335@oracle.com>


> On Feb 7, 2017, at 5:10 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Mandy,
> 
> On 06/02/17 00:16, Mandy Chung wrote:
>> Hi Daniel,
>> 
>> Thanks for the patch and uncover that Constructor::newInstance is not covered by SHOW_REFLECT_FRAMES.
>> 
>> The change looks okay.  The javadoc of SHOW_REFLECT_FRAMES can be clarified to include Constructor::newInstance.  As for the test, can you separate this in a new test to test showing and hiding reflecton frames and also getCallerClass?
> 
> Please find below a new webrev that incorporates your feedback.
> I have added a new test, and also tweaked the API documentation
> in StackWalker.java as you suggested:
> http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.03/
> 

I think this sentence is not needed.
 216          * <p>A {@code StackWalker} with this {@code SHOW_REFLECT_FRAMES} option
 217          * will show all reflection frames.

Basic.java test - the @bug already includes the bug number.  line 67-69 can be removed.  

Minor comments: StackFrame.getClassName() can replace StackFrame.getDeclaringClass().getName().  Or if you want to compare package name, StackFrame.getDeclaringClass().getPackageName is an alternative.

Nit: what about renaming SimpleObj to ConstructorNewInstance? 
SimpleObj::found should probably name as `framesInUnnamedOrReflectionPackage`.

Nit: ReflectionFrames.java test - the test is a bit hard maybe SimpleObj can be renamed to TestHelper and `found` be `result`.   Just trying to make the test easier to read and understand.  You may have better idea.

Otherwise looks good.

Mandy


From Roger.Riggs at Oracle.com  Tue Feb  7 20:06:08 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 7 Feb 2017 15:06:08 -0500
Subject: JDK 9: 8174128: [testbug] Remove implementation dependency from
	java.time TCK tests
Message-ID: <046b99c0-eaf2-c526-1809-c8a5179ae66c@Oracle.com>

Please review minor changes to the java.time.tck tests to avoid the use of
implementation details and the related opening of the modules.
The testng directive to open needed modules is now specific to the 
java.time.test... tests.

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-opens-8174128/

Thanks, Roger


From bill.shannon at oracle.com  Tue Feb  7 20:17:50 2017
From: bill.shannon at oracle.com (Bill Shannon)
Date: Tue, 7 Feb 2017 12:17:50 -0800
Subject: 8057795: Update of the mimestypes.default for JAF
In-Reply-To: <E31001A8-4540-448F-B360-B6E78252BCC4@oracle.com>
References: <5D4E765A-2D03-40D1-8188-B36E868082B4@oracle.com>
	<1B123407-C890-4C25-A6BB-3E8E900DC33B@oracle.com>
	<E31001A8-4540-448F-B360-B6E78252BCC4@oracle.com>
Message-ID: <544288ca-1f6d-29be-a993-a3dd33ac7d08@oracle.com>

The list of possible MIME type mappings is endless and it's not worth the effort
to try to keep up.  This one change just keeps the JDK in sync with the
standalone version.

Lance Andersen wrote on 02/ 7/17 12:01 PM:
> Hi Brian,
>
> Thank you for the quick review.
>
> I will defer to Bill on whether anything else should be added as it should be
> included in the standalone JAF RI as well.
>
> Bill, let us know.  :-)
>
> Best
> Lance
>> On Feb 7, 2017, at 2:56 PM, Brian Burkhalter <brian.burkhalter at oracle.com
>> <mailto:brian.burkhalter at oracle.com>> wrote:
>>
>> Hi Lance,
>>
>> +1
>>
>> Good thing especially given that PNG is now two decades old. ;-)
>>
>> Are there other now-common media types which should also be added, e.g.,
>> anything that QuickTime, WMP, VideoLAN, iTunes, Preview, etc. would typically
>> handle? See, e.g., https://bugs.openjdk.java.net/browse/JDK-8162745 and
>> others ...
>>
>> Thanks,
>>
>> Brian
>>
>> On Feb 7, 2017, at 11:32 AM, Lance Andersen <lance.andersen at oracle.com
>> <mailto:lance.andersen at oracle.com>> wrote:
>>
>>> Attached is the diff to update the  mimetypes.default for JAF.  The
>>> standalone standalone JAF was updated with support for .png files some time ago.
>>>
>>>
>>> ???????
>>> hg diff
>>> diff -r 7c829eba7814
>>> src/java.activation/share/classes/META-INF/mimetypes.default
>>> --- a/src/java.activation/share/classes/META-INF/mimetypes.defaultSat Feb 04
>>> 14:03:15 2017 -0500
>>> +++ b/src/java.activation/share/classes/META-INF/mimetypes.defaultTue Feb 07
>>> 14:23:23 2017 -0500
>>> @@ -7,6 +7,7 @@
>>> image/iefief
>>> image/jpegjpeg jpg jpe JPG
>>> image/tifftiff tif
>>> +image/pngpng PNG
>>> image/x-xwindowdumpxwd
>>> application/postscriptai eps ps
>>> application/rtfrtf
>>> ljanders-mac:jaxws ljanders$ 
>>> ??????????
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>
>
>
>


From mandy.chung at oracle.com  Tue Feb  7 20:32:52 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 7 Feb 2017 12:32:52 -0800
Subject: RFR JDK-8173777: Merge javac -Xmodule into javac--patch-module
In-Reply-To: <589A0DC4.5020409@oracle.com>
References: <58989C16.80404@oracle.com> <5898C36D.30902@oracle.com>
	<206f4364-1d18-fed8-840a-f655b235b943@oracle.com>
	<589A0DC4.5020409@oracle.com>
Message-ID: <BC923ACF-DEB3-4CD4-A1FE-90BABAA9CDC1@oracle.com>


> On Feb 7, 2017, at 10:11 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
> 
> Updated webrevs:
> -langtools repository:
> http://cr.openjdk.java.net/~jlahoda/8173777/langtools.01/

test/tools/jdeps/jdkinternals/RemovedJDKInternals.java change looks okay to me.

> -jdk repository:
> http://cr.openjdk.java.net/~jlahoda/8173777/jdk.02/


Looks okay too.

Mandy

From lance.andersen at oracle.com  Tue Feb  7 20:42:31 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 7 Feb 2017 15:42:31 -0500
Subject: 8057795: Update of the mimestypes.default for JAF
In-Reply-To: <544288ca-1f6d-29be-a993-a3dd33ac7d08@oracle.com>
References: <5D4E765A-2D03-40D1-8188-B36E868082B4@oracle.com>
	<1B123407-C890-4C25-A6BB-3E8E900DC33B@oracle.com>
	<E31001A8-4540-448F-B360-B6E78252BCC4@oracle.com>
	<544288ca-1f6d-29be-a993-a3dd33ac7d08@oracle.com>
Message-ID: <D29CF874-E50A-41C4-A48A-536D0D5A133E@oracle.com>

Thank you Bill, I will push as is then.

Best
Lance
> On Feb 7, 2017, at 3:17 PM, Bill Shannon <bill.shannon at oracle.com> wrote:
> 
> The list of possible MIME type mappings is endless and it's not worth the effort to try to keep up.  This one change just keeps the JDK in sync with the standalone version.
> 
> Lance Andersen wrote on 02/ 7/17 12:01 PM:
>> Hi Brian,
>> 
>> Thank you for the quick review.
>> 
>> I will defer to Bill on whether anything else should be added as it should be included in the standalone JAF RI as well.
>> 
>> Bill, let us know.  :-)
>> 
>> Best
>> Lance
>>> On Feb 7, 2017, at 2:56 PM, Brian Burkhalter <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> wrote:
>>> 
>>> Hi Lance,
>>> 
>>> +1
>>> 
>>> Good thing especially given that PNG is now two decades old. ;-)
>>> 
>>> Are there other now-common media types which should also be added, e.g., anything that QuickTime, WMP, VideoLAN, iTunes, Preview, etc. would typically handle? See, e.g., https://bugs.openjdk.java.net/browse/JDK-8162745 <https://bugs.openjdk.java.net/browse/JDK-8162745> and others ...
>>> 
>>> Thanks,
>>> 
>>> Brian
>>> 
>>> On Feb 7, 2017, at 11:32 AM, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
>>> 
>>>> Attached is the diff to update the  mimetypes.default for JAF.  The standalone standalone JAF was updated with support for .png files some time ago.
>>>> 
>>>> 
>>>> ???????
>>>> hg diff
>>>> diff -r 7c829eba7814 src/java.activation/share/classes/META-INF/mimetypes.default
>>>> --- a/src/java.activation/share/classes/META-INF/mimetypes.default	Sat Feb 04 14:03:15 2017 -0500
>>>> +++ b/src/java.activation/share/classes/META-INF/mimetypes.default	Tue Feb 07 14:23:23 2017 -0500
>>>> @@ -7,6 +7,7 @@
>>>> image/ief		ief
>>>> image/jpeg		jpeg jpg jpe JPG
>>>> image/tiff		tiff tif
>>>> +image/png		png PNG
>>>> image/x-xwindowdump	xwd
>>>> application/postscript	ai eps ps
>>>> application/rtf		rtf
>>>> ljanders-mac:jaxws ljanders$ 
>>>> ??????????
>>> 
>> 
>> <Mail Attachment.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>
>> 
>> 
>> 
> 
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From scolebourne at joda.org  Tue Feb  7 20:42:21 2017
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 7 Feb 2017 20:42:21 +0000
Subject: JDK 9: 8174128: [testbug] Remove implementation dependency from
	java.time TCK tests
In-Reply-To: <046b99c0-eaf2-c526-1809-c8a5179ae66c@Oracle.com>
References: <046b99c0-eaf2-c526-1809-c8a5179ae66c@Oracle.com>
Message-ID: <CACzrW9BZi+XgsxH1R2JU7Z7S5c5F=p7a5jtSsHCu=ZGnWYEeww@mail.gmail.com>

+1
Stephen


On 7 February 2017 at 20:06, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> Please review minor changes to the java.time.tck tests to avoid the use of
> implementation details and the related opening of the modules.
> The testng directive to open needed modules is now specific to the
> java.time.test... tests.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-opens-8174128/
>
> Thanks, Roger
>

From ramanand.patil at oracle.com  Tue Feb  7 20:57:11 2017
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Tue, 7 Feb 2017 12:57:11 -0800 (PST)
Subject: RFR: 8173943: Change error reporting of LauncherHelper to include
	actual Error class name
In-Reply-To: <5898A30D.9010908@oracle.com>
References: <32e0a2e8-34a8-4bc2-8fbf-db1107995b33@default>
	<5898A30D.9010908@oracle.com>
Message-ID: <ea11be40-e1da-485d-9e46-a7179b28c411@default>

Thank you Alan and Kumar.
I have just pushed the fix.

Regards,
Ramanand.

-----Original Message-----
From: Kumar Srinivasan 
Sent: Monday, February 06, 2017 9:54 PM
To: Ramanand Patil <ramanand.patil at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: RFR: 8173943: Change error reporting of LauncherHelper to include actual Error class name

+1

Kumar

On 2/5/2017 11:14 AM, Ramanand Patil wrote:
> Hi all,
> Please review the following trivial bug fix:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8173943
> Webrev: http://cr.openjdk.java.net/~rpatil/8173943/webrev.00/
>
> LinkageError message added by - https://bugs.openjdk.java.net/browse/JDK-8167063 is updated to include the Error Class name.
>
> Regards,
> Ramanand.
>


From mandy.chung at oracle.com  Tue Feb  7 21:16:45 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 7 Feb 2017 13:16:45 -0800
Subject: Review Request: JDK-8173712: Rename JAVA_OPTIONS environment variable
	to JDK_JAVA_OPTIONS
Message-ID: <1CAB1A0E-0EC7-4050-9D73-B3B473C5EB60@oracle.com>

Henry, Kumar,

Can you please review this patch:
  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173712/webrev.00/

JAVA_OPTIONS was introduced by JDK-8170832 but it turns out that
environment variable name conflicts with existing uses.  It might 
not be uncommon for scripts to set JAVA_OPTIONS. To mitigate the
compatibility concern, we decide to rename JAVA_OPTIONS to 
JDK_JAVA_OPTIONS.  With multi-word name and `JDK_` prefix, that
should reduce the chance of name clash.

thanks
Mandy

From paul.sandoz at oracle.com  Tue Feb  7 21:50:09 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 7 Feb 2017 13:50:09 -0800
Subject: Review Request: JDK-8173712: Rename JAVA_OPTIONS environment
	variable to JDK_JAVA_OPTIONS
In-Reply-To: <1CAB1A0E-0EC7-4050-9D73-B3B473C5EB60@oracle.com>
References: <1CAB1A0E-0EC7-4050-9D73-B3B473C5EB60@oracle.com>
Message-ID: <313D509D-3F10-4337-86C4-423DF60A2A11@oracle.com>


> On 7 Feb 2017, at 13:16, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> Henry, Kumar,
> 
> Can you please review this patch:
>  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173712/webrev.00/
> 
> JAVA_OPTIONS was introduced by JDK-8170832 but it turns out that
> environment variable name conflicts with existing uses.  It might
> not be uncommon for scripts to set JAVA_OPTIONS. To mitigate the
> compatibility concern, we decide to rename JAVA_OPTIONS to
> JDK_JAVA_OPTIONS.  With multi-word name and `JDK_` prefix, that
> should reduce the chance of name clash.
> 

+1

Paul.

From henry.jen at oracle.com  Tue Feb  7 23:01:01 2017
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 7 Feb 2017 15:01:01 -0800
Subject: Review Request: JDK-8173712: Rename JAVA_OPTIONS environment
	variable to JDK_JAVA_OPTIONS
In-Reply-To: <1CAB1A0E-0EC7-4050-9D73-B3B473C5EB60@oracle.com>
References: <1CAB1A0E-0EC7-4050-9D73-B3B473C5EB60@oracle.com>
Message-ID: <FB53D0A0-3D19-4D6A-AFF0-CB8E574533D3@oracle.com>

+1.

Cheers,
Henry

> On Feb 7, 2017, at 1:16 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> Henry, Kumar,
> 
> Can you please review this patch:
>  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173712/webrev.00/
> 
> JAVA_OPTIONS was introduced by JDK-8170832 but it turns out that
> environment variable name conflicts with existing uses.  It might 
> not be uncommon for scripts to set JAVA_OPTIONS. To mitigate the
> compatibility concern, we decide to rename JAVA_OPTIONS to 
> JDK_JAVA_OPTIONS.  With multi-word name and `JDK_` prefix, that
> should reduce the chance of name clash.
> 
> thanks
> Mandy


From mark.sheppard at oracle.com  Wed Feb  8 00:08:43 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 8 Feb 2017 00:08:43 +0000
Subject: RFR: JDK-8049375 - Extend how the org.omg.CORBA.ORB handles the
	search for orb.properties
In-Reply-To: <d499987d-9280-fecc-1356-52bcf45333f5@oracle.com>
References: <82e9646a-a052-8707-54ae-fa1dd57ab9c1@oracle.com>
	<57313EEE-0E1E-44CB-A0DB-A095D0731768@oracle.com>
	<d499987d-9280-fecc-1356-52bcf45333f5@oracle.com>
Message-ID: <b60b398d-2288-7bf9-a54b-fbb32caac69a@oracle.com>

webrev has been updated as per feedback and suggestions:

http://cr.openjdk.java.net/~msheppar/8049375/test/webrev.02/
http://cr.openjdk.java.net/~msheppar/8049375/corba/webrev.02/

regards
Mark


On 07/02/2017 12:12, Mark Sheppard wrote:
>
> thanks Lance for the feedback
>
> TODO auto-generated in eclipse, I'll delete them
>
> yes, for completeness it would do no harm to add a test run with 
> Security Manager
>
> regards
> Mark
>
> On 06/02/2017 23:47, Lance Andersen wrote:
>> Hi Mark,
>>
>> The change and test looks reasonable.  I might consider removing the 
>> ?TODO? comments from your test cases prior to pushing.
>>
>> Maybe it is not needed, but should the test also be run with a 
>> SecurityManager or did you feel that was not needed?
>>
>> HTH
>>
>> Best
>> Lance
>>> On Feb 6, 2017, at 4:20 PM, Mark Sheppard <mark.sheppard at oracle.com 
>>> <mailto:mark.sheppard at oracle.com>> wrote:
>>>
>>> Hi,
>>>   please oblige and review the following changes to the corba component
>>>
>>> http://cr.openjdk.java.net/~msheppar/8049375/corba/webrev/ 
>>> <http://cr.openjdk.java.net/%7Emsheppar/8049375/corba/webrev/>
>>> http://cr.openjdk.java.net/~msheppar/8049375/test/webrev/
>>>
>>> which address the issue
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8049375
>>>
>>> the JDK9 rt image has changed structure to include a conf directory.
>>> This will hold a component's properties file, if any, and as such the
>>> corba component has amended the locating of the properties file with
>>> a search in the ${java.home}/conf directory.
>>>
>>> regards
>>> Mark
>>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> 
>>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>
>>
>>
>>
>


From huizhe.wang at oracle.com  Wed Feb  8 00:39:16 2017
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 07 Feb 2017 16:39:16 -0800
Subject: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates
	namespace prefixes if namespace is given as URI only
In-Reply-To: <dcceb6e6de034a748d881d2f3eb19e47@derote13de46.global.corp.sap>
References: <dcceb6e6de034a748d881d2f3eb19e47@derote13de46.global.corp.sap>
Message-ID: <589A68B4.7010307@oracle.com>

Hi Christoph,

As we discussed, let's target this for JDK 10 as a spec change at this 
stage for JDK 9 is too late. Removing the namespace generation would be 
another reason to do this in JDK 10 since then, we wouldn't need the 
additional property.

Thanks,
Joe

On 1/31/17, 11:02 AM, Langer, Christoph wrote:
>
> Hi Joe,
>
> evenutally I have updated my webrev for this issue: 
> http://cr.openjdk.java.net/~clanger/webrevs/8168664.1/ 
> <http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664.1/>
>
> I've implemented your suggestion to add a property 
> "jdk.xml.generatePrefix" which is true by default. I also added a 
> testcase which tests the correct behavior with 
> "-Djdk.xml.generatePrefix=false".
>
> Generally, I think namespace prefix generation at this place is not 
> needed. Or would you know of or be able to construct a case where it 
> is really required? If not, I rather think namespace generation at 
> this place should be thrown out unconditionally. Maybe for JDK10? In 
> case it is removed, it would render the test 
> javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java which was 
> implemented recently by Alex for bug 
> https://bugs.openjdk.java.net/browse/JDK-8167179 obsolete in its 
> current form. However, the namespace generation function is still used 
> some place for attribute namespaces.
>
> For JDK9 I can imagine the change of this webrev going in -- however, 
> as we already discussed, you would have to do a ccc for me.
>
> Thanks & Best regards
>
> Christoph
>
> *From:*Langer, Christoph
> *Sent:* Dienstag, 25. Oktober 2016 15:39
> *To:* core-libs-dev at openjdk.java.net
> *Subject:* RFR (JAXP): 8168664 [JAXP] XALAN: xsl:element generates 
> namespace prefixes if namespace is given as URI only
>
> Hi JAXP experts,
>
> please review a fix for a new issue regarding namespace handling in 
> Xalan with xsl:element.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8168664
>
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8168664.0/ 
> <http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664.0/>
>
> I'm not 100% sure if this is the right way to go or if it would break 
> some correct behavior elsewhere. But I think the current behavior is 
> either not correct or at least it is not required to generate new xsl 
> namespace prefixes if the namespace comes in as URI only to an 
> xsl:element node. The interpretative transformer from the Apache Xalan 
> project will also produce the expected output, different to the 
> compiled XSLTC here.
>
> In the webrev, my changes to XslElement.java are only 
> cosmetical/comments, the behavior does not change. In 
> BasisLibrary.java I also took the opportunity to remove the $Id tag 
> and the unused method "nodeList2IteratorUsingHandleFromNode".
>
> If you think my change is good, I'll also add a test that runs the 
> transformation which can be found in the bug...
>
> Thanks & best regards
>
> Christoph
>

From huizhe.wang at oracle.com  Wed Feb  8 00:54:36 2017
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 07 Feb 2017 16:54:36 -0800
Subject: Update: RFR 8172974 [JAXP] XALAN: Wrong result when transforming
	namespace unaware StAX Input
In-Reply-To: <3f43563228ef4f7ca2eed6281698a17c@derote13de46.global.corp.sap>
References: <3f43563228ef4f7ca2eed6281698a17c@derote13de46.global.corp.sap>
Message-ID: <589A6C4C.60302@oracle.com>

Hi Christoph,

We'll double-check whether there's any performance implications. Please 
give us a couple of (or few) days.

Thanks,
Joe

On 1/30/17, 7:28 AM, Langer, Christoph wrote:
> Hi Joe,
>
> I've updated my webrev for 8172974 after pulling out the refactoring of javax/xml/jaxp/unittest/transform/TransformerTest.java to Bug 8173602: http://cr.openjdk.java.net/~clanger/webrevs/8172974.1/
>
> After exchanging some off-list mails with Lance and Daniel, we came to the conclusion that you should decide about this one when you are back. The changes are merely cleanups apart from com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM2.startElement(), which to me seem natural after 8169631, though.
>
> Thanks,
> Christoph
>
>> -----Original Message-----
>> From: Langer, Christoph
>> Sent: Mittwoch, 18. Januar 2017 22:55
>> To: 'huizhe wang'<huizhe.wang at oracle.com>; core-libs-dev at openjdk.java.net
>> Subject: RE: RFR 8172974 [JAXP] XALAN: Wrong result when transforming
>> namespace unaware StAX Input
>>
>> Hi Joe,
>>
>> generally, you are right, XSLT requires namespace support. For parsing the
>> stylesheet, it is definitely a hard requirement. Otherwise this would not make
>> sense at all. For instance xsl directives are in the xsl namespace. That
>> requirement is what the FAQ you are referencing [1] is talking about.
>>
>> As for the InputSource which is to be processed, it is probably also not a right to
>> use non namespace aware parsing. But still it's not forbidden. For instance, the
>> JavaDoc for SAXSource [2] states this:
>> "Note that XSLT requires namespace support. Attempting to transform an input
>> source that is not generated with a namespace-aware parser may result in
>> errors. Parsers can be made namespace aware by calling the
>> SAXParserFactory.setNamespaceAware(boolean awareness) method."
>>
>> So, I agree, we are in the error space here. But still I think the result of non
>> namespace aware parsing should be the same for all types of input source. And
>> at the moment it is the same for DOMSource and SAXSource but not for
>> StAXSource. From that point of view I think my fix makes sense (along with the
>> other cleanups).
>>
>> Best regards
>> Christoph
>>
>> [1] https://xml.apache.org/xalan-j/faq.html#faq-N10207
>> [2]
>> https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSource
>> .html
>>
>>
>>> -----Original Message-----
>>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
>>> Sent: Mittwoch, 18. Januar 2017 22:12
>>> To: Langer, Christoph<christoph.langer at sap.com>; core-libs-
>>> dev at openjdk.java.net
>>> Subject: Re: RFR 8172974 [JAXP] XALAN: Wrong result when transforming
>>> namespace unaware StAX Input
>>>
>>> Hi Christoph,
>>>
>>> Xalan requires the underlying parser to be namespace aware. Please refer
>>> to https://xml.apache.org/xalan-j/faq.html#faq-N10207
>>>
>>> Thanks,
>>> Joe
>>>
>>> On 1/18/2017 8:26 AM, Langer, Christoph wrote:
>>>> Hi,
>>>>
>>>> please review a change for JAXP.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172974
>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172974.0/
>>>>
>>>> When enhancing the test for https://bugs.openjdk.java.net/browse/JDK-
>>> 8023653, I saw that there's still an issue with StAXInputSource which is not
>>> namespace aware. This needs a small update in
>>>
>> src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dt
>>> m/SAX2DTM2.java. Furthermore, I added the fixed warnings and formattings
>>> from the proposal http://cr.openjdk.java.net/~clanger/webrevs/8023653.0/ to
>>> this webrev, as 8023653 is an enhancement and might not go in in the near
>>> future.
>>>> I also enhanced the TransformerTest to utilize data providers now and test
>> a
>>> comprehensive matrix of XALAN input.
>>>> Thanks in advance and Best regards
>>>> Christoph
>>>>

From Alan.Bateman at oracle.com  Wed Feb  8 06:47:49 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 8 Feb 2017 06:47:49 +0000
Subject: Review Request: JDK-8173712: Rename JAVA_OPTIONS environment
	variable to JDK_JAVA_OPTIONS
In-Reply-To: <1CAB1A0E-0EC7-4050-9D73-B3B473C5EB60@oracle.com>
References: <1CAB1A0E-0EC7-4050-9D73-B3B473C5EB60@oracle.com>
Message-ID: <addbdc53-e0d8-2920-8736-82891cd195be@oracle.com>

On 07/02/2017 21:16, Mandy Chung wrote:

> Henry, Kumar,
>
> Can you please review this patch:
>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173712/webrev.00/
>
> JAVA_OPTIONS was introduced by JDK-8170832 but it turns out that
> environment variable name conflicts with existing uses.  It might
> not be uncommon for scripts to set JAVA_OPTIONS. To mitigate the
> compatibility concern, we decide to rename JAVA_OPTIONS to
> JDK_JAVA_OPTIONS.  With multi-word name and `JDK_` prefix, that
> should reduce the chance of name clash.
>
The rename looks okay. You might want to add to the @bug list so that it 
captures the bug with the rename.

-Alan

From christoph.langer at sap.com  Wed Feb  8 07:28:41 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 8 Feb 2017 07:28:41 +0000
Subject: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates
	namespace prefixes if namespace is given as URI only
In-Reply-To: <589A68B4.7010307@oracle.com>
References: <dcceb6e6de034a748d881d2f3eb19e47@derote13de46.global.corp.sap>
	<589A68B4.7010307@oracle.com>
Message-ID: <95d39d5bdb2f404fa97cbe77d314d061@derote13de46.global.corp.sap>

Hi Joe,

welcome back. :) This sounds reasonable. I'll prepare a change for JDK10.

Thanks
Christoph

From: Joe Wang [mailto:huizhe.wang at oracle.com]
Sent: Mittwoch, 8. Februar 2017 01:39
To: Langer, Christoph <christoph.langer at sap.com>
Cc: core-libs-dev at openjdk.java.net; Aleksej Efimov <aleksej.efimov at oracle.com>
Subject: Re: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only

Hi Christoph,

As we discussed, let's target this for JDK 10 as a spec change at this stage for JDK 9 is too late. Removing the namespace generation would be another reason to do this in JDK 10 since then, we wouldn't need the additional property.

Thanks,
Joe

On 1/31/17, 11:02 AM, Langer, Christoph wrote:
Hi Joe,

evenutally I have updated my webrev for this issue: http://cr.openjdk.java.net/~clanger/webrevs/8168664.1/<http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664.1/>

I've implemented your suggestion to add a property "jdk.xml.generatePrefix" which is true by default. I also added a testcase which tests the correct behavior with "-Djdk.xml.generatePrefix=false".

Generally, I think namespace prefix generation at this place is not needed. Or would you know of or be able to construct a case where it is really required? If not, I rather think namespace generation at this place should be thrown out unconditionally. Maybe for JDK10? In case it is removed, it would render the test javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java which was implemented recently by Alex for bug https://bugs.openjdk.java.net/browse/JDK-8167179 obsolete in its current form. However, the namespace generation function is still used some place for attribute namespaces.

For JDK9 I can imagine the change of this webrev going in - however, as we already discussed, you would have to do a ccc for me.

Thanks & Best regards
Christoph

From: Langer, Christoph
Sent: Dienstag, 25. Oktober 2016 15:39
To: core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>
Subject: RFR (JAXP): 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only

Hi JAXP experts,

please review a fix for a new issue regarding namespace handling in Xalan with xsl:element.

Bug: https://bugs.openjdk.java.net/browse/JDK-8168664
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8168664.0/<http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664.0/>

I'm not 100% sure if this is the right way to go or if it would break some correct behavior elsewhere. But I think the current behavior is either not correct or at least it is not required to generate new xsl namespace prefixes if the namespace comes in as URI only to an xsl:element node. The interpretative transformer from the Apache Xalan project will also produce the expected output, different to the compiled XSLTC here.

In the webrev, my changes to XslElement.java are only cosmetical/comments, the behavior does not change. In BasisLibrary.java I also took the opportunity to remove the $Id tag and the unused method "nodeList2IteratorUsingHandleFromNode".

If you think my change is good, I'll also add a test that runs the transformation which can be found in the bug...

Thanks & best regards
Christoph


From amy.lu at oracle.com  Wed Feb  8 09:57:52 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 8 Feb 2017 17:57:52 +0800
Subject: JDK 9 RFR of JDK-8169903: Refactor spliterator traversing tests
	into a library
In-Reply-To: <2F67C7EC-0FC5-4E1B-B287-E1491B061926@oracle.com>
References: <8f7822d7-e66c-8d53-89f4-9d9b7f9a713f@oracle.com>
	<e78193c5-565b-3034-1131-2fd1a0f94624@oracle.com>
	<39AF9B61-1680-4D3E-8523-EAC6DC8EB550@oracle.com>
	<573cbb38-61d0-7f03-3918-fe0ee5a4f54b@oracle.com>
	<2F67C7EC-0FC5-4E1B-B287-E1491B061926@oracle.com>
Message-ID: <b9aa4212-9901-1d55-192b-475205b50f8e@oracle.com>

On 1/26/17 1:04 AM, Paul Sandoz wrote:
>    @SuppressWarnings({"unchecked", "rawtypes?})
>
> Can we remove those with an appropriate adjustment to the test method signatures?

Fixed.
>
> We should be careful adding Integer.MAX_VALUE tests for BitStream as the can consume lots of memory.
>
> My suggestion is not to add them to this test and instead consider, as a follow on issue, moving spliterator testing of BitSet to BitSetStreamTest, where we can better control large memory consuming cases.

To test/java/util/BitSet/BitSetStreamTest.java?Created JDK-8174171.

For now, I reverted the change of adding back Integer.MAX_VALUE, and 
also removed the change of
<  * @requires os.maxMemory >= 2g
<  * @run testng/othervm -Xms512m -Xmx1024m 
SpliteratorTraversingAndSplittingTest


Please review the updated webrev:
http://cr.openjdk.java.net/~amlu/8169903/webrev.02/

Thanks,
Amy

> Paul.
>
>> On 25 Jan 2017, at 03:29, Amy Lu<amy.lu at oracle.com>  wrote:
>>
>> Thank you Paul for reviewing.
>>
>> Webrev updated:http://cr.openjdk.java.net/~amlu/8169903/webrev.01/
>>
>> Note that SpliteratorTestHelper.java now still under test/java/util/stream/bootlib/java.base but changed to "java.util" (instead of java.util.stream). It may be re-located to test/lib/testlibrary, together with other stream-based test libs, later in JDK-8085814.
>>
>> Thanks,
>> Amy
>>
>>
>> On 1/20/17 3:22 AM, Paul Sandoz wrote:
>>>> On 19 Jan 2017, at 05:37, Amy Lu<amy.lu at oracle.com>  wrote:
>>>>
>>>> This is test-only change, can still go into JDK 9?
>>>>
>>> Yes.
>>>
>>> It?s verbose but i would prefer if you can explicitly declare each test rather than having one test deferring to SpliteratorTestHelper.testSpliterator. So in effect the test methods are proxies to the equivalent methods on the helper. That way it?s easier to diagnose test failures.
>>>
>>> The expected contents (collection) has also been removed. It?s important in many cases to be able to pass this independently and not derive the expected result from traversing the spliterator, as that could mask bugs.
>>>
>>> There is no need to create separate classes for primitive tests (you only added explicit for int traversing and not long and double).
>>>
>>>
>>> Independently i wonder if test/java/util/stream/bootlib/java.base/java/util/stream/SpliteratorTestHelper.java is the right location. I know it?s used in Streams, but perhaps it and the provider should be placed within a library?
>>>
>>> Paul.
>>>
>>>> Thanks,
>>>> Amy
>>>>
>>>> On 1/19/17 9:34 PM, Amy Lu wrote:
>>>>> java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
>>>>> java/util/Spliterator/SpliteratorCollisions.java
>>>>>
>>>>> Test functions in above tests are almost duplicate with functions in java/util/stream/SpliteratorTestHelper.java. Test can reuse test functions from SpliteratorTestHelper, but with it?s own DataProvider.
>>>>>
>>>>> Please review the patch for refactoring spliterator traversing tests.
>>>>>
>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8169903
>>>>> webrev:http://cr.openjdk.java.net/~amlu/8169903/webrev.00/
>>>>>
>>>>> SpliteratorTestHelper.java has a minor update, added one small testcase that originally from SpliteratorCollisions.testForEach.
>>>>>
>>>>> The two skipped tests in SpliteratorCollisions.java are now enabled back, as mentioned bug has already been fixed.
>>>>> 256 /* skip this test until 8013649 is fixed
>>>>> ...
>>>>> 268 */
>>>>>
>>>>> This patch also brings back Integer.MAX_VALUE test data which requires big memory (and removed in JDK-8169838), in a separate test.
>>>>>
>>>>> Thanks,
>>>>> Amy


From Alan.Bateman at oracle.com  Wed Feb  8 10:02:07 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 8 Feb 2017 10:02:07 +0000
Subject: RFR: JDK-8049375 - Extend how the org.omg.CORBA.ORB handles the
	search for orb.properties
In-Reply-To: <b60b398d-2288-7bf9-a54b-fbb32caac69a@oracle.com>
References: <82e9646a-a052-8707-54ae-fa1dd57ab9c1@oracle.com>
	<57313EEE-0E1E-44CB-A0DB-A095D0731768@oracle.com>
	<d499987d-9280-fecc-1356-52bcf45333f5@oracle.com>
	<b60b398d-2288-7bf9-a54b-fbb32caac69a@oracle.com>
Message-ID: <37511faf-3367-a45b-8271-e72aec200857@oracle.com>

On 08/02/2017 00:08, Mark Sheppard wrote:

> webrev has been updated as per feedback and suggestions:
>
> http://cr.openjdk.java.net/~msheppar/8049375/test/webrev.02/
> http://cr.openjdk.java.net/~msheppar/8049375/corba/webrev.02/
"(if any)" => "(, if any)", did you mean to add the comma? The rest of 
the javadoc update looks okay to me.

-Alan

From daniel.fuchs at oracle.com  Wed Feb  8 11:36:21 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 8 Feb 2017 11:36:21 +0000
Subject: RFR: 8173898: StackWalker.walk throws InternalError if called
	from a constructor invoked through reflection.
In-Reply-To: <7DA4047D-4ED5-43A8-ACC6-33B6A98C4335@oracle.com>
References: <951dc6d5-8fce-6af7-eda6-bcacfdb60b52@oracle.com>
	<FF6E35EA-7653-4AD9-BB6B-D1606D21FA75@oracle.com>
	<2e645742-5ffb-4fb9-c6f1-710585053de7@oracle.com>
	<7DA4047D-4ED5-43A8-ACC6-33B6A98C4335@oracle.com>
Message-ID: <8d3645b2-ffd6-b9e7-4a50-46a878f2f9c9@oracle.com>

Hi Mandy,

Thanks for all the suggestions!

On 07/02/17 20:03, Mandy Chung wrote:
>> Please find below a new webrev that incorporates your feedback.
>> http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.03/
>>
>
> I think this sentence is not needed.
>  216          * <p>A {@code StackWalker} with this {@code SHOW_REFLECT_FRAMES} option
>  217          * will show all reflection frames.

I disagree: the text starts by saying:
"By default reflection frames are hidden. The reflection
  frames include [...]"
but the sentence at lines 216-217 is the only place where we say what
the option actually does: it shows all reflection frames.
I think it's needed.
Possibly the sentence at lines 216-217 could be moved to become
the first sentence in the doc comment, but I'd rather not change
it now that the CCC has approved the doc changes as in webrev.03.


> Basic.java test - the @bug already includes the bug number.  line 67-69 can be removed.

Done.

> Minor comments: StackFrame.getClassName() can replace StackFrame.getDeclaringClass().getName().  Or if you want to compare package name, StackFrame.getDeclaringClass().getPackageName is an alternative.

Oh - good remark. StackFrame.getClassName() it is.

> Nit: what about renaming SimpleObj to ConstructorNewInstance?
> SimpleObj::found should probably name as `framesInUnnamedOrReflectionPackage`.

SimpleObj => ConstructorNewInstance
found => testFramesOrReflectionFrames
          (frames in the unnamed package are test frames)

I added some comments as well in the accept() method.

> Nit: ReflectionFrames.java test - the test is a bit hard maybe SimpleObj can be renamed to TestHelper and `found` be `result`.   Just trying to make the test easier to read and understand.  You may have better idea.

SimpleObj => StackInspector (it calls walk & getCallerClass
              to inspect the stack from its constructor)
found => collectedFrames

Also added some comments to better explain the purposes of
StackInspector and StackInspector.Caller.

Here is the new webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.04/

best regards,

-- daniel
>
> Otherwise looks good.
>
> Mandy
>


From daniel.fuchs at oracle.com  Wed Feb  8 12:13:02 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 8 Feb 2017 12:13:02 +0000
Subject: JDK 9: 8174128: [testbug] Remove implementation dependency from
	java.time TCK tests
In-Reply-To: <046b99c0-eaf2-c526-1809-c8a5179ae66c@Oracle.com>
References: <046b99c0-eaf2-c526-1809-c8a5179ae66c@Oracle.com>
Message-ID: <7f80e9cc-2db3-6064-4bdb-8362d8577f4a@oracle.com>

Looks good!

-- daniel

On 07/02/17 20:06, Roger Riggs wrote:
> Please review minor changes to the java.time.tck tests to avoid the use of
> implementation details and the related opening of the modules.
> The testng directive to open needed modules is now specific to the
> java.time.test... tests.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-opens-8174128/
>
> Thanks, Roger
>


From sergei.kovalev at oracle.com  Wed Feb  8 13:51:53 2017
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Wed, 8 Feb 2017 16:51:53 +0300
Subject: RFR(s): 8174194: Several java/lang tests failing due to undeclared
	module dependencies.
Message-ID: <a8d481df-aef8-7f66-6c37-f4412a3a96c5@oracle.com>

Hi Team,

Please review small fix for test suite regarding module dependency.

BugID: https://bugs.openjdk.java.net/browse/JDK-8174194
WebRev: http://cr.openjdk.java.net/~skovalev/8174194/webrev.00/

-- 
With best regards,
Sergei


From daniel.fuchs at oracle.com  Wed Feb  8 14:09:35 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 8 Feb 2017 14:09:35 +0000
Subject: RFR(s): 8174194: Several java/lang tests failing due to
	undeclared module dependencies.
In-Reply-To: <a8d481df-aef8-7f66-6c37-f4412a3a96c5@oracle.com>
References: <a8d481df-aef8-7f66-6c37-f4412a3a96c5@oracle.com>
Message-ID: <b6fa2a08-3006-ae06-3161-3c2eeab88c91@oracle.com>

Hi Sergey,

LFMultiThreadCachingTest.java

Can you clarify the change in this file?

jdk.management requires java.management - so if the test failed with
--limit-modules when it required jdk.management then it's not going to
pass if it is changed to require only java.management.

Or is it that jdk.management was actually not required and the
test was passing all right because it only required java.management?

The other files look OK, I guess.

best regards,

-- daniel

On 08/02/17 13:51, Sergei Kovalev wrote:
> Hi Team,
>
> Please review small fix for test suite regarding module dependency.
>
> BugID: https://bugs.openjdk.java.net/browse/JDK-8174194
> WebRev: http://cr.openjdk.java.net/~skovalev/8174194/webrev.00/
>


From sergei.kovalev at oracle.com  Wed Feb  8 14:13:42 2017
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Wed, 8 Feb 2017 17:13:42 +0300
Subject: RFR(s): 8174194: Several java/lang tests failing due to undeclared
	module dependencies.
Message-ID: <a1512a53-77f6-4fde-d4a8-9638268362d5@oracle.com>

Hi Daniel,

Thank you for review.


> Hi Sergey,
>
> LFMultiThreadCachingTest.java
>
> Can you clarify the change in this file?
>
> jdk.management requires java.management - so if the test failed with
> --limit-modules when it required jdk.management then it's not going to
> pass if it is changed to require only java.management.
>
> Or is it that jdk.management was actually not required and the
> test was passing all right because it only required java.management?
Actually jdk.management is not required for this particular test. 
java.management module is enough to pass the test.
> The other files look OK, I guess.
>
> best regards,
>
> -- daniel
>
> On 08/02/17 13:51, Sergei Kovalev wrote:
> >/Hi Team, />//>/Please review small fix for test suite regarding module dependency. />//>/BugID: https://bugs.openjdk.java.net/browse/JDK-8174194 />/WebRev: http://cr.openjdk.java.net/~skovalev/8174194/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eskovalev/8174194/webrev.00/> />//
>


-- 
With best regards,
Sergei


From daniel.fuchs at oracle.com  Wed Feb  8 14:15:40 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 8 Feb 2017 14:15:40 +0000
Subject: RFR(s): 8174194: Several java/lang tests failing due to
	undeclared module dependencies.
In-Reply-To: <a1512a53-77f6-4fde-d4a8-9638268362d5@oracle.com>
References: <a1512a53-77f6-4fde-d4a8-9638268362d5@oracle.com>
Message-ID: <3f2df3b5-5546-254d-823d-a9b477ad285e@oracle.com>

On 08/02/17 14:13, Sergei Kovalev wrote:
> Actually jdk.management is not required for this particular test.
> java.management module is enough to pass the test.

Well, looks good to me then!

best regards,

-- daniel

From mandy.chung at oracle.com  Wed Feb  8 15:58:07 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 8 Feb 2017 07:58:07 -0800
Subject: RFR: 8173898: StackWalker.walk throws InternalError if called
	from a constructor invoked through reflection.
In-Reply-To: <8d3645b2-ffd6-b9e7-4a50-46a878f2f9c9@oracle.com>
References: <951dc6d5-8fce-6af7-eda6-bcacfdb60b52@oracle.com>
	<FF6E35EA-7653-4AD9-BB6B-D1606D21FA75@oracle.com>
	<2e645742-5ffb-4fb9-c6f1-710585053de7@oracle.com>
	<7DA4047D-4ED5-43A8-ACC6-33B6A98C4335@oracle.com>
	<8d3645b2-ffd6-b9e7-4a50-46a878f2f9c9@oracle.com>
Message-ID: <F6FC4940-77A8-40B3-8FFB-43A02A55A3DF@oracle.com>


> On Feb 8, 2017, at 3:36 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Mandy,
> 
> Thanks for all the suggestions!
> 
> On 07/02/17 20:03, Mandy Chung wrote:
>>> Please find below a new webrev that incorporates your feedback.
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.03/
>>> 
>> 
>> I think this sentence is not needed.
>> 216          * <p>A {@code StackWalker} with this {@code SHOW_REFLECT_FRAMES} option
>> 217          * will show all reflection frames.
> 
> I disagree: the text starts by saying:
> "By default reflection frames are hidden. The reflection
> frames include [?]"

209          * Shows all reflection frames.

This is the first sentence.  line 216-217 repeats line 209.

> but the sentence at lines 216-217 is the only place where we say what
> the option actually does: it shows all reflection frames.
> I think it's needed.
> Possibly the sentence at lines 216-217 could be moved to become
> the first sentence in the doc comment, but I'd rather not change
> it now that the CCC has approved the doc changes as in webrev.03.

This does not change the spec and this is minor rewording.  No need to update CCC.

What about:

Shows all reflection frames.

<p>By default, reflection frames are hidden.  A {@code StackWalker} with this {@code SHOW_REFLECT_FRAMES} option will show the reflection frames that include ?.


> 
> 
>> Nit: what about renaming SimpleObj to ConstructorNewInstance?
>> SimpleObj::found should probably name as `framesInUnnamedOrReflectionPackage`.
> 
> SimpleObj => ConstructorNewInstance
> found => testFramesOrReflectionFrames
>         (frames in the unnamed package are test frames)
> 
> I added some comments as well in the accept() method.

That?s good.

> 
>> Nit: ReflectionFrames.java test - the test is a bit hard maybe SimpleObj can be renamed to TestHelper and `found` be `result`.   Just trying to make the test easier to read and understand.  You may have better idea.
> 
> SimpleObj => StackInspector (it calls walk & getCallerClass
>             to inspect the stack from its constructor)
> found => collectedFrames
> 
> Also added some comments to better explain the purposes of
> StackInspector and StackInspector.Caller.
> 
> Here is the new webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.04/
> 

Thanks for updating the test.

Mandy


From mandy.chung at oracle.com  Wed Feb  8 16:06:32 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 8 Feb 2017 08:06:32 -0800
Subject: RFR(s): 8174194: Several java/lang tests failing due to
	undeclared module dependencies.
In-Reply-To: <a1512a53-77f6-4fde-d4a8-9638268362d5@oracle.com>
References: <a1512a53-77f6-4fde-d4a8-9638268362d5@oracle.com>
Message-ID: <AE0C8335-49C3-41C6-B625-03355A4AF734@oracle.com>


> On Feb 8, 2017, at 6:13 AM, Sergei Kovalev <sergei.kovalev at oracle.com> wrote:
> 
> Thank you for review.
> 
>> On 08/02/17 13:51, Sergei Kovalev wrote:
>> WebRev: http://cr.openjdk.java.net/~skovalev/8174194/webrev.00/
>> 

CheckPackageAccess.java
  86             System.out.println(String.format(MODULE_TEXT, moduleName, isModulePresent ? "" : " NOT"));

this can be simplified with:

System.out.format(MODULE_TEXT, moduleName, isModulePresent ? "" : " NOT?);

I suggest to inline MODULE_TEXT in this method as it?s clear what it?s printed.  No need for MODULE_TEXT varaiable.  Please wrap long lines.

LFSingleThreadCachingTest.java
  - can you keep @modules in alphatical order.

thanks
Mandy

From daniel.fuchs at oracle.com  Wed Feb  8 16:17:22 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 8 Feb 2017 16:17:22 +0000
Subject: RFR: 8173898: StackWalker.walk throws InternalError if called
	from a constructor invoked through reflection.
In-Reply-To: <F6FC4940-77A8-40B3-8FFB-43A02A55A3DF@oracle.com>
References: <951dc6d5-8fce-6af7-eda6-bcacfdb60b52@oracle.com>
	<FF6E35EA-7653-4AD9-BB6B-D1606D21FA75@oracle.com>
	<2e645742-5ffb-4fb9-c6f1-710585053de7@oracle.com>
	<7DA4047D-4ED5-43A8-ACC6-33B6A98C4335@oracle.com>
	<8d3645b2-ffd6-b9e7-4a50-46a878f2f9c9@oracle.com>
	<F6FC4940-77A8-40B3-8FFB-43A02A55A3DF@oracle.com>
Message-ID: <872ae134-249a-3f2c-9cb9-240850db0adb@oracle.com>

On 08/02/17 15:58, Mandy Chung wrote:
>> I disagree: the text starts by saying:
>> "By default reflection frames are hidden. The reflection
>> frames include [?]"
> 209          * Shows all reflection frames.
>
> This is the first sentence.  line 216-217 repeats line 209.
>
>> but the sentence at lines 216-217 is the only place where we say what
>> the option actually does: it shows all reflection frames.
>> I think it's needed.
>> Possibly the sentence at lines 216-217 could be moved to become
>> the first sentence in the doc comment, but I'd rather not change
>> it now that the CCC has approved the doc changes as in webrev.03.
> This does not change the spec and this is minor rewording.  No need to update CCC.
>
> What about:
>
> Shows all reflection frames.
>
> <p>By default, reflection frames are hidden.  A {@code StackWalker} with this {@code SHOW_REFLECT_FRAMES} option will show the reflection frames that include ?.

Oh - you're right! I missed it.

I have made this change in my workspace:
http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.05/

         /**
          * Shows all reflection frames.
          *
          * <p>By default, reflection frames are hidden.  A {@code 
StackWalker}
          * configured with this {@code SHOW_REFLECT_FRAMES} option
          * will show all reflection frames that
          * include {@link java.lang.reflect.Method#invoke} and
          * {@link java.lang.reflect.Constructor#newInstance(Object...)}
          * and their reflection implementation classes.

best regards,

-- daniel


From mandy.chung at oracle.com  Wed Feb  8 16:19:42 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 8 Feb 2017 08:19:42 -0800
Subject: RFR: 8173898: StackWalker.walk throws InternalError if called
	from a constructor invoked through reflection.
In-Reply-To: <872ae134-249a-3f2c-9cb9-240850db0adb@oracle.com>
References: <951dc6d5-8fce-6af7-eda6-bcacfdb60b52@oracle.com>
	<FF6E35EA-7653-4AD9-BB6B-D1606D21FA75@oracle.com>
	<2e645742-5ffb-4fb9-c6f1-710585053de7@oracle.com>
	<7DA4047D-4ED5-43A8-ACC6-33B6A98C4335@oracle.com>
	<8d3645b2-ffd6-b9e7-4a50-46a878f2f9c9@oracle.com>
	<F6FC4940-77A8-40B3-8FFB-43A02A55A3DF@oracle.com>
	<872ae134-249a-3f2c-9cb9-240850db0adb@oracle.com>
Message-ID: <B0E9749F-8A8E-4470-A9A4-85B3F216517D@oracle.com>


> On Feb 8, 2017, at 8:17 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> 
> I have made this change in my workspace:
> http://cr.openjdk.java.net/~dfuchs/webrev_8173898/webrev.05/
> 
>        /**
>         * Shows all reflection frames.
>         *
>         * <p>By default, reflection frames are hidden.  A {@code StackWalker}
>         * configured with this {@code SHOW_REFLECT_FRAMES} option
>         * will show all reflection frames that
>         * include {@link java.lang.reflect.Method#invoke} and
>         * {@link java.lang.reflect.Constructor#newInstance(Object...)}
>         * and their reflection implementation classes.

Looks good.

Thanks
Mandy

From paul.sandoz at oracle.com  Wed Feb  8 17:50:18 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 8 Feb 2017 09:50:18 -0800
Subject: JDK 9 RFR of JDK-8169903: Refactor spliterator traversing tests
	into a library
In-Reply-To: <b9aa4212-9901-1d55-192b-475205b50f8e@oracle.com>
References: <8f7822d7-e66c-8d53-89f4-9d9b7f9a713f@oracle.com>
	<e78193c5-565b-3034-1131-2fd1a0f94624@oracle.com>
	<39AF9B61-1680-4D3E-8523-EAC6DC8EB550@oracle.com>
	<573cbb38-61d0-7f03-3918-fe0ee5a4f54b@oracle.com>
	<2F67C7EC-0FC5-4E1B-B287-E1491B061926@oracle.com>
	<b9aa4212-9901-1d55-192b-475205b50f8e@oracle.com>
Message-ID: <55DA3691-5915-4B8B-88ED-A2BB6BA0D857@oracle.com>


> On 8 Feb 2017, at 01:57, Amy Lu <amy.lu at oracle.com> wrote:
> 
> On 1/26/17 1:04 AM, Paul Sandoz wrote:
>>   @SuppressWarnings({"unchecked", "rawtypes?})
>> 
>> Can we remove those with an appropriate adjustment to the test method signatures?
>> 
> 
> Fixed.

SpliteratorCollisions
?

 232         testForEach(exp, s, (Consumer<HashableInteger> b) -> b);

Do you require the type declaration for the lambda function parameter?

It might be possible to use UnaryOperator.identity() in those cases.

Then i think we are good to go.


>> 
>> We should be careful adding Integer.MAX_VALUE tests for BitStream as the can consume lots of memory.
>> 
>> My suggestion is not to add them to this test and instead consider, as a follow on issue, moving spliterator testing of BitSet to BitSetStreamTest, where we can better control large memory consuming cases.
>> 
> 
> To test/java/util/BitSet/BitSetStreamTest.java? Created JDK-8174171.
> 
> For now, I reverted the change of adding back Integer.MAX_VALUE, and also removed the change of
> <  * @requires os.maxMemory >= 2g
> <  * @run testng/othervm -Xms512m -Xmx1024m SpliteratorTraversingAndSplittingTest
> 

Thanks,

Paul.

> 
> Please review the updated webrev:
> http://cr.openjdk.java.net/~amlu/8169903/webrev.02/
> 
> Thanks,
> Amy
> 
>> 
>> Paul.
>> 
>> 
>>> On 25 Jan 2017, at 03:29, Amy Lu <amy.lu at oracle.com>
>>>  wrote:
>>> 
>>> Thank you Paul for reviewing.
>>> 
>>> Webrev updated:
>>> http://cr.openjdk.java.net/~amlu/8169903/webrev.01/
>>> 
>>> 
>>> Note that SpliteratorTestHelper.java now still under test/java/util/stream/bootlib/java.base but changed to "java.util" (instead of java.util.stream). It may be re-located to test/lib/testlibrary, together with other stream-based test libs, later in JDK-8085814.
>>> 
>>> Thanks,
>>> Amy
>>> 
>>> 
>>> On 1/20/17 3:22 AM, Paul Sandoz wrote:
>>> 
>>>>> On 19 Jan 2017, at 05:37, Amy Lu <amy.lu at oracle.com>
>>>>>  wrote:
>>>>> 
>>>>> This is test-only change, can still go into JDK 9?
>>>>> 
>>>>> 
>>>> Yes.
>>>> 
>>>> It?s verbose but i would prefer if you can explicitly declare each test rather than having one test deferring to SpliteratorTestHelper.testSpliterator. So in effect the test methods are proxies to the equivalent methods on the helper. That way it?s easier to diagnose test failures.
>>>> 
>>>> The expected contents (collection) has also been removed. It?s important in many cases to be able to pass this independently and not derive the expected result from traversing the spliterator, as that could mask bugs.
>>>> 
>>>> There is no need to create separate classes for primitive tests (you only added explicit for int traversing and not long and double).
>>>> 
>>>> 
>>>> Independently i wonder if test/java/util/stream/bootlib/java.base/java/util/stream/SpliteratorTestHelper.java is the right location. I know it?s used in Streams, but perhaps it and the provider should be placed within a library?
>>>> 
>>>> Paul.
>>>> 
>>>> 
>>>>> Thanks,
>>>>> Amy
>>>>> 
>>>>> On 1/19/17 9:34 PM, Amy Lu wrote:
>>>>> 
>>>>>> java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
>>>>>> java/util/Spliterator/SpliteratorCollisions.java
>>>>>> 
>>>>>> Test functions in above tests are almost duplicate with functions in java/util/stream/SpliteratorTestHelper.java. Test can reuse test functions from SpliteratorTestHelper, but with it?s own DataProvider.
>>>>>> 
>>>>>> Please review the patch for refactoring spliterator traversing tests.
>>>>>> 
>>>>>> bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8169903
>>>>>> 
>>>>>> webrev:
>>>>>> http://cr.openjdk.java.net/~amlu/8169903/webrev.00/
>>>>>> 
>>>>>> 
>>>>>> SpliteratorTestHelper.java has a minor update, added one small testcase that originally from SpliteratorCollisions.testForEach.
>>>>>> 
>>>>>> The two skipped tests in SpliteratorCollisions.java are now enabled back, as mentioned bug has already been fixed.
>>>>>> 256 /* skip this test until 8013649 is fixed
>>>>>> ...
>>>>>> 268 */
>>>>>> 
>>>>>> This patch also brings back Integer.MAX_VALUE test data which requires big memory (and removed in JDK-8169838), in a separate test.
>>>>>> 
>>>>>> Thanks,
>>>>>> Amy
>>>>>> 
> 


From jan.lahoda at oracle.com  Wed Feb  8 20:46:31 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 8 Feb 2017 21:46:31 +0100
Subject: RFR JDK-8173777: Merge javac -Xmodule into javac--patch-module
In-Reply-To: <589A0DC4.5020409@oracle.com>
References: <58989C16.80404@oracle.com> <5898C36D.30902@oracle.com>
	<206f4364-1d18-fed8-840a-f655b235b943@oracle.com>
	<589A0DC4.5020409@oracle.com>
Message-ID: <589B83A7.9020207@oracle.com>

Hi,

Based on some (offline) feedback and further testing, I've updated the 
langtools patch. The new webrev is here:
http://cr.openjdk.java.net/~jlahoda/8173777/langtools.02/

Delta webrev compared to .01:
http://cr.openjdk.java.net/~jlahoda/8173777/langtools.02/delta/webrev/index.html

The changes in this updated version:
-the previous version didn't allow the same file to be under both 
--patch-module and --module-source-path. The updated version allows 
this, and the --patch-module will prevail. This is currently only 
allowed when both --patch-module and --module-source-path agree on the 
name of the module, but this could be trivially removed if desired.

-for incremental compilation, the previous version required that the 
class output is also specified in --patch-module. The updated version 
will automatically use class output to read classfiles for patch modules 
(by virtue of ModuleSymbol.patchOutputLocation).

-the previous version didn't (always) report an error for module-info on 
--patch-module in multi-module mode. This should be fixed now, and there 
should be an error for module-info on patch location even in 
multi-module mode.

I was looking at explicit uses of -Xmodule: in other repositories, and 
there are some in the hotspot repository. All these appear to use a 
utility from the top-level repository:
test/lib/jdk/test/lib/InMemoryJavaCompiler.java
(there are other tests that use @compile/module in various repositories, 
including hotspot, but these need to be coordinated with jtreg). For 
now, I propose to tweak the utility to interpret -Xmodule: itself:
http://cr.openjdk.java.net/~jlahoda/8173777/top-level.00/

Eventually, we could stop using -Xmodule: inside this utility and pass 
the module name explicitly, e.g. encoded in the className, but for now 
this seems acceptable to me.

Feedback is welcome.

Thanks!

Jan


On 7.2.2017 19:11, Jan Lahoda wrote:
> Hi,
>
> Thanks.
>
> I did two small updates to the patches:
> -for langtools repository, I added unwrapping to
> ClientCodeWrapper.WrappedJavaFileManager.getLocationForModule - the
> incoming JavaFileObject is unwrapped, so that we don't pass our wrappers
> to the client's code. Direct link:
> http://cr.openjdk.java.net/~jlahoda/8173777/langtools.01/src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java.udiff.html
>
>
> -for jdk repository, I fixed the:
> test/javax/xml/jaxp/common/8035437/run.sh
> to use a platform specific path separator. This is based on code from
> jdk/test/java/lang/instrument/appendToClassLoaderSearch/CommonSetup.sh
> Direct link:
> http://cr.openjdk.java.net/~jlahoda/8173777/jdk.02/test/javax/xml/jaxp/common/8035437/run.sh.udiff.html
>
>
> (Sorry that I missed this before.)
>
> Updated webrevs:
> -langtools repository:
> http://cr.openjdk.java.net/~jlahoda/8173777/langtools.01/
> -jdk repository:
> http://cr.openjdk.java.net/~jlahoda/8173777/jdk.02/
>
> Thanks,
>     Jan
>
> On 6.2.2017 21:42, Alan Bateman wrote:
>>
>>
>> On 06/02/2017 18:41, Jan Lahoda wrote:
>>> I've updated the jdk repository webrev to wrap long lines:
>>> http://cr.openjdk.java.net/~jlahoda/8173777/jdk.01/
>>>
>>> Jan
>> This looks okay to me.
>>
>> -Alan
>>

From robert.field at oracle.com  Wed Feb  8 21:38:06 2017
From: robert.field at oracle.com (Robert Field)
Date: Wed, 08 Feb 2017 13:38:06 -0800
Subject: RFR JDK-8173777: Merge javac -Xmodule into javac--patch-module
In-Reply-To: <589B83A7.9020207@oracle.com>
References: <58989C16.80404@oracle.com>
	<5898C36D.30902@oracle.com>	<206f4364-1d18-fed8-840a-f655b235b943@oracle.com>	<589A0DC4.5020409@oracle.com>
	<589B83A7.9020207@oracle.com>
Message-ID: <589B8FBE.3060600@oracle.com>

JShell changes to the memory file manager are unchanged in this update 
and so still look good.

-Robert


On 02/08/17 12:46, Jan Lahoda wrote:
> Hi,
>
> Based on some (offline) feedback and further testing, I've updated the 
> langtools patch. The new webrev is here:
> http://cr.openjdk.java.net/~jlahoda/8173777/langtools.02/
>
> Delta webrev compared to .01:
> http://cr.openjdk.java.net/~jlahoda/8173777/langtools.02/delta/webrev/index.html 
>
>
> The changes in this updated version:
> -the previous version didn't allow the same file to be under both 
> --patch-module and --module-source-path. The updated version allows 
> this, and the --patch-module will prevail. This is currently only 
> allowed when both --patch-module and --module-source-path agree on the 
> name of the module, but this could be trivially removed if desired.
>
> -for incremental compilation, the previous version required that the 
> class output is also specified in --patch-module. The updated version 
> will automatically use class output to read classfiles for patch 
> modules (by virtue of ModuleSymbol.patchOutputLocation).
>
> -the previous version didn't (always) report an error for module-info 
> on --patch-module in multi-module mode. This should be fixed now, and 
> there should be an error for module-info on patch location even in 
> multi-module mode.
>
> I was looking at explicit uses of -Xmodule: in other repositories, and 
> there are some in the hotspot repository. All these appear to use a 
> utility from the top-level repository:
> test/lib/jdk/test/lib/InMemoryJavaCompiler.java
> (there are other tests that use @compile/module in various 
> repositories, including hotspot, but these need to be coordinated with 
> jtreg). For now, I propose to tweak the utility to interpret -Xmodule: 
> itself:
> http://cr.openjdk.java.net/~jlahoda/8173777/top-level.00/
>
> Eventually, we could stop using -Xmodule: inside this utility and pass 
> the module name explicitly, e.g. encoded in the className, but for now 
> this seems acceptable to me.
>
> Feedback is welcome.
>
> Thanks!
>
> Jan
>
>
> On 7.2.2017 19:11, Jan Lahoda wrote:
>> Hi,
>>
>> Thanks.
>>
>> I did two small updates to the patches:
>> -for langtools repository, I added unwrapping to
>> ClientCodeWrapper.WrappedJavaFileManager.getLocationForModule - the
>> incoming JavaFileObject is unwrapped, so that we don't pass our wrappers
>> to the client's code. Direct link:
>> http://cr.openjdk.java.net/~jlahoda/8173777/langtools.01/src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java.udiff.html 
>>
>>
>>
>> -for jdk repository, I fixed the:
>> test/javax/xml/jaxp/common/8035437/run.sh
>> to use a platform specific path separator. This is based on code from
>> jdk/test/java/lang/instrument/appendToClassLoaderSearch/CommonSetup.sh
>> Direct link:
>> http://cr.openjdk.java.net/~jlahoda/8173777/jdk.02/test/javax/xml/jaxp/common/8035437/run.sh.udiff.html 
>>
>>
>>
>> (Sorry that I missed this before.)
>>
>> Updated webrevs:
>> -langtools repository:
>> http://cr.openjdk.java.net/~jlahoda/8173777/langtools.01/
>> -jdk repository:
>> http://cr.openjdk.java.net/~jlahoda/8173777/jdk.02/
>>
>> Thanks,
>>     Jan
>>
>> On 6.2.2017 21:42, Alan Bateman wrote:
>>>
>>>
>>> On 06/02/2017 18:41, Jan Lahoda wrote:
>>>> I've updated the jdk repository webrev to wrap long lines:
>>>> http://cr.openjdk.java.net/~jlahoda/8173777/jdk.01/
>>>>
>>>> Jan
>>> This looks okay to me.
>>>
>>> -Alan
>>>


From amy.lu at oracle.com  Thu Feb  9 04:35:15 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 9 Feb 2017 12:35:15 +0800
Subject: JDK 9 RFR of JDK-8169903: Refactor spliterator traversing tests
	into a library
In-Reply-To: <55DA3691-5915-4B8B-88ED-A2BB6BA0D857@oracle.com>
References: <8f7822d7-e66c-8d53-89f4-9d9b7f9a713f@oracle.com>
	<e78193c5-565b-3034-1131-2fd1a0f94624@oracle.com>
	<39AF9B61-1680-4D3E-8523-EAC6DC8EB550@oracle.com>
	<573cbb38-61d0-7f03-3918-fe0ee5a4f54b@oracle.com>
	<2F67C7EC-0FC5-4E1B-B287-E1491B061926@oracle.com>
	<b9aa4212-9901-1d55-192b-475205b50f8e@oracle.com>
	<55DA3691-5915-4B8B-88ED-A2BB6BA0D857@oracle.com>
Message-ID: <888df139-abae-69cf-87ca-408e53ed8852@oracle.com>

On 2/9/17 1:50 AM, Paul Sandoz wrote:
> SpliteratorCollisions
> ?
>
>   232         testForEach(exp, s, (Consumer<HashableInteger> b) -> b);
>
> Do you require the type declaration for the lambda function parameter?
>
> It might be possible to use UnaryOperator.identity() in those cases.
>

Right :-)

Fixed in http://cr.openjdk.java.net/~amlu/8169903/webrev.03/

Thanks,
Amy

From huaming.li at oracle.com  Thu Feb  9 07:24:39 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Thu, 9 Feb 2017 15:24:39 +0800
Subject: RFR of JDK-8173957: Fix @since in module-info.java in dev/jdk repo
Message-ID: <150a1bf4-3a7b-98d4-51e3-a1267e2427d9@oracle.com>

Would you please review the below patch?

bug: https://bugs.openjdk.java.net/browse/JDK-8173957

webrev: http://cr.openjdk.java.net/~mli/8173957/webrev.00/


Thank you

-Hamlin


From sergei.kovalev at oracle.com  Thu Feb  9 08:05:53 2017
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Thu, 9 Feb 2017 11:05:53 +0300
Subject: RFR(s): 8174194: Several java/lang tests failing due to
	undeclared module dependencies.
In-Reply-To: <AE0C8335-49C3-41C6-B625-03355A4AF734@oracle.com>
References: <a1512a53-77f6-4fde-d4a8-9638268362d5@oracle.com>
	<AE0C8335-49C3-41C6-B625-03355A4AF734@oracle.com>
Message-ID: <3edad862-4a89-9846-7d87-43d03a417eca@oracle.com>

Hi Mandy,

Thank you for review and remarks.

http://cr.openjdk.java.net/~skovalev/8174194/webrev.01/


08.02.17 19:06, Mandy Chung wrote:
>> On Feb 8, 2017, at 6:13 AM, Sergei Kovalev <sergei.kovalev at oracle.com> wrote:
>>
>> Thank you for review.
>>
>>> On 08/02/17 13:51, Sergei Kovalev wrote:
>>> WebRev: http://cr.openjdk.java.net/~skovalev/8174194/webrev.00/
>>>
> CheckPackageAccess.java
>    86             System.out.println(String.format(MODULE_TEXT, moduleName, isModulePresent ? "" : " NOT"));
>
> this can be simplified with:
>
> System.out.format(MODULE_TEXT, moduleName, isModulePresent ? "" : " NOT?);
>
> I suggest to inline MODULE_TEXT in this method as it?s clear what it?s printed.  No need for MODULE_TEXT varaiable.  Please wrap long lines.
>
> LFSingleThreadCachingTest.java
>    - can you keep @modules in alphatical order.
>
> thanks
> Mandy

-- 
With best regards,
Sergei


From amy.lu at oracle.com  Thu Feb  9 09:32:27 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 9 Feb 2017 17:32:27 +0800
Subject: JDK 9 RFR for JDK-8174241: ProblemList update for TestWsImport,
	JdbMethodExitTest and jimage tests
Message-ID: <91db090f-0b77-381b-a261-55334f32a8e4@oracle.com>

Please review the ProblemList.txt cleanup on updating bugid for several 
tests.

javax/xml/ws/clientjar/TestWsImport.java    8170370 generic-all
This test is in ProblemList, related bug JDK-8170370 has been resolved. 
Test is going to be revisited in JDK-8173317

tools/jimage/JImageExtractTest.java 8169713 generic-all
tools/jimage/JImageListTest.java 8169713 generic-all
tools/jimage/JImageVerifyTest.java 8169713 generic-all
Mentioned bug JDK-8169713 has been closed, while test is going to be 
fixed in JDK-8170120

com/sun/jdi/JdbMethodExitTest.sh 6902121 generic-all
Mentioned bug JDK-6902121 has been closed, test is going to be revisited 
in JDK-8171483

Thanks,
Amy



--- old/test/ProblemList.txt	2017-02-09 17:28:52.000000000 +0800
+++ new/test/ProblemList.txt	2017-02-09 17:28:51.000000000 +0800
@@ -253,9 +253,9 @@
  
  tools/launcher/FXLauncherTest.java                              8068049 linux-all,macosx-all
  
-tools/jimage/JImageExtractTest.java                             8169713 generic-all
-tools/jimage/JImageListTest.java                                8169713 generic-all
-tools/jimage/JImageVerifyTest.java                              8169713 generic-all
+tools/jimage/JImageExtractTest.java                             8170120 generic-all
+tools/jimage/JImageListTest.java                                8170120 generic-all
+tools/jimage/JImageVerifyTest.java                              8170120 generic-all
  
  
  tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java       8169971 windows-x64
@@ -266,7 +266,7 @@
  
  com/sun/jdi/RedefineImplementor.sh                              8004127 generic-all
  
-com/sun/jdi/JdbMethodExitTest.sh                                6902121 generic-all
+com/sun/jdi/JdbMethodExitTest.sh                                8171483 generic-all
  
  com/sun/jdi/RepStep.java                                        8043571 generic-all
  
@@ -307,6 +307,6 @@
  
  javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 8169737 linux-all
  
-javax/xml/ws/clientjar/TestWsImport.java			8170370 generic-all
+javax/xml/ws/clientjar/TestWsImport.java			8173317 generic-all
  
  ############################################################################




From denis.kononenko at oracle.com  Thu Feb  9 10:03:53 2017
From: denis.kononenko at oracle.com (Denis Kononenko)
Date: Thu, 9 Feb 2017 02:03:53 -0800 (PST)
Subject: [9] RFR 8170113: jimage extract to readonly directory causes
	MissingResourceException
Message-ID: <f40ab9fa-09af-4a22-be83-95fd0c100392@default>


Hi,

> 
> On 06/02/2017 10:27, Denis Kononenko wrote:
> > Hi,
> >
> > Could someone please review this very small fix.
> >
> > The class JImageTask
> (src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java) has
> references to an info message by 'err.cannot.create.dir' key.
> Unfortunately the corresponding resource file
> (src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties)
> doesn't contain this key. This results in long not user friendly
> stacktraces in output when jimage cannot create a directory. The fix
> is very small, I added the missing definition into the resource file.
> >
> > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170113
> > WEBREV: http://cr.openjdk.java.net/~dkononenko/8170113/webrev.00
> >
> This looks okay as a short term fix but I think that extract need to 
> be-implemented to use the new file system API so that the reasons why
> 
> the directory can be printed too. Also there is an anomaly in errors 
> related to the directory result in an error message whereas any errors
> 
> extracting to the directory lead to an exception.
> 
> -Alan


I think we might have to defer such big change to the next release. If there's no objections I'd propose to deliver this fix AS IS and open a new enhancement request to re-implement 'extract' method.

Thank you,
Denis.

From lance.andersen at oracle.com  Thu Feb  9 12:18:26 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 9 Feb 2017 07:18:26 -0500
Subject: RFR of JDK-8173957: Fix @since in module-info.java in dev/jdk repo
In-Reply-To: <150a1bf4-3a7b-98d4-51e3-a1267e2427d9@oracle.com>
References: <150a1bf4-3a7b-98d4-51e3-a1267e2427d9@oracle.com>
Message-ID: <D4A88438-32B6-4FFB-AAA6-F58F49FBAE07@oracle.com>

Hi Hamlin,

This is fine.  I am not sure why when I added the comments to the various module-info.java, I did not include @since.

Best
Lance
> On Feb 9, 2017, at 2:24 AM, Hamlin Li <huaming.li at oracle.com> wrote:
> 
> Would you please review the below patch?
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8173957
> 
> webrev: http://cr.openjdk.java.net/~mli/8173957/webrev.00/
> 
> 
> Thank you
> 
> -Hamlin
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From Alan.Bateman at oracle.com  Thu Feb  9 12:22:36 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 9 Feb 2017 12:22:36 +0000
Subject: RFR of JDK-8173957: Fix @since in module-info.java in dev/jdk repo
In-Reply-To: <150a1bf4-3a7b-98d4-51e3-a1267e2427d9@oracle.com>
References: <150a1bf4-3a7b-98d4-51e3-a1267e2427d9@oracle.com>
Message-ID: <0af61f07-9b90-c7e0-a53b-e97b0d22ab75@oracle.com>

On 09/02/2017 07:24, Hamlin Li wrote:

> Would you please review the below patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8173957
>
> webrev: http://cr.openjdk.java.net/~mli/8173957/webrev.00/
Looks okay, it would be good to add it to the modules in the other repos 
while you're at it.

-Alan

From lance.andersen at oracle.com  Thu Feb  9 12:23:06 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 9 Feb 2017 07:23:06 -0500
Subject: JDK 9 RFR for JDK-8174241: ProblemList update for TestWsImport,
	JdbMethodExitTest and jimage tests
In-Reply-To: <91db090f-0b77-381b-a261-55334f32a8e4@oracle.com>
References: <91db090f-0b77-381b-a261-55334f32a8e4@oracle.com>
Message-ID: <B7E73FE6-3E51-482D-BF3E-7F776B1DDCFD@oracle.com>

+1
> On Feb 9, 2017, at 4:32 AM, Amy Lu <amy.lu at oracle.com> wrote:
> 
> Please review the ProblemList.txt cleanup on updating bugid for several tests.
> 
> javax/xml/ws/clientjar/TestWsImport.java    8170370 generic-all
> This test is in ProblemList, related bug JDK-8170370 has been resolved. Test is going to be revisited in JDK-8173317
> 
> tools/jimage/JImageExtractTest.java 8169713 generic-all
> tools/jimage/JImageListTest.java 8169713 generic-all
> tools/jimage/JImageVerifyTest.java 8169713 generic-all
> Mentioned bug JDK-8169713 has been closed, while test is going to be fixed in JDK-8170120
> 
> com/sun/jdi/JdbMethodExitTest.sh 6902121 generic-all
> Mentioned bug JDK-6902121 has been closed, test is going to be revisited in JDK-8171483
> 
> Thanks,
> Amy
> 
> 
> 
> --- old/test/ProblemList.txt	2017-02-09 17:28:52.000000000 +0800
> +++ new/test/ProblemList.txt	2017-02-09 17:28:51.000000000 +0800
> @@ -253,9 +253,9 @@
>  tools/launcher/FXLauncherTest.java                              8068049 linux-all,macosx-all
> -tools/jimage/JImageExtractTest.java                             8169713 generic-all
> -tools/jimage/JImageListTest.java                                8169713 generic-all
> -tools/jimage/JImageVerifyTest.java                              8169713 generic-all
> +tools/jimage/JImageExtractTest.java                             8170120 generic-all
> +tools/jimage/JImageListTest.java                                8170120 generic-all
> +tools/jimage/JImageVerifyTest.java                              8170120 generic-all
>   tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java       8169971 windows-x64
> @@ -266,7 +266,7 @@
>  com/sun/jdi/RedefineImplementor.sh                              8004127 generic-all
> -com/sun/jdi/JdbMethodExitTest.sh                                6902121 generic-all
> +com/sun/jdi/JdbMethodExitTest.sh                                8171483 generic-all
>  com/sun/jdi/RepStep.java                                        8043571 generic-all
> @@ -307,6 +307,6 @@
>  javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 8169737 linux-all
> -javax/xml/ws/clientjar/TestWsImport.java			8170370 generic-all
> +javax/xml/ws/clientjar/TestWsImport.java			8173317 generic-all
>  ############################################################################
> 
> 
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From andrey.x.nazarov at oracle.com  Thu Feb  9 15:30:55 2017
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Thu, 9 Feb 2017 18:30:55 +0300
Subject: [9] RFR 8170113: jimage extract to readonly directory causes
	MissingResourceException
In-Reply-To: <f40ab9fa-09af-4a22-be83-95fd0c100392@default>
References: <f40ab9fa-09af-4a22-be83-95fd0c100392@default>
Message-ID: <46CAA49D-859F-481F-9C33-72968F8E7697@oracle.com>

Hi,

looks ok for me. Simple and safe fix.

?Andrey
> On 9 Feb 2017, at 13:03, Denis Kononenko <denis.kononenko at oracle.com> wrote:
> 
> 
> Hi,
> 
>> 
>> On 06/02/2017 10:27, Denis Kononenko wrote:
>>> Hi,
>>> 
>>> Could someone please review this very small fix.
>>> 
>>> The class JImageTask
>> (src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java) has
>> references to an info message by 'err.cannot.create.dir' key.
>> Unfortunately the corresponding resource file
>> (src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties)
>> doesn't contain this key. This results in long not user friendly
>> stacktraces in output when jimage cannot create a directory. The fix
>> is very small, I added the missing definition into the resource file.
>>> 
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170113
>>> WEBREV: http://cr.openjdk.java.net/~dkononenko/8170113/webrev.00
>>> 
>> This looks okay as a short term fix but I think that extract need to 
>> be-implemented to use the new file system API so that the reasons why
>> 
>> the directory can be printed too. Also there is an anomaly in errors 
>> related to the directory result in an error message whereas any errors
>> 
>> extracting to the directory lead to an exception.
>> 
>> -Alan
> 
> 
> I think we might have to defer such big change to the next release. If there's no objections I'd propose to deliver this fix AS IS and open a new enhancement request to re-implement 'extract' method.
> 
> Thank you,
> Denis.


From volker.simonis at gmail.com  Thu Feb  9 16:18:00 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 9 Feb 2017 17:18:00 +0100
Subject: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify
	what happens if the passed supplier is null itself
Message-ID: <CA+3eh13qSnt+CbyVNzB0eRp-rQkPhPu82tNhawhM11Q1Gw9qkg@mail.gmail.com>

Hi,

I want to finally resolve this long standing issue (or close it as
"will not fix" if that's not possible):

http://cr.openjdk.java.net/~simonis/webrevs/2017/8033909/

This change has already been discussed in length on the mailing list:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/thread.html#24989

and in the bug comments:

https://bugs.openjdk.java.net/browse/JDK-8033909

So I'll give just a short summary here:

 - Objects.requireNonNull(T, Supplier) does not check for the Supplier
argument being null. Instead it relies on the fact, that the VM will
implicitly throw a NullPointerException when it calls .get on the
Supplier argument during the creation of the explicit
NullPointerException which it is supposed to throw.

- this behavior slightly differs from Objects.requireNonNull(T,
String) which simply creates a NullPointerException with a null
message in the case where the String argument is null.

- the difference is not evident in the OpenJDK, because the HotSpot VM
creates a NPE with a null message by default if we call a method on a
null object.

- however creating such a NPE with a null message when invoking a
method on a null object is not enforced by the standard, and other
implementations can do better :) For the following trivial program:

public class NonNull {
  public static void main(String[] args) {
    Supplier<String> ss = null;
    Object o = Objects.requireNonNull(null, ss);
  }
}

the current OpenJDK implementation returns:

Exception in thread "main" java.lang.NullPointerException
    at java.util.Objects.requireNonNull(Objects.java:290)
    at NonNull.main(NonNull.java:8)

but the SAP JVM will print:

Exception in thread "main" java.lang.NullPointerException: while
trying to invoke the method java.util.function.Supplier.get() of a
null object loaded from local variable 'messageSupplier'
    at java.util.Objects.requireNonNull(Objects.java:290)
    at NonNull.main(NonNull.java:8)

which is at least confusing for a call to Objects.requireNonNul() with
a null Supplier. We think the exception should be the same like the
one we get when invoking Objects.requireNonNul() with a null String.

- because of this difference (and because we like our extended
Exception messages :) the JCK test for Objects.requireNonNul(T,
Supplier) (i.e.
api/java_util/Objects/index.html#RequireNonNullMessageSupplier) was
removed from TCK 8 and is still commented out in TCK 9
(npe_checkingNullSupplier() in RequireNonNullMessageSupplier.java).

I really think that the simplest and most natural fix for this problem
is to simply check for a null Supplier argument and create the NPE
with an explicit null message in that case (as outlined in the
webrev). This:
 - makes the two requireNonNul() overloads for String and Supplier
behave the same (which I think was the initial intention).
 - doesn't require documentation changes
 - makes it possible to write a simple and conforming TCK test

If we can't agree on this quickly, I suggest to close the issue as
"will-not-fix" and leave it untested by the TCK.

Thank you and best regards,
Volker

PS: the 'XS' obviously only applies to the fix, not to this message :)

From huizhe.wang at oracle.com  Thu Feb  9 16:25:15 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 9 Feb 2017 08:25:15 -0800
Subject: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates
	namespace prefixes if namespace is given as URI only
In-Reply-To: <95d39d5bdb2f404fa97cbe77d314d061@derote13de46.global.corp.sap>
References: <dcceb6e6de034a748d881d2f3eb19e47@derote13de46.global.corp.sap>
	<589A68B4.7010307@oracle.com>
	<95d39d5bdb2f404fa97cbe77d314d061@derote13de46.global.corp.sap>
Message-ID: <abe747df-0b0f-f1e7-6451-b9f5c4801c0f@oracle.com>


On 2/7/2017 11:28 PM, Langer, Christoph wrote:
>
> Hi Joe,
>
> welcome back.
>

Thanks!

> This sounds reasonable. I?ll prepare a change for JDK10.
>

Hopefully it'd open soon so that you don't have to keep it for too long.

Best,
Joe

> Thanks
>
> Christoph
>
> *From:*Joe Wang [mailto:huizhe.wang at oracle.com]
> *Sent:* Mittwoch, 8. Februar 2017 01:39
> *To:* Langer, Christoph <christoph.langer at sap.com>
> *Cc:* core-libs-dev at openjdk.java.net; Aleksej Efimov 
> <aleksej.efimov at oracle.com>
> *Subject:* Re: RFR - Update: 8168664 [JAXP] XALAN: xsl:element 
> generates namespace prefixes if namespace is given as URI only
>
> Hi Christoph,
>
> As we discussed, let's target this for JDK 10 as a spec change at this 
> stage for JDK 9 is too late. Removing the namespace generation would 
> be another reason to do this in JDK 10 since then, we wouldn't need 
> the additional property.
>
> Thanks,
> Joe
>
> On 1/31/17, 11:02 AM, Langer, Christoph wrote:
>
>     Hi Joe,
>
>     evenutally I have updated my webrev for this issue:
>     http://cr.openjdk.java.net/~clanger/webrevs/8168664.1/
>     <http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664.1/>
>
>     I?ve implemented your suggestion to add a property
>     ?jdk.xml.generatePrefix? which is true by default. I also added a
>     testcase which tests the correct behavior with
>     ?-Djdk.xml.generatePrefix=false?.
>
>     Generally, I think namespace prefix generation at this place is
>     not needed. Or would you know of or be able to construct a case
>     where it is really required? If not, I rather think namespace
>     generation at this place should be thrown out unconditionally.
>     Maybe for JDK10? In case it is removed, it would render the test
>     javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java which
>     was implemented recently by Alex for bug
>     https://bugs.openjdk.java.net/browse/JDK-8167179 obsolete in its
>     current form. However, the namespace generation function is still
>     used some place for attribute namespaces.
>
>     For JDK9 I can imagine the change of this webrev going in ?
>     however, as we already discussed, you would have to do a ccc for me.
>
>     Thanks & Best regards
>
>     Christoph
>
>     *From:*Langer, Christoph
>     *Sent:* Dienstag, 25. Oktober 2016 15:39
>     *To:* core-libs-dev at openjdk.java.net
>     <mailto:core-libs-dev at openjdk.java.net>
>     *Subject:* RFR (JAXP): 8168664 [JAXP] XALAN: xsl:element generates
>     namespace prefixes if namespace is given as URI only
>
>     Hi JAXP experts,
>
>     please review a fix for a new issue regarding namespace handling
>     in Xalan with xsl:element.
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8168664
>     <https://bugs.openjdk.java.net/browse/JDK-8168664>
>
>     Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8168664.0/
>     <http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664.0/>
>
>     I?m not 100% sure if this is the right way to go or if it would
>     break some correct behavior elsewhere. But I think the current
>     behavior is either not correct or at least it is not required to
>     generate new xsl namespace prefixes if the namespace comes in as
>     URI only to an xsl:element node. The interpretative transformer
>     from the Apache Xalan project will also produce the expected
>     output, different to the compiled XSLTC here.
>
>     In the webrev, my changes to XslElement.java are only
>     cosmetical/comments, the behavior does not change. In
>     BasisLibrary.java I also took the opportunity to remove the $Id
>     tag and the unused method ?nodeList2IteratorUsingHandleFromNode?.
>
>     If you think my change is good, I?ll also add a test that runs the
>     transformation which can be found in the bug?
>
>     Thanks & best regards
>
>     Christoph
>


From jeff.dinkins at oracle.com  Thu Feb  9 16:32:56 2017
From: jeff.dinkins at oracle.com (Jeff Dinkins)
Date: Thu, 9 Feb 2017 10:32:56 -0600
Subject: RFR(XS): 8033909: Objects.requireNonNull(T,
	Supplier) doesn't specify what happens if the passed supplier is null
	itself
In-Reply-To: <CA+3eh13qSnt+CbyVNzB0eRp-rQkPhPu82tNhawhM11Q1Gw9qkg@mail.gmail.com>
References: <CA+3eh13qSnt+CbyVNzB0eRp-rQkPhPu82tNhawhM11Q1Gw9qkg@mail.gmail.com>
Message-ID: <7A11D19E-FBF6-4973-A38E-BA5D18C8F52F@oracle.com>


Adding Mike?s current email.

-jeff

> On Feb 9, 2017, at 10:18 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> Hi,
> 
> I want to finally resolve this long standing issue (or close it as
> "will not fix" if that's not possible):
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2017/8033909/
> 
> This change has already been discussed in length on the mailing list:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/thread.html#24989
> 
> and in the bug comments:
> 
> https://bugs.openjdk.java.net/browse/JDK-8033909
> 
> So I'll give just a short summary here:
> 
> - Objects.requireNonNull(T, Supplier) does not check for the Supplier
> argument being null. Instead it relies on the fact, that the VM will
> implicitly throw a NullPointerException when it calls .get on the
> Supplier argument during the creation of the explicit
> NullPointerException which it is supposed to throw.
> 
> - this behavior slightly differs from Objects.requireNonNull(T,
> String) which simply creates a NullPointerException with a null
> message in the case where the String argument is null.
> 
> - the difference is not evident in the OpenJDK, because the HotSpot VM
> creates a NPE with a null message by default if we call a method on a
> null object.
> 
> - however creating such a NPE with a null message when invoking a
> method on a null object is not enforced by the standard, and other
> implementations can do better :) For the following trivial program:
> 
> public class NonNull {
>  public static void main(String[] args) {
>    Supplier<String> ss = null;
>    Object o = Objects.requireNonNull(null, ss);
>  }
> }
> 
> the current OpenJDK implementation returns:
> 
> Exception in thread "main" java.lang.NullPointerException
>    at java.util.Objects.requireNonNull(Objects.java:290)
>    at NonNull.main(NonNull.java:8)
> 
> but the SAP JVM will print:
> 
> Exception in thread "main" java.lang.NullPointerException: while
> trying to invoke the method java.util.function.Supplier.get() of a
> null object loaded from local variable 'messageSupplier'
>    at java.util.Objects.requireNonNull(Objects.java:290)
>    at NonNull.main(NonNull.java:8)
> 
> which is at least confusing for a call to Objects.requireNonNul() with
> a null Supplier. We think the exception should be the same like the
> one we get when invoking Objects.requireNonNul() with a null String.
> 
> - because of this difference (and because we like our extended
> Exception messages :) the JCK test for Objects.requireNonNul(T,
> Supplier) (i.e.
> api/java_util/Objects/index.html#RequireNonNullMessageSupplier) was
> removed from TCK 8 and is still commented out in TCK 9
> (npe_checkingNullSupplier() in RequireNonNullMessageSupplier.java).
> 
> I really think that the simplest and most natural fix for this problem
> is to simply check for a null Supplier argument and create the NPE
> with an explicit null message in that case (as outlined in the
> webrev). This:
> - makes the two requireNonNul() overloads for String and Supplier
> behave the same (which I think was the initial intention).
> - doesn't require documentation changes
> - makes it possible to write a simple and conforming TCK test
> 
> If we can't agree on this quickly, I suggest to close the issue as
> "will-not-fix" and leave it untested by the TCK.
> 
> Thank you and best regards,
> Volker
> 
> PS: the 'XS' obviously only applies to the fix, not to this message :)


From denis.kononenko at oracle.com  Thu Feb  9 18:27:30 2017
From: denis.kononenko at oracle.com (Denis Kononenko)
Date: Thu, 9 Feb 2017 10:27:30 -0800 (PST)
Subject: [9] RFR: 8169715: jimage fails with IAE when attempts to inspect an
	empty file
Message-ID: <7666a451-ff4f-4850-a373-9c878b77a51f@default>


  Hi,

Could please someone review the fix for JDK-8169715.
  
The problem occurs when jimage tool is attempting to read an empty or incomplete image. The current implementation works with ByteBuffer and always relies on that there's enough data to inspect the image. This results in IAE inside of BasicImageReader.slice method when the buffer is smaller then it's expected.

I added a few checks to avoid IAE and throw IOException with a more descriptive text.


  BUGURL: https://bugs.openjdk.java.net/browse/JDK-8169715
  WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.01

  Thank you,
  Denis.

From huizhe.wang at oracle.com  Thu Feb  9 22:15:29 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 9 Feb 2017 14:15:29 -0800
Subject: Update: RFR 8172974 [JAXP] XALAN: Wrong result when transforming
	namespace unaware StAX Input
In-Reply-To: <589A6C4C.60302@oracle.com>
References: <3f43563228ef4f7ca2eed6281698a17c@derote13de46.global.corp.sap>
	<589A6C4C.60302@oracle.com>
Message-ID: <b831884c-627d-5551-cb0c-2d12d0c55b9b@oracle.com>

Hi Christoph,

The performance results showed two regressions, one on Linux and another 
Solaris SPARC, while at the same time a bit more than half of the 
results across 5 platforms were negative. This is unfortunate. We're too 
close to the release date, it's super sensitive for jaxp on the 
performance front. I'd like to suggest that we move this patch to a 
9-update or 10 when we'd have plenty of time to deal with any possible 
fallout. I consulted our performance expert and this is also his 
recommendation. I hope you'd understand.

Thanks,
Joe

On 2/7/2017 4:54 PM, Joe Wang wrote:
> Hi Christoph,
>
> We'll double-check whether there's any performance implications. 
> Please give us a couple of (or few) days.
>
> Thanks,
> Joe
>
> On 1/30/17, 7:28 AM, Langer, Christoph wrote:
>> Hi Joe,
>>
>> I've updated my webrev for 8172974 after pulling out the refactoring 
>> of javax/xml/jaxp/unittest/transform/TransformerTest.java to Bug 
>> 8173602: http://cr.openjdk.java.net/~clanger/webrevs/8172974.1/
>>
>> After exchanging some off-list mails with Lance and Daniel, we came 
>> to the conclusion that you should decide about this one when you are 
>> back. The changes are merely cleanups apart from 
>> com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM2.startElement(), 
>> which to me seem natural after 8169631, though.
>>
>> Thanks,
>> Christoph
>>
>>> -----Original Message-----
>>> From: Langer, Christoph
>>> Sent: Mittwoch, 18. Januar 2017 22:55
>>> To: 'huizhe wang'<huizhe.wang at oracle.com>; 
>>> core-libs-dev at openjdk.java.net
>>> Subject: RE: RFR 8172974 [JAXP] XALAN: Wrong result when transforming
>>> namespace unaware StAX Input
>>>
>>> Hi Joe,
>>>
>>> generally, you are right, XSLT requires namespace support. For 
>>> parsing the
>>> stylesheet, it is definitely a hard requirement. Otherwise this 
>>> would not make
>>> sense at all. For instance xsl directives are in the xsl namespace. 
>>> That
>>> requirement is what the FAQ you are referencing [1] is talking about.
>>>
>>> As for the InputSource which is to be processed, it is probably also 
>>> not a right to
>>> use non namespace aware parsing. But still it's not forbidden. For 
>>> instance, the
>>> JavaDoc for SAXSource [2] states this:
>>> "Note that XSLT requires namespace support. Attempting to transform 
>>> an input
>>> source that is not generated with a namespace-aware parser may 
>>> result in
>>> errors. Parsers can be made namespace aware by calling the
>>> SAXParserFactory.setNamespaceAware(boolean awareness) method."
>>>
>>> So, I agree, we are in the error space here. But still I think the 
>>> result of non
>>> namespace aware parsing should be the same for all types of input 
>>> source. And
>>> at the moment it is the same for DOMSource and SAXSource but not for
>>> StAXSource. From that point of view I think my fix makes sense 
>>> (along with the
>>> other cleanups).
>>>
>>> Best regards
>>> Christoph
>>>
>>> [1] https://xml.apache.org/xalan-j/faq.html#faq-N10207
>>> [2]
>>> https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSource 
>>>
>>> .html
>>>
>>>
>>>> -----Original Message-----
>>>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
>>>> Sent: Mittwoch, 18. Januar 2017 22:12
>>>> To: Langer, Christoph<christoph.langer at sap.com>; core-libs-
>>>> dev at openjdk.java.net
>>>> Subject: Re: RFR 8172974 [JAXP] XALAN: Wrong result when transforming
>>>> namespace unaware StAX Input
>>>>
>>>> Hi Christoph,
>>>>
>>>> Xalan requires the underlying parser to be namespace aware. Please 
>>>> refer
>>>> to https://xml.apache.org/xalan-j/faq.html#faq-N10207
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>> On 1/18/2017 8:26 AM, Langer, Christoph wrote:
>>>>> Hi,
>>>>>
>>>>> please review a change for JAXP.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172974
>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172974.0/
>>>>>
>>>>> When enhancing the test for https://bugs.openjdk.java.net/browse/JDK-
>>>> 8023653, I saw that there's still an issue with StAXInputSource 
>>>> which is not
>>>> namespace aware. This needs a small update in
>>>>
>>> src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dt 
>>>
>>>> m/SAX2DTM2.java. Furthermore, I added the fixed warnings and 
>>>> formattings
>>>> from the proposal 
>>>> http://cr.openjdk.java.net/~clanger/webrevs/8023653.0/ to
>>>> this webrev, as 8023653 is an enhancement and might not go in in 
>>>> the near
>>>> future.
>>>>> I also enhanced the TransformerTest to utilize data providers now 
>>>>> and test
>>> a
>>>> comprehensive matrix of XALAN input.
>>>>> Thanks in advance and Best regards
>>>>> Christoph
>>>>>


From huaming.li at oracle.com  Fri Feb 10 02:24:42 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Fri, 10 Feb 2017 10:24:42 +0800
Subject: RFR of JDK-8173957: Fix @since in module-info.java in dev/jdk repo
In-Reply-To: <0af61f07-9b90-c7e0-a53b-e97b0d22ab75@oracle.com>
References: <150a1bf4-3a7b-98d4-51e3-a1267e2427d9@oracle.com>
	<0af61f07-9b90-c7e0-a53b-e97b0d22ab75@oracle.com>
Message-ID: <ba720158-7725-bb54-c815-f02dca3fafcf@oracle.com>


On 2017/2/9 20:22, Alan Bateman wrote:
> On 09/02/2017 07:24, Hamlin Li wrote:
>
>> Would you please review the below patch?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8173957
>>
>> webrev: http://cr.openjdk.java.net/~mli/8173957/webrev.00/
> Looks okay, it would be good to add it to the modules in the other 
> repos while you're at it.
Hi Alan,

Sure, I will add @since to modules in other repos.

Thank you
-Hamlin
>
> -Alan


From huaming.li at oracle.com  Fri Feb 10 03:09:49 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Fri, 10 Feb 2017 11:09:49 +0800
Subject: RFR of JDK-8174696: Fix @since in module-info.java in dev/jaxp repo
Message-ID: <3ffb602a-dbf4-b67c-9971-7c883c8d0457@oracle.com>

Would you please review the below patch?

bug: https://bugs.openjdk.java.net/browse/JDK-8174696

webrev: http://cr.openjdk.java.net/~mli/8174696/webrev.00/


Thank you

-Hamlin


From huaming.li at oracle.com  Fri Feb 10 03:22:03 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Fri, 10 Feb 2017 11:22:03 +0800
Subject: RFR of JDK-8174697: Fix @since in module-info.java in dev/jaxws repo
Message-ID: <5e418f45-e496-4a68-37a0-ca6f15399547@oracle.com>

Would you please review the below patch?

bug: https://bugs.openjdk.java.net/browse/JDK-8174697
webrev: http://cr.openjdk.java.net/~mli/8174697/webrev.00/

Thank you
-Hamlin

From huaming.li at oracle.com  Fri Feb 10 03:29:30 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Fri, 10 Feb 2017 11:29:30 +0800
Subject: RFR of JDK-8174698: Fix @since in module-info.java in dev/corba repo
Message-ID: <9d6429a2-d6e2-22f4-337b-e3bd3e860e95@oracle.com>

Would you please review the below patch?

bug: https://bugs.openjdk.java.net/browse/JDK-8174698

webrev: http://cr.openjdk.java.net/~mli/8174698/webrev.00/


Thank you

-Hamlin


From Alan.Bateman at oracle.com  Fri Feb 10 07:00:16 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 10 Feb 2017 07:00:16 +0000
Subject: RFR of JDK-8174698: Fix @since in module-info.java in dev/corba
	repo
In-Reply-To: <9d6429a2-d6e2-22f4-337b-e3bd3e860e95@oracle.com>
References: <9d6429a2-d6e2-22f4-337b-e3bd3e860e95@oracle.com>
Message-ID: <4ae75ddd-2414-1771-1883-7da9724702ab@oracle.com>

On 10/02/2017 03:29, Hamlin Li wrote:

> Would you please review the below patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8174698
>
> webrev: http://cr.openjdk.java.net/~mli/8174698/webrev.00/
Adding @since 9 to each of the java.* modules in the corba, jaxp and 
jaxws repos looks fine.

-Alan

From erik.joelsson at oracle.com  Fri Feb 10 08:48:30 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 10 Feb 2017 09:48:30 +0100
Subject: jdk10 : simplify jexec build settings
In-Reply-To: <20161b2fc66242b6930e179f0bbdf121@DEWDFE13DE14.global.corp.sap>
References: <92a51f307d33465faca64e8d43c176bc@DEWDFE13DE14.global.corp.sap>
	<abf8e046-3528-1c9c-ad12-ce786239b385@oracle.com>
	<20161b2fc66242b6930e179f0bbdf121@DEWDFE13DE14.global.corp.sap>
Message-ID: <ec35e180-114b-d2c0-c9ff-7ff17674898d@oracle.com>

Since the file has never been built, I would say remove the macosx 
source file. You can point directly to the unix source dir if you prefer 
too. No need to have dead logic for macosx in the makefile.

/Erik


On 2017-02-09 15:27, Baesken, Matthias wrote:
>
> I compared the  jexec.c  versions for  macosx and unix
>
> ( jdk/src/java.base/macosx/native/launcher/jexec.c    and 
>  jdk/src/java.base/unix/native/launcher/jexec.c )
>
> And to me it looks like  the  unix version could be used for macosx 
> too  (just in case there is a need to reenable the build of jexec.c  
> for macosx one day again).
>
> Comments / suggestions ?
>
> Best regards, Matthias
>
> *From:*Baesken, Matthias
> *Sent:* Donnerstag, 9. Februar 2017 14:10
> *To:* 'Erik Joelsson' <erik.joelsson at oracle.com>; 
> build-dev at openjdk.java.net; 'core-libs-dev at openjdk.java.net' 
> <core-libs-dev at openjdk.java.net>
> *Cc:* Langer, Christoph <christoph.langer at sap.com>
> *Subject:* RE: jdk10 : simplify jexec build settings
>
> Hello Erik, thanks for the comments .
>
> >>Then there is handling for macosx left , but the build is not enabled for macosx, 
> does it still make sense to include the macosx handling (there is even 
> a separate jexec.c for macosx) :
>
> >
>
> >This is indeed weird. I don't think we ever built jexec for macosx so the 
> source file should likely be removed. That is however a question for 
> core-libs I think.
>
> I include core-libs-dev , can someone comment on  jexec on macosx ?
>
> Currently jexec.c  is not compiled for macosx (jdk9/10), see 
>  jdk/make/launcher/Launcher-java.base.gmk  .
>
> It is just compiled on linux .
>
> So I wonder -  is it ok to remove  the macosx handling  in the 
> mentioned  makefile jdk/make/launcher/Launcher-java.base.gmk   for 
>  jexec ?
>
> >This will automatically look in all the directories where source files are 
> supposed to be and pick the most specific one if there are any with 
> the same name.
>
> >Since the share launcher dir contains more src files, you will need to 
> leave the INCLUDE_FILES := jexec.c this time.
>
> From what I observe in the linux  build log,  just jexec.c  is 
> compiled into jexec.o and then this single object is used to create 
> the executable (?program?)  jexec.
>
> Other src files are not used in the compilation of jexec, so just 
> using   $(JDK_TOPDIR)/src/$(MODULE)/unix/native/launcher   would be 
> fine (as long as macosx can be dropped).
>
> Best regards, Matthias
>
> *From:*Erik Joelsson [mailto:erik.joelsson at oracle.com]
> *Sent:* Donnerstag, 9. Februar 2017 13:42
> *To:* Baesken, Matthias <matthias.baesken at sap.com 
> <mailto:matthias.baesken at sap.com>>; build-dev at openjdk.java.net 
> <mailto:build-dev at openjdk.java.net>
> *Cc:* Langer, Christoph <christoph.langer at sap.com 
> <mailto:christoph.langer at sap.com>>
> *Subject:* Re: jdk10 : simplify jexec build settings
>
> Hello,
>
> On 2017-02-09 12:36, Baesken, Matthias wrote:
>
>     Hello , while adjusting the jspawnhelper build settings with
>     8174086, it has been noticed that the jexec build settings need
>     some simplification as well.
>
>     The bug
>
>     https://bugs.openjdk.java.net/browse/JDK-8174242
>
>     has been created for this.
>
>     When looking into it,  I had some questions :
>
>     http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/ae7afa9abe67/make/launcher/Launcher-java.base.gmk
>
>     The makefile (make/launcher/Launcher-java.base.gmk )  handles
>     Solaris 32bit,  but is this really  supported  in jdk 9 or 10  ( I
>     think it was removed in 9 and only 64bit Solaris support remains ) ?
>
> We do not support 32bit Solaris. The issue with jexec for Solaris was 
> raised a while back and the conclusion was to scrap support, so no 
> need to build it for Solaris at all.
>
>     ifeq ($(OPENJDK_TARGET_OS), solaris)
>
>       ifeq ($(OPENJDK_TARGET_CPU_BITS), 32)
>
>         BUILD_JEXEC := 1
>
>       endif
>
>     endif
>
>     ifeq ($(OPENJDK_TARGET_OS), linux)
>
>       BUILD_JEXEC := 1
>
>     endif # OPENJDK_TARGET_OS
>
>     #
>
>     # jdk/make/java/jexec/Makefile
>
>     #
>
>     ifeq ($(BUILD_JEXEC), 1)
>
>     Then there is handling for macosx left , but the build is not
>     enabled for macosx, does it still make sense to include the macosx
>     handling (there is even a separate jexec.c for macosx) :
>
> This is indeed weird. I don't think we ever built jexec for macosx so 
> the source file should likely be removed. That is however a question 
> for core-libs I think.
>
> The makefile logic shouldn't need to be that specific though. Our 
> modern pattern for this is something like this:
>
> SRC := $(call uniq, $(wildcard \
> $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS)/native/launcher \
> $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS_TYPE)/native/launcher \
> $(JDK_TOPDIR)/src/$(MODULE)/share/native/launcher))
>
> This will automatically look in all the directories where source files 
> are supposed to be and pick the most specific one if there are any 
> with the same name. Since the share launcher dir contains more src 
> files, you will need to leave the INCLUDE_FILES := jexec.c this time.
>
> For libraries, we have abstracted this construct in the macro 
> FindSrcDirForLib (LibCommon.gmk) but we haven't done the same for 
> launchers yet.
>
> /Erik
>
>       ifeq ($(OPENJDK_TARGET_OS), windows)
>
>       else ifeq ($(OPENJDK_TARGET_OS), macosx)
>
>         BUILD_JEXEC_SRC :=
>     $(JDK_TOPDIR)/src/java.base/macosx/native/launcher
>
>       else
>
>         BUILD_JEXEC_SRC :=
>     $(JDK_TOPDIR)/src/java.base/unix/native/launcher
>
>       endif
>
>     Should I remove the solaris 32bit / macosx handling  for jexec 
>     from  make/launcher/Launcher-java.base.gmk ?
>
>     Regards, Matthias
>


From christoph.dreis at freenet.de  Fri Feb 10 10:22:09 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Fri, 10 Feb 2017 11:22:09 +0100
Subject: RFR: 8029019: (ann) Optimize annotation handling in
	core	reflection
In-Reply-To: <b7f9e9c9-1f06-7669-1250-dd5249c475c4@oracle.com>
References: <431967d8-bdba-83e0-258c-6fe384630ff3@gmail.com>	<1d8c06cf-ddba-ff49-bd61-2edd496efb48@oracle.com>	<bbe1f51f-ee62-4008-e2d2-6a06da8c09b3@gmail.com>
	<b7f9e9c9-1f06-7669-1250-dd5249c475c4@oracle.com>
Message-ID: <000001d28387$8989d1a0$9c9d74e0$@freenet.de>

Hi Claes,

> 
> I think this all seems reasonable, but subtle behavior changes like this
> needs more scrutiny than I can provide.  I've discussed this offline
> with Joe and sadly concluded it's probably too much, too late for 9 at
> this point.
> 
> Hope you don't mind re-targetting this to JDK 10.

Do you mean the error handling change or the ticket in general? In case of the latter, may I start a proposal?

As the original issue for me was to reduce the allocations coming from AnnotationInvocationHandler.invoke() caused by Method.getParameterTypes(), what about creating a sub-ticket of 8029019 and just take care of the low-risk change below? That would eventually allow a backbort to JDK 8 as well, although I'm not quite sure yet how the backport process is working.

What do you think?

Cheers,
Christoph

========= PATCH ===========
diff --git a/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java b/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java
--- a/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java
+++ b/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java
@@ -57,13 +57,13 @@

     public Object invoke(Object proxy, Method method, Object[] args) {
         String member = method.getName();
-        Class<?>[] paramTypes = method.getParameterTypes();
+        int parameterCount = method.getParameterCount();

         // Handle Object and Annotation methods
-        if (member.equals("equals") && paramTypes.length == 1 &&
-            paramTypes[0] == Object.class)
+        if (parameterCount == 1 && member.equals("equals") &&
+            method.getParameterTypes()[0] == Object.class)
             return equalsImpl(proxy, args[0]);
-        if (paramTypes.length != 0)
+        if (parameterCount != 0)
             throw new AssertionError("Too many parameters for an annotation method");

         switch(member) {


From abhijit.r.roy at oracle.com  Fri Feb 10 10:51:02 2017
From: abhijit.r.roy at oracle.com (Abhijit Roy)
Date: Fri, 10 Feb 2017 02:51:02 -0800 (PST)
Subject: RFR: JDK-8173094 Error in API documentation for SwingWorker
In-Reply-To: <e6663ccf-dead-4412-88a7-9cf25a0d8508@default>
References: <e6663ccf-dead-4412-88a7-9cf25a0d8508@default>
Message-ID: <6dbdc805-d3f9-498b-b15e-888d4011f683@default>

Hi all,

Please review the java doc fix for the below Bug:

Bug: https://bugs.openjdk.java.net/browse/JDK-8173094

Description: Error in API documentation for SwingWorker

Webrev-http://cr.openjdk.java.net/~rpatil/ababroy/8173094/webrev.00/

 

I have addressed some other doc issues which I included into the same webrev, please find those links below.

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8173751

Description: Syntax error in ZipFile.getComment() method

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8173752

Description: Syntax error in ZipEntry.setCompressedSize(long) method documentation

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8173755

Description: The word input should be replaced by output in FilterOutputStream.write(byte[],int,int) method documentation

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8173802

Description: Incorrect argument name in java.io.FilterInputStream.read(byte[]) method documentation

 

 

Regards,

Abhijit

From frank.yuan at oracle.com  Fri Feb 10 11:03:31 2017
From: frank.yuan at oracle.com (Frank Yuan)
Date: Fri, 10 Feb 2017 19:03:31 +0800
Subject: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by
	JDK-8087303
Message-ID: <053101d2838d$529e5020$f7daf060$@oracle.com>

Hi All

 

Would you like to review http://cr.openjdk.java.net/~fyuan/8174025/webrev.00/?

Bug: https://bugs.openjdk.java.net/browse/JDK-8174025

 

JDK-8087303 introduced 2 issues:

1.       Flaw when xlst uses disable-output-escaping attribute

2.       Eat the whitespace between html inline elements

 

This patch fixed the issues.

To fix the second issue, we decide to keep the compatibility with JDK 8 on the whitespace handling, that is only LSSerializer cleans
the extra whitespaces in if pretty-print is on, but XSLT doesn't.

I modified the behavior of getIndent() method in class ToStream, to make LSSerializer be sensitive of current state from ToStream.
This should be safe because ToStream is an internal class and getIndent() method is never used before.

 

Thanks

Frank

 


From matthias.baesken at sap.com  Fri Feb 10 12:18:56 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 10 Feb 2017 12:18:56 +0000
Subject: jdk10 : simplify jexec build settings
In-Reply-To: <ec35e180-114b-d2c0-c9ff-7ff17674898d@oracle.com>
References: <92a51f307d33465faca64e8d43c176bc@DEWDFE13DE14.global.corp.sap>
	<abf8e046-3528-1c9c-ad12-ce786239b385@oracle.com>
	<20161b2fc66242b6930e179f0bbdf121@DEWDFE13DE14.global.corp.sap>
	<ec35e180-114b-d2c0-c9ff-7ff17674898d@oracle.com>
Message-ID: <420929b535234138871e47a6019d9403@DEWDFE13DE14.global.corp.sap>

Hi Eric, thanks for the comment, I think I'll remove the macosx source file .
Btw. is there already some test  for jexec (a "fast grep" through the  jdk  tests did not show me much) ?

Best regards, Matthias



From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
Sent: Freitag, 10. Februar 2017 09:49
To: Baesken, Matthias <matthias.baesken at sap.com>; build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
Cc: Langer, Christoph <christoph.langer at sap.com>
Subject: Re: jdk10 : simplify jexec build settings


Since the file has never been built, I would say remove the macosx source file. You can point directly to the unix source dir if you prefer too. No need to have dead logic for macosx in the makefile.

/Erik

On 2017-02-09 15:27, Baesken, Matthias wrote:
I compared the  jexec.c  versions for  macosx and unix

( jdk/src/java.base/macosx/native/launcher/jexec.c    and    jdk/src/java.base/unix/native/launcher/jexec.c )

And to me it looks like  the  unix version could be used for macosx too  (just in case there is a need to reenable the  build of jexec.c  for macosx one day again).

Comments / suggestions ?

Best regards, Matthias


From: Baesken, Matthias
Sent: Donnerstag, 9. Februar 2017 14:10
To: 'Erik Joelsson' <erik.joelsson at oracle.com><mailto:erik.joelsson at oracle.com>; build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>; 'core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>' <core-libs-dev at openjdk.java.net><mailto:core-libs-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com><mailto:christoph.langer at sap.com>
Subject: RE: jdk10 : simplify jexec build settings

Hello Erik, thanks for the comments .

>>Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) :
>
>This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think.

I include core-libs-dev , can someone comment on  jexec on macosx ?
Currently  jexec.c  is not compiled for macosx (jdk9/10), see  jdk/make/launcher/Launcher-java.base.gmk  .
It is just compiled on linux .

So I wonder -  is it ok to remove  the macosx handling  in the mentioned  makefile   jdk/make/launcher/Launcher-java.base.gmk   for  jexec ?

>This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name.
>Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time.

>From what I observe in the linux  build log,  just jexec.c  is  compiled into jexec.o and then this single object is used to create the executable ("program")  jexec.
Other src files are not used in the compilation of jexec, so  just using   $(JDK_TOPDIR)/src/$(MODULE)/unix/native/launcher   would be fine (as long as macosx can be dropped).



Best regards, Matthias


From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
Sent: Donnerstag, 9. Februar 2017 13:42
To: Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>; build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Subject: Re: jdk10 : simplify jexec build settings


Hello,

On 2017-02-09 12:36, Baesken, Matthias wrote:
Hello ,  while adjusting the jspawnhelper build settings with 8174086, it has been noticed that the jexec build settings need some simplification as well.

The bug

https://bugs.openjdk.java.net/browse/JDK-8174242

has been created for this.

When looking into it,  I had some questions :

http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/ae7afa9abe67/make/launcher/Launcher-java.base.gmk

The makefile  (make/launcher/Launcher-java.base.gmk )  handles Solaris 32bit,  but is this really  supported  in jdk 9 or 10  ( I think it was removed in 9 and only 64bit Solaris support remains ) ?
We do not support 32bit Solaris. The issue with jexec for Solaris was raised a while back and the conclusion was to scrap support, so no need to build it for Solaris at all.


ifeq ($(OPENJDK_TARGET_OS), solaris)
  ifeq ($(OPENJDK_TARGET_CPU_BITS), 32)
    BUILD_JEXEC := 1
  endif
endif

ifeq ($(OPENJDK_TARGET_OS), linux)
  BUILD_JEXEC := 1
endif # OPENJDK_TARGET_OS

#
# jdk/make/java/jexec/Makefile
#
ifeq ($(BUILD_JEXEC), 1)

Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) :
This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think.

The makefile logic shouldn't need to be that specific though. Our modern pattern for this is something like this:

SRC := $(call uniq, $(wildcard \
      $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS)/native/launcher \
      $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS_TYPE)/native/launcher \
      $(JDK_TOPDIR)/src/$(MODULE)/share/native/launcher))

This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name. Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time.

For libraries, we have abstracted this construct in the macro FindSrcDirForLib (LibCommon.gmk) but we haven't done the same for launchers yet.

/Erik



  ifeq ($(OPENJDK_TARGET_OS), windows)
  else ifeq ($(OPENJDK_TARGET_OS), macosx)
    BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/macosx/native/launcher
  else
    BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/unix/native/launcher
  endif

Should I remove  the solaris 32bit / macosx handling  for jexec  from   make/launcher/Launcher-java.base.gmk ?

Regards, Matthias







From daniel.fuchs at oracle.com  Fri Feb 10 13:25:23 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 10 Feb 2017 13:25:23 +0000
Subject: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by
	JDK-8087303
In-Reply-To: <053101d2838d$529e5020$f7daf060$@oracle.com>
References: <053101d2838d$529e5020$f7daf060$@oracle.com>
Message-ID: <519870f0-80e8-cb70-e8e4-17c2ddfb0b50@oracle.com>

Hi Frank,

Thanks for fixing this!

I imported your patch and played with it a bit.
Also ran the jaxp test.

Both issues reported have indeed disappeared.

So that's a +1 from me.

best regards,

-- daniel

On 10/02/17 11:03, Frank Yuan wrote:
> Hi All
>
>
>
> Would you like to review
> http://cr.openjdk.java.net/~fyuan/8174025/webrev.00/?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8174025
>
>
>
> JDK-8087303 introduced 2 issues:
>
> 1.       Flaw when xlst uses disable-output-escaping attribute
>
> 2.       Eat the whitespace between html inline elements
>
>
>
> This patch fixed the issues.
>
> To fix the second issue, we decide to keep the compatibility with JDK 8
> on the whitespace handling, that is only LSSerializer cleans the extra
> whitespaces in if pretty-print is on, but XSLT doesn?t.
>
> I modified the behavior of getIndent() method in class ToStream, to make
> LSSerializer be sensitive of current state from ToStream. This should be
> safe because ToStream is an internal class and getIndent() method is
> never used before.
>
>
>
> Thanks
>
> Frank
>
>
>


From xueming.shen at oracle.com  Fri Feb 10 15:48:50 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 10 Feb 2017 07:48:50 -0800
Subject: RFR JDK-8165640: Enhance jar tool to allow module-info in versioned
	directories but not in base in modular multi-release jar files
Message-ID: <7652b6e0-8698-c74d-1ad3-46d9a20ad7ee@oracle.com>

Hi,

Please help review the changes for

https://bugs.openjdk.java.net/browse/JDK-8165640
http://cr.openjdk.java.net/~sherman/8146486/webrev

There are two changes
(1) to use the versioned module-info as the module descriptor to validate
the versioned entries, if the root/base "/module-info.class" is missing.
(2) -d to print out all available module-info entries, versioned included.


Thanks,
Sherman


From sean.coffey at oracle.com  Fri Feb 10 17:07:44 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 10 Feb 2017 17:07:44 +0000
Subject: RFR: JDK-8173094 Error in API documentation for SwingWorker
In-Reply-To: <6dbdc805-d3f9-498b-b15e-888d4011f683@default>
References: <e6663ccf-dead-4412-88a7-9cf25a0d8508@default>
	<6dbdc805-d3f9-498b-b15e-888d4011f683@default>
Message-ID: <f4158cc9-f6f0-af93-e7ea-7d778248ea36@oracle.com>

Hi Abhijit,

you'll need to correct the Copyright year format in your edits. It needs 
to be "Copyright (c) <start_year>, <end_year>, Oracle..." format.

For the ZipFile change, you need to use lower case 's' in @since.

Looks good otherwise.

regards,
Sean.

On 10/02/17 10:51, Abhijit Roy wrote:
> Hi all,
>
> Please review the java doc fix for the below Bug:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8173094
>
> Description: Error in API documentation for SwingWorker
>
> Webrev-http://cr.openjdk.java.net/~rpatil/ababroy/8173094/webrev.00/
>
>   
>
> I have addressed some other doc issues which I included into the same webrev, please find those links below.
>
>   
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8173751
>
> Description: Syntax error in ZipFile.getComment() method
>
>   
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8173752
>
> Description: Syntax error in ZipEntry.setCompressedSize(long) method documentation
>
>   
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8173755
>
> Description: The word input should be replaced by output in FilterOutputStream.write(byte[],int,int) method documentation
>
>   
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8173802
>
> Description: Incorrect argument name in java.io.FilterInputStream.read(byte[]) method documentation
>
>   
>
>   
>
> Regards,
>
> Abhijit


From matthias.baesken at sap.com  Thu Feb  9 13:10:29 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 9 Feb 2017 13:10:29 +0000
Subject: jdk10 : simplify jexec build settings
In-Reply-To: <abf8e046-3528-1c9c-ad12-ce786239b385@oracle.com>
References: <92a51f307d33465faca64e8d43c176bc@DEWDFE13DE14.global.corp.sap>
	<abf8e046-3528-1c9c-ad12-ce786239b385@oracle.com>
Message-ID: <7f89e4612cef4c3793ef73be2a7846c6@DEWDFE13DE14.global.corp.sap>

Hello Erik, thanks for the comments .

>>Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) :
>
>This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think.

I include core-libs-dev , can someone comment on  jexec on macosx ?
Currently  jexec.c  is not compiled for macosx (jdk9/10), see  jdk/make/launcher/Launcher-java.base.gmk  .
It is just compiled on linux .

So I wonder -  is it ok to remove  the macosx handling  in the mentioned  makefile   jdk/make/launcher/Launcher-java.base.gmk   for  jexec ?

>This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name.
>Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time.

>From what I observe in the linux  build log,  just jexec.c  is  compiled into jexec.o and then this single object is used to create the executable ("program")  jexec.
Other src files are not used in the compilation of jexec, so  just using   $(JDK_TOPDIR)/src/$(MODULE)/unix/native/launcher   would be fine (as long as macosx can be dropped).



Best regards, Matthias


From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
Sent: Donnerstag, 9. Februar 2017 13:42
To: Baesken, Matthias <matthias.baesken at sap.com>; build-dev at openjdk.java.net
Cc: Langer, Christoph <christoph.langer at sap.com>
Subject: Re: jdk10 : simplify jexec build settings


Hello,

On 2017-02-09 12:36, Baesken, Matthias wrote:
Hello ,  while adjusting the jspawnhelper build settings with 8174086, it has been noticed that the jexec build settings need some simplification as well.

The bug

https://bugs.openjdk.java.net/browse/JDK-8174242

has been created for this.

When looking into it,  I had some questions :

http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/ae7afa9abe67/make/launcher/Launcher-java.base.gmk

The makefile  (make/launcher/Launcher-java.base.gmk )  handles Solaris 32bit,  but is this really  supported  in jdk 9 or 10  ( I think it was removed in 9 and only 64bit Solaris support remains ) ?
We do not support 32bit Solaris. The issue with jexec for Solaris was raised a while back and the conclusion was to scrap support, so no need to build it for Solaris at all.



ifeq ($(OPENJDK_TARGET_OS), solaris)
  ifeq ($(OPENJDK_TARGET_CPU_BITS), 32)
    BUILD_JEXEC := 1
  endif
endif

ifeq ($(OPENJDK_TARGET_OS), linux)
  BUILD_JEXEC := 1
endif # OPENJDK_TARGET_OS

#
# jdk/make/java/jexec/Makefile
#
ifeq ($(BUILD_JEXEC), 1)

Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) :
This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think.

The makefile logic shouldn't need to be that specific though. Our modern pattern for this is something like this:

SRC := $(call uniq, $(wildcard \
      $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS)/native/launcher \
      $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS_TYPE)/native/launcher \
      $(JDK_TOPDIR)/src/$(MODULE)/share/native/launcher))

This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name. Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time.

For libraries, we have abstracted this construct in the macro FindSrcDirForLib (LibCommon.gmk) but we haven't done the same for launchers yet.

/Erik



  ifeq ($(OPENJDK_TARGET_OS), windows)
  else ifeq ($(OPENJDK_TARGET_OS), macosx)
    BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/macosx/native/launcher
  else
    BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/unix/native/launcher
  endif

Should I remove  the solaris 32bit / macosx handling  for jexec  from   make/launcher/Launcher-java.base.gmk ?

Regards, Matthias






From matthias.baesken at sap.com  Thu Feb  9 14:27:29 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 9 Feb 2017 14:27:29 +0000
Subject: jdk10 : simplify jexec build settings
References: <92a51f307d33465faca64e8d43c176bc@DEWDFE13DE14.global.corp.sap>
	<abf8e046-3528-1c9c-ad12-ce786239b385@oracle.com> 
Message-ID: <20161b2fc66242b6930e179f0bbdf121@DEWDFE13DE14.global.corp.sap>

I compared the  jexec.c  versions for  macosx and unix

( jdk/src/java.base/macosx/native/launcher/jexec.c    and    jdk/src/java.base/unix/native/launcher/jexec.c )

And to me it looks like  the  unix version could be used for macosx too  (just in case there is a need to reenable the  build of jexec.c  for macosx one day again).

Comments / suggestions ?

Best regards, Matthias


From: Baesken, Matthias
Sent: Donnerstag, 9. Februar 2017 14:10
To: 'Erik Joelsson' <erik.joelsson at oracle.com>; build-dev at openjdk.java.net; 'core-libs-dev at openjdk.java.net' <core-libs-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com>
Subject: RE: jdk10 : simplify jexec build settings

Hello Erik, thanks for the comments .

>>Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) :
>
>This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think.

I include core-libs-dev , can someone comment on  jexec on macosx ?
Currently  jexec.c  is not compiled for macosx (jdk9/10), see  jdk/make/launcher/Launcher-java.base.gmk  .
It is just compiled on linux .

So I wonder -  is it ok to remove  the macosx handling  in the mentioned  makefile   jdk/make/launcher/Launcher-java.base.gmk   for  jexec ?

>This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name.
>Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time.

>From what I observe in the linux  build log,  just jexec.c  is  compiled into jexec.o and then this single object is used to create the executable ("program")  jexec.
Other src files are not used in the compilation of jexec, so  just using   $(JDK_TOPDIR)/src/$(MODULE)/unix/native/launcher   would be fine (as long as macosx can be dropped).



Best regards, Matthias


From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
Sent: Donnerstag, 9. Februar 2017 13:42
To: Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>; build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Subject: Re: jdk10 : simplify jexec build settings


Hello,

On 2017-02-09 12:36, Baesken, Matthias wrote:
Hello ,  while adjusting the jspawnhelper build settings with 8174086, it has been noticed that the jexec build settings need some simplification as well.

The bug

https://bugs.openjdk.java.net/browse/JDK-8174242

has been created for this.

When looking into it,  I had some questions :

http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/ae7afa9abe67/make/launcher/Launcher-java.base.gmk

The makefile  (make/launcher/Launcher-java.base.gmk )  handles Solaris 32bit,  but is this really  supported  in jdk 9 or 10  ( I think it was removed in 9 and only 64bit Solaris support remains ) ?
We do not support 32bit Solaris. The issue with jexec for Solaris was raised a while back and the conclusion was to scrap support, so no need to build it for Solaris at all.


ifeq ($(OPENJDK_TARGET_OS), solaris)
  ifeq ($(OPENJDK_TARGET_CPU_BITS), 32)
    BUILD_JEXEC := 1
  endif
endif

ifeq ($(OPENJDK_TARGET_OS), linux)
  BUILD_JEXEC := 1
endif # OPENJDK_TARGET_OS

#
# jdk/make/java/jexec/Makefile
#
ifeq ($(BUILD_JEXEC), 1)

Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) :
This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think.

The makefile logic shouldn't need to be that specific though. Our modern pattern for this is something like this:

SRC := $(call uniq, $(wildcard \
      $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS)/native/launcher \
      $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS_TYPE)/native/launcher \
      $(JDK_TOPDIR)/src/$(MODULE)/share/native/launcher))

This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name. Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time.

For libraries, we have abstracted this construct in the macro FindSrcDirForLib (LibCommon.gmk) but we haven't done the same for launchers yet.

/Erik


  ifeq ($(OPENJDK_TARGET_OS), windows)
  else ifeq ($(OPENJDK_TARGET_OS), macosx)
    BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/macosx/native/launcher
  else
    BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/unix/native/launcher
  endif

Should I remove  the solaris 32bit / macosx handling  for jexec  from   make/launcher/Launcher-java.base.gmk ?

Regards, Matthias






From abhijit.r.roy at oracle.com  Fri Feb 10 19:18:42 2017
From: abhijit.r.roy at oracle.com (Abhijit Roy)
Date: Sat, 11 Feb 2017 00:48:42 +0530
Subject: RFR: JDK-8173094 Error in API documentation for SwingWorker
In-Reply-To: <f4158cc9-f6f0-af93-e7ea-7d778248ea36@oracle.com>
References: <e6663ccf-dead-4412-88a7-9cf25a0d8508@default>
	<6dbdc805-d3f9-498b-b15e-888d4011f683@default>
	<f4158cc9-f6f0-af93-e7ea-7d778248ea36@oracle.com>
Message-ID: <78234c7d-e048-7e61-4361-f0861d09aabd@oracle.com>

Hi Sean,

As per your suggestion, I have corrected those points. Please find the 
link below for further review.

http://cr.openjdk.java.net/~rpatil/ababroy/8173094/webrev.01/ 
<http://cr.openjdk.java.net/%7Erpatil/ababroy/8173094/webrev.01/>

Thanks,
Abhijit



On 2/10/2017 10:37 PM, Se?n Coffey wrote:
> Hi Abhijit,
>
> you'll need to correct the Copyright year format in your edits. It 
> needs to be "Copyright (c) <start_year>, <end_year>, Oracle..." format.
>
> For the ZipFile change, you need to use lower case 's' in @since.
>
> Looks good otherwise.
>
> regards,
> Sean.
>
> On 10/02/17 10:51, Abhijit Roy wrote:
>> Hi all,
>>
>> Please review the java doc fix for the below Bug:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173094
>>
>> Description: Error in API documentation for SwingWorker
>>
>> Webrev-http://cr.openjdk.java.net/~rpatil/ababroy/8173094/webrev.00/
>>
>>
>> I have addressed some other doc issues which I included into the same 
>> webrev, please find those links below.
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173751
>>
>> Description: Syntax error in ZipFile.getComment() method
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173752
>>
>> Description: Syntax error in ZipEntry.setCompressedSize(long) method 
>> documentation
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173755
>>
>> Description: The word input should be replaced by output in 
>> FilterOutputStream.write(byte[],int,int) method documentation
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173802
>>
>> Description: Incorrect argument name in 
>> java.io.FilterInputStream.read(byte[]) method documentation
>>
>>
>>
>> Regards,
>>
>> Abhijit
>


From lance.andersen at oracle.com  Fri Feb 10 20:58:10 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 10 Feb 2017 15:58:10 -0500
Subject: RFR 8174728:  Mark Java EE modules deprecated and for removal
Message-ID: <FEB23C1E-ADD0-4F8D-AC13-2F2D95893549@oracle.com>

Hi all,

This is a request to review marking the Java EE based modules as deprecated.  The corba module was already updated.

Best
Lance
????????
ljanders-mac:dev-annotations ljanders$ cd jdk
ljanders-mac:jdk ljanders$ hg diff
diff -r ed26eebc8c88 src/java.transaction/share/classes/module-info.java
--- a/src/java.transaction/share/classes/module-info.java	Fri Feb 10 10:26:46 2017 -0800
+++ b/src/java.transaction/share/classes/module-info.java	Fri Feb 10 15:54:10 2017 -0500
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2015, 2017, 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
@@ -31,6 +31,7 @@
  *
  * @since 9
  */
+ at Deprecated(since="9", forRemoval=true)
 module java.transaction {
     requires transitive java.rmi;
     exports javax.transaction;
ljanders-mac:jdk ljanders$ cd ../jaxws
ljanders-mac:jaxws ljanders$ hg diff
diff -r b7e70e1e0154 src/java.activation/share/classes/module-info.java
--- a/src/java.activation/share/classes/module-info.java	Fri Feb 10 00:39:51 2017 -0800
+++ b/src/java.activation/share/classes/module-info.java	Fri Feb 10 15:54:19 2017 -0500
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2014, 2017, 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
@@ -28,6 +28,7 @@
  *
  * @since 9
  */
+ at Deprecated(since="9", forRemoval=true)
 module java.activation {
     requires transitive java.datatransfer;
     requires java.logging;
diff -r b7e70e1e0154 src/java.xml.bind/share/classes/module-info.java
--- a/src/java.xml.bind/share/classes/module-info.java	Fri Feb 10 00:39:51 2017 -0800
+++ b/src/java.xml.bind/share/classes/module-info.java	Fri Feb 10 15:54:19 2017 -0500
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2014, 2017, 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
@@ -28,6 +28,7 @@
  *
  * @since 9
  */
+ at Deprecated(since="9", forRemoval=true)
 module java.xml.bind {
     requires transitive java.activation;
     requires transitive java.xml;
diff -r b7e70e1e0154 src/java.xml.ws.annotation/share/classes/module-info.java
--- a/src/java.xml.ws.annotation/share/classes/module-info.java	Fri Feb 10 00:39:51 2017 -0800
+++ b/src/java.xml.ws.annotation/share/classes/module-info.java	Fri Feb 10 15:54:19 2017 -0500
@@ -29,6 +29,7 @@
  *
  * @since 9
  */
+ at Deprecated(since="9", forRemoval=true)
 module java.xml.ws.annotation {
     exports javax.annotation;
 }
diff -r b7e70e1e0154 src/java.xml.ws/share/classes/module-info.java
--- a/src/java.xml.ws/share/classes/module-info.java	Fri Feb 10 00:39:51 2017 -0800
+++ b/src/java.xml.ws/share/classes/module-info.java	Fri Feb 10 15:54:19 2017 -0500
@@ -29,6 +29,7 @@
  *
  * @since 9
  */
+ at Deprecated(since="9", forRemoval=true)
 module java.xml.ws {
     requires transitive java.activation;
     requires transitive java.xml;
ljanders-mac:jaxws ljanders$ 

-----------------------
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From mandy.chung at oracle.com  Fri Feb 10 21:01:08 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 10 Feb 2017 13:01:08 -0800
Subject: RFR JDK-8165640: Enhance jar tool to allow module-info in
	versioned directories but not in base in modular multi-release
	jar files
In-Reply-To: <7652b6e0-8698-c74d-1ad3-46d9a20ad7ee@oracle.com>
References: <7652b6e0-8698-c74d-1ad3-46d9a20ad7ee@oracle.com>
Message-ID: <310E1480-D5F4-4EFE-B96A-1D259FB71A19@oracle.com>


> On Feb 10, 2017, at 7:48 AM, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> Hi,
> 
> Please help review the changes for
> 
> https://bugs.openjdk.java.net/browse/JDK-8165640
> http://cr.openjdk.java.net/~sherman/8146486/webrev


1781         sb.append("\n[").append(ename).append("]?);
1786         sb.append("\n  name ").append(md.toNameAndVersion());

We can make jar -d output similiar to `java ?-list-modules` and have the entry name next to the module name in the same line.  

module hi (module-info.class)
module hi (META-INF/versions/10/module-info.class)

1759-1763:  an alternative is to use stream().sorted().foreach(?) that you won?t need to create the names array.

Otherwise, looks okay.

Mandy



From huizhe.wang at oracle.com  Fri Feb 10 21:51:53 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Fri, 10 Feb 2017 13:51:53 -0800
Subject: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by
	JDK-8087303
In-Reply-To: <519870f0-80e8-cb70-e8e4-17c2ddfb0b50@oracle.com>
References: <053101d2838d$529e5020$f7daf060$@oracle.com>
	<519870f0-80e8-cb70-e8e4-17c2ddfb0b50@oracle.com>
Message-ID: <fcb8c2b1-429a-1377-fdbc-a27eb46acc3f@oracle.com>

+1 from me too.

Thanks,
Joe

On 2/10/2017 5:25 AM, Daniel Fuchs wrote:
> Hi Frank,
>
> Thanks for fixing this!
>
> I imported your patch and played with it a bit.
> Also ran the jaxp test.
>
> Both issues reported have indeed disappeared.
>
> So that's a +1 from me.
>
> best regards,
>
> -- daniel
>
> On 10/02/17 11:03, Frank Yuan wrote:
>> Hi All
>>
>>
>>
>> Would you like to review
>> http://cr.openjdk.java.net/~fyuan/8174025/webrev.00/?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174025
>>
>>
>>
>> JDK-8087303 introduced 2 issues:
>>
>> 1.       Flaw when xlst uses disable-output-escaping attribute
>>
>> 2.       Eat the whitespace between html inline elements
>>
>>
>>
>> This patch fixed the issues.
>>
>> To fix the second issue, we decide to keep the compatibility with JDK 8
>> on the whitespace handling, that is only LSSerializer cleans the extra
>> whitespaces in if pretty-print is on, but XSLT doesn?t.
>>
>> I modified the behavior of getIndent() method in class ToStream, to make
>> LSSerializer be sensitive of current state from ToStream. This should be
>> safe because ToStream is an internal class and getIndent() method is
>> never used before.
>>
>>
>>
>> Thanks
>>
>> Frank
>>
>>
>>
>


From mandy.chung at oracle.com  Fri Feb 10 21:57:18 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 10 Feb 2017 13:57:18 -0800
Subject: Review Request: JDK-8173712: Rename JAVA_OPTIONS environment
	variable to JDK_JAVA_OPTIONS
In-Reply-To: <addbdc53-e0d8-2920-8736-82891cd195be@oracle.com>
References: <1CAB1A0E-0EC7-4050-9D73-B3B473C5EB60@oracle.com>
	<addbdc53-e0d8-2920-8736-82891cd195be@oracle.com>
Message-ID: <0516DA55-5AF4-46ED-B840-EE5F0B3E0115@oracle.com>


> On Feb 7, 2017, at 10:47 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 07/02/2017 21:16, Mandy Chung wrote:
> 
>> Henry, Kumar,
>> 
>> Can you please review this patch:
>>   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173712/webrev.00/
>> 
>> JAVA_OPTIONS was introduced by JDK-8170832 but it turns out that
>> environment variable name conflicts with existing uses.  It might
>> not be uncommon for scripts to set JAVA_OPTIONS. To mitigate the
>> compatibility concern, we decide to rename JAVA_OPTIONS to
>> JDK_JAVA_OPTIONS.  With multi-word name and `JDK_` prefix, that
>> should reduce the chance of name clash.
>> 
> The rename looks okay. You might want to add to the @bug list so that it captures the bug with the rename.

Thanks.  I have pushed the changeset. JDK-8170832 is linked with JDK-8173712. Hope it?s okay to leave it as is.  When some launcher change is made, we could piggy that one to update @bugs on these tests.

Mandy

From paul.sandoz at oracle.com  Fri Feb 10 22:30:14 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 10 Feb 2017 14:30:14 -0800
Subject: RFR JDK-8165640: Enhance jar tool to allow module-info in
	versioned directories but not in base in modular multi-release
	jar files
In-Reply-To: <310E1480-D5F4-4EFE-B96A-1D259FB71A19@oracle.com>
References: <7652b6e0-8698-c74d-1ad3-46d9a20ad7ee@oracle.com>
	<310E1480-D5F4-4EFE-B96A-1D259FB71A19@oracle.com>
Message-ID: <38669276-4642-4B68-872D-FCA546CB34F7@oracle.com>


> On 10 Feb 2017, at 13:01, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
>> On Feb 10, 2017, at 7:48 AM, Xueming Shen <xueming.shen at oracle.com> wrote:
>> 
>> Hi,
>> 
>> Please help review the changes for
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8165640
>> http://cr.openjdk.java.net/~sherman/8146486/webrev
> 
> 
> 1781         sb.append("\n[").append(ename).append("]?);
> 1786         sb.append("\n  name ").append(md.toNameAndVersion());
> 
> We can make jar -d output similiar to `java ?-list-modules` and have the entry name next to the module name in the same line.
> 
> module hi (module-info.class)
> module hi (META-INF/versions/10/module-info.class)
> 
> 1759-1763:  an alternative is to use stream().sorted().foreach(?) that you won?t need to create the names array.
> 

Yes, i prefer to stream approach too. (FWIW if Stream.toArray was used and performance was a concern that might motivate using a more imperative style).


> Otherwise, looks okay.
> 

+1

Paul.

From xueming.shen at oracle.com  Sat Feb 11 02:06:20 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 10 Feb 2017 18:06:20 -0800
Subject: RFR JDK-8165640: Enhance jar tool to allow module-info in
 versioned
 directories but not in base in modular multi-release jar files
In-Reply-To: <38669276-4642-4B68-872D-FCA546CB34F7@oracle.com>
References: <7652b6e0-8698-c74d-1ad3-46d9a20ad7ee@oracle.com>
 <310E1480-D5F4-4EFE-B96A-1D259FB71A19@oracle.com>
 <38669276-4642-4B68-872D-FCA546CB34F7@oracle.com>
Message-ID: <589E719C.4060506@oracle.com>

On 2/10/17, 2:30 PM, Paul Sandoz wrote:
>
> We can make jar -d output similiar to `java ?-list-modules` and have the entry name next to the module name in the same line.
>
> module hi (module-info.class)
> module hi (META-INF/versions/10/module-info.class)

updated to use the suggested format.

>
> 1759-1763:  an alternative is to use stream().sorted().foreach(?) that you won?t need to create the names array.
>
> Yes, i prefer to stream approach too. (FWIW if Stream.toArray was used and performance was a concern that might motivate using a more imperative style).

updated to use stream style.

https://bugs.openjdk.java.net/browse/JDK-8165640
http://cr.openjdk.java.net/~sherman/8165640/webrev
(webrev link is changed. the id was wrong in previous email)

thanks
sherman





From mandy.chung at oracle.com  Sat Feb 11 06:30:23 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 10 Feb 2017 22:30:23 -0800
Subject: RFR JDK-8165640: Enhance jar tool to allow module-info in
 versioned directories but not in base in modular multi-release jar files
In-Reply-To: <589E719C.4060506@oracle.com>
References: <7652b6e0-8698-c74d-1ad3-46d9a20ad7ee@oracle.com>
 <310E1480-D5F4-4EFE-B96A-1D259FB71A19@oracle.com>
 <38669276-4642-4B68-872D-FCA546CB34F7@oracle.com>
 <589E719C.4060506@oracle.com>
Message-ID: <9B500DE7-098D-42EB-A61E-17A1AF5DF08E@oracle.com>


> On Feb 10, 2017, at 6:06 PM, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> updated to use stream style.
> 
> https://bugs.openjdk.java.net/browse/JDK-8165640
> http://cr.openjdk.java.net/~sherman/8165640/webrev

Looks okay.  A minor point is that you can use foreach instead of toArray but it would need to catch IOException inside foreach block.

Mandy

From Alan.Bateman at oracle.com  Sat Feb 11 09:21:50 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 11 Feb 2017 09:21:50 +0000
Subject: RFR 8174728: Mark Java EE modules deprecated and for removal
In-Reply-To: <FEB23C1E-ADD0-4F8D-AC13-2F2D95893549@oracle.com>
References: <FEB23C1E-ADD0-4F8D-AC13-2F2D95893549@oracle.com>
Message-ID: <39f691d2-6176-9fb8-4663-7c1a11a2499d@oracle.com>

On 10/02/2017 20:58, Lance Andersen wrote:

> Hi all,
>
> This is a request to review marking the Java EE based modules as deprecated.  The corba module was already updated.
>
>
This looks okay to me. I don't know if you are planning to push this now 
or waiting to see if there is any feedback on the proposal in the JSR 
379 EDR.

-Alan

From lance.andersen at oracle.com  Sat Feb 11 12:43:44 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sat, 11 Feb 2017 07:43:44 -0500
Subject: RFR 8174728: Mark Java EE modules deprecated and for removal
In-Reply-To: <39f691d2-6176-9fb8-4663-7c1a11a2499d@oracle.com>
References: <FEB23C1E-ADD0-4F8D-AC13-2F2D95893549@oracle.com>
 <39f691d2-6176-9fb8-4663-7c1a11a2499d@oracle.com>
Message-ID: <3F98E70E-448A-4863-BA7F-0F7EC3C53689@oracle.com>


> On Feb 11, 2017, at 4:21 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 10/02/2017 20:58, Lance Andersen wrote:
> 
>> Hi all,
>> 
>> This is a request to review marking the Java EE based modules as deprecated.  The corba module was already updated.
>> 
>> 
> This looks okay to me. I don't know if you are planning to push this now or waiting to see if there is any feedback on the proposal in the JSR 379 EDR.

I can go either way given the cobra module-info had previously been updated.   So I might suggest doing it now, but will let you make the call :-)

Best
Lance
> 
> -Alan

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From christoph.langer at sap.com  Sat Feb 11 14:49:42 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Sat, 11 Feb 2017 14:49:42 +0000
Subject: Update: RFR 8172974 [JAXP] XALAN: Wrong result when transforming
 namespace unaware StAX Input
In-Reply-To: <b831884c-627d-5551-cb0c-2d12d0c55b9b@oracle.com>
References: <3f43563228ef4f7ca2eed6281698a17c@derote13de46.global.corp.sap>
 <589A6C4C.60302@oracle.com> <b831884c-627d-5551-cb0c-2d12d0c55b9b@oracle.com>
Message-ID: <d448c4c69f594259a45eca3b82832a01@derote13de46.global.corp.sap>

Hi Joe,

that's unfortunate but if these are the numbers then we have to deal with it. It's a bit odd, though, that this does not cause a regression on all platforms. So, you are really sure the regression roots in my current proposal for 8172974?

One thing I'd want to have been looked at is if the regression really roots to my change in SAX2DTM2.java. This is the real modification. Everything else is just cleanup. And looking at SAX2DTM2, I really can't see where I should have introduced something bad. Can you retest this?

Also, moving this to JDK10 would be fine for me. Shall I submit my fix there as is or do you want to conduct some deeper analysis about the performance regression's root cause? Can I somehow assist with that?

Thanks
Christoph

> -----Original Message-----
> From: huizhe wang [mailto:huizhe.wang at oracle.com]
> Sent: Donnerstag, 9. Februar 2017 23:15
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: Update: RFR 8172974 [JAXP] XALAN: Wrong result when
> transforming namespace unaware StAX Input
> 
> Hi Christoph,
> 
> The performance results showed two regressions, one on Linux and another
> Solaris SPARC, while at the same time a bit more than half of the
> results across 5 platforms were negative. This is unfortunate. We're too
> close to the release date, it's super sensitive for jaxp on the
> performance front. I'd like to suggest that we move this patch to a
> 9-update or 10 when we'd have plenty of time to deal with any possible
> fallout. I consulted our performance expert and this is also his
> recommendation. I hope you'd understand.
> 
> Thanks,
> Joe
> 
> On 2/7/2017 4:54 PM, Joe Wang wrote:
> > Hi Christoph,
> >
> > We'll double-check whether there's any performance implications.
> > Please give us a couple of (or few) days.
> >
> > Thanks,
> > Joe
> >
> > On 1/30/17, 7:28 AM, Langer, Christoph wrote:
> >> Hi Joe,
> >>
> >> I've updated my webrev for 8172974 after pulling out the refactoring
> >> of javax/xml/jaxp/unittest/transform/TransformerTest.java to Bug
> >> 8173602: http://cr.openjdk.java.net/~clanger/webrevs/8172974.1/
> >>
> >> After exchanging some off-list mails with Lance and Daniel, we came
> >> to the conclusion that you should decide about this one when you are
> >> back. The changes are merely cleanups apart from
> >>
> com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM2.startEleme
> nt(),
> >> which to me seem natural after 8169631, though.
> >>
> >> Thanks,
> >> Christoph
> >>
> >>> -----Original Message-----
> >>> From: Langer, Christoph
> >>> Sent: Mittwoch, 18. Januar 2017 22:55
> >>> To: 'huizhe wang'<huizhe.wang at oracle.com>;
> >>> core-libs-dev at openjdk.java.net
> >>> Subject: RE: RFR 8172974 [JAXP] XALAN: Wrong result when
> transforming
> >>> namespace unaware StAX Input
> >>>
> >>> Hi Joe,
> >>>
> >>> generally, you are right, XSLT requires namespace support. For
> >>> parsing the
> >>> stylesheet, it is definitely a hard requirement. Otherwise this
> >>> would not make
> >>> sense at all. For instance xsl directives are in the xsl namespace.
> >>> That
> >>> requirement is what the FAQ you are referencing [1] is talking about.
> >>>
> >>> As for the InputSource which is to be processed, it is probably also
> >>> not a right to
> >>> use non namespace aware parsing. But still it's not forbidden. For
> >>> instance, the
> >>> JavaDoc for SAXSource [2] states this:
> >>> "Note that XSLT requires namespace support. Attempting to transform
> >>> an input
> >>> source that is not generated with a namespace-aware parser may
> >>> result in
> >>> errors. Parsers can be made namespace aware by calling the
> >>> SAXParserFactory.setNamespaceAware(boolean awareness) method."
> >>>
> >>> So, I agree, we are in the error space here. But still I think the
> >>> result of non
> >>> namespace aware parsing should be the same for all types of input
> >>> source. And
> >>> at the moment it is the same for DOMSource and SAXSource but not for
> >>> StAXSource. From that point of view I think my fix makes sense
> >>> (along with the
> >>> other cleanups).
> >>>
> >>> Best regards
> >>> Christoph
> >>>
> >>> [1] https://xml.apache.org/xalan-j/faq.html#faq-N10207
> >>> [2]
> >>>
> https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSo
> urce
> >>>
> >>> .html
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
> >>>> Sent: Mittwoch, 18. Januar 2017 22:12
> >>>> To: Langer, Christoph<christoph.langer at sap.com>; core-libs-
> >>>> dev at openjdk.java.net
> >>>> Subject: Re: RFR 8172974 [JAXP] XALAN: Wrong result when
> transforming
> >>>> namespace unaware StAX Input
> >>>>
> >>>> Hi Christoph,
> >>>>
> >>>> Xalan requires the underlying parser to be namespace aware. Please
> >>>> refer
> >>>> to https://xml.apache.org/xalan-j/faq.html#faq-N10207
> >>>>
> >>>> Thanks,
> >>>> Joe
> >>>>
> >>>> On 1/18/2017 8:26 AM, Langer, Christoph wrote:
> >>>>> Hi,
> >>>>>
> >>>>> please review a change for JAXP.
> >>>>>
> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172974
> >>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172974.0/
> >>>>>
> >>>>> When enhancing the test for
> https://bugs.openjdk.java.net/browse/JDK-
> >>>> 8023653, I saw that there's still an issue with StAXInputSource
> >>>> which is not
> >>>> namespace aware. This needs a small update in
> >>>>
> >>>
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2
> dt
> >>>
> >>>> m/SAX2DTM2.java. Furthermore, I added the fixed warnings and
> >>>> formattings
> >>>> from the proposal
> >>>> http://cr.openjdk.java.net/~clanger/webrevs/8023653.0/ to
> >>>> this webrev, as 8023653 is an enhancement and might not go in in
> >>>> the near
> >>>> future.
> >>>>> I also enhanced the TransformerTest to utilize data providers now
> >>>>> and test
> >>> a
> >>>> comprehensive matrix of XALAN input.
> >>>>> Thanks in advance and Best regards
> >>>>> Christoph
> >>>>>


From volker.simonis at gmail.com  Mon Feb 13 08:04:49 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 13 Feb 2017 09:04:49 +0100
Subject: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't
 specify what happens if the passed supplier is null itself
In-Reply-To: <7A11D19E-FBF6-4973-A38E-BA5D18C8F52F@oracle.com>
References: <CA+3eh13qSnt+CbyVNzB0eRp-rQkPhPu82tNhawhM11Q1Gw9qkg@mail.gmail.com>
 <7A11D19E-FBF6-4973-A38E-BA5D18C8F52F@oracle.com>
Message-ID: <CA+3eh13Z6gkqvi1CqH+cjDTtXmsoYSTucuWKfh_zLkUZntM5Ww@mail.gmail.com>

Ping...

On Thu, Feb 9, 2017 at 5:32 PM, Jeff Dinkins <jeff.dinkins at oracle.com> wrote:
>
> Adding Mike?s current email.
>
> -jeff
>
>> On Feb 9, 2017, at 10:18 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>
>> Hi,
>>
>> I want to finally resolve this long standing issue (or close it as
>> "will not fix" if that's not possible):
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2017/8033909/
>>
>> This change has already been discussed in length on the mailing list:
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/thread.html#24989
>>
>> and in the bug comments:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8033909
>>
>> So I'll give just a short summary here:
>>
>> - Objects.requireNonNull(T, Supplier) does not check for the Supplier
>> argument being null. Instead it relies on the fact, that the VM will
>> implicitly throw a NullPointerException when it calls .get on the
>> Supplier argument during the creation of the explicit
>> NullPointerException which it is supposed to throw.
>>
>> - this behavior slightly differs from Objects.requireNonNull(T,
>> String) which simply creates a NullPointerException with a null
>> message in the case where the String argument is null.
>>
>> - the difference is not evident in the OpenJDK, because the HotSpot VM
>> creates a NPE with a null message by default if we call a method on a
>> null object.
>>
>> - however creating such a NPE with a null message when invoking a
>> method on a null object is not enforced by the standard, and other
>> implementations can do better :) For the following trivial program:
>>
>> public class NonNull {
>>  public static void main(String[] args) {
>>    Supplier<String> ss = null;
>>    Object o = Objects.requireNonNull(null, ss);
>>  }
>> }
>>
>> the current OpenJDK implementation returns:
>>
>> Exception in thread "main" java.lang.NullPointerException
>>    at java.util.Objects.requireNonNull(Objects.java:290)
>>    at NonNull.main(NonNull.java:8)
>>
>> but the SAP JVM will print:
>>
>> Exception in thread "main" java.lang.NullPointerException: while
>> trying to invoke the method java.util.function.Supplier.get() of a
>> null object loaded from local variable 'messageSupplier'
>>    at java.util.Objects.requireNonNull(Objects.java:290)
>>    at NonNull.main(NonNull.java:8)
>>
>> which is at least confusing for a call to Objects.requireNonNul() with
>> a null Supplier. We think the exception should be the same like the
>> one we get when invoking Objects.requireNonNul() with a null String.
>>
>> - because of this difference (and because we like our extended
>> Exception messages :) the JCK test for Objects.requireNonNul(T,
>> Supplier) (i.e.
>> api/java_util/Objects/index.html#RequireNonNullMessageSupplier) was
>> removed from TCK 8 and is still commented out in TCK 9
>> (npe_checkingNullSupplier() in RequireNonNullMessageSupplier.java).
>>
>> I really think that the simplest and most natural fix for this problem
>> is to simply check for a null Supplier argument and create the NPE
>> with an explicit null message in that case (as outlined in the
>> webrev). This:
>> - makes the two requireNonNul() overloads for String and Supplier
>> behave the same (which I think was the initial intention).
>> - doesn't require documentation changes
>> - makes it possible to write a simple and conforming TCK test
>>
>> If we can't agree on this quickly, I suggest to close the issue as
>> "will-not-fix" and leave it untested by the TCK.
>>
>> Thank you and best regards,
>> Volker
>>
>> PS: the 'XS' obviously only applies to the fix, not to this message :)
>

From david.holmes at oracle.com  Mon Feb 13 08:27:05 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 13 Feb 2017 18:27:05 +1000
Subject: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't
 specify what happens if the passed supplier is null itself
In-Reply-To: <CA+3eh13Z6gkqvi1CqH+cjDTtXmsoYSTucuWKfh_zLkUZntM5Ww@mail.gmail.com>
References: <CA+3eh13qSnt+CbyVNzB0eRp-rQkPhPu82tNhawhM11Q1Gw9qkg@mail.gmail.com>
 <7A11D19E-FBF6-4973-A38E-BA5D18C8F52F@oracle.com>
 <CA+3eh13Z6gkqvi1CqH+cjDTtXmsoYSTucuWKfh_zLkUZntM5Ww@mail.gmail.com>
Message-ID: <314308f5-a885-cab1-ea2e-aa362f34c367@oracle.com>

FWIW I think a null Supplier should simply be ignored.

David

On 13/02/2017 6:04 PM, Volker Simonis wrote:
> Ping...
>
> On Thu, Feb 9, 2017 at 5:32 PM, Jeff Dinkins <jeff.dinkins at oracle.com> wrote:
>>
>> Adding Mike?s current email.
>>
>> -jeff
>>
>>> On Feb 9, 2017, at 10:18 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> I want to finally resolve this long standing issue (or close it as
>>> "will not fix" if that's not possible):
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2017/8033909/
>>>
>>> This change has already been discussed in length on the mailing list:
>>>
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/thread.html#24989
>>>
>>> and in the bug comments:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8033909
>>>
>>> So I'll give just a short summary here:
>>>
>>> - Objects.requireNonNull(T, Supplier) does not check for the Supplier
>>> argument being null. Instead it relies on the fact, that the VM will
>>> implicitly throw a NullPointerException when it calls .get on the
>>> Supplier argument during the creation of the explicit
>>> NullPointerException which it is supposed to throw.
>>>
>>> - this behavior slightly differs from Objects.requireNonNull(T,
>>> String) which simply creates a NullPointerException with a null
>>> message in the case where the String argument is null.
>>>
>>> - the difference is not evident in the OpenJDK, because the HotSpot VM
>>> creates a NPE with a null message by default if we call a method on a
>>> null object.
>>>
>>> - however creating such a NPE with a null message when invoking a
>>> method on a null object is not enforced by the standard, and other
>>> implementations can do better :) For the following trivial program:
>>>
>>> public class NonNull {
>>>  public static void main(String[] args) {
>>>    Supplier<String> ss = null;
>>>    Object o = Objects.requireNonNull(null, ss);
>>>  }
>>> }
>>>
>>> the current OpenJDK implementation returns:
>>>
>>> Exception in thread "main" java.lang.NullPointerException
>>>    at java.util.Objects.requireNonNull(Objects.java:290)
>>>    at NonNull.main(NonNull.java:8)
>>>
>>> but the SAP JVM will print:
>>>
>>> Exception in thread "main" java.lang.NullPointerException: while
>>> trying to invoke the method java.util.function.Supplier.get() of a
>>> null object loaded from local variable 'messageSupplier'
>>>    at java.util.Objects.requireNonNull(Objects.java:290)
>>>    at NonNull.main(NonNull.java:8)
>>>
>>> which is at least confusing for a call to Objects.requireNonNul() with
>>> a null Supplier. We think the exception should be the same like the
>>> one we get when invoking Objects.requireNonNul() with a null String.
>>>
>>> - because of this difference (and because we like our extended
>>> Exception messages :) the JCK test for Objects.requireNonNul(T,
>>> Supplier) (i.e.
>>> api/java_util/Objects/index.html#RequireNonNullMessageSupplier) was
>>> removed from TCK 8 and is still commented out in TCK 9
>>> (npe_checkingNullSupplier() in RequireNonNullMessageSupplier.java).
>>>
>>> I really think that the simplest and most natural fix for this problem
>>> is to simply check for a null Supplier argument and create the NPE
>>> with an explicit null message in that case (as outlined in the
>>> webrev). This:
>>> - makes the two requireNonNul() overloads for String and Supplier
>>> behave the same (which I think was the initial intention).
>>> - doesn't require documentation changes
>>> - makes it possible to write a simple and conforming TCK test
>>>
>>> If we can't agree on this quickly, I suggest to close the issue as
>>> "will-not-fix" and leave it untested by the TCK.
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>> PS: the 'XS' obviously only applies to the fix, not to this message :)
>>

From christoph.langer at sap.com  Mon Feb 13 08:41:19 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 13 Feb 2017 08:41:19 +0000
Subject: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't
 specify what happens if the passed supplier is null itself
In-Reply-To: <314308f5-a885-cab1-ea2e-aa362f34c367@oracle.com>
References: <CA+3eh13qSnt+CbyVNzB0eRp-rQkPhPu82tNhawhM11Q1Gw9qkg@mail.gmail.com>
 <7A11D19E-FBF6-4973-A38E-BA5D18C8F52F@oracle.com>
 <CA+3eh13Z6gkqvi1CqH+cjDTtXmsoYSTucuWKfh_zLkUZntM5Ww@mail.gmail.com>
 <314308f5-a885-cab1-ea2e-aa362f34c367@oracle.com>
Message-ID: <a107103601444e11814a2343b75255a6@derote13de46.global.corp.sap>

Hi

> FWIW I think a null Supplier should simply be ignored.
...which is what Volker's change does.

After reading through all the discussion, I'm pro adding the null check as proposed in Volker's webrev.

Best regards
Christoph

> On 13/02/2017 6:04 PM, Volker Simonis wrote:
> > Ping...
> >
> > On Thu, Feb 9, 2017 at 5:32 PM, Jeff Dinkins <jeff.dinkins at oracle.com>
> wrote:
> >>
> >> Adding Mike?s current email.
> >>
> >> -jeff
> >>
> >>> On Feb 9, 2017, at 10:18 AM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I want to finally resolve this long standing issue (or close it as
> >>> "will not fix" if that's not possible):
> >>>
> >>> http://cr.openjdk.java.net/~simonis/webrevs/2017/8033909/
> >>>
> >>> This change has already been discussed in length on the mailing list:
> >>>
> >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-
> February/thread.html#24989
> >>>
> >>> and in the bug comments:
> >>>
> >>> https://bugs.openjdk.java.net/browse/JDK-8033909
> >>>
> >>> So I'll give just a short summary here:
> >>>
> >>> - Objects.requireNonNull(T, Supplier) does not check for the Supplier
> >>> argument being null. Instead it relies on the fact, that the VM will
> >>> implicitly throw a NullPointerException when it calls .get on the
> >>> Supplier argument during the creation of the explicit
> >>> NullPointerException which it is supposed to throw.
> >>>
> >>> - this behavior slightly differs from Objects.requireNonNull(T,
> >>> String) which simply creates a NullPointerException with a null
> >>> message in the case where the String argument is null.
> >>>
> >>> - the difference is not evident in the OpenJDK, because the HotSpot VM
> >>> creates a NPE with a null message by default if we call a method on a
> >>> null object.
> >>>
> >>> - however creating such a NPE with a null message when invoking a
> >>> method on a null object is not enforced by the standard, and other
> >>> implementations can do better :) For the following trivial program:
> >>>
> >>> public class NonNull {
> >>>  public static void main(String[] args) {
> >>>    Supplier<String> ss = null;
> >>>    Object o = Objects.requireNonNull(null, ss);
> >>>  }
> >>> }
> >>>
> >>> the current OpenJDK implementation returns:
> >>>
> >>> Exception in thread "main" java.lang.NullPointerException
> >>>    at java.util.Objects.requireNonNull(Objects.java:290)
> >>>    at NonNull.main(NonNull.java:8)
> >>>
> >>> but the SAP JVM will print:
> >>>
> >>> Exception in thread "main" java.lang.NullPointerException: while
> >>> trying to invoke the method java.util.function.Supplier.get() of a
> >>> null object loaded from local variable 'messageSupplier'
> >>>    at java.util.Objects.requireNonNull(Objects.java:290)
> >>>    at NonNull.main(NonNull.java:8)
> >>>
> >>> which is at least confusing for a call to Objects.requireNonNul() with
> >>> a null Supplier. We think the exception should be the same like the
> >>> one we get when invoking Objects.requireNonNul() with a null String.
> >>>
> >>> - because of this difference (and because we like our extended
> >>> Exception messages :) the JCK test for Objects.requireNonNul(T,
> >>> Supplier) (i.e.
> >>> api/java_util/Objects/index.html#RequireNonNullMessageSupplier)
> was
> >>> removed from TCK 8 and is still commented out in TCK 9
> >>> (npe_checkingNullSupplier() in RequireNonNullMessageSupplier.java).
> >>>
> >>> I really think that the simplest and most natural fix for this problem
> >>> is to simply check for a null Supplier argument and create the NPE
> >>> with an explicit null message in that case (as outlined in the
> >>> webrev). This:
> >>> - makes the two requireNonNul() overloads for String and Supplier
> >>> behave the same (which I think was the initial intention).
> >>> - doesn't require documentation changes
> >>> - makes it possible to write a simple and conforming TCK test
> >>>
> >>> If we can't agree on this quickly, I suggest to close the issue as
> >>> "will-not-fix" and leave it untested by the TCK.
> >>>
> >>> Thank you and best regards,
> >>> Volker
> >>>
> >>> PS: the 'XS' obviously only applies to the fix, not to this message :)
> >>

From volker.simonis at gmail.com  Mon Feb 13 09:10:51 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 13 Feb 2017 10:10:51 +0100
Subject: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't
 specify what happens if the passed supplier is null itself
In-Reply-To: <314308f5-a885-cab1-ea2e-aa362f34c367@oracle.com>
References: <CA+3eh13qSnt+CbyVNzB0eRp-rQkPhPu82tNhawhM11Q1Gw9qkg@mail.gmail.com>
 <7A11D19E-FBF6-4973-A38E-BA5D18C8F52F@oracle.com>
 <CA+3eh13Z6gkqvi1CqH+cjDTtXmsoYSTucuWKfh_zLkUZntM5Ww@mail.gmail.com>
 <314308f5-a885-cab1-ea2e-aa362f34c367@oracle.com>
Message-ID: <CA+3eh11jf-yeveUiobehMcr99MR6ZJ8O8qGyj4nRfE_5g_cNVg@mail.gmail.com>

On Mon, Feb 13, 2017 at 9:27 AM, David Holmes <david.holmes at oracle.com> wrote:
> FWIW I think a null Supplier should simply be ignored.
>

What do you mean by ignored? Do you mean "ignored" in the sense of  my
proposed changes (i.e. throw a NPE with a a null message) or do you
mean "ignored" in the sense that it is fine to generate a new,
implicit NPE when accessing the null supplier (with the consequences
detailed in the bug description')?

> David
>
>
> On 13/02/2017 6:04 PM, Volker Simonis wrote:
>>
>> Ping...
>>
>> On Thu, Feb 9, 2017 at 5:32 PM, Jeff Dinkins <jeff.dinkins at oracle.com>
>> wrote:
>>>
>>>
>>> Adding Mike?s current email.
>>>
>>> -jeff
>>>
>>>> On Feb 9, 2017, at 10:18 AM, Volker Simonis <volker.simonis at gmail.com>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I want to finally resolve this long standing issue (or close it as
>>>> "will not fix" if that's not possible):
>>>>
>>>> http://cr.openjdk.java.net/~simonis/webrevs/2017/8033909/
>>>>
>>>> This change has already been discussed in length on the mailing list:
>>>>
>>>>
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/thread.html#24989
>>>>
>>>> and in the bug comments:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8033909
>>>>
>>>> So I'll give just a short summary here:
>>>>
>>>> - Objects.requireNonNull(T, Supplier) does not check for the Supplier
>>>> argument being null. Instead it relies on the fact, that the VM will
>>>> implicitly throw a NullPointerException when it calls .get on the
>>>> Supplier argument during the creation of the explicit
>>>> NullPointerException which it is supposed to throw.
>>>>
>>>> - this behavior slightly differs from Objects.requireNonNull(T,
>>>> String) which simply creates a NullPointerException with a null
>>>> message in the case where the String argument is null.
>>>>
>>>> - the difference is not evident in the OpenJDK, because the HotSpot VM
>>>> creates a NPE with a null message by default if we call a method on a
>>>> null object.
>>>>
>>>> - however creating such a NPE with a null message when invoking a
>>>> method on a null object is not enforced by the standard, and other
>>>> implementations can do better :) For the following trivial program:
>>>>
>>>> public class NonNull {
>>>>  public static void main(String[] args) {
>>>>    Supplier<String> ss = null;
>>>>    Object o = Objects.requireNonNull(null, ss);
>>>>  }
>>>> }
>>>>
>>>> the current OpenJDK implementation returns:
>>>>
>>>> Exception in thread "main" java.lang.NullPointerException
>>>>    at java.util.Objects.requireNonNull(Objects.java:290)
>>>>    at NonNull.main(NonNull.java:8)
>>>>
>>>> but the SAP JVM will print:
>>>>
>>>> Exception in thread "main" java.lang.NullPointerException: while
>>>> trying to invoke the method java.util.function.Supplier.get() of a
>>>> null object loaded from local variable 'messageSupplier'
>>>>    at java.util.Objects.requireNonNull(Objects.java:290)
>>>>    at NonNull.main(NonNull.java:8)
>>>>
>>>> which is at least confusing for a call to Objects.requireNonNul() with
>>>> a null Supplier. We think the exception should be the same like the
>>>> one we get when invoking Objects.requireNonNul() with a null String.
>>>>
>>>> - because of this difference (and because we like our extended
>>>> Exception messages :) the JCK test for Objects.requireNonNul(T,
>>>> Supplier) (i.e.
>>>> api/java_util/Objects/index.html#RequireNonNullMessageSupplier) was
>>>> removed from TCK 8 and is still commented out in TCK 9
>>>> (npe_checkingNullSupplier() in RequireNonNullMessageSupplier.java).
>>>>
>>>> I really think that the simplest and most natural fix for this problem
>>>> is to simply check for a null Supplier argument and create the NPE
>>>> with an explicit null message in that case (as outlined in the
>>>> webrev). This:
>>>> - makes the two requireNonNul() overloads for String and Supplier
>>>> behave the same (which I think was the initial intention).
>>>> - doesn't require documentation changes
>>>> - makes it possible to write a simple and conforming TCK test
>>>>
>>>> If we can't agree on this quickly, I suggest to close the issue as
>>>> "will-not-fix" and leave it untested by the TCK.
>>>>
>>>> Thank you and best regards,
>>>> Volker
>>>>
>>>> PS: the 'XS' obviously only applies to the fix, not to this message :)
>>>
>>>
>

From frank.yuan at oracle.com  Mon Feb 13 09:35:47 2017
From: frank.yuan at oracle.com (Frank Yuan)
Date: Mon, 13 Feb 2017 17:35:47 +0800
Subject: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by
 JDK-8087303
In-Reply-To: <fcb8c2b1-429a-1377-fdbc-a27eb46acc3f@oracle.com>
References: <053101d2838d$529e5020$f7daf060$@oracle.com>
 <519870f0-80e8-cb70-e8e4-17c2ddfb0b50@oracle.com>
 <fcb8c2b1-429a-1377-fdbc-a27eb46acc3f@oracle.com>
Message-ID: <023b01d285dc$901573b0$b0405b10$@oracle.com>

Hi Joe and Daniel

Thank you very much for your review!

Frank


-----Original Message-----
From: huizhe wang [mailto:huizhe.wang at oracle.com] 
Sent: Saturday, February 11, 2017 5:52 AM
To: Daniel Fuchs; Frank Yuan; core-libs-dev at openjdk.java.net
Subject: Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303

+1 from me too.

Thanks,
Joe

On 2/10/2017 5:25 AM, Daniel Fuchs wrote:
> Hi Frank,
>
> Thanks for fixing this!
>
> I imported your patch and played with it a bit.
> Also ran the jaxp test.
>
> Both issues reported have indeed disappeared.
>
> So that's a +1 from me.
>
> best regards,
>
> -- daniel
>
> On 10/02/17 11:03, Frank Yuan wrote:
>> Hi All
>>
>>
>>
>> Would you like to review
>> http://cr.openjdk.java.net/~fyuan/8174025/webrev.00/?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174025
>>
>>
>>
>> JDK-8087303 introduced 2 issues:
>>
>> 1.       Flaw when xlst uses disable-output-escaping attribute
>>
>> 2.       Eat the whitespace between html inline elements
>>
>>
>>
>> This patch fixed the issues.
>>
>> To fix the second issue, we decide to keep the compatibility with JDK 8
>> on the whitespace handling, that is only LSSerializer cleans the extra
>> whitespaces in if pretty-print is on, but XSLT doesn't.
>>
>> I modified the behavior of getIndent() method in class ToStream, to make
>> LSSerializer be sensitive of current state from ToStream. This should be
>> safe because ToStream is an internal class and getIndent() method is
>> never used before.
>>
>>
>>
>> Thanks
>>
>> Frank
>>
>>
>>
>



From christoph.langer at sap.com  Mon Feb 13 15:14:44 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 13 Feb 2017 15:14:44 +0000
Subject: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates
 namespace prefixes if namespace is given as URI only
In-Reply-To: <abe747df-0b0f-f1e7-6451-b9f5c4801c0f@oracle.com>
References: <dcceb6e6de034a748d881d2f3eb19e47@derote13de46.global.corp.sap>
 <589A68B4.7010307@oracle.com>
 <95d39d5bdb2f404fa97cbe77d314d061@derote13de46.global.corp.sap>
 <abe747df-0b0f-f1e7-6451-b9f5c4801c0f@oracle.com>
Message-ID: <03a4a1fa20cd41d3b9f7ca56bc814f90@derote13de46.global.corp.sap>

Hi Joe,

here is the change, rebased for JDK10:
http://cr.openjdk.java.net/~clanger/webrevs/8168664-10.0/

This version would never generate prefixes for xsl:element and hence I removed the check for the property. Also Aleksej's test test/javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java needs to go then as it would be obsolete and would fail. Other than that, I ran the jtreg tests and found no other issues.

Thanks
Christoph


From: huizhe wang [mailto:huizhe.wang at oracle.com]
Sent: Donnerstag, 9. Februar 2017 17:25
To: Langer, Christoph <christoph.langer at sap.com>
Cc: core-libs-dev at openjdk.java.net; Aleksej Efimov <aleksej.efimov at oracle.com>
Subject: Re: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only


On 2/7/2017 11:28 PM, Langer, Christoph wrote:
Hi Joe,

welcome back.

Thanks!


This sounds reasonable. I'll prepare a change for JDK10.

Hopefully it'd open soon so that you don't have to keep it for too long.

Best,
Joe



Thanks
Christoph

From: Joe Wang [mailto:huizhe.wang at oracle.com]
Sent: Mittwoch, 8. Februar 2017 01:39
To: Langer, Christoph <christoph.langer at sap.com><mailto:christoph.langer at sap.com>
Cc: core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>; Aleksej Efimov <aleksej.efimov at oracle.com><mailto:aleksej.efimov at oracle.com>
Subject: Re: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only

Hi Christoph,

As we discussed, let's target this for JDK 10 as a spec change at this stage for JDK 9 is too late. Removing the namespace generation would be another reason to do this in JDK 10 since then, we wouldn't need the additional property.

Thanks,
Joe

On 1/31/17, 11:02 AM, Langer, Christoph wrote:
Hi Joe,

evenutally I have updated my webrev for this issue: http://cr.openjdk.java.net/~clanger/webrevs/8168664.1/<http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664.1/>

I've implemented your suggestion to add a property "jdk.xml.generatePrefix" which is true by default. I also added a testcase which tests the correct behavior with "-Djdk.xml.generatePrefix=false".

Generally, I think namespace prefix generation at this place is not needed. Or would you know of or be able to construct a case where it is really required? If not, I rather think namespace generation at this place should be thrown out unconditionally. Maybe for JDK10? In case it is removed, it would render the test javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java which was implemented recently by Alex for bug https://bugs.openjdk.java.net/browse/JDK-8167179 obsolete in its current form. However, the namespace generation function is still used some place for attribute namespaces.

For JDK9 I can imagine the change of this webrev going in - however, as we already discussed, you would have to do a ccc for me.

Thanks & Best regards
Christoph

From: Langer, Christoph
Sent: Dienstag, 25. Oktober 2016 15:39
To: core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>
Subject: RFR (JAXP): 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only

Hi JAXP experts,

please review a fix for a new issue regarding namespace handling in Xalan with xsl:element.

Bug: https://bugs.openjdk.java.net/browse/JDK-8168664
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8168664.0/<http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664.0/>

I'm not 100% sure if this is the right way to go or if it would break some correct behavior elsewhere. But I think the current behavior is either not correct or at least it is not required to generate new xsl namespace prefixes if the namespace comes in as URI only to an xsl:element node. The interpretative transformer from the Apache Xalan project will also produce the expected output, different to the compiled XSLTC here.

In the webrev, my changes to XslElement.java are only cosmetical/comments, the behavior does not change. In BasisLibrary.java I also took the opportunity to remove the $Id tag and the unused method "nodeList2IteratorUsingHandleFromNode".

If you think my change is good, I'll also add a test that runs the transformation which can be found in the bug...

Thanks & best regards
Christoph



From christoph.langer at sap.com  Mon Feb 13 15:29:27 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 13 Feb 2017 15:29:27 +0000
Subject: Update: RFR 8172974 [JAXP] XALAN: Wrong result when transforming
 namespace unaware StAX Input
References: <3f43563228ef4f7ca2eed6281698a17c@derote13de46.global.corp.sap>
 <589A6C4C.60302@oracle.com> <b831884c-627d-5551-cb0c-2d12d0c55b9b@oracle.com> 
Message-ID: <1dda16fed9e74ead8f4b885ac1fb4c54@derote13de46.global.corp.sap>

Hi Joe,

this is an updated webrev with only the change in namespace handling and the testcase: http://cr.openjdk.java.net/~clanger/webrevs/8172974.1-SAX2DTM2only/

I'd really be interested in the performance results for that one before I turn to JDK10.

Thanks
Christoph

> -----Original Message-----
> From: Langer, Christoph
> Sent: Samstag, 11. Februar 2017 15:50
> To: 'huizhe wang' <huizhe.wang at oracle.com>
> Cc: core-libs-dev at openjdk.java.net
> Subject: RE: Update: RFR 8172974 [JAXP] XALAN: Wrong result when
> transforming namespace unaware StAX Input
> 
> Hi Joe,
> 
> that's unfortunate but if these are the numbers then we have to deal with it.
> It's a bit odd, though, that this does not cause a regression on all platforms.
> So, you are really sure the regression roots in my current proposal for
> 8172974?
> 
> One thing I'd want to have been looked at is if the regression really roots to
> my change in SAX2DTM2.java. This is the real modification. Everything else is
> just cleanup. And looking at SAX2DTM2, I really can't see where I should have
> introduced something bad. Can you retest this?
> 
> Also, moving this to JDK10 would be fine for me. Shall I submit my fix there as
> is or do you want to conduct some deeper analysis about the performance
> regression's root cause? Can I somehow assist with that?
> 
> Thanks
> Christoph
> 
> > -----Original Message-----
> > From: huizhe wang [mailto:huizhe.wang at oracle.com]
> > Sent: Donnerstag, 9. Februar 2017 23:15
> > To: Langer, Christoph <christoph.langer at sap.com>
> > Cc: core-libs-dev at openjdk.java.net
> > Subject: Re: Update: RFR 8172974 [JAXP] XALAN: Wrong result when
> > transforming namespace unaware StAX Input
> >
> > Hi Christoph,
> >
> > The performance results showed two regressions, one on Linux and
> another
> > Solaris SPARC, while at the same time a bit more than half of the
> > results across 5 platforms were negative. This is unfortunate. We're too
> > close to the release date, it's super sensitive for jaxp on the
> > performance front. I'd like to suggest that we move this patch to a
> > 9-update or 10 when we'd have plenty of time to deal with any possible
> > fallout. I consulted our performance expert and this is also his
> > recommendation. I hope you'd understand.
> >
> > Thanks,
> > Joe
> >
> > On 2/7/2017 4:54 PM, Joe Wang wrote:
> > > Hi Christoph,
> > >
> > > We'll double-check whether there's any performance implications.
> > > Please give us a couple of (or few) days.
> > >
> > > Thanks,
> > > Joe
> > >
> > > On 1/30/17, 7:28 AM, Langer, Christoph wrote:
> > >> Hi Joe,
> > >>
> > >> I've updated my webrev for 8172974 after pulling out the refactoring
> > >> of javax/xml/jaxp/unittest/transform/TransformerTest.java to Bug
> > >> 8173602: http://cr.openjdk.java.net/~clanger/webrevs/8172974.1/
> > >>
> > >> After exchanging some off-list mails with Lance and Daniel, we came
> > >> to the conclusion that you should decide about this one when you are
> > >> back. The changes are merely cleanups apart from
> > >>
> >
> com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM2.startEleme
> > nt(),
> > >> which to me seem natural after 8169631, though.
> > >>
> > >> Thanks,
> > >> Christoph
> > >>
> > >>> -----Original Message-----
> > >>> From: Langer, Christoph
> > >>> Sent: Mittwoch, 18. Januar 2017 22:55
> > >>> To: 'huizhe wang'<huizhe.wang at oracle.com>;
> > >>> core-libs-dev at openjdk.java.net
> > >>> Subject: RE: RFR 8172974 [JAXP] XALAN: Wrong result when
> > transforming
> > >>> namespace unaware StAX Input
> > >>>
> > >>> Hi Joe,
> > >>>
> > >>> generally, you are right, XSLT requires namespace support. For
> > >>> parsing the
> > >>> stylesheet, it is definitely a hard requirement. Otherwise this
> > >>> would not make
> > >>> sense at all. For instance xsl directives are in the xsl namespace.
> > >>> That
> > >>> requirement is what the FAQ you are referencing [1] is talking about.
> > >>>
> > >>> As for the InputSource which is to be processed, it is probably also
> > >>> not a right to
> > >>> use non namespace aware parsing. But still it's not forbidden. For
> > >>> instance, the
> > >>> JavaDoc for SAXSource [2] states this:
> > >>> "Note that XSLT requires namespace support. Attempting to transform
> > >>> an input
> > >>> source that is not generated with a namespace-aware parser may
> > >>> result in
> > >>> errors. Parsers can be made namespace aware by calling the
> > >>> SAXParserFactory.setNamespaceAware(boolean awareness)
> method."
> > >>>
> > >>> So, I agree, we are in the error space here. But still I think the
> > >>> result of non
> > >>> namespace aware parsing should be the same for all types of input
> > >>> source. And
> > >>> at the moment it is the same for DOMSource and SAXSource but not
> for
> > >>> StAXSource. From that point of view I think my fix makes sense
> > >>> (along with the
> > >>> other cleanups).
> > >>>
> > >>> Best regards
> > >>> Christoph
> > >>>
> > >>> [1] https://xml.apache.org/xalan-j/faq.html#faq-N10207
> > >>> [2]
> > >>>
> >
> https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSo
> > urce
> > >>>
> > >>> .html
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
> > >>>> Sent: Mittwoch, 18. Januar 2017 22:12
> > >>>> To: Langer, Christoph<christoph.langer at sap.com>; core-libs-
> > >>>> dev at openjdk.java.net
> > >>>> Subject: Re: RFR 8172974 [JAXP] XALAN: Wrong result when
> > transforming
> > >>>> namespace unaware StAX Input
> > >>>>
> > >>>> Hi Christoph,
> > >>>>
> > >>>> Xalan requires the underlying parser to be namespace aware. Please
> > >>>> refer
> > >>>> to https://xml.apache.org/xalan-j/faq.html#faq-N10207
> > >>>>
> > >>>> Thanks,
> > >>>> Joe
> > >>>>
> > >>>> On 1/18/2017 8:26 AM, Langer, Christoph wrote:
> > >>>>> Hi,
> > >>>>>
> > >>>>> please review a change for JAXP.
> > >>>>>
> > >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172974
> > >>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172974.0/
> > >>>>>
> > >>>>> When enhancing the test for
> > https://bugs.openjdk.java.net/browse/JDK-
> > >>>> 8023653, I saw that there's still an issue with StAXInputSource
> > >>>> which is not
> > >>>> namespace aware. This needs a small update in
> > >>>>
> > >>>
> >
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2
> > dt
> > >>>
> > >>>> m/SAX2DTM2.java. Furthermore, I added the fixed warnings and
> > >>>> formattings
> > >>>> from the proposal
> > >>>> http://cr.openjdk.java.net/~clanger/webrevs/8023653.0/ to
> > >>>> this webrev, as 8023653 is an enhancement and might not go in in
> > >>>> the near
> > >>>> future.
> > >>>>> I also enhanced the TransformerTest to utilize data providers now
> > >>>>> and test
> > >>> a
> > >>>> comprehensive matrix of XALAN input.
> > >>>>> Thanks in advance and Best regards
> > >>>>> Christoph
> > >>>>>


From chris.hegarty at oracle.com  Mon Feb 13 16:12:19 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 13 Feb 2017 16:12:19 +0000
Subject: RFR: JDK-8173094 Error in API documentation for SwingWorker
In-Reply-To: <78234c7d-e048-7e61-4361-f0861d09aabd@oracle.com>
References: <e6663ccf-dead-4412-88a7-9cf25a0d8508@default>
 <6dbdc805-d3f9-498b-b15e-888d4011f683@default>
 <f4158cc9-f6f0-af93-e7ea-7d778248ea36@oracle.com>
 <78234c7d-e048-7e61-4361-f0861d09aabd@oracle.com>
Message-ID: <36319c78-2001-4c71-13e9-13234b64f2a5@oracle.com>

On 10/02/17 19:18, Abhijit Roy wrote:
> Hi Sean,
>
> As per your suggestion, I have corrected those points. Please find the
> link below for further review.
>
> http://cr.openjdk.java.net/~rpatil/ababroy/8173094/webrev.01/

This looks good. Please include all the relevant bugIds in the
changeset comment.

-Chris.

> <http://cr.openjdk.java.net/%7Erpatil/ababroy/8173094/webrev.01/>
>
> Thanks,
> Abhijit
>
>
>
> On 2/10/2017 10:37 PM, Se?n Coffey wrote:
>> Hi Abhijit,
>>
>> you'll need to correct the Copyright year format in your edits. It
>> needs to be "Copyright (c) <start_year>, <end_year>, Oracle..." format.
>>
>> For the ZipFile change, you need to use lower case 's' in @since.
>>
>> Looks good otherwise.
>>
>> regards,
>> Sean.
>>
>> On 10/02/17 10:51, Abhijit Roy wrote:
>>> Hi all,
>>>
>>> Please review the java doc fix for the below Bug:
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173094
>>>
>>> Description: Error in API documentation for SwingWorker
>>>
>>> Webrev-http://cr.openjdk.java.net/~rpatil/ababroy/8173094/webrev.00/
>>>
>>>
>>> I have addressed some other doc issues which I included into the same
>>> webrev, please find those links below.
>>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173751
>>>
>>> Description: Syntax error in ZipFile.getComment() method
>>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173752
>>>
>>> Description: Syntax error in ZipEntry.setCompressedSize(long) method
>>> documentation
>>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173755
>>>
>>> Description: The word input should be replaced by output in
>>> FilterOutputStream.write(byte[],int,int) method documentation
>>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173802
>>>
>>> Description: Incorrect argument name in
>>> java.io.FilterInputStream.read(byte[]) method documentation
>>>
>>>
>>>
>>> Regards,
>>>
>>> Abhijit
>>
>

From sean.coffey at oracle.com  Mon Feb 13 16:14:07 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 13 Feb 2017 16:14:07 +0000
Subject: RFR: JDK-8173094, 8173751, 8173752, 8173755, 8173802
In-Reply-To: <78234c7d-e048-7e61-4361-f0861d09aabd@oracle.com>
References: <e6663ccf-dead-4412-88a7-9cf25a0d8508@default>
 <6dbdc805-d3f9-498b-b15e-888d4011f683@default>
 <f4158cc9-f6f0-af93-e7ea-7d778248ea36@oracle.com>
 <78234c7d-e048-7e61-4361-f0861d09aabd@oracle.com>
Message-ID: <ec655e37-366d-7ce5-306e-0e3f31c1a7f3@oracle.com>

Updated the subject line. Looks fine.

Minor nit with FilterOutputStream.java

       * <code>write</code> method of its underlying output stream with 
the single
       * argument <code>b</code>.

You're gone over 80 chars in length here. You can bring a word or two 
down to the last line. Do you want me to push this change for you?

Regards,
Sean.

On 10/02/17 19:18, Abhijit Roy wrote:

> Hi Sean,
>
> As per your suggestion, I have corrected those points. Please find the 
> link below for further review.
>
> http://cr.openjdk.java.net/~rpatil/ababroy/8173094/webrev.01/ 
> <http://cr.openjdk.java.net/%7Erpatil/ababroy/8173094/webrev.01/>
>
> Thanks,
> Abhijit
>
>
>
> On 2/10/2017 10:37 PM, Se?n Coffey wrote:
>> Hi Abhijit,
>>
>> you'll need to correct the Copyright year format in your edits. It 
>> needs to be "Copyright (c) <start_year>, <end_year>, Oracle..." format.
>>
>> For the ZipFile change, you need to use lower case 's' in @since.
>>
>> Looks good otherwise.
>>
>> regards,
>> Sean.
>>
>> On 10/02/17 10:51, Abhijit Roy wrote:
>>> Hi all,
>>>
>>> Please review the java doc fix for the below Bug:
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173094
>>>
>>> Description: Error in API documentation for SwingWorker
>>>
>>> Webrev-http://cr.openjdk.java.net/~rpatil/ababroy/8173094/webrev.00/
>>>
>>>
>>> I have addressed some other doc issues which I included into the 
>>> same webrev, please find those links below.
>>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173751
>>>
>>> Description: Syntax error in ZipFile.getComment() method
>>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173752
>>>
>>> Description: Syntax error in ZipEntry.setCompressedSize(long) method 
>>> documentation
>>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173755
>>>
>>> Description: The word input should be replaced by output in 
>>> FilterOutputStream.write(byte[],int,int) method documentation
>>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173802
>>>
>>> Description: Incorrect argument name in 
>>> java.io.FilterInputStream.read(byte[]) method documentation
>>>
>>>
>>>
>>> Regards,
>>>
>>> Abhijit
>>
>


From Alan.Bateman at oracle.com  Mon Feb 13 16:57:49 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 13 Feb 2017 16:57:49 +0000
Subject: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't
 specify what happens if the passed supplier is null itself
In-Reply-To: <CA+3eh13qSnt+CbyVNzB0eRp-rQkPhPu82tNhawhM11Q1Gw9qkg@mail.gmail.com>
References: <CA+3eh13qSnt+CbyVNzB0eRp-rQkPhPu82tNhawhM11Q1Gw9qkg@mail.gmail.com>
Message-ID: <b6c27d3b-27bf-921f-597c-e57d193101fc@oracle.com>

On 09/02/2017 16:18, Volker Simonis wrote:

> :
>
> I really think that the simplest and most natural fix for this problem
> is to simply check for a null Supplier argument and create the NPE
> with an explicit null message in that case (as outlined in the
> webrev). This:
>   - makes the two requireNonNul() overloads for String and Supplier
> behave the same (which I think was the initial intention).
>   - doesn't require documentation changes
>   - makes it possible to write a simple and conforming TCK test
>
> If we can't agree on this quickly, I suggest to close the issue as
> "will-not-fix" and leave it untested by the TCK.
>
If I read JDK-8033909 correctly then it's a request for the javadoc to 
specify the expected behavior when called with a messageSupplier of 
null. I think Joe said at one point that he deliberately didn't specify 
this. If that remains the position then the issue can be closed as WNF 
so that we don't waste any more discussion on it.

If I read your mail and patch correctly then it's more about what the 
NPE message is. I agree the exception you pasted in from the SAP build 
is difficult to read, in which case your patch makes it easier to read. 
That make sense and maybe just push that with a separate issue.

-Alan

From denis.kononenko at oracle.com  Mon Feb 13 17:58:12 2017
From: denis.kononenko at oracle.com (Denis Kononenko)
Date: Mon, 13 Feb 2017 09:58:12 -0800 (PST)
Subject: [9] RFR: 8169715: jimage fails with IAE when attempts to inspect
 an empty file
Message-ID: <9de28ff1-30b3-4a66-8b95-8469a58a55a0@default>

  
  Hi,

  Optimized buffer's capacity checks.

  WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.02

> 
> Could please someone review the fix for JDK-8169715.
>   
> The problem occurs when jimage tool is attempting to read an empty or
> incomplete image. The current implementation works with ByteBuffer and
> always relies on that there's enough data to inspect the image. This
> results in IAE inside of BasicImageReader.slice method when the buffer
> is smaller then it's expected.
> 
> I added a few checks to avoid IAE and throw IOException with a more
> descriptive text.
> 
> 
>   BUGURL: https://bugs.openjdk.java.net/browse/JDK-8169715
>   WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.01
> 
>   Thank you,
>   Denis.

Thank you,
Denis.

From james.laskey at oracle.com  Mon Feb 13 18:01:44 2017
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Mon, 13 Feb 2017 14:01:44 -0400
Subject: [9] RFR: 8169715: jimage fails with IAE when attempts to inspect
 an empty file
In-Reply-To: <9de28ff1-30b3-4a66-8b95-8469a58a55a0@default>
References: <9de28ff1-30b3-4a66-8b95-8469a58a55a0@default>
Message-ID: <F4E34234-7AA7-4BDE-BC10-1F176377690B@oracle.com>

+1

> On Feb 13, 2017, at 1:58 PM, Denis Kononenko <denis.kononenko at oracle.com> wrote:
> 
> 
>  Hi,
> 
>  Optimized buffer's capacity checks.
> 
>  WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.02 <http://cr.openjdk.java.net/~dkononenko/8169715/webrev.02>
> 
>> 
>> Could please someone review the fix for JDK-8169715.
>> 
>> The problem occurs when jimage tool is attempting to read an empty or
>> incomplete image. The current implementation works with ByteBuffer and
>> always relies on that there's enough data to inspect the image. This
>> results in IAE inside of BasicImageReader.slice method when the buffer
>> is smaller then it's expected.
>> 
>> I added a few checks to avoid IAE and throw IOException with a more
>> descriptive text.
>> 
>> 
>>  BUGURL: https://bugs.openjdk.java.net/browse/JDK-8169715
>>  WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.01
>> 
>>  Thank you,
>>  Denis.
> 
> Thank you,
> Denis.


From andrey.x.nazarov at oracle.com  Mon Feb 13 18:05:10 2017
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Mon, 13 Feb 2017 21:05:10 +0300
Subject: [9] RFR: 8169715: jimage fails with IAE when attempts to inspect
 an empty file
In-Reply-To: <9de28ff1-30b3-4a66-8b95-8469a58a55a0@default>
References: <9de28ff1-30b3-4a66-8b95-8469a58a55a0@default>
Message-ID: <619AD863-FF35-43DE-9A85-62034B43A049@oracle.com>

Looks good
> On 13 Feb 2017, at 20:58, Denis Kononenko <denis.kononenko at oracle.com> wrote:
> 
> 
>  Hi,
> 
>  Optimized buffer's capacity checks.
> 
>  WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.02 <http://cr.openjdk.java.net/~dkononenko/8169715/webrev.02>
> 
>> 
>> Could please someone review the fix for JDK-8169715.
>> 
>> The problem occurs when jimage tool is attempting to read an empty or
>> incomplete image. The current implementation works with ByteBuffer and
>> always relies on that there's enough data to inspect the image. This
>> results in IAE inside of BasicImageReader.slice method when the buffer
>> is smaller then it's expected.
>> 
>> I added a few checks to avoid IAE and throw IOException with a more
>> descriptive text.
>> 
>> 
>>  BUGURL: https://bugs.openjdk.java.net/browse/JDK-8169715
>>  WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.01
>> 
>>  Thank you,
>>  Denis.
> 
> Thank you,
> Denis.


From huizhe.wang at oracle.com  Mon Feb 13 18:22:31 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 13 Feb 2017 10:22:31 -0800
Subject: should have been 8174025 -> Re: RFR [JAXP] JDK-8170192 Regression in
 XML Transform caused by JDK-8087303
In-Reply-To: <023b01d285dc$901573b0$b0405b10$@oracle.com>
References: <053101d2838d$529e5020$f7daf060$@oracle.com>
 <519870f0-80e8-cb70-e8e4-17c2ddfb0b50@oracle.com>
 <fcb8c2b1-429a-1377-fdbc-a27eb46acc3f@oracle.com>
 <023b01d285dc$901573b0$b0405b10$@oracle.com>
Message-ID: <3aca7dfd-92bf-163c-b9d9-1505e534ecff@oracle.com>

Note that the bug id was incorrect, it should have been 8174025. 8170192 
was a test bug fix.

-Joe

On 2/13/2017 1:35 AM, Frank Yuan wrote:
> Hi Joe and Daniel
>
> Thank you very much for your review!
>
> Frank
>
>
> -----Original Message-----
> From: huizhe wang [mailto:huizhe.wang at oracle.com]
> Sent: Saturday, February 11, 2017 5:52 AM
> To: Daniel Fuchs; Frank Yuan; core-libs-dev at openjdk.java.net
> Subject: Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303
>
> +1 from me too.
>
> Thanks,
> Joe
>
> On 2/10/2017 5:25 AM, Daniel Fuchs wrote:
>> Hi Frank,
>>
>> Thanks for fixing this!
>>
>> I imported your patch and played with it a bit.
>> Also ran the jaxp test.
>>
>> Both issues reported have indeed disappeared.
>>
>> So that's a +1 from me.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 10/02/17 11:03, Frank Yuan wrote:
>>> Hi All
>>>
>>>
>>>
>>> Would you like to review
>>> http://cr.openjdk.java.net/~fyuan/8174025/webrev.00/?
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174025
>>>
>>>
>>>
>>> JDK-8087303 introduced 2 issues:
>>>
>>> 1.       Flaw when xlst uses disable-output-escaping attribute
>>>
>>> 2.       Eat the whitespace between html inline elements
>>>
>>>
>>>
>>> This patch fixed the issues.
>>>
>>> To fix the second issue, we decide to keep the compatibility with JDK 8
>>> on the whitespace handling, that is only LSSerializer cleans the extra
>>> whitespaces in if pretty-print is on, but XSLT doesn't.
>>>
>>> I modified the behavior of getIndent() method in class ToStream, to make
>>> LSSerializer be sensitive of current state from ToStream. This should be
>>> safe because ToStream is an internal class and getIndent() method is
>>> never used before.
>>>
>>>
>>>
>>> Thanks
>>>
>>> Frank
>>>
>>>
>>>
>


From abhijit.r.roy at oracle.com  Mon Feb 13 18:37:30 2017
From: abhijit.r.roy at oracle.com (Abhijit Roy)
Date: Tue, 14 Feb 2017 00:07:30 +0530
Subject: RFR: JDK-8173094, 8173751, 8173752, 8173755, 8173802
In-Reply-To: <ec655e37-366d-7ce5-306e-0e3f31c1a7f3@oracle.com>
References: <e6663ccf-dead-4412-88a7-9cf25a0d8508@default>
 <6dbdc805-d3f9-498b-b15e-888d4011f683@default>
 <f4158cc9-f6f0-af93-e7ea-7d778248ea36@oracle.com>
 <78234c7d-e048-7e61-4361-f0861d09aabd@oracle.com>
 <ec655e37-366d-7ce5-306e-0e3f31c1a7f3@oracle.com>
Message-ID: <adb2ed05-0485-39fb-3e60-010bfd96b5d6@oracle.com>

Hi Sean,

Yes, It would be great if you could push it for me. For that, I will 
send you a new webrev link with the below update.

Thanks,
Abhijit

On 2/13/2017 9:44 PM, Se?n Coffey wrote:
> Updated the subject line. Looks fine.
>
> Minor nit with FilterOutputStream.java
>
>       * <code>write</code> method of its underlying output stream with 
> the single
>       * argument <code>b</code>.
>
> You're gone over 80 chars in length here. You can bring a word or two 
> down to the last line. Do you want me to push this change for you?
>
> Regards,
> Sean.
>
> On 10/02/17 19:18, Abhijit Roy wrote:
>
>> Hi Sean,
>>
>> As per your suggestion, I have corrected those points. Please find 
>> the link below for further review.
>>
>> http://cr.openjdk.java.net/~rpatil/ababroy/8173094/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Erpatil/ababroy/8173094/webrev.01/>
>>
>> Thanks,
>> Abhijit
>>
>>
>>
>> On 2/10/2017 10:37 PM, Se?n Coffey wrote:
>>> Hi Abhijit,
>>>
>>> you'll need to correct the Copyright year format in your edits. It 
>>> needs to be "Copyright (c) <start_year>, <end_year>, Oracle..." format.
>>>
>>> For the ZipFile change, you need to use lower case 's' in @since.
>>>
>>> Looks good otherwise.
>>>
>>> regards,
>>> Sean.
>>>
>>> On 10/02/17 10:51, Abhijit Roy wrote:
>>>> Hi all,
>>>>
>>>> Please review the java doc fix for the below Bug:
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173094
>>>>
>>>> Description: Error in API documentation for SwingWorker
>>>>
>>>> Webrev-http://cr.openjdk.java.net/~rpatil/ababroy/8173094/webrev.00/
>>>>
>>>>
>>>> I have addressed some other doc issues which I included into the 
>>>> same webrev, please find those links below.
>>>>
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173751
>>>>
>>>> Description: Syntax error in ZipFile.getComment() method
>>>>
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173752
>>>>
>>>> Description: Syntax error in ZipEntry.setCompressedSize(long) 
>>>> method documentation
>>>>
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173755
>>>>
>>>> Description: The word input should be replaced by output in 
>>>> FilterOutputStream.write(byte[],int,int) method documentation
>>>>
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173802
>>>>
>>>> Description: Incorrect argument name in 
>>>> java.io.FilterInputStream.read(byte[]) method documentation
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Abhijit
>>>
>>
>


From claes.redestad at oracle.com  Mon Feb 13 19:03:07 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 13 Feb 2017 20:03:07 +0100
Subject: RFR: 8174831: Reduce number of Charset classes loaded on bootstrap
Message-ID: <3b3acc2c-0bd9-2991-3981-e72e9d418559@oracle.com>

Hi,

this patch addresses a few tiny startup regressions incurred mostly by
the fact that Compact Strings eagerly loads more Charsets early.

java.nio.charset.StandardCharsets is dropped from the early bootstrap,
load fastpaths are added for the 3 eagerly used Charsets (which avoids
some early reflection use), plus a couple of other nits:

Webrev: http://cr.openjdk.java.net/~redestad/8174831/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8174831

Testing: jdk-tier1 tests

Thanks!

/Claes

From xueming.shen at oracle.com  Mon Feb 13 19:08:40 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 13 Feb 2017 11:08:40 -0800
Subject: RFR: 8174831: Reduce number of Charset classes loaded on bootstrap
In-Reply-To: <3b3acc2c-0bd9-2991-3981-e72e9d418559@oracle.com>
References: <3b3acc2c-0bd9-2991-3981-e72e9d418559@oracle.com>
Message-ID: <58A20438.1040808@oracle.com>

On 02/13/2017 11:03 AM, Claes Redestad wrote:
> Hi,
>
> this patch addresses a few tiny startup regressions incurred mostly by
> the fact that Compact Strings eagerly loads more Charsets early.
>
> java.nio.charset.StandardCharsets is dropped from the early bootstrap,
> load fastpaths are added for the 3 eagerly used Charsets (which avoids
> some early reflection use), plus a couple of other nits:
>
> Webrev: http://cr.openjdk.java.net/~redestad/8174831/webrev.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8174831
>
> Testing: jdk-tier1 tests
>
> Thanks!
>
> /Claes
+1

From Alan.Bateman at oracle.com  Mon Feb 13 19:12:33 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 13 Feb 2017 19:12:33 +0000
Subject: RFR: 8174831: Reduce number of Charset classes loaded on bootstrap
In-Reply-To: <3b3acc2c-0bd9-2991-3981-e72e9d418559@oracle.com>
References: <3b3acc2c-0bd9-2991-3981-e72e9d418559@oracle.com>
Message-ID: <a32f4f20-731a-d14d-8574-9dea601087f8@oracle.com>

On 13/02/2017 19:03, Claes Redestad wrote:

> Hi,
>
> this patch addresses a few tiny startup regressions incurred mostly by
> the fact that Compact Strings eagerly loads more Charsets early.
>
> java.nio.charset.StandardCharsets is dropped from the early bootstrap,
> load fastpaths are added for the 3 eagerly used Charsets (which avoids
> some early reflection use), plus a couple of other nits:
>
> Webrev: http://cr.openjdk.java.net/~redestad/8174831/webrev.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8174831
>
> Testing: jdk-tier1 tests
One suggestion is to comment the `==` check in Charset.lookup as future 
maintainers may wonder why it doesn't use equals.

-Alan.

From huizhe.wang at oracle.com  Mon Feb 13 19:21:35 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 13 Feb 2017 11:21:35 -0800
Subject: Update: RFR 8172974 [JAXP] XALAN: Wrong result when transforming
 namespace unaware StAX Input
In-Reply-To: <1dda16fed9e74ead8f4b885ac1fb4c54@derote13de46.global.corp.sap>
References: <3f43563228ef4f7ca2eed6281698a17c@derote13de46.global.corp.sap>
 <589A6C4C.60302@oracle.com> <b831884c-627d-5551-cb0c-2d12d0c55b9b@oracle.com>
 <1dda16fed9e74ead8f4b885ac1fb4c54@derote13de46.global.corp.sap>
Message-ID: <71acc2ab-9f35-df77-3792-f63a1e59b667@oracle.com>

Hi Christoph,

The negatives were actually across all platforms, although the benchmark 
system picked up that it thinks were significant (high probability of a 
regression). There were negatives numbers that were bigger than the two.

One possibility, if you look at the code change, is that the tests 
contained cases where both uri and localName are null, with this change 
then, there will be extra operations.

Thanks,
Joe

On 2/13/2017 7:29 AM, Langer, Christoph wrote:
> Hi Joe,
>
> this is an updated webrev with only the change in namespace handling and the testcase: http://cr.openjdk.java.net/~clanger/webrevs/8172974.1-SAX2DTM2only/
>
> I'd really be interested in the performance results for that one before I turn to JDK10.
>
> Thanks
> Christoph
>
>> -----Original Message-----
>> From: Langer, Christoph
>> Sent: Samstag, 11. Februar 2017 15:50
>> To: 'huizhe wang' <huizhe.wang at oracle.com>
>> Cc: core-libs-dev at openjdk.java.net
>> Subject: RE: Update: RFR 8172974 [JAXP] XALAN: Wrong result when
>> transforming namespace unaware StAX Input
>>
>> Hi Joe,
>>
>> that's unfortunate but if these are the numbers then we have to deal with it.
>> It's a bit odd, though, that this does not cause a regression on all platforms.
>> So, you are really sure the regression roots in my current proposal for
>> 8172974?
>>
>> One thing I'd want to have been looked at is if the regression really roots to
>> my change in SAX2DTM2.java. This is the real modification. Everything else is
>> just cleanup. And looking at SAX2DTM2, I really can't see where I should have
>> introduced something bad. Can you retest this?
>>
>> Also, moving this to JDK10 would be fine for me. Shall I submit my fix there as
>> is or do you want to conduct some deeper analysis about the performance
>> regression's root cause? Can I somehow assist with that?
>>
>> Thanks
>> Christoph
>>
>>> -----Original Message-----
>>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
>>> Sent: Donnerstag, 9. Februar 2017 23:15
>>> To: Langer, Christoph <christoph.langer at sap.com>
>>> Cc: core-libs-dev at openjdk.java.net
>>> Subject: Re: Update: RFR 8172974 [JAXP] XALAN: Wrong result when
>>> transforming namespace unaware StAX Input
>>>
>>> Hi Christoph,
>>>
>>> The performance results showed two regressions, one on Linux and
>> another
>>> Solaris SPARC, while at the same time a bit more than half of the
>>> results across 5 platforms were negative. This is unfortunate. We're too
>>> close to the release date, it's super sensitive for jaxp on the
>>> performance front. I'd like to suggest that we move this patch to a
>>> 9-update or 10 when we'd have plenty of time to deal with any possible
>>> fallout. I consulted our performance expert and this is also his
>>> recommendation. I hope you'd understand.
>>>
>>> Thanks,
>>> Joe
>>>
>>> On 2/7/2017 4:54 PM, Joe Wang wrote:
>>>> Hi Christoph,
>>>>
>>>> We'll double-check whether there's any performance implications.
>>>> Please give us a couple of (or few) days.
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>> On 1/30/17, 7:28 AM, Langer, Christoph wrote:
>>>>> Hi Joe,
>>>>>
>>>>> I've updated my webrev for 8172974 after pulling out the refactoring
>>>>> of javax/xml/jaxp/unittest/transform/TransformerTest.java to Bug
>>>>> 8173602: http://cr.openjdk.java.net/~clanger/webrevs/8172974.1/
>>>>>
>>>>> After exchanging some off-list mails with Lance and Daniel, we came
>>>>> to the conclusion that you should decide about this one when you are
>>>>> back. The changes are merely cleanups apart from
>>>>>
>> com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM2.startEleme
>>> nt(),
>>>>> which to me seem natural after 8169631, though.
>>>>>
>>>>> Thanks,
>>>>> Christoph
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Langer, Christoph
>>>>>> Sent: Mittwoch, 18. Januar 2017 22:55
>>>>>> To: 'huizhe wang'<huizhe.wang at oracle.com>;
>>>>>> core-libs-dev at openjdk.java.net
>>>>>> Subject: RE: RFR 8172974 [JAXP] XALAN: Wrong result when
>>> transforming
>>>>>> namespace unaware StAX Input
>>>>>>
>>>>>> Hi Joe,
>>>>>>
>>>>>> generally, you are right, XSLT requires namespace support. For
>>>>>> parsing the
>>>>>> stylesheet, it is definitely a hard requirement. Otherwise this
>>>>>> would not make
>>>>>> sense at all. For instance xsl directives are in the xsl namespace.
>>>>>> That
>>>>>> requirement is what the FAQ you are referencing [1] is talking about.
>>>>>>
>>>>>> As for the InputSource which is to be processed, it is probably also
>>>>>> not a right to
>>>>>> use non namespace aware parsing. But still it's not forbidden. For
>>>>>> instance, the
>>>>>> JavaDoc for SAXSource [2] states this:
>>>>>> "Note that XSLT requires namespace support. Attempting to transform
>>>>>> an input
>>>>>> source that is not generated with a namespace-aware parser may
>>>>>> result in
>>>>>> errors. Parsers can be made namespace aware by calling the
>>>>>> SAXParserFactory.setNamespaceAware(boolean awareness)
>> method."
>>>>>> So, I agree, we are in the error space here. But still I think the
>>>>>> result of non
>>>>>> namespace aware parsing should be the same for all types of input
>>>>>> source. And
>>>>>> at the moment it is the same for DOMSource and SAXSource but not
>> for
>>>>>> StAXSource. From that point of view I think my fix makes sense
>>>>>> (along with the
>>>>>> other cleanups).
>>>>>>
>>>>>> Best regards
>>>>>> Christoph
>>>>>>
>>>>>> [1] https://xml.apache.org/xalan-j/faq.html#faq-N10207
>>>>>> [2]
>>>>>>
>> https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSo
>>> urce
>>>>>> .html
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
>>>>>>> Sent: Mittwoch, 18. Januar 2017 22:12
>>>>>>> To: Langer, Christoph<christoph.langer at sap.com>; core-libs-
>>>>>>> dev at openjdk.java.net
>>>>>>> Subject: Re: RFR 8172974 [JAXP] XALAN: Wrong result when
>>> transforming
>>>>>>> namespace unaware StAX Input
>>>>>>>
>>>>>>> Hi Christoph,
>>>>>>>
>>>>>>> Xalan requires the underlying parser to be namespace aware. Please
>>>>>>> refer
>>>>>>> to https://xml.apache.org/xalan-j/faq.html#faq-N10207
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Joe
>>>>>>>
>>>>>>> On 1/18/2017 8:26 AM, Langer, Christoph wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> please review a change for JAXP.
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172974
>>>>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172974.0/
>>>>>>>>
>>>>>>>> When enhancing the test for
>>> https://bugs.openjdk.java.net/browse/JDK-
>>>>>>> 8023653, I saw that there's still an issue with StAXInputSource
>>>>>>> which is not
>>>>>>> namespace aware. This needs a small update in
>>>>>>>
>> src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2
>>> dt
>>>>>>> m/SAX2DTM2.java. Furthermore, I added the fixed warnings and
>>>>>>> formattings
>>>>>>> from the proposal
>>>>>>> http://cr.openjdk.java.net/~clanger/webrevs/8023653.0/ to
>>>>>>> this webrev, as 8023653 is an enhancement and might not go in in
>>>>>>> the near
>>>>>>> future.
>>>>>>>> I also enhanced the TransformerTest to utilize data providers now
>>>>>>>> and test
>>>>>> a
>>>>>>> comprehensive matrix of XALAN input.
>>>>>>>> Thanks in advance and Best regards
>>>>>>>> Christoph
>>>>>>>>


From claes.redestad at oracle.com  Mon Feb 13 19:26:54 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 13 Feb 2017 20:26:54 +0100
Subject: RFR: 8174831: Reduce number of Charset classes loaded on bootstrap
In-Reply-To: <a32f4f20-731a-d14d-8574-9dea601087f8@oracle.com>
References: <3b3acc2c-0bd9-2991-3981-e72e9d418559@oracle.com>
 <a32f4f20-731a-d14d-8574-9dea601087f8@oracle.com>
Message-ID: <2fdbdd22-d95c-e872-a7ea-56e647e4dad2@oracle.com>



On 2017-02-13 20:12, Alan Bateman wrote:
> On 13/02/2017 19:03, Claes Redestad wrote:
>
>> Hi,
>>
>> this patch addresses a few tiny startup regressions incurred mostly by
>> the fact that Compact Strings eagerly loads more Charsets early.
>>
>> java.nio.charset.StandardCharsets is dropped from the early bootstrap,
>> load fastpaths are added for the 3 eagerly used Charsets (which avoids
>> some early reflection use), plus a couple of other nits:
>>
>> Webrev: http://cr.openjdk.java.net/~redestad/8174831/webrev.01/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174831
>>
>> Testing: jdk-tier1 tests
> One suggestion is to comment the `==` check in Charset.lookup as future
> maintainers may wonder why it doesn't use equals.

Sure, how about:

  // As all charset class names added to classMap are string literals
  // we can check identity here as an optimization

/Claes

>
> -Alan.

From huizhe.wang at oracle.com  Mon Feb 13 19:29:53 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 13 Feb 2017 11:29:53 -0800
Subject: Update: RFR 8172974 [JAXP] XALAN: Wrong result when transforming
 namespace unaware StAX Input
In-Reply-To: <71acc2ab-9f35-df77-3792-f63a1e59b667@oracle.com>
References: <3f43563228ef4f7ca2eed6281698a17c@derote13de46.global.corp.sap>
 <589A6C4C.60302@oracle.com> <b831884c-627d-5551-cb0c-2d12d0c55b9b@oracle.com>
 <1dda16fed9e74ead8f4b885ac1fb4c54@derote13de46.global.corp.sap>
 <71acc2ab-9f35-df77-3792-f63a1e59b667@oracle.com>
Message-ID: <4a05e743-ccca-94fd-57bf-08d210ef7642@oracle.com>



On 2/13/2017 11:21 AM, huizhe wang wrote:
> Hi Christoph,
>
> The negatives were actually across all platforms, although the 
> benchmark system picked up that it thinks were significant (high 
> probability of a regression). There were negatives numbers that were 
> bigger than the two.
>
> One possibility, if you look at the code change, is that the tests 
> contained cases where both uri and localName are null, with this 
> change then, there will be extra operations.

Oops, I meant to say the uri == null, but localName != null.

-Joe

>
> Thanks,
> Joe
>
> On 2/13/2017 7:29 AM, Langer, Christoph wrote:
>> Hi Joe,
>>
>> this is an updated webrev with only the change in namespace handling 
>> and the testcase: 
>> http://cr.openjdk.java.net/~clanger/webrevs/8172974.1-SAX2DTM2only/
>>
>> I'd really be interested in the performance results for that one 
>> before I turn to JDK10.
>>
>> Thanks
>> Christoph
>>
>>> -----Original Message-----
>>> From: Langer, Christoph
>>> Sent: Samstag, 11. Februar 2017 15:50
>>> To: 'huizhe wang' <huizhe.wang at oracle.com>
>>> Cc: core-libs-dev at openjdk.java.net
>>> Subject: RE: Update: RFR 8172974 [JAXP] XALAN: Wrong result when
>>> transforming namespace unaware StAX Input
>>>
>>> Hi Joe,
>>>
>>> that's unfortunate but if these are the numbers then we have to deal 
>>> with it.
>>> It's a bit odd, though, that this does not cause a regression on all 
>>> platforms.
>>> So, you are really sure the regression roots in my current proposal for
>>> 8172974?
>>>
>>> One thing I'd want to have been looked at is if the regression 
>>> really roots to
>>> my change in SAX2DTM2.java. This is the real modification. 
>>> Everything else is
>>> just cleanup. And looking at SAX2DTM2, I really can't see where I 
>>> should have
>>> introduced something bad. Can you retest this?
>>>
>>> Also, moving this to JDK10 would be fine for me. Shall I submit my 
>>> fix there as
>>> is or do you want to conduct some deeper analysis about the performance
>>> regression's root cause? Can I somehow assist with that?
>>>
>>> Thanks
>>> Christoph
>>>
>>>> -----Original Message-----
>>>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
>>>> Sent: Donnerstag, 9. Februar 2017 23:15
>>>> To: Langer, Christoph <christoph.langer at sap.com>
>>>> Cc: core-libs-dev at openjdk.java.net
>>>> Subject: Re: Update: RFR 8172974 [JAXP] XALAN: Wrong result when
>>>> transforming namespace unaware StAX Input
>>>>
>>>> Hi Christoph,
>>>>
>>>> The performance results showed two regressions, one on Linux and
>>> another
>>>> Solaris SPARC, while at the same time a bit more than half of the
>>>> results across 5 platforms were negative. This is unfortunate. 
>>>> We're too
>>>> close to the release date, it's super sensitive for jaxp on the
>>>> performance front. I'd like to suggest that we move this patch to a
>>>> 9-update or 10 when we'd have plenty of time to deal with any possible
>>>> fallout. I consulted our performance expert and this is also his
>>>> recommendation. I hope you'd understand.
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>> On 2/7/2017 4:54 PM, Joe Wang wrote:
>>>>> Hi Christoph,
>>>>>
>>>>> We'll double-check whether there's any performance implications.
>>>>> Please give us a couple of (or few) days.
>>>>>
>>>>> Thanks,
>>>>> Joe
>>>>>
>>>>> On 1/30/17, 7:28 AM, Langer, Christoph wrote:
>>>>>> Hi Joe,
>>>>>>
>>>>>> I've updated my webrev for 8172974 after pulling out the refactoring
>>>>>> of javax/xml/jaxp/unittest/transform/TransformerTest.java to Bug
>>>>>> 8173602: http://cr.openjdk.java.net/~clanger/webrevs/8172974.1/
>>>>>>
>>>>>> After exchanging some off-list mails with Lance and Daniel, we came
>>>>>> to the conclusion that you should decide about this one when you are
>>>>>> back. The changes are merely cleanups apart from
>>>>>>
>>> com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM2.startEleme
>>>> nt(),
>>>>>> which to me seem natural after 8169631, though.
>>>>>>
>>>>>> Thanks,
>>>>>> Christoph
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Langer, Christoph
>>>>>>> Sent: Mittwoch, 18. Januar 2017 22:55
>>>>>>> To: 'huizhe wang'<huizhe.wang at oracle.com>;
>>>>>>> core-libs-dev at openjdk.java.net
>>>>>>> Subject: RE: RFR 8172974 [JAXP] XALAN: Wrong result when
>>>> transforming
>>>>>>> namespace unaware StAX Input
>>>>>>>
>>>>>>> Hi Joe,
>>>>>>>
>>>>>>> generally, you are right, XSLT requires namespace support. For
>>>>>>> parsing the
>>>>>>> stylesheet, it is definitely a hard requirement. Otherwise this
>>>>>>> would not make
>>>>>>> sense at all. For instance xsl directives are in the xsl namespace.
>>>>>>> That
>>>>>>> requirement is what the FAQ you are referencing [1] is talking 
>>>>>>> about.
>>>>>>>
>>>>>>> As for the InputSource which is to be processed, it is probably 
>>>>>>> also
>>>>>>> not a right to
>>>>>>> use non namespace aware parsing. But still it's not forbidden. For
>>>>>>> instance, the
>>>>>>> JavaDoc for SAXSource [2] states this:
>>>>>>> "Note that XSLT requires namespace support. Attempting to transform
>>>>>>> an input
>>>>>>> source that is not generated with a namespace-aware parser may
>>>>>>> result in
>>>>>>> errors. Parsers can be made namespace aware by calling the
>>>>>>> SAXParserFactory.setNamespaceAware(boolean awareness)
>>> method."
>>>>>>> So, I agree, we are in the error space here. But still I think the
>>>>>>> result of non
>>>>>>> namespace aware parsing should be the same for all types of input
>>>>>>> source. And
>>>>>>> at the moment it is the same for DOMSource and SAXSource but not
>>> for
>>>>>>> StAXSource. From that point of view I think my fix makes sense
>>>>>>> (along with the
>>>>>>> other cleanups).
>>>>>>>
>>>>>>> Best regards
>>>>>>> Christoph
>>>>>>>
>>>>>>> [1] https://xml.apache.org/xalan-j/faq.html#faq-N10207
>>>>>>> [2]
>>>>>>>
>>> https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSo
>>>> urce
>>>>>>> .html
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
>>>>>>>> Sent: Mittwoch, 18. Januar 2017 22:12
>>>>>>>> To: Langer, Christoph<christoph.langer at sap.com>; core-libs-
>>>>>>>> dev at openjdk.java.net
>>>>>>>> Subject: Re: RFR 8172974 [JAXP] XALAN: Wrong result when
>>>> transforming
>>>>>>>> namespace unaware StAX Input
>>>>>>>>
>>>>>>>> Hi Christoph,
>>>>>>>>
>>>>>>>> Xalan requires the underlying parser to be namespace aware. Please
>>>>>>>> refer
>>>>>>>> to https://xml.apache.org/xalan-j/faq.html#faq-N10207
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Joe
>>>>>>>>
>>>>>>>> On 1/18/2017 8:26 AM, Langer, Christoph wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> please review a change for JAXP.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172974
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172974.0/
>>>>>>>>>
>>>>>>>>> When enhancing the test for
>>>> https://bugs.openjdk.java.net/browse/JDK-
>>>>>>>> 8023653, I saw that there's still an issue with StAXInputSource
>>>>>>>> which is not
>>>>>>>> namespace aware. This needs a small update in
>>>>>>>>
>>> src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2
>>>> dt
>>>>>>>> m/SAX2DTM2.java. Furthermore, I added the fixed warnings and
>>>>>>>> formattings
>>>>>>>> from the proposal
>>>>>>>> http://cr.openjdk.java.net/~clanger/webrevs/8023653.0/ to
>>>>>>>> this webrev, as 8023653 is an enhancement and might not go in in
>>>>>>>> the near
>>>>>>>> future.
>>>>>>>>> I also enhanced the TransformerTest to utilize data providers now
>>>>>>>>> and test
>>>>>>> a
>>>>>>>> comprehensive matrix of XALAN input.
>>>>>>>>> Thanks in advance and Best regards
>>>>>>>>> Christoph
>>>>>>>>>
>


From paul.sandoz at oracle.com  Mon Feb 13 22:52:56 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 13 Feb 2017 14:52:56 -0800
Subject: RFR 8174151: URLClassLoader no longer uses custom URLStreamHandler
 for jar URLs
Message-ID: <603F09A0-39F1-45DC-926C-FE2FC1368F2F@oracle.com>

Hi,

Please review.

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8174151-url-class-path-loader/webrev/index.html

This is a nasty edge case when a URLStreamHandler is registered (via the system property) to process jar: URLs.

The support for multi-release JAR files changed the implementation of ClassLoader.findResource such that the to be returned jar: URLs would not be operated on, and therefore the jar: URLStreamHandler would not be queried [*]. If the returned jar: URL is operated on by the caller then the jar: URLStreamHandler would (of course) be queried.

This is arguably an implementation detail but it does change long term established behaviour in a very delicate area.

While i find it unpalatable to do so this patch restores the previous behaviour, if a custom jar: URLStreamHandler is registered. The compromise is such a custom jar: URLStreamHandler needs to explicitly support multi-release JAR files.

Paul.

[*] Note that there are already such optimisations for file: URLs.

From david.holmes at oracle.com  Mon Feb 13 23:51:37 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 14 Feb 2017 09:51:37 +1000
Subject: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't
 specify what happens if the passed supplier is null itself
In-Reply-To: <CA+3eh11jf-yeveUiobehMcr99MR6ZJ8O8qGyj4nRfE_5g_cNVg@mail.gmail.com>
References: <CA+3eh13qSnt+CbyVNzB0eRp-rQkPhPu82tNhawhM11Q1Gw9qkg@mail.gmail.com>
 <7A11D19E-FBF6-4973-A38E-BA5D18C8F52F@oracle.com>
 <CA+3eh13Z6gkqvi1CqH+cjDTtXmsoYSTucuWKfh_zLkUZntM5Ww@mail.gmail.com>
 <314308f5-a885-cab1-ea2e-aa362f34c367@oracle.com>
 <CA+3eh11jf-yeveUiobehMcr99MR6ZJ8O8qGyj4nRfE_5g_cNVg@mail.gmail.com>
Message-ID: <976688b8-1507-63c8-e647-1fae15d147d9@oracle.com>

On 13/02/2017 7:10 PM, Volker Simonis wrote:
> On Mon, Feb 13, 2017 at 9:27 AM, David Holmes <david.holmes at oracle.com> wrote:
>> FWIW I think a null Supplier should simply be ignored.
>>
>
> What do you mean by ignored? Do you mean "ignored" in the sense of  my
> proposed changes (i.e. throw a NPE with a a null message) or do you
> mean "ignored" in the sense that it is fine to generate a new,
> implicit NPE when accessing the null supplier (with the consequences
> detailed in the bug description')?

I mean "ignored" in the sense that no method should be called upon it if 
null. Which matches your patch.

David

>> David
>>
>>
>> On 13/02/2017 6:04 PM, Volker Simonis wrote:
>>>
>>> Ping...
>>>
>>> On Thu, Feb 9, 2017 at 5:32 PM, Jeff Dinkins <jeff.dinkins at oracle.com>
>>> wrote:
>>>>
>>>>
>>>> Adding Mike?s current email.
>>>>
>>>> -jeff
>>>>
>>>>> On Feb 9, 2017, at 10:18 AM, Volker Simonis <volker.simonis at gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I want to finally resolve this long standing issue (or close it as
>>>>> "will not fix" if that's not possible):
>>>>>
>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2017/8033909/
>>>>>
>>>>> This change has already been discussed in length on the mailing list:
>>>>>
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/thread.html#24989
>>>>>
>>>>> and in the bug comments:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8033909
>>>>>
>>>>> So I'll give just a short summary here:
>>>>>
>>>>> - Objects.requireNonNull(T, Supplier) does not check for the Supplier
>>>>> argument being null. Instead it relies on the fact, that the VM will
>>>>> implicitly throw a NullPointerException when it calls .get on the
>>>>> Supplier argument during the creation of the explicit
>>>>> NullPointerException which it is supposed to throw.
>>>>>
>>>>> - this behavior slightly differs from Objects.requireNonNull(T,
>>>>> String) which simply creates a NullPointerException with a null
>>>>> message in the case where the String argument is null.
>>>>>
>>>>> - the difference is not evident in the OpenJDK, because the HotSpot VM
>>>>> creates a NPE with a null message by default if we call a method on a
>>>>> null object.
>>>>>
>>>>> - however creating such a NPE with a null message when invoking a
>>>>> method on a null object is not enforced by the standard, and other
>>>>> implementations can do better :) For the following trivial program:
>>>>>
>>>>> public class NonNull {
>>>>>  public static void main(String[] args) {
>>>>>    Supplier<String> ss = null;
>>>>>    Object o = Objects.requireNonNull(null, ss);
>>>>>  }
>>>>> }
>>>>>
>>>>> the current OpenJDK implementation returns:
>>>>>
>>>>> Exception in thread "main" java.lang.NullPointerException
>>>>>    at java.util.Objects.requireNonNull(Objects.java:290)
>>>>>    at NonNull.main(NonNull.java:8)
>>>>>
>>>>> but the SAP JVM will print:
>>>>>
>>>>> Exception in thread "main" java.lang.NullPointerException: while
>>>>> trying to invoke the method java.util.function.Supplier.get() of a
>>>>> null object loaded from local variable 'messageSupplier'
>>>>>    at java.util.Objects.requireNonNull(Objects.java:290)
>>>>>    at NonNull.main(NonNull.java:8)
>>>>>
>>>>> which is at least confusing for a call to Objects.requireNonNul() with
>>>>> a null Supplier. We think the exception should be the same like the
>>>>> one we get when invoking Objects.requireNonNul() with a null String.
>>>>>
>>>>> - because of this difference (and because we like our extended
>>>>> Exception messages :) the JCK test for Objects.requireNonNul(T,
>>>>> Supplier) (i.e.
>>>>> api/java_util/Objects/index.html#RequireNonNullMessageSupplier) was
>>>>> removed from TCK 8 and is still commented out in TCK 9
>>>>> (npe_checkingNullSupplier() in RequireNonNullMessageSupplier.java).
>>>>>
>>>>> I really think that the simplest and most natural fix for this problem
>>>>> is to simply check for a null Supplier argument and create the NPE
>>>>> with an explicit null message in that case (as outlined in the
>>>>> webrev). This:
>>>>> - makes the two requireNonNul() overloads for String and Supplier
>>>>> behave the same (which I think was the initial intention).
>>>>> - doesn't require documentation changes
>>>>> - makes it possible to write a simple and conforming TCK test
>>>>>
>>>>> If we can't agree on this quickly, I suggest to close the issue as
>>>>> "will-not-fix" and leave it untested by the TCK.
>>>>>
>>>>> Thank you and best regards,
>>>>> Volker
>>>>>
>>>>> PS: the 'XS' obviously only applies to the fix, not to this message :)
>>>>
>>>>
>>

From david.holmes at oracle.com  Mon Feb 13 23:56:30 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 14 Feb 2017 09:56:30 +1000
Subject: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't
 specify what happens if the passed supplier is null itself
In-Reply-To: <b6c27d3b-27bf-921f-597c-e57d193101fc@oracle.com>
References: <CA+3eh13qSnt+CbyVNzB0eRp-rQkPhPu82tNhawhM11Q1Gw9qkg@mail.gmail.com>
 <b6c27d3b-27bf-921f-597c-e57d193101fc@oracle.com>
Message-ID: <3587b1a5-2fee-6f27-efb7-cd5ca5e0aefb@oracle.com>

On 14/02/2017 2:57 AM, Alan Bateman wrote:
> On 09/02/2017 16:18, Volker Simonis wrote:
>
>> :
>>
>> I really think that the simplest and most natural fix for this problem
>> is to simply check for a null Supplier argument and create the NPE
>> with an explicit null message in that case (as outlined in the
>> webrev). This:
>>   - makes the two requireNonNul() overloads for String and Supplier
>> behave the same (which I think was the initial intention).
>>   - doesn't require documentation changes
>>   - makes it possible to write a simple and conforming TCK test
>>
>> If we can't agree on this quickly, I suggest to close the issue as
>> "will-not-fix" and leave it untested by the TCK.
>>
> If I read JDK-8033909 correctly then it's a request for the javadoc to
> specify the expected behavior when called with a messageSupplier of
> null. I think Joe said at one point that he deliberately didn't specify
> this. If that remains the position then the issue can be closed as WNF
> so that we don't waste any more discussion on it.

I think the fact this method is intended to throw a NPE if the target 
object is null, complicates the "normal" position of "if any arg is null 
we throw NPE", and so requires explicitly being addressed. I would 
address this by making the supplier be optional, so that it is only used 
if non-null and so can itself never be the source of the generated NPE. 
That would then lead naturally to the implementation Volker proposes as 
being the only correct implementation.

David
-----

> If I read your mail and patch correctly then it's more about what the
> NPE message is. I agree the exception you pasted in from the SAP build
> is difficult to read, in which case your patch makes it easier to read.
> That make sense and maybe just push that with a separate issue.
>
> -Alan

From huizhe.wang at oracle.com  Tue Feb 14 02:27:46 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 13 Feb 2017 18:27:46 -0800
Subject: RFR (JAXP) 8169450: StAX parse error if there is a newline in xml
 declaration
Message-ID: <4ea5378a-2d51-4282-3a0b-af39c909b9c5@oracle.com>

A quick fix for the error parsing xml declaration. This is one of the 
three outstanding issues in the xml area that must be addressed for the 
coming development deadline.

JBS: https://bugs.openjdk.java.net/browse/JDK-8169450
webrev: http://cr.openjdk.java.net/~joehw/jdk9/8169450/webrev/

Checking whether a space follows "<?xml" was sufficient for DOM/SAX for 
which the base parser was originally created since the xml declaration 
was normalized during version detection. StAX, sharing the base parser 
after it was added to the JDK, however, does not use the same version 
detection/normalization process and would incorrectly parse the 
declaration if there are other whitespaces.

Thanks,
Joe



From volker.simonis at gmail.com  Tue Feb 14 07:36:20 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 14 Feb 2017 08:36:20 +0100
Subject: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't
 specify what happens if the passed supplier is null itself
In-Reply-To: <3587b1a5-2fee-6f27-efb7-cd5ca5e0aefb@oracle.com>
References: <CA+3eh13qSnt+CbyVNzB0eRp-rQkPhPu82tNhawhM11Q1Gw9qkg@mail.gmail.com>
 <b6c27d3b-27bf-921f-597c-e57d193101fc@oracle.com>
 <3587b1a5-2fee-6f27-efb7-cd5ca5e0aefb@oracle.com>
Message-ID: <CA+3eh10LDDR1zfZJyz0RdwJRv3Zh9ni-cPHLsWyCymCvxALRJw@mail.gmail.com>

On Tue, Feb 14, 2017 at 12:56 AM, David Holmes <david.holmes at oracle.com> wrote:
> On 14/02/2017 2:57 AM, Alan Bateman wrote:
>>
>> On 09/02/2017 16:18, Volker Simonis wrote:
>>
>>> :
>>>
>>> I really think that the simplest and most natural fix for this problem
>>> is to simply check for a null Supplier argument and create the NPE
>>> with an explicit null message in that case (as outlined in the
>>> webrev). This:
>>>   - makes the two requireNonNul() overloads for String and Supplier
>>> behave the same (which I think was the initial intention).
>>>   - doesn't require documentation changes
>>>   - makes it possible to write a simple and conforming TCK test
>>>
>>> If we can't agree on this quickly, I suggest to close the issue as
>>> "will-not-fix" and leave it untested by the TCK.
>>>
>> If I read JDK-8033909 correctly then it's a request for the javadoc to
>> specify the expected behavior when called with a messageSupplier of
>> null. I think Joe said at one point that he deliberately didn't specify
>> this. If that remains the position then the issue can be closed as WNF
>> so that we don't waste any more discussion on it.
>
>
> I think the fact this method is intended to throw a NPE if the target object
> is null, complicates the "normal" position of "if any arg is null we throw
> NPE", and so requires explicitly being addressed. I would address this by
> making the supplier be optional, so that it is only used if non-null and so
> can itself never be the source of the generated NPE. That would then lead
> naturally to the implementation Volker proposes as being the only correct
> implementation.
>

Thanks David!

Finally somebody who understands me :)
As this seems a very controversial topic, I'll wait for a second
positive review before I'll push this.

Regards,
Volker

> David
> -----
>
>
>> If I read your mail and patch correctly then it's more about what the
>> NPE message is. I agree the exception you pasted in from the SAP build
>> is difficult to read, in which case your patch makes it easier to read.
>> That make sense and maybe just push that with a separate issue.
>>
>> -Alan

From Alan.Bateman at oracle.com  Tue Feb 14 07:48:43 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 14 Feb 2017 07:48:43 +0000
Subject: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't
 specify what happens if the passed supplier is null itself
In-Reply-To: <CA+3eh10LDDR1zfZJyz0RdwJRv3Zh9ni-cPHLsWyCymCvxALRJw@mail.gmail.com>
References: <CA+3eh13qSnt+CbyVNzB0eRp-rQkPhPu82tNhawhM11Q1Gw9qkg@mail.gmail.com>
 <b6c27d3b-27bf-921f-597c-e57d193101fc@oracle.com>
 <3587b1a5-2fee-6f27-efb7-cd5ca5e0aefb@oracle.com>
 <CA+3eh10LDDR1zfZJyz0RdwJRv3Zh9ni-cPHLsWyCymCvxALRJw@mail.gmail.com>
Message-ID: <032ce0d3-c086-287b-14ee-08f696443884@oracle.com>

On 14/02/2017 07:36, Volker Simonis wrote:

> :
> Finally somebody who understands me :)
> As this seems a very controversial topic, I'll wait for a second
> positive review before I'll push this.
>
If you are going to push this change then best to do it with another 
JIRA issue as JDK-8033909 is a request for a spec change. That is what I 
was trying to explain in the other mail.

-Alan

From christoph.langer at sap.com  Tue Feb 14 07:56:32 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 14 Feb 2017 07:56:32 +0000
Subject: RFR (JAXP) 8169450: StAX parse error if there is a newline in xml
 declaration
In-Reply-To: <4ea5378a-2d51-4282-3a0b-af39c909b9c5@oracle.com>
References: <4ea5378a-2d51-4282-3a0b-af39c909b9c5@oracle.com>
Message-ID: <5f53374da1e0472aa97f9fa133663a45@derote13de46.global.corp.sap>

Hi Joe,

this looks right to me, quite straightforward.

I just have some formatting nits for the test:

1. Line 107 (XMLInputFactory xif=): space missing before '='

2. Method comments on test methods would look nicer if formatted like:
/*
* line 1
* line 2
* ...
*/
... I want to say that the '*' is missing in the beginning of the middle lines

3. Several whitespace at the end of lines - but jcheck should find out

Best regards
Christoph


> -----Original Message-----
> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
> Behalf Of huizhe wang
> Sent: Dienstag, 14. Februar 2017 03:28
> To: core-libs-dev at openjdk.java.net
> Subject: RFR (JAXP) 8169450: StAX parse error if there is a newline in xml
> declaration
> 
> A quick fix for the error parsing xml declaration. This is one of the
> three outstanding issues in the xml area that must be addressed for the
> coming development deadline.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8169450
> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8169450/webrev/
> 
> Checking whether a space follows "<?xml" was sufficient for DOM/SAX for
> which the base parser was originally created since the xml declaration
> was normalized during version detection. StAX, sharing the base parser
> after it was added to the JDK, however, does not use the same version
> detection/normalization process and would incorrectly parse the
> declaration if there are other whitespaces.
> 
> Thanks,
> Joe
> 


From frank.yuan at oracle.com  Tue Feb 14 10:33:15 2017
From: frank.yuan at oracle.com (Frank Yuan)
Date: Tue, 14 Feb 2017 18:33:15 +0800
Subject: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by
 JDK-8087303
Message-ID: <045901d286ad$c1f21e20$45d65a60$@oracle.com>

Hi Joe

As you suggested, I made pretty-print a little better based on the fix. That is when adding indentation, just check the beginning
character(s), in case of '\n' or '\r' then, ignore it/them.

Please check the new webrev: http://cr.openjdk.java.net/~fyuan/8174025/webrev.01/


Thanks
Frank

-----Original Message-----
From: huizhe wang [mailto:huizhe.wang at oracle.com] 
Subject: should have been 8174025 -> Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303

Note that the bug id was incorrect, it should have been 8174025. 8170192 
was a test bug fix.

-Joe

On 2/13/2017 1:35 AM, Frank Yuan wrote:
> Hi Joe and Daniel
>
> Thank you very much for your review!
>
> Frank
>
>
> -----Original Message-----
> From: huizhe wang [mailto:huizhe.wang at oracle.com]
> Subject: Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303
>
> +1 from me too.
>
> Thanks,
> Joe
>
> On 2/10/2017 5:25 AM, Daniel Fuchs wrote:
>> Hi Frank,
>>
>> Thanks for fixing this!
>>
>> I imported your patch and played with it a bit.
>> Also ran the jaxp test.
>>
>> Both issues reported have indeed disappeared.
>>
>> So that's a +1 from me.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 10/02/17 11:03, Frank Yuan wrote:
>>> Hi All
>>>
>>>
>>>
>>> Would you like to review
>>> http://cr.openjdk.java.net/~fyuan/8174025/webrev.00/?
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174025
>>>
>>>
>>>
>>> JDK-8087303 introduced 2 issues:
>>>
>>> 1.       Flaw when xlst uses disable-output-escaping attribute
>>>
>>> 2.       Eat the whitespace between html inline elements
>>>
>>>
>>>
>>> This patch fixed the issues.
>>>
>>> To fix the second issue, we decide to keep the compatibility with JDK 8
>>> on the whitespace handling, that is only LSSerializer cleans the extra
>>> whitespaces in if pretty-print is on, but XSLT doesn't.
>>>
>>> I modified the behavior of getIndent() method in class ToStream, to make
>>> LSSerializer be sensitive of current state from ToStream. This should be
>>> safe because ToStream is an internal class and getIndent() method is
>>> never used before.
>>>
>>>
>>>
>>> Thanks
>>>
>>> Frank
>>>
>>>
>>>
>



From daniel.fuchs at oracle.com  Tue Feb 14 10:45:07 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 14 Feb 2017 10:45:07 +0000
Subject: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by
 JDK-8087303
In-Reply-To: <045901d286ad$c1f21e20$45d65a60$@oracle.com>
References: <045901d286ad$c1f21e20$45d65a60$@oracle.com>
Message-ID: <5d9c5098-e11c-1190-b2d8-b3c675de7ac7@oracle.com>

Hi Frank,

Should you skip '\r' if it's not followed by '\n'?


best regards,

-- daniel

On 14/02/17 10:33, Frank Yuan wrote:
> Hi Joe
>
> As you suggested, I made pretty-print a little better based on the fix. That is when adding indentation, just check the beginning
> character(s), in case of '\n' or '\r' then, ignore it/them.
>
> Please check the new webrev: http://cr.openjdk.java.net/~fyuan/8174025/webrev.01/
>
>
> Thanks
> Frank
>
> -----Original Message-----
> From: huizhe wang [mailto:huizhe.wang at oracle.com]
> Subject: should have been 8174025 -> Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303
>
> Note that the bug id was incorrect, it should have been 8174025. 8170192
> was a test bug fix.
>
> -Joe
>
> On 2/13/2017 1:35 AM, Frank Yuan wrote:
>> Hi Joe and Daniel
>>
>> Thank you very much for your review!
>>
>> Frank
>>
>>
>> -----Original Message-----
>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
>> Subject: Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303
>>
>> +1 from me too.
>>
>> Thanks,
>> Joe
>>
>> On 2/10/2017 5:25 AM, Daniel Fuchs wrote:
>>> Hi Frank,
>>>
>>> Thanks for fixing this!
>>>
>>> I imported your patch and played with it a bit.
>>> Also ran the jaxp test.
>>>
>>> Both issues reported have indeed disappeared.
>>>
>>> So that's a +1 from me.
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> On 10/02/17 11:03, Frank Yuan wrote:
>>>> Hi All
>>>>
>>>>
>>>>
>>>> Would you like to review
>>>> http://cr.openjdk.java.net/~fyuan/8174025/webrev.00/?
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174025
>>>>
>>>>
>>>>
>>>> JDK-8087303 introduced 2 issues:
>>>>
>>>> 1.       Flaw when xlst uses disable-output-escaping attribute
>>>>
>>>> 2.       Eat the whitespace between html inline elements
>>>>
>>>>
>>>>
>>>> This patch fixed the issues.
>>>>
>>>> To fix the second issue, we decide to keep the compatibility with JDK 8
>>>> on the whitespace handling, that is only LSSerializer cleans the extra
>>>> whitespaces in if pretty-print is on, but XSLT doesn't.
>>>>
>>>> I modified the behavior of getIndent() method in class ToStream, to make
>>>> LSSerializer be sensitive of current state from ToStream. This should be
>>>> safe because ToStream is an internal class and getIndent() method is
>>>> never used before.
>>>>
>>>>
>>>>
>>>> Thanks
>>>>
>>>> Frank
>>>>
>>>>
>>>>
>>
>
>


From daniel.fuchs at oracle.com  Tue Feb 14 11:16:37 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 14 Feb 2017 11:16:37 +0000
Subject: RFR (JAXP) 8169450: StAX parse error if there is a newline in xml
 declaration
In-Reply-To: <4ea5378a-2d51-4282-3a0b-af39c909b9c5@oracle.com>
References: <4ea5378a-2d51-4282-3a0b-af39c909b9c5@oracle.com>
Message-ID: <988cd4f7-5ffd-e224-8bb9-20269d45089a@oracle.com>

Looks good Joe.

I wonder about this though (which may be an issue for
another time):

102         [25] Eq         ::= S? '=' S?

Do we support space (new line?) before and after the '=' sign?

best regards,

-- daniel

On 14/02/17 02:27, huizhe wang wrote:
> A quick fix for the error parsing xml declaration. This is one of the
> three outstanding issues in the xml area that must be addressed for the
> coming development deadline.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8169450
> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8169450/webrev/
>
> Checking whether a space follows "<?xml" was sufficient for DOM/SAX for
> which the base parser was originally created since the xml declaration
> was normalized during version detection. StAX, sharing the base parser
> after it was added to the JDK, however, does not use the same version
> detection/normalization process and would incorrectly parse the
> declaration if there are other whitespaces.
>
> Thanks,
> Joe
>
>


From roman.grigoriadi at oracle.com  Tue Feb 14 12:00:27 2017
From: roman.grigoriadi at oracle.com (Roman Grigoriadi)
Date: Tue, 14 Feb 2017 13:00:27 +0100
Subject: RFR: 8174735 Update JAX-WS RI integration to latest version
Message-ID: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>

Hi,

Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.

JBS: https://bugs.openjdk.java.net/browse/JDK-8174735
Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/00/

You can find change list in the description of JBS and its linked 
issues. Most diffs are for SAAJ-RI related to JDK-8166745 - remove 
dependencies on jdks Xerces internal classes.

Thanks,
Roman

From Alan.Bateman at oracle.com  Tue Feb 14 12:05:35 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 14 Feb 2017 12:05:35 +0000
Subject: RFR: 8174735 Update JAX-WS RI integration to latest version
In-Reply-To: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
References: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
Message-ID: <ee580fc0-5404-11a0-86d9-2551e2f340ae@oracle.com>



On 14/02/2017 12:00, Roman Grigoriadi wrote:
> Hi,
>
> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8174735
> Webrev: 
> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/00/
>
> You can find change list in the description of JBS and its linked 
> issues. Most diffs are for SAAJ-RI related to JDK-8166745 - remove 
> dependencies on jdks Xerces internal classes.
Is the webrev missing the update to java.base's module-info.java? I 
assume we can drop the exporting of sun.reflect.misc to java.xml.ws.

-Alan

From lance.andersen at oracle.com  Tue Feb 14 12:07:32 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 14 Feb 2017 07:07:32 -0500
Subject: RFR (JAXP) 8169450: StAX parse error if there is a newline in xml
 declaration
In-Reply-To: <4ea5378a-2d51-4282-3a0b-af39c909b9c5@oracle.com>
References: <4ea5378a-2d51-4282-3a0b-af39c909b9c5@oracle.com>
Message-ID: <1C84D336-7E4B-497C-B662-91A09B0A1439@oracle.com>

Looks good overall Joe.  I would agree that I would clean up the minor comment alignment issues.

Best
Lance
> On Feb 13, 2017, at 9:27 PM, huizhe wang <huizhe.wang at oracle.com> wrote:
> 
> A quick fix for the error parsing xml declaration. This is one of the three outstanding issues in the xml area that must be addressed for the coming development deadline.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8169450
> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8169450/webrev/
> 
> Checking whether a space follows "<?xml" was sufficient for DOM/SAX for which the base parser was originally created since the xml declaration was normalized during version detection. StAX, sharing the base parser after it was added to the JDK, however, does not use the same version detection/normalization process and would incorrectly parse the declaration if there are other whitespaces.
> 
> Thanks,
> Joe
> 
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From Alan.Bateman at oracle.com  Tue Feb 14 12:20:27 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 14 Feb 2017 12:20:27 +0000
Subject: RFR 8174151: URLClassLoader no longer uses custom
 URLStreamHandler for jar URLs
In-Reply-To: <603F09A0-39F1-45DC-926C-FE2FC1368F2F@oracle.com>
References: <603F09A0-39F1-45DC-926C-FE2FC1368F2F@oracle.com>
Message-ID: <d32bafa8-48e9-4c48-be17-a4f0a99e7ac2@oracle.com>

On 13/02/2017 22:52, Paul Sandoz wrote:

> Hi,
>
> Please review.
>
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8174151-url-class-path-loader/webrev/index.html
>
> This is a nasty edge case when a URLStreamHandler is registered (via the system property) to process jar: URLs.
>
> The support for multi-release JAR files changed the implementation of ClassLoader.findResource such that the to be returned jar: URLs would not be operated on, and therefore the jar: URLStreamHandler would not be queried [*]. If the returned jar: URL is operated on by the caller then the jar: URLStreamHandler would (of course) be queried.
>
> This is arguably an implementation detail but it does change long term established behaviour in a very delicate area.
>
> While i find it unpalatable to do so this patch restores the previous behaviour, if a custom jar: URLStreamHandler is registered. The compromise is such a custom jar: URLStreamHandler needs to explicitly support multi-release JAR files.
>
This is really ugly but I think the changes are okay/safe. Initially I 
thought it might be simpler to just use URL.handlers but the API allows 
someone to create a URL with a different URLStreamHandler.

-Alan

From roman.grigoriadi at oracle.com  Tue Feb 14 12:28:12 2017
From: roman.grigoriadi at oracle.com (Roman Grigoriadi)
Date: Tue, 14 Feb 2017 13:28:12 +0100
Subject: RFR: 8174735 Update JAX-WS RI integration to latest version
In-Reply-To: <ee580fc0-5404-11a0-86d9-2551e2f340ae@oracle.com>
References: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
 <ee580fc0-5404-11a0-86d9-2551e2f340ae@oracle.com>
Message-ID: <ecc0ac83-97cd-a7f2-9274-b4987cf056ca@oracle.com>

On 02/14/2017 01:05 PM, Alan Bateman wrote:
> Is the webrev missing the update to java.base's module-info.java? I 
> assume we can drop the exporting of sun.reflect.misc to java.xml.ws.
Thanks Alan, Mandy's patch for jaxws own MethodUtil is integrated, so 
sun.reflect.misc export should now be removed.
>
> -Alan 


From Alan.Bateman at oracle.com  Tue Feb 14 12:47:15 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 14 Feb 2017 12:47:15 +0000
Subject: RFR: 8174735 Update JAX-WS RI integration to latest version
In-Reply-To: <ecc0ac83-97cd-a7f2-9274-b4987cf056ca@oracle.com>
References: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
 <ee580fc0-5404-11a0-86d9-2551e2f340ae@oracle.com>
 <ecc0ac83-97cd-a7f2-9274-b4987cf056ca@oracle.com>
Message-ID: <31b1e7fa-ed0c-1f86-b38b-2bf22c88044a@oracle.com>



On 14/02/2017 12:28, Roman Grigoriadi wrote:
> On 02/14/2017 01:05 PM, Alan Bateman wrote:
>> Is the webrev missing the update to java.base's module-info.java? I 
>> assume we can drop the exporting of sun.reflect.misc to java.xml.ws.
> Thanks Alan, Mandy's patch for jaxws own MethodUtil is integrated, so 
> sun.reflect.misc export should now be removed.
Good, no need to update the webrev, I just wanted to make sure this 
wasn't forgotten.

-Alan

From frank.yuan at oracle.com  Tue Feb 14 13:43:23 2017
From: frank.yuan at oracle.com (Frank Yuan)
Date: Tue, 14 Feb 2017 21:43:23 +0800
Subject: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by
 JDK-8087303
In-Reply-To: <5d9c5098-e11c-1190-b2d8-b3c675de7ac7@oracle.com>
References: <045901d286ad$c1f21e20$45d65a60$@oracle.com>
 <5d9c5098-e11c-1190-b2d8-b3c675de7ac7@oracle.com>
Message-ID: <05c301d286c8$51439350$f3cab9f0$@oracle.com>


> -----Original Message-----
> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> Subject: Re: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by JDK-8087303
> 
> Hi Frank,
> 
> Should you skip '\r' if it's not followed by '\n'?
> 
Does it matter? Since XML processor should normalize the newline.

Thanks
Frank
> 
> best regards,
> 
> -- daniel
> 
> On 14/02/17 10:33, Frank Yuan wrote:
> > Hi Joe
> >
> > As you suggested, I made pretty-print a little better based on the fix. That is when adding indentation, just check the
beginning
> > character(s), in case of '\n' or '\r' then, ignore it/them.
> >
> > Please check the new webrev: http://cr.openjdk.java.net/~fyuan/8174025/webrev.01/
> >
> >
> > Thanks
> > Frank
> >
> > -----Original Message-----
> > From: huizhe wang [mailto:huizhe.wang at oracle.com]
> > Subject: should have been 8174025 -> Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303
> >
> > Note that the bug id was incorrect, it should have been 8174025. 8170192
> > was a test bug fix.
> >
> > -Joe
> >
> > On 2/13/2017 1:35 AM, Frank Yuan wrote:
> >> Hi Joe and Daniel
> >>
> >> Thank you very much for your review!
> >>
> >> Frank
> >>
> >>
> >> -----Original Message-----
> >> From: huizhe wang [mailto:huizhe.wang at oracle.com]
> >> Subject: Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303
> >>
> >> +1 from me too.
> >>
> >> Thanks,
> >> Joe
> >>
> >> On 2/10/2017 5:25 AM, Daniel Fuchs wrote:
> >>> Hi Frank,
> >>>
> >>> Thanks for fixing this!
> >>>
> >>> I imported your patch and played with it a bit.
> >>> Also ran the jaxp test.
> >>>
> >>> Both issues reported have indeed disappeared.
> >>>
> >>> So that's a +1 from me.
> >>>
> >>> best regards,
> >>>
> >>> -- daniel
> >>>
> >>> On 10/02/17 11:03, Frank Yuan wrote:
> >>>> Hi All
> >>>>
> >>>>
> >>>>
> >>>> Would you like to review
> >>>> http://cr.openjdk.java.net/~fyuan/8174025/webrev.00/?
> >>>>
> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174025
> >>>>
> >>>>
> >>>>
> >>>> JDK-8087303 introduced 2 issues:
> >>>>
> >>>> 1.       Flaw when xlst uses disable-output-escaping attribute
> >>>>
> >>>> 2.       Eat the whitespace between html inline elements
> >>>>
> >>>>
> >>>>
> >>>> This patch fixed the issues.
> >>>>
> >>>> To fix the second issue, we decide to keep the compatibility with JDK 8
> >>>> on the whitespace handling, that is only LSSerializer cleans the extra
> >>>> whitespaces in if pretty-print is on, but XSLT doesn't.
> >>>>
> >>>> I modified the behavior of getIndent() method in class ToStream, to make
> >>>> LSSerializer be sensitive of current state from ToStream. This should be
> >>>> safe because ToStream is an internal class and getIndent() method is
> >>>> never used before.
> >>>>
> >>>>
> >>>>
> >>>> Thanks
> >>>>
> >>>> Frank
> >>>>
> >>>>
> >>>>
> >>
> >
> >



From chris.hegarty at oracle.com  Tue Feb 14 13:58:32 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 14 Feb 2017 13:58:32 +0000
Subject: RFR 8174151: URLClassLoader no longer uses custom
 URLStreamHandler for jar URLs
In-Reply-To: <603F09A0-39F1-45DC-926C-FE2FC1368F2F@oracle.com>
References: <603F09A0-39F1-45DC-926C-FE2FC1368F2F@oracle.com>
Message-ID: <4540E31A-8473-4E48-8954-5EB0E2663CB6@oracle.com>


> On 13 Feb 2017, at 22:52, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi,
> 
> Please review.
> 
>  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8174151-url-class-path-loader/webrev/index.html

If I understand this correctly then the only optimisation ( by-pass of
openConnection ), which is causing the problem, is when the URL
is of the form ?jar:file:xxxxx!/?, right? If so, you could limit the scope
of your changes to only fall back to Loader when the nested URL
has a ?file? protocol. This would give you MR JAR functionality for
"jar:http://xxx?, which is fairly common.

> This is a nasty edge case when a URLStreamHandler is registered (via the system property) to process jar: URLs.
> 
> The support for multi-release JAR files changed the implementation of ClassLoader.findResource such that the to be returned jar: URLs would not be operated on, and therefore the jar: URLStreamHandler would not be queried [*]. If the returned jar: URL is operated on by the caller then the jar: URLStreamHandler would (of course) be queried.
> 
> This is arguably an implementation detail but it does change long term established behaviour in a very delicate area.
> 
> While i find it unpalatable to do so this patch restores the previous behaviour, if a custom jar: URLStreamHandler is registered. The compromise is such a custom jar: URLStreamHandler needs to explicitly support multi-release JAR files.
> 
> Paul.
> 
> [*] Note that there are already such optimisations for file: URLs.

-Chris.


From daniel.fuchs at oracle.com  Tue Feb 14 14:16:51 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 14 Feb 2017 14:16:51 +0000
Subject: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by
 JDK-8087303
In-Reply-To: <05c301d286c8$51439350$f3cab9f0$@oracle.com>
References: <045901d286ad$c1f21e20$45d65a60$@oracle.com>
 <5d9c5098-e11c-1190-b2d8-b3c675de7ac7@oracle.com>
 <05c301d286c8$51439350$f3cab9f0$@oracle.com>
Message-ID: <6c08a0b5-90e5-bd2c-eb02-b53a83e11469@oracle.com>

Hi Frank,

On 14/02/17 13:43, Frank Yuan wrote:
>
>> -----Original Message-----
>> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
>> Subject: Re: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by JDK-8087303
>>
>> Hi Frank,
>>
>> Should you skip '\r' if it's not followed by '\n'?

Well - I'll let Joe answer that. ;-)
It was just a question, I was wondering whether that could
potentially cause problems down the road - since new lines
are usually only either '\n' or '\r'+'\n'.

Your patch looks fine otherwise, maybe the code that skips
the '\n' could be factorized somewhere to avoid duplication,
but that's not really important.

Both issues reported in the bug are still fix - so I think we
should try to get this patch in as soon as we can.

best regards,

-- daniel

>>
> Does it matter? Since XML processor should normalize the newline.
>
> Thanks
> Frank
>>
>> best regards,
>>
>> -- daniel
>>
>> On 14/02/17 10:33, Frank Yuan wrote:
>>> Hi Joe
>>>
>>> As you suggested, I made pretty-print a little better based on the fix. That is when adding indentation, just check the
> beginning
>>> character(s), in case of '\n' or '\r' then, ignore it/them.
>>>
>>> Please check the new webrev: http://cr.openjdk.java.net/~fyuan/8174025/webrev.01/
>>>
>>>
>>> Thanks
>>> Frank
>>>
>>> -----Original Message-----
>>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
>>> Subject: should have been 8174025 -> Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303
>>>
>>> Note that the bug id was incorrect, it should have been 8174025. 8170192
>>> was a test bug fix.
>>>
>>> -Joe
>>>
>>> On 2/13/2017 1:35 AM, Frank Yuan wrote:
>>>> Hi Joe and Daniel
>>>>
>>>> Thank you very much for your review!
>>>>
>>>> Frank
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
>>>> Subject: Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303
>>>>
>>>> +1 from me too.
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>> On 2/10/2017 5:25 AM, Daniel Fuchs wrote:
>>>>> Hi Frank,
>>>>>
>>>>> Thanks for fixing this!
>>>>>
>>>>> I imported your patch and played with it a bit.
>>>>> Also ran the jaxp test.
>>>>>
>>>>> Both issues reported have indeed disappeared.
>>>>>
>>>>> So that's a +1 from me.
>>>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>>>
>>>>> On 10/02/17 11:03, Frank Yuan wrote:
>>>>>> Hi All
>>>>>>
>>>>>>
>>>>>>
>>>>>> Would you like to review
>>>>>> http://cr.openjdk.java.net/~fyuan/8174025/webrev.00/?
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174025
>>>>>>
>>>>>>
>>>>>>
>>>>>> JDK-8087303 introduced 2 issues:
>>>>>>
>>>>>> 1.       Flaw when xlst uses disable-output-escaping attribute
>>>>>>
>>>>>> 2.       Eat the whitespace between html inline elements
>>>>>>
>>>>>>
>>>>>>
>>>>>> This patch fixed the issues.
>>>>>>
>>>>>> To fix the second issue, we decide to keep the compatibility with JDK 8
>>>>>> on the whitespace handling, that is only LSSerializer cleans the extra
>>>>>> whitespaces in if pretty-print is on, but XSLT doesn't.
>>>>>>
>>>>>> I modified the behavior of getIndent() method in class ToStream, to make
>>>>>> LSSerializer be sensitive of current state from ToStream. This should be
>>>>>> safe because ToStream is an internal class and getIndent() method is
>>>>>> never used before.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Frank
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>>
>
>


From frank.yuan at oracle.com  Tue Feb 14 14:58:16 2017
From: frank.yuan at oracle.com (Frank Yuan)
Date: Tue, 14 Feb 2017 22:58:16 +0800
Subject: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by
 JDK-8087303
In-Reply-To: <6c08a0b5-90e5-bd2c-eb02-b53a83e11469@oracle.com>
References: <045901d286ad$c1f21e20$45d65a60$@oracle.com>
 <5d9c5098-e11c-1190-b2d8-b3c675de7ac7@oracle.com>
 <05c301d286c8$51439350$f3cab9f0$@oracle.com>
 <6c08a0b5-90e5-bd2c-eb02-b53a83e11469@oracle.com>
Message-ID: <05e801d286d2$c83fbc40$58bf34c0$@oracle.com>

> -----Original Message-----
> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> Subject: Re: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by JDK-8087303
> 
> Hi Frank,
> 
> On 14/02/17 13:43, Frank Yuan wrote:
> >
> >> -----Original Message-----
> >> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> >> Subject: Re: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by JDK-8087303
> >>
> >> Hi Frank,
> >>
> >> Should you skip '\r' if it's not followed by '\n'?
> 
> Well - I'll let Joe answer that. ;-)
Hmm, wait for Joe to confirm.

> It was just a question, I was wondering whether that could
> potentially cause problems down the road - since new lines
> are usually only either '\n' or '\r'+'\n'.
> 
Agree.

> Your patch looks fine otherwise, maybe the code that skips
> the '\n' could be factorized somewhere to avoid duplication,
> but that's not really important.
> 
> Both issues reported in the bug are still fix - so I think we
> should try to get this patch in as soon as we can.
> 
Yes, understand!

Thanks
Frank

> best regards,
> 
> -- daniel
> 
> >>
> > Does it matter? Since XML processor should normalize the newline.
> >
> > Thanks
> > Frank
> >>
> >> best regards,
> >>
> >> -- daniel
> >>
> >> On 14/02/17 10:33, Frank Yuan wrote:
> >>> Hi Joe
> >>>
> >>> As you suggested, I made pretty-print a little better based on the fix. That is when adding indentation, just check the
> > beginning
> >>> character(s), in case of '\n' or '\r' then, ignore it/them.
> >>>
> >>> Please check the new webrev: http://cr.openjdk.java.net/~fyuan/8174025/webrev.01/
> >>>
> >>>
> >>> Thanks
> >>> Frank
> >>>
> >>> -----Original Message-----
> >>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
> >>> Subject: should have been 8174025 -> Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303
> >>>
> >>> Note that the bug id was incorrect, it should have been 8174025. 8170192
> >>> was a test bug fix.
> >>>
> >>> -Joe
> >>>
> >>> On 2/13/2017 1:35 AM, Frank Yuan wrote:
> >>>> Hi Joe and Daniel
> >>>>
> >>>> Thank you very much for your review!
> >>>>
> >>>> Frank
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
> >>>> Subject: Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303
> >>>>
> >>>> +1 from me too.
> >>>>
> >>>> Thanks,
> >>>> Joe
> >>>>
> >>>> On 2/10/2017 5:25 AM, Daniel Fuchs wrote:
> >>>>> Hi Frank,
> >>>>>
> >>>>> Thanks for fixing this!
> >>>>>
> >>>>> I imported your patch and played with it a bit.
> >>>>> Also ran the jaxp test.
> >>>>>
> >>>>> Both issues reported have indeed disappeared.
> >>>>>
> >>>>> So that's a +1 from me.
> >>>>>
> >>>>> best regards,
> >>>>>
> >>>>> -- daniel
> >>>>>
> >>>>> On 10/02/17 11:03, Frank Yuan wrote:
> >>>>>> Hi All
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Would you like to review
> >>>>>> http://cr.openjdk.java.net/~fyuan/8174025/webrev.00/?
> >>>>>>
> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174025
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> JDK-8087303 introduced 2 issues:
> >>>>>>
> >>>>>> 1.       Flaw when xlst uses disable-output-escaping attribute
> >>>>>>
> >>>>>> 2.       Eat the whitespace between html inline elements
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> This patch fixed the issues.
> >>>>>>
> >>>>>> To fix the second issue, we decide to keep the compatibility with JDK 8
> >>>>>> on the whitespace handling, that is only LSSerializer cleans the extra
> >>>>>> whitespaces in if pretty-print is on, but XSLT doesn't.
> >>>>>>
> >>>>>> I modified the behavior of getIndent() method in class ToStream, to make
> >>>>>> LSSerializer be sensitive of current state from ToStream. This should be
> >>>>>> safe because ToStream is an internal class and getIndent() method is
> >>>>>> never used before.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Thanks
> >>>>>>
> >>>>>> Frank
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>
> >>>
> >
> >



From matthias.baesken at sap.com  Tue Feb 14 16:27:49 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 14 Feb 2017 16:27:49 +0000
Subject: jdk10 : simplify jexec build settings
References: <92a51f307d33465faca64e8d43c176bc@DEWDFE13DE14.global.corp.sap>
 <abf8e046-3528-1c9c-ad12-ce786239b385@oracle.com>
 <20161b2fc66242b6930e179f0bbdf121@DEWDFE13DE14.global.corp.sap>
 <ec35e180-114b-d2c0-c9ff-7ff17674898d@oracle.com> 
Message-ID: <13388daa72314ad6869c4235b71de083@DEWDFE13DE14.global.corp.sap>

Hello,  here is  the webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8174242/

bug :

https://bugs.openjdk.java.net/browse/JDK-8174242


As discussed , I deleted the macosx   jexec.c    .


Btw. I found out  that   jexec  does not work (fully?)  in jdk8 / 9     ( seems  this has to do with the change  8156478: 3 Buffer overrun defect groups in jexec.c   )
Executing a         helloworld.jar  with  jexec   leads to
     "invalid file (bad magic number): Exec format error"  .

Should I open another bug for this ?

Best regards, Matthias



From: Baesken, Matthias
Sent: Freitag, 10. Februar 2017 13:19
To: 'Erik Joelsson' <erik.joelsson at oracle.com>; build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
Cc: Langer, Christoph <christoph.langer at sap.com>
Subject: RE: jdk10 : simplify jexec build settings

Hi Eric, thanks for the comment, I think I'll remove the macosx source file .
Btw. is there already some test  for jexec (a "fast grep" through the  jdk  tests did not show me much) ?

Best regards, Matthias



From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
Sent: Freitag, 10. Februar 2017 09:49
To: Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>; build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Subject: Re: jdk10 : simplify jexec build settings


Since the file has never been built, I would say remove the macosx source file. You can point directly to the unix source dir if you prefer too. No need to have dead logic for macosx in the makefile.

/Erik

On 2017-02-09 15:27, Baesken, Matthias wrote:
I compared the  jexec.c  versions for  macosx and unix

( jdk/src/java.base/macosx/native/launcher/jexec.c    and    jdk/src/java.base/unix/native/launcher/jexec.c )

And to me it looks like  the  unix version could be used for macosx too  (just in case there is a need to reenable the  build of jexec.c  for macosx one day again).

Comments / suggestions ?

Best regards, Matthias


From: Baesken, Matthias
Sent: Donnerstag, 9. Februar 2017 14:10
To: 'Erik Joelsson' <erik.joelsson at oracle.com><mailto:erik.joelsson at oracle.com>; build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>; 'core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>' <core-libs-dev at openjdk.java.net><mailto:core-libs-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com><mailto:christoph.langer at sap.com>
Subject: RE: jdk10 : simplify jexec build settings

Hello Erik, thanks for the comments .

>>Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) :
>
>This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think.

I include core-libs-dev , can someone comment on  jexec on macosx ?
Currently  jexec.c  is not compiled for macosx (jdk9/10), see  jdk/make/launcher/Launcher-java.base.gmk  .
It is just compiled on linux .

So I wonder -  is it ok to remove  the macosx handling  in the mentioned  makefile   jdk/make/launcher/Launcher-java.base.gmk   for  jexec ?

>This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name.
>Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time.

>From what I observe in the linux  build log,  just jexec.c  is  compiled into jexec.o and then this single object is used to create the executable ("program")  jexec.
Other src files are not used in the compilation of jexec, so  just using   $(JDK_TOPDIR)/src/$(MODULE)/unix/native/launcher   would be fine (as long as macosx can be dropped).



Best regards, Matthias


From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
Sent: Donnerstag, 9. Februar 2017 13:42
To: Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>; build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Subject: Re: jdk10 : simplify jexec build settings


Hello,

On 2017-02-09 12:36, Baesken, Matthias wrote:
Hello ,  while adjusting the jspawnhelper build settings with 8174086, it has been noticed that the jexec build settings need some simplification as well.

The bug

https://bugs.openjdk.java.net/browse/JDK-8174242

has been created for this.

When looking into it,  I had some questions :

http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/ae7afa9abe67/make/launcher/Launcher-java.base.gmk

The makefile  (make/launcher/Launcher-java.base.gmk )  handles Solaris 32bit,  but is this really  supported  in jdk 9 or 10  ( I think it was removed in 9 and only 64bit Solaris support remains ) ?
We do not support 32bit Solaris. The issue with jexec for Solaris was raised a while back and the conclusion was to scrap support, so no need to build it for Solaris at all.


ifeq ($(OPENJDK_TARGET_OS), solaris)
  ifeq ($(OPENJDK_TARGET_CPU_BITS), 32)
    BUILD_JEXEC := 1
  endif
endif

ifeq ($(OPENJDK_TARGET_OS), linux)
  BUILD_JEXEC := 1
endif # OPENJDK_TARGET_OS

#
# jdk/make/java/jexec/Makefile
#
ifeq ($(BUILD_JEXEC), 1)

Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) :
This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think.

The makefile logic shouldn't need to be that specific though. Our modern pattern for this is something like this:

SRC := $(call uniq, $(wildcard \
      $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS)/native/launcher \
      $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS_TYPE)/native/launcher \
      $(JDK_TOPDIR)/src/$(MODULE)/share/native/launcher))

This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name. Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time.

For libraries, we have abstracted this construct in the macro FindSrcDirForLib (LibCommon.gmk) but we haven't done the same for launchers yet.

/Erik


  ifeq ($(OPENJDK_TARGET_OS), windows)
  else ifeq ($(OPENJDK_TARGET_OS), macosx)
    BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/macosx/native/launcher
  else
    BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/unix/native/launcher
  endif

Should I remove  the solaris 32bit / macosx handling  for jexec  from   make/launcher/Launcher-java.base.gmk ?

Regards, Matthias







From erik.joelsson at oracle.com  Tue Feb 14 16:57:02 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 14 Feb 2017 17:57:02 +0100
Subject: jdk10 : simplify jexec build settings
In-Reply-To: <13388daa72314ad6869c4235b71de083@DEWDFE13DE14.global.corp.sap>
References: <92a51f307d33465faca64e8d43c176bc@DEWDFE13DE14.global.corp.sap>
 <abf8e046-3528-1c9c-ad12-ce786239b385@oracle.com>
 <20161b2fc66242b6930e179f0bbdf121@DEWDFE13DE14.global.corp.sap>
 <ec35e180-114b-d2c0-c9ff-7ff17674898d@oracle.com>
 <13388daa72314ad6869c4235b71de083@DEWDFE13DE14.global.corp.sap>
Message-ID: <026d9dec-a64a-bd98-d95f-7cce061819f5@oracle.com>

Hello,

Looks good to me.

Fixing jexec is a separate issue and not really build related.

/Erik

On 2017-02-14 17:27, Baesken, Matthias wrote:
>
> Hello, here is  the webrev :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8174242/ 
> <http://cr.openjdk.java.net/%7Embaesken/webrevs/8174242/>
>
> bug :
>
> https://bugs.openjdk.java.net/browse/JDK-8174242
>
> As discussed , I deleted the macosx   jexec.c    .
>
> Btw. I found out  that   jexec  does not work (fully?)  in jdk8 / 9  
>    ( seems  this has to do with the change  8156478: 3 Buffer overrun 
> defect groups in jexec.c   )
>
> Executing a         helloworld.jar  with  jexec   leads to
>
>      ?invalid file (bad magic number): Exec format error?  .
>
> Should I open another bug for this ?
>
> Best regards, Matthias
>
> *From:*Baesken, Matthias
> *Sent:* Freitag, 10. Februar 2017 13:19
> *To:* 'Erik Joelsson' <erik.joelsson at oracle.com>; 
> build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> *Cc:* Langer, Christoph <christoph.langer at sap.com>
> *Subject:* RE: jdk10 : simplify jexec build settings
>
> Hi Eric, thanks for the comment, I think I?ll remove the macosx source 
> file .
>
> Btw. is there already some test  for jexec (a ?fast grep? through the  
> jdk  tests did not show me much) ?
>
> Best regards, Matthias
>
> *From:*Erik Joelsson [mailto:erik.joelsson at oracle.com]
> *Sent:* Freitag, 10. Februar 2017 09:49
> *To:* Baesken, Matthias <matthias.baesken at sap.com 
> <mailto:matthias.baesken at sap.com>>; build-dev at openjdk.java.net 
> <mailto:build-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net 
> <mailto:core-libs-dev at openjdk.java.net>
> *Cc:* Langer, Christoph <christoph.langer at sap.com 
> <mailto:christoph.langer at sap.com>>
> *Subject:* Re: jdk10 : simplify jexec build settings
>
> Since the file has never been built, I would say remove the macosx 
> source file. You can point directly to the unix source dir if you 
> prefer too. No need to have dead logic for macosx in the makefile.
>
> /Erik
>
> On 2017-02-09 15:27, Baesken, Matthias wrote:
>
>     I compared the  jexec.c  versions for macosx and unix
>
>     ( jdk/src/java.base/macosx/native/launcher/jexec.c    and
>      jdk/src/java.base/unix/native/launcher/jexec.c )
>
>     And to me it looks like  the  unix version could be used for
>     macosx too  (just in case there is a need to reenable the  build
>     of jexec.c  for macosx one day again).
>
>     Comments / suggestions ?
>
>     Best regards, Matthias
>
>     *From:*Baesken, Matthias
>     *Sent:* Donnerstag, 9. Februar 2017 14:10
>     *To:* 'Erik Joelsson' <erik.joelsson at oracle.com>
>     <mailto:erik.joelsson at oracle.com>; build-dev at openjdk.java.net
>     <mailto:build-dev at openjdk.java.net>;
>     'core-libs-dev at openjdk.java.net
>     <mailto:core-libs-dev at openjdk.java.net>'
>     <core-libs-dev at openjdk.java.net>
>     <mailto:core-libs-dev at openjdk.java.net>
>     *Cc:* Langer, Christoph <christoph.langer at sap.com>
>     <mailto:christoph.langer at sap.com>
>     *Subject:* RE: jdk10 : simplify jexec build settings
>
>     Hello Erik, thanks for the comments .
>
>     >>Then there is handling for macosx left , but the build is not enabled
>     for macosx, does it still make sense to include the macosx
>     handling (there is even a separate jexec.c for macosx) :
>
>     >
>
>     >This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely
>     be removed. That is however a question for core-libs I think.
>
>     I include core-libs-dev , can someone comment on  jexec on macosx ?
>
>     Currently  jexec.c  is not compiled for macosx (jdk9/10), see
>      jdk/make/launcher/Launcher-java.base.gmk  .
>
>     It is just compiled on linux .
>
>     So I wonder -  is it ok to remove  the macosx handling  in the
>     mentioned  makefile jdk/make/launcher/Launcher-java.base.gmk   for
>      jexec ?
>
>     >This will automatically look in all the directories where source files are supposed to be and pick
>     the most specific one if there are any with the same name.
>
>     >Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES
>     := jexec.c this time.
>
>     From what I observe in the linux  build log,  just jexec.c  is 
>     compiled into jexec.o and then this single object is used to
>     create the executable (?program?)  jexec.
>
>     Other src files are not used in the compilation of jexec, so  just
>     using   $(JDK_TOPDIR)/src/$(MODULE)/unix/native/launcher would be
>     fine (as long as macosx can be dropped).
>
>     Best regards, Matthias
>
>     *From:*Erik Joelsson [mailto:erik.joelsson at oracle.com]
>     *Sent:* Donnerstag, 9. Februar 2017 13:42
>     *To:* Baesken, Matthias <matthias.baesken at sap.com
>     <mailto:matthias.baesken at sap.com>>; build-dev at openjdk.java.net
>     <mailto:build-dev at openjdk.java.net>
>     *Cc:* Langer, Christoph <christoph.langer at sap.com
>     <mailto:christoph.langer at sap.com>>
>     *Subject:* Re: jdk10 : simplify jexec build settings
>
>     Hello,
>
>     On 2017-02-09 12:36, Baesken, Matthias wrote:
>
>         Hello , while adjusting the jspawnhelper build settings with
>         8174086, it has been noticed that the jexec build settings
>         need some simplification as well.
>
>         The bug
>
>         https://bugs.openjdk.java.net/browse/JDK-8174242
>
>         has been created for this.
>
>         When looking into it,  I had some questions :
>
>         http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/ae7afa9abe67/make/launcher/Launcher-java.base.gmk
>
>         The makefile  (make/launcher/Launcher-java.base.gmk )  handles
>         Solaris 32bit,  but is this really supported  in jdk 9 or 10 
>         ( I think it was removed in 9 and only 64bit Solaris support
>         remains ) ?
>
>     We do not support 32bit Solaris. The issue with jexec for Solaris
>     was raised a while back and the conclusion was to scrap support,
>     so no need to build it for Solaris at all.
>
>         ifeq ($(OPENJDK_TARGET_OS), solaris)
>
>           ifeq ($(OPENJDK_TARGET_CPU_BITS), 32)
>
>             BUILD_JEXEC := 1
>
>           endif
>
>         endif
>
>         ifeq ($(OPENJDK_TARGET_OS), linux)
>
>           BUILD_JEXEC := 1
>
>         endif # OPENJDK_TARGET_OS
>
>         #
>
>         # jdk/make/java/jexec/Makefile
>
>         #
>
>         ifeq ($(BUILD_JEXEC), 1)
>
>         Then there is handling for macosx left , but the build is not
>         enabled for macosx, does it still make sense to include the
>         macosx handling (there is even a separate jexec.c for macosx) :
>
>     This is indeed weird. I don't think we ever built jexec for macosx
>     so the source file should likely be removed. That is however a
>     question for core-libs I think.
>
>     The makefile logic shouldn't need to be that specific though. Our
>     modern pattern for this is something like this:
>
>     SRC := $(call uniq, $(wildcard \
>     $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS)/native/launcher \
>     $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS_TYPE)/native/launcher
>     \
>     $(JDK_TOPDIR)/src/$(MODULE)/share/native/launcher))
>
>     This will automatically look in all the directories where source
>     files are supposed to be and pick the most specific one if there
>     are any with the same name. Since the share launcher dir contains
>     more src files, you will need to leave the INCLUDE_FILES :=
>     jexec.c this time.
>
>     For libraries, we have abstracted this construct in the macro
>     FindSrcDirForLib (LibCommon.gmk) but we haven't done the same for
>     launchers yet.
>
>     /Erik
>
>           ifeq ($(OPENJDK_TARGET_OS), windows)
>
>           else ifeq ($(OPENJDK_TARGET_OS), macosx)
>
>             BUILD_JEXEC_SRC :=
>         $(JDK_TOPDIR)/src/java.base/macosx/native/launcher
>
>           else
>
>             BUILD_JEXEC_SRC :=
>         $(JDK_TOPDIR)/src/java.base/unix/native/launcher
>
>           endif
>
>         Should I remove  the solaris 32bit / macosx handling  for
>         jexec  from  make/launcher/Launcher-java.base.gmk ?
>
>         Regards, Matthias
>


From huizhe.wang at oracle.com  Tue Feb 14 17:19:14 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 14 Feb 2017 09:19:14 -0800
Subject: RFR (JAXP) 8169450: StAX parse error if there is a newline in xml
 declaration
In-Reply-To: <5f53374da1e0472aa97f9fa133663a45@derote13de46.global.corp.sap>
References: <4ea5378a-2d51-4282-3a0b-af39c909b9c5@oracle.com>
 <5f53374da1e0472aa97f9fa133663a45@derote13de46.global.corp.sap>
Message-ID: <93f0f2bf-6ead-b313-582c-14da0de01d69@oracle.com>

Thanks Christoph.  Will fix those comments.

-Joe

On 2/13/2017 11:56 PM, Langer, Christoph wrote:
> Hi Joe,
>
> this looks right to me, quite straightforward.
>
> I just have some formatting nits for the test:
>
> 1. Line 107 (XMLInputFactory xif=): space missing before '='
>
> 2. Method comments on test methods would look nicer if formatted like:
> /*
> * line 1
> * line 2
> * ...
> */
> ... I want to say that the '*' is missing in the beginning of the middle lines
>
> 3. Several whitespace at the end of lines - but jcheck should find out
>
> Best regards
> Christoph
>
>
>> -----Original Message-----
>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
>> Behalf Of huizhe wang
>> Sent: Dienstag, 14. Februar 2017 03:28
>> To: core-libs-dev at openjdk.java.net
>> Subject: RFR (JAXP) 8169450: StAX parse error if there is a newline in xml
>> declaration
>>
>> A quick fix for the error parsing xml declaration. This is one of the
>> three outstanding issues in the xml area that must be addressed for the
>> coming development deadline.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8169450
>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8169450/webrev/
>>
>> Checking whether a space follows "<?xml" was sufficient for DOM/SAX for
>> which the base parser was originally created since the xml declaration
>> was normalized during version detection. StAX, sharing the base parser
>> after it was added to the JDK, however, does not use the same version
>> detection/normalization process and would incorrectly parse the
>> declaration if there are other whitespaces.
>>
>> Thanks,
>> Joe
>>


From huizhe.wang at oracle.com  Tue Feb 14 17:20:06 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 14 Feb 2017 09:20:06 -0800
Subject: RFR (JAXP) 8169450: StAX parse error if there is a newline in xml
 declaration
In-Reply-To: <988cd4f7-5ffd-e224-8bb9-20269d45089a@oracle.com>
References: <4ea5378a-2d51-4282-3a0b-af39c909b9c5@oracle.com>
 <988cd4f7-5ffd-e224-8bb9-20269d45089a@oracle.com>
Message-ID: <3e395a9e-35e9-e829-58ce-427f30393fbc@oracle.com>



On 2/14/2017 3:16 AM, Daniel Fuchs wrote:
> Looks good Joe.
>
> I wonder about this though (which may be an issue for
> another time):
>
> 102         [25] Eq         ::= S? '=' S?
>
> Do we support space (new line?) before and after the '=' sign?

Yes, we do. I've added a couple of test cases to cover this.

Best,
Joe

>
> best regards,
>
> -- daniel
>
> On 14/02/17 02:27, huizhe wang wrote:
>> A quick fix for the error parsing xml declaration. This is one of the
>> three outstanding issues in the xml area that must be addressed for the
>> coming development deadline.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8169450
>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8169450/webrev/
>>
>> Checking whether a space follows "<?xml" was sufficient for DOM/SAX for
>> which the base parser was originally created since the xml declaration
>> was normalized during version detection. StAX, sharing the base parser
>> after it was added to the JDK, however, does not use the same version
>> detection/normalization process and would incorrectly parse the
>> declaration if there are other whitespaces.
>>
>> Thanks,
>> Joe
>>
>>
>


From huizhe.wang at oracle.com  Tue Feb 14 17:21:13 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 14 Feb 2017 09:21:13 -0800
Subject: RFR (JAXP) 8169450: StAX parse error if there is a newline in xml
 declaration
In-Reply-To: <1C84D336-7E4B-497C-B662-91A09B0A1439@oracle.com>
References: <4ea5378a-2d51-4282-3a0b-af39c909b9c5@oracle.com>
 <1C84D336-7E4B-497C-B662-91A09B0A1439@oracle.com>
Message-ID: <441bccfd-ae9e-9bc6-a5a4-36ae03f9b11f@oracle.com>

Thanks!

Here's an updated webrev: 
http://cr.openjdk.java.net/~joehw/jdk9/8169450/webrev/

-Joe

On 2/14/2017 4:07 AM, Lance Andersen wrote:
> Looks good overall Joe.  I would agree that I would clean up the minor 
> comment alignment issues.
>
> Best
> Lance
>> On Feb 13, 2017, at 9:27 PM, huizhe wang <huizhe.wang at oracle.com 
>> <mailto:huizhe.wang at oracle.com>> wrote:
>>
>> A quick fix for the error parsing xml declaration. This is one of the 
>> three outstanding issues in the xml area that must be addressed for 
>> the coming development deadline.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8169450
>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8169450/webrev/ 
>> <http://cr.openjdk.java.net/%7Ejoehw/jdk9/8169450/webrev/>
>>
>> Checking whether a space follows "<?xml" was sufficient for DOM/SAX 
>> for which the base parser was originally created since the xml 
>> declaration was normalized during version detection. StAX, sharing 
>> the base parser after it was added to the JDK, however, does not use 
>> the same version detection/normalization process and would 
>> incorrectly parse the declaration if there are other whitespaces.
>>
>> Thanks,
>> Joe
>>
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>
>
>
>


From paul.sandoz at oracle.com  Tue Feb 14 18:37:32 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 14 Feb 2017 10:37:32 -0800
Subject: RFR 8174151: URLClassLoader no longer uses custom
 URLStreamHandler for jar URLs
In-Reply-To: <4540E31A-8473-4E48-8954-5EB0E2663CB6@oracle.com>
References: <603F09A0-39F1-45DC-926C-FE2FC1368F2F@oracle.com>
 <4540E31A-8473-4E48-8954-5EB0E2663CB6@oracle.com>
Message-ID: <601349FB-CE7F-4895-A0B5-079420E3BC4C@oracle.com>


> On 14 Feb 2017, at 05:58, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> 
>> On 13 Feb 2017, at 22:52, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> 
>> Hi,
>> 
>> Please review.
>> 
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8174151-url-class-path-loader/webrev/index.html
> 
> If I understand this correctly then the only optimisation ( by-pass of
> openConnection ), which is causing the problem, is when the URL
> is of the form ?jar:file:xxxxx!/?, right? If so, you could limit the scope
> of your changes to only fall back to Loader when the nested URL
> has a ?file? protocol. This would give you MR JAR functionality for
> "jar:http://xxx?, which is fairly common.
> 

We need to tunnel, by default, all jar: URL resources through the JarLoader which creates and caches the runtime versioned JarFile and returns an appropriately URL (to a versioned resource if necessary).

(Note that there is already an optimization in the internal JarURLConnection to bypass access to the jar file via the embedded URL is the embedded scheme is file:)

Paul.

>> This is a nasty edge case when a URLStreamHandler is registered (via the system property) to process jar: URLs.
>> 
>> The support for multi-release JAR files changed the implementation of ClassLoader.findResource such that the to be returned jar: URLs would not be operated on, and therefore the jar: URLStreamHandler would not be queried [*]. If the returned jar: URL is operated on by the caller then the jar: URLStreamHandler would (of course) be queried.
>> 
>> This is arguably an implementation detail but it does change long term established behaviour in a very delicate area.
>> 
>> While i find it unpalatable to do so this patch restores the previous behaviour, if a custom jar: URLStreamHandler is registered. The compromise is such a custom jar: URLStreamHandler needs to explicitly support multi-release JAR files.
>> 
>> Paul.
>> 
>> [*] Note that there are already such optimisations for file: URLs.
> 
> -Chris.
> 


From chris.hegarty at oracle.com  Tue Feb 14 18:41:19 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 14 Feb 2017 18:41:19 +0000
Subject: RFR 8174151: URLClassLoader no longer uses custom
 URLStreamHandler for jar URLs
In-Reply-To: <601349FB-CE7F-4895-A0B5-079420E3BC4C@oracle.com>
References: <603F09A0-39F1-45DC-926C-FE2FC1368F2F@oracle.com>
 <4540E31A-8473-4E48-8954-5EB0E2663CB6@oracle.com>
 <601349FB-CE7F-4895-A0B5-079420E3BC4C@oracle.com>
Message-ID: <D3CADCBC-9523-444A-8277-4A0A76B81351@oracle.com>


> On 14 Feb 2017, at 18:37, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
>> 
>> On 14 Feb 2017, at 05:58, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> 
>> 
>>> On 13 Feb 2017, at 22:52, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Please review.
>>> 
>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8174151-url-class-path-loader/webrev/index.html
>> 
>> If I understand this correctly then the only optimisation ( by-pass of
>> openConnection ), which is causing the problem, is when the URL
>> is of the form ?jar:file:xxxxx!/?, right? If so, you could limit the scope
>> of your changes to only fall back to Loader when the nested URL
>> has a ?file? protocol. This would give you MR JAR functionality for
>> "jar:http://xxx?, which is fairly common.
>> 
> 
> We need to tunnel, by default, all jar: URL resources through the JarLoader which creates and caches the runtime versioned JarFile and returns an appropriately URL (to a versioned resource if necessary).

Ok, thanks Paul.

-Chris.

From daniel.fuchs at oracle.com  Tue Feb 14 18:41:37 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 14 Feb 2017 18:41:37 +0000
Subject: RFR (JAXP) 8169450: StAX parse error if there is a newline in xml
 declaration
In-Reply-To: <441bccfd-ae9e-9bc6-a5a4-36ae03f9b11f@oracle.com>
References: <4ea5378a-2d51-4282-3a0b-af39c909b9c5@oracle.com>
 <1C84D336-7E4B-497C-B662-91A09B0A1439@oracle.com>
 <441bccfd-ae9e-9bc6-a5a4-36ae03f9b11f@oracle.com>
Message-ID: <77b9bbc7-006f-8fb3-9ad3-a5a14b0e8d17@oracle.com>

On 14/02/17 17:21, huizhe wang wrote:
> Thanks!
>
> Here's an updated webrev:
> http://cr.openjdk.java.net/~joehw/jdk9/8169450/webrev/

+1

-- daniel

>
> -Joe
>
> On 2/14/2017 4:07 AM, Lance Andersen wrote:
>> Looks good overall Joe.  I would agree that I would clean up the minor
>> comment alignment issues.
>>
>> Best
>> Lance
>>> On Feb 13, 2017, at 9:27 PM, huizhe wang <huizhe.wang at oracle.com
>>> <mailto:huizhe.wang at oracle.com>> wrote:
>>>
>>> A quick fix for the error parsing xml declaration. This is one of the
>>> three outstanding issues in the xml area that must be addressed for
>>> the coming development deadline.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8169450
>>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8169450/webrev/
>>> <http://cr.openjdk.java.net/%7Ejoehw/jdk9/8169450/webrev/>
>>>
>>> Checking whether a space follows "<?xml" was sufficient for DOM/SAX
>>> for which the base parser was originally created since the xml
>>> declaration was normalized during version detection. StAX, sharing
>>> the base parser after it was added to the JDK, however, does not use
>>> the same version detection/normalization process and would
>>> incorrectly parse the declaration if there are other whitespaces.
>>>
>>> Thanks,
>>> Joe
>>>
>>>
>>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>
>>
>>
>>
>


From volker.simonis at gmail.com  Tue Feb 14 18:52:54 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 14 Feb 2017 19:52:54 +0100
Subject: RFR(XS): 8174950: Gracefully handle null Supplier in
 Objects.requireNonNull
Message-ID: <CA+3eh122aWwsYgWL9O+xYF9r+9PK4puM2ySHr47RCc7ACC7gZg@mail.gmail.com>

Hi,

can I please have another review for the following trivial fix:

http://cr.openjdk.java.net/~simonis/webrevs/2017/8174950/
https://bugs.openjdk.java.net/browse/JDK-8174950

This change has already been discussed in length on the mailing list:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-February/thread.html#46324
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/thread.html#24989

and in the bug comments at:

https://bugs.openjdk.java.net/browse/JDK-8033909

So I'll give just (yet another) short summary here:

- Objects.requireNonNull(T, Supplier) does not check for the Supplier
argument being null. Instead it relies on the fact, that the VM will
implicitly throw a NullPointerException when it calls .get on the
Supplier argument during the creation of the explicit
NullPointerException which it is supposed to throw.

- this behavior slightly differs from Objects.requireNonNull(T,
String) which simply creates a NullPointerException with a null
message in the case where the String argument is null.

- the difference is not evident in the OpenJDK, because the HotSpot VM
creates a NPE with a null message by default if we call a method on a
null object.

- however creating such a NPE with a null message when invoking a
method on a null object is not enforced by the standard, and other
implementations can do better :) For the following trivial program:

public class NonNull {
  public static void main(String[] args) {
    Supplier<String> ss = null;
    Object o = Objects.requireNonNull(null, ss);
  }
}

the current OpenJDK implementation returns:

Exception in thread "main" java.lang.NullPointerException
    at java.util.Objects.requireNonNull(Objects.java:290)
    at NonNull.main(NonNull.java:8)

but the SAP JVM will print:

Exception in thread "main" java.lang.NullPointerException: while
trying to invoke the method java.util.function.Supplier.get() of a
null object loaded from local variable 'messageSupplier'
    at java.util.Objects.requireNonNull(Objects.java:290)
    at NonNull.main(NonNull.java:8)

which is at least confusing for a call to Objects.requireNonNul() with
a null Supplier. We think the exception should be the same like the
one we get when invoking Objects.requireNonNul() with a null String.

- because of this difference (and because we like our extended
Exception messages :) the JCK test for Objects.requireNonNul(T,
Supplier) (i.e.
api/java_util/Objects/index.html#RequireNonNullMessageSupplier) was
removed from TCK 8 and is still commented out in TCK 9
(npe_checkingNullSupplier() in RequireNonNullMessageSupplier.java).

I really think that the simplest and most natural fix for this problem
is to simply check for a null Supplier argument and create the NPE
with an explicit null message in that case (as outlined in the
webrev). This:
 - makes the two requireNonNul() overloads for String and Supplier
behave the same (which I think was the initial intention).
 - doesn't require documentation changes
 - makes it possible to write a simple and conforming TCK test

Regards,
Volker

From lance.andersen at oracle.com  Tue Feb 14 18:53:12 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 14 Feb 2017 13:53:12 -0500
Subject: RFR (JAXP) 8169450: StAX parse error if there is a newline in xml
 declaration
In-Reply-To: <77b9bbc7-006f-8fb3-9ad3-a5a14b0e8d17@oracle.com>
References: <4ea5378a-2d51-4282-3a0b-af39c909b9c5@oracle.com>
 <1C84D336-7E4B-497C-B662-91A09B0A1439@oracle.com>
 <441bccfd-ae9e-9bc6-a5a4-36ae03f9b11f@oracle.com>
 <77b9bbc7-006f-8fb3-9ad3-a5a14b0e8d17@oracle.com>
Message-ID: <88A0996A-34A6-453B-ADFF-0B39CF9AE5FD@oracle.com>

Looks good? ship it.

> On Feb 14, 2017, at 1:41 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> On 14/02/17 17:21, huizhe wang wrote:
>> Thanks!
>> 
>> Here's an updated webrev:
>> http://cr.openjdk.java.net/~joehw/jdk9/8169450/webrev/
> 
> +1
> 
> -- daniel
> 
>> 
>> -Joe
>> 
>> On 2/14/2017 4:07 AM, Lance Andersen wrote:
>>> Looks good overall Joe.  I would agree that I would clean up the minor
>>> comment alignment issues.
>>> 
>>> Best
>>> Lance
>>>> On Feb 13, 2017, at 9:27 PM, huizhe wang <huizhe.wang at oracle.com
>>>> <mailto:huizhe.wang at oracle.com>> wrote:
>>>> 
>>>> A quick fix for the error parsing xml declaration. This is one of the
>>>> three outstanding issues in the xml area that must be addressed for
>>>> the coming development deadline.
>>>> 
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8169450
>>>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8169450/webrev/
>>>> <http://cr.openjdk.java.net/%7Ejoehw/jdk9/8169450/webrev/>
>>>> 
>>>> Checking whether a space follows "<?xml" was sufficient for DOM/SAX
>>>> for which the base parser was originally created since the xml
>>>> declaration was normalized during version detection. StAX, sharing
>>>> the base parser after it was added to the JDK, however, does not use
>>>> the same version detection/normalization process and would
>>>> incorrectly parse the declaration if there are other whitespaces.
>>>> 
>>>> Thanks,
>>>> Joe
>>>> 
>>>> 
>>> 
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> 
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>
>>> 
>>> 
>>> 
>> 
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From naoto.sato at oracle.com  Tue Feb 14 19:05:54 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 14 Feb 2017 11:05:54 -0800
Subject: [9] RFR: 8174779: Locale issues with Mac 10.12
Message-ID: <e1b195a0-2c58-7e80-2630-97cddf8918eb@oracle.com>

Hello,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8174779

The proposed fix is located at:

http://cr.openjdk.java.net/~naoto/8174779/webrev.01/

The root cause of the problem was that starting from macOS 10.12, it 
returns the preferred user language including both script and region, 
which cannot be dealt with the existing parsing code.

Naoto

From xueming.shen at oracle.com  Tue Feb 14 19:09:47 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 14 Feb 2017 11:09:47 -0800
Subject: RFR JDK-8174248: partialUpdateFooMainClass test in
 tools/jar/modularJar/Basic.java needs to be re-examined
Message-ID: <58A355FB.2010209@oracle.com>

Hi,

Please review the test change for JDK-8174248

issue: https://bugs.openjdk.java.net/browse/JDK-8174248
webrev: http://cr.openjdk.java.net/~sherman/8174248/webrev

The change is to simply rename the entry name from "IAmNotTheEntryPoint"
to a "packaged" one as " jdk.test.foo.IAmNotTheEntryPoint" to satisfy the
newly added sanity check in j.l.m.ModuleDescriptor.Builder.mainClass(), in
which the "main-class in unnamed package" is no longer allowed (and the
named package must exist in module "packages") .

Arguably it might be desired for "jar" tool to also verify whether or not the
"main-class" really exists in the module jar file (the implementation does not
verify the existence of the main-class for the manifest  for now, the newly
added module related code follows the "convention"), but this probably should
be handled/discussed in a separate rfe.

Thanks,
Sherman

From huizhe.wang at oracle.com  Tue Feb 14 19:18:14 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 14 Feb 2017 11:18:14 -0800
Subject: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by
 JDK-8087303
In-Reply-To: <05e801d286d2$c83fbc40$58bf34c0$@oracle.com>
References: <045901d286ad$c1f21e20$45d65a60$@oracle.com>
 <5d9c5098-e11c-1190-b2d8-b3c675de7ac7@oracle.com>
 <05c301d286c8$51439350$f3cab9f0$@oracle.com>
 <6c08a0b5-90e5-bd2c-eb02-b53a83e11469@oracle.com>
 <05e801d286d2$c83fbc40$58bf34c0$@oracle.com>
Message-ID: <6728500c-a89e-1e2b-493d-7c50d0f5f5e6@oracle.com>

Looks good to me as well.

For the CR and LF question, XML processors are required by the 
specification to normalize and translate both CRLF sequence and any CR 
not followed by LF to a single LF.  For that reason, you don't have 
check CR since the content the serializer gets is parsed.

Best,
Joe

On 2/14/2017 6:58 AM, Frank Yuan wrote:
>> -----Original Message-----
>> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
>> Subject: Re: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by JDK-8087303
>>
>> Hi Frank,
>>
>> On 14/02/17 13:43, Frank Yuan wrote:
>>>> -----Original Message-----
>>>> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
>>>> Subject: Re: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by JDK-8087303
>>>>
>>>> Hi Frank,
>>>>
>>>> Should you skip '\r' if it's not followed by '\n'?
>> Well - I'll let Joe answer that. ;-)
> Hmm, wait for Joe to confirm.
>
>> It was just a question, I was wondering whether that could
>> potentially cause problems down the road - since new lines
>> are usually only either '\n' or '\r'+'\n'.
>>
> Agree.
>
>> Your patch looks fine otherwise, maybe the code that skips
>> the '\n' could be factorized somewhere to avoid duplication,
>> but that's not really important.
>>
>> Both issues reported in the bug are still fix - so I think we
>> should try to get this patch in as soon as we can.
>>
> Yes, understand!
>
> Thanks
> Frank
>
>> best regards,
>>
>> -- daniel
>>
>>> Does it matter? Since XML processor should normalize the newline.
>>>
>>> Thanks
>>> Frank
>>>> best regards,
>>>>
>>>> -- daniel
>>>>
>>>> On 14/02/17 10:33, Frank Yuan wrote:
>>>>> Hi Joe
>>>>>
>>>>> As you suggested, I made pretty-print a little better based on the fix. That is when adding indentation, just check the
>>> beginning
>>>>> character(s), in case of '\n' or '\r' then, ignore it/them.
>>>>>
>>>>> Please check the new webrev: http://cr.openjdk.java.net/~fyuan/8174025/webrev.01/
>>>>>
>>>>>
>>>>> Thanks
>>>>> Frank
>>>>>
>>>>> -----Original Message-----
>>>>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
>>>>> Subject: should have been 8174025 -> Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303
>>>>>
>>>>> Note that the bug id was incorrect, it should have been 8174025. 8170192
>>>>> was a test bug fix.
>>>>>
>>>>> -Joe
>>>>>
>>>>> On 2/13/2017 1:35 AM, Frank Yuan wrote:
>>>>>> Hi Joe and Daniel
>>>>>>
>>>>>> Thank you very much for your review!
>>>>>>
>>>>>> Frank
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
>>>>>> Subject: Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303
>>>>>>
>>>>>> +1 from me too.
>>>>>>
>>>>>> Thanks,
>>>>>> Joe
>>>>>>
>>>>>> On 2/10/2017 5:25 AM, Daniel Fuchs wrote:
>>>>>>> Hi Frank,
>>>>>>>
>>>>>>> Thanks for fixing this!
>>>>>>>
>>>>>>> I imported your patch and played with it a bit.
>>>>>>> Also ran the jaxp test.
>>>>>>>
>>>>>>> Both issues reported have indeed disappeared.
>>>>>>>
>>>>>>> So that's a +1 from me.
>>>>>>>
>>>>>>> best regards,
>>>>>>>
>>>>>>> -- daniel
>>>>>>>
>>>>>>> On 10/02/17 11:03, Frank Yuan wrote:
>>>>>>>> Hi All
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Would you like to review
>>>>>>>> http://cr.openjdk.java.net/~fyuan/8174025/webrev.00/?
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174025
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> JDK-8087303 introduced 2 issues:
>>>>>>>>
>>>>>>>> 1.       Flaw when xlst uses disable-output-escaping attribute
>>>>>>>>
>>>>>>>> 2.       Eat the whitespace between html inline elements
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This patch fixed the issues.
>>>>>>>>
>>>>>>>> To fix the second issue, we decide to keep the compatibility with JDK 8
>>>>>>>> on the whitespace handling, that is only LSSerializer cleans the extra
>>>>>>>> whitespaces in if pretty-print is on, but XSLT doesn't.
>>>>>>>>
>>>>>>>> I modified the behavior of getIndent() method in class ToStream, to make
>>>>>>>> LSSerializer be sensitive of current state from ToStream. This should be
>>>>>>>> safe because ToStream is an internal class and getIndent() method is
>>>>>>>> never used before.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Frank
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>
>


From huizhe.wang at oracle.com  Tue Feb 14 19:18:43 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 14 Feb 2017 11:18:43 -0800
Subject: RFR (JAXP) 8169450: StAX parse error if there is a newline in xml
 declaration
In-Reply-To: <88A0996A-34A6-453B-ADFF-0B39CF9AE5FD@oracle.com>
References: <4ea5378a-2d51-4282-3a0b-af39c909b9c5@oracle.com>
 <1C84D336-7E4B-497C-B662-91A09B0A1439@oracle.com>
 <441bccfd-ae9e-9bc6-a5a4-36ae03f9b11f@oracle.com>
 <77b9bbc7-006f-8fb3-9ad3-a5a14b0e8d17@oracle.com>
 <88A0996A-34A6-453B-ADFF-0B39CF9AE5FD@oracle.com>
Message-ID: <5dc213e2-704b-1ae9-4798-21b8944a496c@oracle.com>

Thanks Lance, Daniel!

-Joe

On 2/14/2017 10:53 AM, Lance Andersen wrote:
> Looks good? ship it.
>
>> On Feb 14, 2017, at 1:41 PM, Daniel Fuchs <daniel.fuchs at oracle.com 
>> <mailto:daniel.fuchs at oracle.com>> wrote:
>>
>> On 14/02/17 17:21, huizhe wang wrote:
>>> Thanks!
>>>
>>> Here's an updated webrev:
>>> http://cr.openjdk.java.net/~joehw/jdk9/8169450/webrev/ 
>>> <http://cr.openjdk.java.net/%7Ejoehw/jdk9/8169450/webrev/>
>>
>> +1
>>
>> -- daniel
>>
>>>
>>> -Joe
>>>
>>> On 2/14/2017 4:07 AM, Lance Andersen wrote:
>>>> Looks good overall Joe.  I would agree that I would clean up the minor
>>>> comment alignment issues.
>>>>
>>>> Best
>>>> Lance
>>>>> On Feb 13, 2017, at 9:27 PM, huizhe wang <huizhe.wang at oracle.com 
>>>>> <mailto:huizhe.wang at oracle.com>
>>>>> <mailto:huizhe.wang at oracle.com>> wrote:
>>>>>
>>>>> A quick fix for the error parsing xml declaration. This is one of the
>>>>> three outstanding issues in the xml area that must be addressed for
>>>>> the coming development deadline.
>>>>>
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8169450
>>>>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8169450/webrev/ 
>>>>> <http://cr.openjdk.java.net/%7Ejoehw/jdk9/8169450/webrev/>
>>>>> <http://cr.openjdk.java.net/%7Ejoehw/jdk9/8169450/webrev/>
>>>>>
>>>>> Checking whether a space follows "<?xml" was sufficient for DOM/SAX
>>>>> for which the base parser was originally created since the xml
>>>>> declaration was normalized during version detection. StAX, sharing
>>>>> the base parser after it was added to the JDK, however, does not use
>>>>> the same version detection/normalization process and would
>>>>> incorrectly parse the declaration if there are other whitespaces.
>>>>>
>>>>> Thanks,
>>>>> Joe
>>>>>
>>>>>
>>>>
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com> 
>>>> <mailto:Lance.Andersen at oracle.com>
>>>>
>>>>
>>>>
>>>
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>
>
>
>


From paul.sandoz at oracle.com  Tue Feb 14 19:20:00 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 14 Feb 2017 11:20:00 -0800
Subject: RFR(XS): 8174950: Gracefully handle null Supplier in
 Objects.requireNonNull
In-Reply-To: <CA+3eh122aWwsYgWL9O+xYF9r+9PK4puM2ySHr47RCc7ACC7gZg@mail.gmail.com>
References: <CA+3eh122aWwsYgWL9O+xYF9r+9PK4puM2ySHr47RCc7ACC7gZg@mail.gmail.com>
Message-ID: <2B7FE3C7-1824-4428-8E08-D67D1F53B6EE@oracle.com>

+1

Paul.

> On 14 Feb 2017, at 10:52, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> Hi,
> 
> can I please have another review for the following trivial fix:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2017/8174950/
> https://bugs.openjdk.java.net/browse/JDK-8174950
> 
> This change has already been discussed in length on the mailing list:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-February/thread.html#46324
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/thread.html#24989
> 
> and in the bug comments at:
> 
> https://bugs.openjdk.java.net/browse/JDK-8033909
> 
> So I'll give just (yet another) short summary here:
> 
> - Objects.requireNonNull(T, Supplier) does not check for the Supplier
> argument being null. Instead it relies on the fact, that the VM will
> implicitly throw a NullPointerException when it calls .get on the
> Supplier argument during the creation of the explicit
> NullPointerException which it is supposed to throw.
> 
> - this behavior slightly differs from Objects.requireNonNull(T,
> String) which simply creates a NullPointerException with a null
> message in the case where the String argument is null.
> 
> - the difference is not evident in the OpenJDK, because the HotSpot VM
> creates a NPE with a null message by default if we call a method on a
> null object.
> 
> - however creating such a NPE with a null message when invoking a
> method on a null object is not enforced by the standard, and other
> implementations can do better :) For the following trivial program:
> 
> public class NonNull {
>  public static void main(String[] args) {
>    Supplier<String> ss = null;
>    Object o = Objects.requireNonNull(null, ss);
>  }
> }
> 
> the current OpenJDK implementation returns:
> 
> Exception in thread "main" java.lang.NullPointerException
>    at java.util.Objects.requireNonNull(Objects.java:290)
>    at NonNull.main(NonNull.java:8)
> 
> but the SAP JVM will print:
> 
> Exception in thread "main" java.lang.NullPointerException: while
> trying to invoke the method java.util.function.Supplier.get() of a
> null object loaded from local variable 'messageSupplier'
>    at java.util.Objects.requireNonNull(Objects.java:290)
>    at NonNull.main(NonNull.java:8)
> 
> which is at least confusing for a call to Objects.requireNonNul() with
> a null Supplier. We think the exception should be the same like the
> one we get when invoking Objects.requireNonNul() with a null String.
> 
> - because of this difference (and because we like our extended
> Exception messages :) the JCK test for Objects.requireNonNul(T,
> Supplier) (i.e.
> api/java_util/Objects/index.html#RequireNonNullMessageSupplier) was
> removed from TCK 8 and is still commented out in TCK 9
> (npe_checkingNullSupplier() in RequireNonNullMessageSupplier.java).
> 
> I really think that the simplest and most natural fix for this problem
> is to simply check for a null Supplier argument and create the NPE
> with an explicit null message in that case (as outlined in the
> webrev). This:
> - makes the two requireNonNul() overloads for String and Supplier
> behave the same (which I think was the initial intention).
> - doesn't require documentation changes
> - makes it possible to write a simple and conforming TCK test
> 
> Regards,
> Volker


From chris.hegarty at oracle.com  Tue Feb 14 19:27:43 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 14 Feb 2017 19:27:43 +0000
Subject: RFR(XS): 8174950: Gracefully handle null Supplier in
 Objects.requireNonNull
In-Reply-To: <CA+3eh122aWwsYgWL9O+xYF9r+9PK4puM2ySHr47RCc7ACC7gZg@mail.gmail.com>
References: <CA+3eh122aWwsYgWL9O+xYF9r+9PK4puM2ySHr47RCc7ACC7gZg@mail.gmail.com>
Message-ID: <8EACFC90-2853-4264-8058-49DBF86AC19C@oracle.com>

On 14 Feb 2017, at 18:52, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> Hi,
> 
> can I please have another review for the following trivial fix:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2017/8174950/

Looks good.

-Chris.

From lance.andersen at oracle.com  Tue Feb 14 19:28:51 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 14 Feb 2017 14:28:51 -0500
Subject: RFR JDK-8174248: partialUpdateFooMainClass test in
 tools/jar/modularJar/Basic.java needs to be re-examined
In-Reply-To: <58A355FB.2010209@oracle.com>
References: <58A355FB.2010209@oracle.com>
Message-ID: <0DC4CD94-3FB9-4858-A43A-F760CD83E60F@oracle.com>

Looks fine Sherman..

> On Feb 14, 2017, at 2:09 PM, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> Hi,
> 
> Please review the test change for JDK-8174248
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8174248
> webrev: http://cr.openjdk.java.net/~sherman/8174248/webrev
> 
> The change is to simply rename the entry name from "IAmNotTheEntryPoint"
> to a "packaged" one as " jdk.test.foo.IAmNotTheEntryPoint" to satisfy the
> newly added sanity check in j.l.m.ModuleDescriptor.Builder.mainClass(), in
> which the "main-class in unnamed package" is no longer allowed (and the
> named package must exist in module "packages") .
> 
> Arguably it might be desired for "jar" tool to also verify whether or not the
> "main-class" really exists in the module jar file (the implementation does not
> verify the existence of the main-class for the manifest  for now, the newly
> added module related code follows the "convention"), but this probably should
> be handled/discussed in a separate rfe.
> 
> Thanks,
> Sherman

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From chris.hegarty at oracle.com  Tue Feb 14 19:28:54 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 14 Feb 2017 19:28:54 +0000
Subject: RFR JDK-8174248: partialUpdateFooMainClass test in
 tools/jar/modularJar/Basic.java needs to be re-examined
In-Reply-To: <58A355FB.2010209@oracle.com>
References: <58A355FB.2010209@oracle.com>
Message-ID: <12678D2A-6BA5-4F7F-A678-62446790C7CA@oracle.com>


> On 14 Feb 2017, at 19:09, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> Hi,
> 
> Please review the test change for JDK-8174248
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8174248
> webrev: http://cr.openjdk.java.net/~sherman/8174248/webrev

Looks fine Sherman.

-Chris.


> The change is to simply rename the entry name from "IAmNotTheEntryPoint"
> to a "packaged" one as " jdk.test.foo.IAmNotTheEntryPoint" to satisfy the
> newly added sanity check in j.l.m.ModuleDescriptor.Builder.mainClass(), in
> which the "main-class in unnamed package" is no longer allowed (and the
> named package must exist in module "packages") .
> 
> Arguably it might be desired for "jar" tool to also verify whether or not the
> "main-class" really exists in the module jar file (the implementation does not
> verify the existence of the main-class for the manifest  for now, the newly
> added module related code follows the "convention"), but this probably should
> be handled/discussed in a separate rfe.
> 
> Thanks,
> Sherman


From joe.darcy at oracle.com  Tue Feb 14 20:01:22 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 14 Feb 2017 12:01:22 -0800
Subject: JDK 9 RFR of JDK-8174960: Mark WakeupAfterClose.java as failing
 intermittentl
Message-ID: <fd20a699-2381-7665-103a-0dd8a2ba2f59@oracle.com>

Hello,

The test

java/nio/channels/Selector/WakeupAfterClose.java

has been seen to fail intermittently at a low frequency (JDK-8143614).

The test should be marked accordingly; patch below.

Thanks,

-Joe

--- a/test/java/nio/channels/Selector/WakeupAfterClose.java Mon Feb 13 
11:35:00 2017 -0500
+++ b/test/java/nio/channels/Selector/WakeupAfterClose.java    Tue Feb 
14 12:01:03 2017 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2007, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2007, 2017, 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
@@ -24,6 +24,7 @@
  /* @test
   * @bug 6524172
   * @summary Invoking wakeup on closed Selector can throw NPE if close 
resets interrupt status
+ * @key intermittent
   */

  import java.nio.channels.Selector;


From Roger.Riggs at Oracle.com  Tue Feb 14 20:16:36 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 14 Feb 2017 15:16:36 -0500
Subject: JDK 9 RFR of JDK-8174960: Mark WakeupAfterClose.java as failing
 intermittentl
In-Reply-To: <fd20a699-2381-7665-103a-0dd8a2ba2f59@oracle.com>
References: <fd20a699-2381-7665-103a-0dd8a2ba2f59@oracle.com>
Message-ID: <d74dd402-a3a7-0804-c362-0981d735c3a7@Oracle.com>

+1

Thanks joe

On 2/14/2017 3:01 PM, joe darcy wrote:
> Hello,
>
> The test
>
> java/nio/channels/Selector/WakeupAfterClose.java
>
> has been seen to fail intermittently at a low frequency (JDK-8143614).
>
> The test should be marked accordingly; patch below.
>
> Thanks,
>
> -Joe
>
> --- a/test/java/nio/channels/Selector/WakeupAfterClose.java Mon Feb 13 
> 11:35:00 2017 -0500
> +++ b/test/java/nio/channels/Selector/WakeupAfterClose.java    Tue Feb 
> 14 12:01:03 2017 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2007, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2007, 2017, 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
> @@ -24,6 +24,7 @@
>  /* @test
>   * @bug 6524172
>   * @summary Invoking wakeup on closed Selector can throw NPE if close 
> resets interrupt status
> + * @key intermittent
>   */
>
>  import java.nio.channels.Selector;
>


From lance.andersen at oracle.com  Tue Feb 14 20:28:50 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 14 Feb 2017 15:28:50 -0500
Subject: RFR: 8174735 Update JAX-WS RI integration to latest version
In-Reply-To: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
References: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
Message-ID: <195829C4-7072-42C5-ABBF-B522EEE85453@oracle.com>

Hi Roman,

I made a pass through the changes.  And here are some general comments which are mostly minor in nature?.

HTH

Best
Lance
----------------------
JAXBRIContext.java:
	- The comment ?If true, despite of the specification?.?;  This does not read well can this be clarified?

Generated.java, PostConstruct.java, PreDestroy.java,Resource.java
         -  Be nice to use {@code} vs <code></code> for readability
         -  Do you really need <p></p>?  I am assuming there are no doclint errors on Generated?
         - Was there a CCC for the changes as there were some minor semantic updates


MimeMultipart.java.:
       - createMimeBodyPart @param len does not align properly

SharedInputStream.java
       - writeTo @param out does not align

NameImpl.java
       -  Some comments have a blank line before the params, others do not.  It would be nice to be consistent

ParserPool.java
       - Can you explain the status regarding returnParser() and https://jaxp.dev.java.net/issues/show_bug.cgi?id=59
SAAJUtil.java
       - getSystemClassLoader, do you really need to check for a SecurityManager?  Why not just AccessController.doPrivilege(could also use a lambda also)

MethodUtil.java
       - Looks like the alignment is off in the changes in invoke

ContextClassloaderLocal.java
        -  getContextClassLoader could be changed to use a lambda with AccessController.doPrivilege if you desire

FactoryFinder.java
       - getSystemProperty, it looks like you were using a lambda and removed it for the AccessController.doPrivilege?

SecureLoader.java
      - same comment as SAAJUtil.java
NGCCRuntimeEx.java
      - copyLocater, createValidationContext @return comment needs checked 

package-info.java
      - Seem the new files include a 2003/2004/1997, 2017, copyright, should just be 2017 i believe

> On Feb 14, 2017, at 7:00 AM, Roman Grigoriadi <roman.grigoriadi at oracle.com> wrote:
> 
> Hi,
> 
> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8174735
> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/00/
> 
> You can find change list in the description of JBS and its linked issues. Most diffs are for SAAJ-RI related to JDK-8166745 - remove dependencies on jdks Xerces internal classes.
> 
> Thanks,
> Roman

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From Alan.Bateman at oracle.com  Tue Feb 14 20:40:09 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 14 Feb 2017 20:40:09 +0000
Subject: RFR(XS): 8174950: Gracefully handle null Supplier in
 Objects.requireNonNull
In-Reply-To: <CA+3eh122aWwsYgWL9O+xYF9r+9PK4puM2ySHr47RCc7ACC7gZg@mail.gmail.com>
References: <CA+3eh122aWwsYgWL9O+xYF9r+9PK4puM2ySHr47RCc7ACC7gZg@mail.gmail.com>
Message-ID: <7e8f1441-0f82-f165-0e23-25afcc2b765d@oracle.com>

On 14/02/2017 18:52, Volker Simonis wrote:

> Hi,
>
> can I please have another review for the following trivial fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2017/8174950/
> https://bugs.openjdk.java.net/browse/JDK-8174950
>
> This change has already been discussed in length on the mailing list:
>
>
This looks okay to me.

-Alan

From paul.sandoz at oracle.com  Tue Feb 14 20:45:39 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 14 Feb 2017 12:45:39 -0800
Subject: RFR 8165035 jar --help-extra should provide information on the
 -n/--normalize option
Message-ID: <C20EF805-F579-4CC9-BD39-B0C13B7B486F@oracle.com>

Hi,

Please review this minor fix to the --help-extra option to to report the -n/--normalize option:

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8165035-jar-tool-n/webrev/

It will report the following (and will be formatted correctly for a fixed width font):

"
 Operation modifiers valid only in create mode:

  -n, --normalize            Normalize information in the new jar archive
                             after creation
?

Paul.

From brian.burkhalter at oracle.com  Tue Feb 14 20:52:20 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 14 Feb 2017 12:52:20 -0800
Subject: JDK 9 RFR of JDK-8174960: Mark WakeupAfterClose.java as failing
 intermittentl
In-Reply-To: <d74dd402-a3a7-0804-c362-0981d735c3a7@Oracle.com>
References: <fd20a699-2381-7665-103a-0dd8a2ba2f59@oracle.com>
 <d74dd402-a3a7-0804-c362-0981d735c3a7@Oracle.com>
Message-ID: <C4E00F46-5694-4457-8B18-C2CA9B6C0654@oracle.com>

+1

Brian

On Feb 14, 2017, at 12:16 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:

> +1
> 
> Thanks joe
> 
> On 2/14/2017 3:01 PM, joe darcy wrote:
>> Hello,
>> 
>> The test
>> 
>> java/nio/channels/Selector/WakeupAfterClose.java
>> 
>> has been seen to fail intermittently at a low frequency (JDK-8143614).
>> 
>> The test should be marked accordingly; patch below.
>> 
>> Thanks,
>> 
>> -Joe
>> 
>> --- a/test/java/nio/channels/Selector/WakeupAfterClose.java Mon Feb 13 11:35:00 2017 -0500
>> +++ b/test/java/nio/channels/Selector/WakeupAfterClose.java    Tue Feb 14 12:01:03 2017 -0800
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2007, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2007, 2017, 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
>> @@ -24,6 +24,7 @@
>> /* @test
>>  * @bug 6524172
>>  * @summary Invoking wakeup on closed Selector can throw NPE if close resets interrupt status
>> + * @key intermittent
>>  */
>> 
>> import java.nio.channels.Selector;
>> 
> 


From brent.christian at oracle.com  Tue Feb 14 20:53:14 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 14 Feb 2017 12:53:14 -0800
Subject: [9] RFR: 8174779: Locale issues with Mac 10.12
In-Reply-To: <e1b195a0-2c58-7e80-2630-97cddf8918eb@oracle.com>
References: <e1b195a0-2c58-7e80-2630-97cddf8918eb@oracle.com>
Message-ID: <58A36E3A.7030704@oracle.com>

Looks good to me, Naoto.

-Brent
On 02/14/2017 11:05 AM, Naoto Sato wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8174779
>
> The proposed fix is located at:
>
> http://cr.openjdk.java.net/~naoto/8174779/webrev.01/
>
> The root cause of the problem was that starting from macOS 10.12, it
> returns the preferred user language including both script and region,
> which cannot be dealt with the existing parsing code.
>
> Naoto


From lance.andersen at oracle.com  Tue Feb 14 21:01:47 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 14 Feb 2017 16:01:47 -0500
Subject: RFR 8165035 jar --help-extra should provide information on the
 -n/--normalize option
In-Reply-To: <C20EF805-F579-4CC9-BD39-B0C13B7B486F@oracle.com>
References: <C20EF805-F579-4CC9-BD39-B0C13B7B486F@oracle.com>
Message-ID: <F3B7DE59-2B72-416B-90D6-6E8E0FC0A0CF@oracle.com>

Looks ok Paul...
> On Feb 14, 2017, at 3:45 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi,
> 
> Please review this minor fix to the --help-extra option to to report the -n/--normalize option:
> 
>  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8165035-jar-tool-n/webrev/
> 
> It will report the following (and will be formatted correctly for a fixed width font):
> 
> "
> Operation modifiers valid only in create mode:
> 
>  -n, --normalize            Normalize information in the new jar archive
>                             after creation
> ?
> 
> Paul.

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From mandy.chung at oracle.com  Tue Feb 14 21:39:47 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 14 Feb 2017 13:39:47 -0800
Subject: RFR: 8174735 Update JAX-WS RI integration to latest version
In-Reply-To: <ecc0ac83-97cd-a7f2-9274-b4987cf056ca@oracle.com>
References: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
 <ee580fc0-5404-11a0-86d9-2551e2f340ae@oracle.com>
 <ecc0ac83-97cd-a7f2-9274-b4987cf056ca@oracle.com>
Message-ID: <98620258-BC1E-4C44-A724-2F2966DACB21@oracle.com>


> On Feb 14, 2017, at 4:28 AM, Roman Grigoriadi <roman.grigoriadi at oracle.com> wrote:
> 
> On 02/14/2017 01:05 PM, Alan Bateman wrote:
>> Is the webrev missing the update to java.base's module-info.java? I assume we can drop the exporting of sun.reflect.misc to java.xml.ws.
> Thanks Alan, Mandy's patch for jaxws own MethodUtil is integrated, so sun.reflect.misc export should now be removed.

After you update module-info.java, you can run jdeps ?-check java.base,java.xml that will report any unused qualified exports.  You can double check if there is any qualified export remaining to java.xml.ws or other relevant modules.

Mandy

From mandy.chung at oracle.com  Tue Feb 14 22:53:33 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 14 Feb 2017 14:53:33 -0800
Subject: RFR: 8174735 Update JAX-WS RI integration to latest version
In-Reply-To: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
References: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
Message-ID: <DF61C6F3-48D0-4EB1-A93D-C09F523D2FB4@oracle.com>


> On Feb 14, 2017, at 4:00 AM, Roman Grigoriadi <roman.grigoriadi at oracle.com> wrote:
> 
> Hi,
> 
> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8174735
> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/00/


jaxws/src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java

-    /** JAXWS module name. JAXWS dependency is mandatory in generated Java module. */
-    private static final String JAXWS_MODULE = "java.xml.ws";
+    /** JAXB module name. JAXB dependency is mandatory in generated Java module. */
+    private static final String JAXWS_PACKAGE = "java.xml.ws?;

JAXWS_MODULE is the right name as we discussed in the last JAX-WS integration to jdk9. This change should be reverted and the upstream project  should be fixed.

+                    if ("-release".equals(opt) && 9 >= getVersion(javacOptions.get(i + 1))) {

javac supports `?-release` (double dashes, GNU long form style) but not the single dash option.  Is this new option in wsimport and wsgen tools?  It should probably be consistent with javac.

You can run jdeps ?-check java.base,java.xml option to double check if any remaining qualified exports to these modules.

Otherwise looks okay.

Mandy


From mandy.chung at oracle.com  Tue Feb 14 23:01:54 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 14 Feb 2017 15:01:54 -0800
Subject: RFR 8165035 jar --help-extra should provide information on the
 -n/--normalize option
In-Reply-To: <C20EF805-F579-4CC9-BD39-B0C13B7B486F@oracle.com>
References: <C20EF805-F579-4CC9-BD39-B0C13B7B486F@oracle.com>
Message-ID: <3B139B55-8CF0-4FDF-95F9-14E8D6FE9DD8@oracle.com>


> On Feb 14, 2017, at 12:45 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi,
> 
> Please review this minor fix to the --help-extra option to to report the -n/--normalize option:
> 
>  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8165035-jar-tool-n/webrev/

Looks fine to me.

Mandy

From lance.andersen at oracle.com  Tue Feb 14 23:08:35 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 14 Feb 2017 18:08:35 -0500
Subject: RFR: 8174735 Update JAX-WS RI integration to latest version
In-Reply-To: <DF61C6F3-48D0-4EB1-A93D-C09F523D2FB4@oracle.com>
References: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
 <DF61C6F3-48D0-4EB1-A93D-C09F523D2FB4@oracle.com>
Message-ID: <A5089034-2345-44A7-A43D-CECF30BD6C62@oracle.com>

Hi Mandy

> On Feb 14, 2017, at 5:53 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
> 
> +                    if ("-release".equals(opt) && 9 >= getVersion(javacOptions.get(i + 1))) {
> 
> javac supports `?-release` (double dashes, GNU long form style) but not the single dash option.  Is this new option in wsimport and wsgen tools?  It should probably be consistent with java.

All of the command line options AFAIK are with a single dash.  I would think you would want to keep all options  consistent (that is have all single dash, or all double dash) so perhaps support both single dash and double dash options if you are looking for javac consistency with GNU long form style?

Best
Lance

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From xueming.shen at oracle.com  Tue Feb 14 23:10:24 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 14 Feb 2017 15:10:24 -0800
Subject: RFR 8165035 jar --help-extra should provide information on the
 -n/--normalize option
In-Reply-To: <C20EF805-F579-4CC9-BD39-B0C13B7B486F@oracle.com>
References: <C20EF805-F579-4CC9-BD39-B0C13B7B486F@oracle.com>
Message-ID: <58A38E60.4020509@oracle.com>

+1

On 02/14/2017 12:45 PM, Paul Sandoz wrote:
> Hi,
>
> Please review this minor fix to the --help-extra option to to report the -n/--normalize option:
>
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8165035-jar-tool-n/webrev/
>
> It will report the following (and will be formatted correctly for a fixed width font):
>
> "
>   Operation modifiers valid only in create mode:
>
>    -n, --normalize            Normalize information in the new jar archive
>                               after creation
> ?
>
> Paul.


From mandy.chung at oracle.com  Tue Feb 14 23:54:12 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 14 Feb 2017 15:54:12 -0800
Subject: RFR: 8174735 Update JAX-WS RI integration to latest version
In-Reply-To: <A5089034-2345-44A7-A43D-CECF30BD6C62@oracle.com>
References: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
 <DF61C6F3-48D0-4EB1-A93D-C09F523D2FB4@oracle.com>
 <A5089034-2345-44A7-A43D-CECF30BD6C62@oracle.com>
Message-ID: <C8FC0FBD-B193-4CC9-906D-D50CA32B108B@oracle.com>


> On Feb 14, 2017, at 3:08 PM, Lance Andersen <lance.andersen at oracle.com> wrote:
> 
> Hi Mandy
> 
>> On Feb 14, 2017, at 5:53 PM, Mandy Chung <mandy.chung at oracle.com <mailto:mandy.chung at oracle.com>> wrote:
>> 
>> 
>> 
>> +                    if ("-release".equals(opt) && 9 >= getVersion(javacOptions.get(i + 1))) {
>> 
>> javac supports `?-release` (double dashes, GNU long form style) but not the single dash option.  Is this new option in wsimport and wsgen tools?  It should probably be consistent with java.
> 
> All of the command line options AFAIK are with a single dash.  I would think you would want to keep all options  consistent (that is have all single dash, or all double dash) so perhaps support both single dash and double dash options if you are looking for javac consistency with GNU long form style?
> 


New JDK 9 options have moved to GNU-style:
   http://openjdk.java.net/jeps/293

There is no short-form for `?release`.   Since this option has the same semantic as javac ?release, I think it should be consistent with javac, just have the long form.

Mandy

From frank.yuan at oracle.com  Wed Feb 15 00:33:15 2017
From: frank.yuan at oracle.com (Frank Yuan)
Date: Wed, 15 Feb 2017 08:33:15 +0800
Subject: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by
 JDK-8087303
In-Reply-To: <6728500c-a89e-1e2b-493d-7c50d0f5f5e6@oracle.com>
References: <045901d286ad$c1f21e20$45d65a60$@oracle.com>
 <5d9c5098-e11c-1190-b2d8-b3c675de7ac7@oracle.com>
 <05c301d286c8$51439350$f3cab9f0$@oracle.com>
 <6c08a0b5-90e5-bd2c-eb02-b53a83e11469@oracle.com>
 <05e801d286d2$c83fbc40$58bf34c0$@oracle.com>
 <6728500c-a89e-1e2b-493d-7c50d0f5f5e6@oracle.com>
Message-ID: <069c01d28723$1a5774f0$4f065ed0$@oracle.com>


> -----Original Message-----
> From: huizhe wang [mailto:huizhe.wang at oracle.com]
> Subject: Re: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by JDK-8087303
> 
> Looks good to me as well.
> 
> For the CR and LF question, XML processors are required by the
> specification to normalize and translate both CRLF sequence and any CR
> not followed by LF to a single LF.  For that reason, you don't have
> check CR since the content the serializer gets is parsed.
> 
Thank you very much for explanation, since that, I will remove the check for CR as below:
3439c3439
<                     while (skipBeginningNewlines && (text[start] == '\n' || text[start] == '\r')) {
---
>                     while (skipBeginningNewlines && text[start] == '\n') {
3498c3498
<                         while (skipBeginningNewlines && (text[start] == '\n' || text[start] == '\r')) {
---
>                         while (skipBeginningNewlines && text[start] == '\n') {

Once it is passed by all tests, I will push the change.

Thanks
Frank

> Best,
> Joe
> 
> On 2/14/2017 6:58 AM, Frank Yuan wrote:
> >> -----Original Message-----
> >> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> >> Subject: Re: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by JDK-8087303
> >>
> >> Hi Frank,
> >>
> >> On 14/02/17 13:43, Frank Yuan wrote:
> >>>> -----Original Message-----
> >>>> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> >>>> Subject: Re: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by JDK-8087303
> >>>>
> >>>> Hi Frank,
> >>>>
> >>>> Should you skip '\r' if it's not followed by '\n'?
> >> Well - I'll let Joe answer that. ;-)
> > Hmm, wait for Joe to confirm.
> >
> >> It was just a question, I was wondering whether that could
> >> potentially cause problems down the road - since new lines
> >> are usually only either '\n' or '\r'+'\n'.
> >>
> > Agree.
> >
> >> Your patch looks fine otherwise, maybe the code that skips
> >> the '\n' could be factorized somewhere to avoid duplication,
> >> but that's not really important.
> >>
> >> Both issues reported in the bug are still fix - so I think we
> >> should try to get this patch in as soon as we can.
> >>
> > Yes, understand!
> >
> > Thanks
> > Frank
> >
> >> best regards,
> >>
> >> -- daniel
> >>
> >>> Does it matter? Since XML processor should normalize the newline.
> >>>
> >>> Thanks
> >>> Frank
> >>>> best regards,
> >>>>
> >>>> -- daniel
> >>>>
> >>>> On 14/02/17 10:33, Frank Yuan wrote:
> >>>>> Hi Joe
> >>>>>
> >>>>> As you suggested, I made pretty-print a little better based on the fix. That is when adding indentation, just check the
> >>> beginning
> >>>>> character(s), in case of '\n' or '\r' then, ignore it/them.
> >>>>>
> >>>>> Please check the new webrev: http://cr.openjdk.java.net/~fyuan/8174025/webrev.01/
> >>>>>
> >>>>>
> >>>>> Thanks
> >>>>> Frank
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
> >>>>> Subject: should have been 8174025 -> Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303
> >>>>>
> >>>>> Note that the bug id was incorrect, it should have been 8174025. 8170192
> >>>>> was a test bug fix.
> >>>>>
> >>>>> -Joe
> >>>>>
> >>>>> On 2/13/2017 1:35 AM, Frank Yuan wrote:
> >>>>>> Hi Joe and Daniel
> >>>>>>
> >>>>>> Thank you very much for your review!
> >>>>>>
> >>>>>> Frank
> >>>>>>
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
> >>>>>> Subject: Re: RFR [JAXP] JDK-8170192 Regression in XML Transform caused by JDK-8087303
> >>>>>>
> >>>>>> +1 from me too.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Joe
> >>>>>>
> >>>>>> On 2/10/2017 5:25 AM, Daniel Fuchs wrote:
> >>>>>>> Hi Frank,
> >>>>>>>
> >>>>>>> Thanks for fixing this!
> >>>>>>>
> >>>>>>> I imported your patch and played with it a bit.
> >>>>>>> Also ran the jaxp test.
> >>>>>>>
> >>>>>>> Both issues reported have indeed disappeared.
> >>>>>>>
> >>>>>>> So that's a +1 from me.
> >>>>>>>
> >>>>>>> best regards,
> >>>>>>>
> >>>>>>> -- daniel
> >>>>>>>
> >>>>>>> On 10/02/17 11:03, Frank Yuan wrote:
> >>>>>>>> Hi All
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Would you like to review
> >>>>>>>> http://cr.openjdk.java.net/~fyuan/8174025/webrev.00/?
> >>>>>>>>
> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174025
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> JDK-8087303 introduced 2 issues:
> >>>>>>>>
> >>>>>>>> 1.       Flaw when xlst uses disable-output-escaping attribute
> >>>>>>>>
> >>>>>>>> 2.       Eat the whitespace between html inline elements
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> This patch fixed the issues.
> >>>>>>>>
> >>>>>>>> To fix the second issue, we decide to keep the compatibility with JDK 8
> >>>>>>>> on the whitespace handling, that is only LSSerializer cleans the extra
> >>>>>>>> whitespaces in if pretty-print is on, but XSLT doesn't.
> >>>>>>>>
> >>>>>>>> I modified the behavior of getIndent() method in class ToStream, to make
> >>>>>>>> LSSerializer be sensitive of current state from ToStream. This should be
> >>>>>>>> safe because ToStream is an internal class and getIndent() method is
> >>>>>>>> never used before.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>>
> >>>>>>>> Frank
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>
> >>>
> >



From david.holmes at oracle.com  Wed Feb 15 02:03:22 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 15 Feb 2017 12:03:22 +1000
Subject: RFR(XS): 8174950: Gracefully handle null Supplier in
 Objects.requireNonNull
In-Reply-To: <CA+3eh122aWwsYgWL9O+xYF9r+9PK4puM2ySHr47RCc7ACC7gZg@mail.gmail.com>
References: <CA+3eh122aWwsYgWL9O+xYF9r+9PK4puM2ySHr47RCc7ACC7gZg@mail.gmail.com>
Message-ID: <d91adb62-f1f2-04ec-e4ed-522550375974@oracle.com>

Looks good to me!

Thanks,
David

On 15/02/2017 4:52 AM, Volker Simonis wrote:
> Hi,
>
> can I please have another review for the following trivial fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2017/8174950/
> https://bugs.openjdk.java.net/browse/JDK-8174950
>
> This change has already been discussed in length on the mailing list:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-February/thread.html#46324
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/thread.html#24989
>
> and in the bug comments at:
>
> https://bugs.openjdk.java.net/browse/JDK-8033909
>
> So I'll give just (yet another) short summary here:
>
> - Objects.requireNonNull(T, Supplier) does not check for the Supplier
> argument being null. Instead it relies on the fact, that the VM will
> implicitly throw a NullPointerException when it calls .get on the
> Supplier argument during the creation of the explicit
> NullPointerException which it is supposed to throw.
>
> - this behavior slightly differs from Objects.requireNonNull(T,
> String) which simply creates a NullPointerException with a null
> message in the case where the String argument is null.
>
> - the difference is not evident in the OpenJDK, because the HotSpot VM
> creates a NPE with a null message by default if we call a method on a
> null object.
>
> - however creating such a NPE with a null message when invoking a
> method on a null object is not enforced by the standard, and other
> implementations can do better :) For the following trivial program:
>
> public class NonNull {
>   public static void main(String[] args) {
>     Supplier<String> ss = null;
>     Object o = Objects.requireNonNull(null, ss);
>   }
> }
>
> the current OpenJDK implementation returns:
>
> Exception in thread "main" java.lang.NullPointerException
>     at java.util.Objects.requireNonNull(Objects.java:290)
>     at NonNull.main(NonNull.java:8)
>
> but the SAP JVM will print:
>
> Exception in thread "main" java.lang.NullPointerException: while
> trying to invoke the method java.util.function.Supplier.get() of a
> null object loaded from local variable 'messageSupplier'
>     at java.util.Objects.requireNonNull(Objects.java:290)
>     at NonNull.main(NonNull.java:8)
>
> which is at least confusing for a call to Objects.requireNonNul() with
> a null Supplier. We think the exception should be the same like the
> one we get when invoking Objects.requireNonNul() with a null String.
>
> - because of this difference (and because we like our extended
> Exception messages :) the JCK test for Objects.requireNonNul(T,
> Supplier) (i.e.
> api/java_util/Objects/index.html#RequireNonNullMessageSupplier) was
> removed from TCK 8 and is still commented out in TCK 9
> (npe_checkingNullSupplier() in RequireNonNullMessageSupplier.java).
>
> I really think that the simplest and most natural fix for this problem
> is to simply check for a null Supplier argument and create the NPE
> with an explicit null message in that case (as outlined in the
> webrev). This:
>  - makes the two requireNonNul() overloads for String and Supplier
> behave the same (which I think was the initial intention).
>  - doesn't require documentation changes
>  - makes it possible to write a simple and conforming TCK test
>
> Regards,
> Volker
>

From frank.yuan at oracle.com  Wed Feb 15 03:22:30 2017
From: frank.yuan at oracle.com (Frank Yuan)
Date: Wed, 15 Feb 2017 11:22:30 +0800
Subject: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by
 JDK-8087303
In-Reply-To: <069d01d28723$1bb27110$53175330$@oracle.com>
References: <045901d286ad$c1f21e20$45d65a60$@oracle.com>
 <5d9c5098-e11c-1190-b2d8-b3c675de7ac7@oracle.com>
 <05c301d286c8$51439350$f3cab9f0$@oracle.com>
 <6c08a0b5-90e5-bd2c-eb02-b53a83e11469@oracle.com>
 <05e801d286d2$c83fbc40$58bf34c0$@oracle.com>
 <6728500c-a89e-1e2b-493d-7c50d0f5f5e6@oracle.com>
 <069d01d28723$1bb27110$53175330$@oracle.com>
Message-ID: <06b901d2873a$bef73290$3ce597b0$@oracle.com>

Hi Joe and Daniel

I tested more and checked the code, both of you are right.

CRLF, CR, LF in the xml file are all normalized to LF, and finally output to the platform-related line.separator if it's serialized.
The serializer only handle LF as newline. User can create CR text node programmatically or there may be some case that CR is sent to
the serializer intentionally, but anyway in these cases, CR is not regarded as a newline. So the change as Joe's comment and I
stated in previous mail is made:
http://cr.openjdk.java.net/~fyuan/8174025/webrev.02/

Thanks
Frank

> -----Original Message-----
> From: Frank Yuan [mailto:frank.yuan at oracle.com]
> Subject: RE: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by JDK-8087303
> 
> 
> > -----Original Message-----
> > From: huizhe wang [mailto:huizhe.wang at oracle.com]
> > Subject: Re: RFR [JAXP] JDK-8174025 Regression in XML Transform caused
> by JDK-8087303
> >
> > Looks good to me as well.
> >
> > For the CR and LF question, XML processors are required by the
> > specification to normalize and translate both CRLF sequence and any CR
> > not followed by LF to a single LF.  For that reason, you don't have
> > check CR since the content the serializer gets is parsed.
> >
> Thank you very much for explanation, since that, I will remove the check
> for CR as below:
> 3439c3439
> <                     while (skipBeginningNewlines && (text[start] == '\n'
> || text[start] == '\r')) {
> ---
> >                     while (skipBeginningNewlines && text[start] == '\n')
> {
> 3498c3498
> <                         while (skipBeginningNewlines && (text[start] ==
> '\n' || text[start] == '\r')) {
> ---
> >                         while (skipBeginningNewlines && text[start] ==
> '\n') {
> 
> Once it is passed by all tests, I will push the change.
> 
> Thanks
> Frank
> 
> > Best,
> > Joe
> >
> > On 2/14/2017 6:58 AM, Frank Yuan wrote:
> > >> -----Original Message-----
> > >> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> > >> Subject: Re: RFR [JAXP] JDK-8174025 Regression in XML Transform
> caused by JDK-8087303
> > >>
> > >> Hi Frank,
> > >>
> > >> On 14/02/17 13:43, Frank Yuan wrote:
> > >>>> -----Original Message-----
> > >>>> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> > >>>> Subject: Re: RFR [JAXP] JDK-8174025 Regression in XML Transform
> caused by JDK-8087303
> > >>>>
> > >>>> Hi Frank,
> > >>>>
> > >>>> Should you skip '\r' if it's not followed by '\n'?
> > >> Well - I'll let Joe answer that. ;-)
> > > Hmm, wait for Joe to confirm.
> > >
> > >> It was just a question, I was wondering whether that could
> > >> potentially cause problems down the road - since new lines
> > >> are usually only either '\n' or '\r'+'\n'.
> > >>
> > > Agree.
> > >
> > >> Your patch looks fine otherwise, maybe the code that skips
> > >> the '\n' could be factorized somewhere to avoid duplication,
> > >> but that's not really important.
> > >>
> > >> Both issues reported in the bug are still fix - so I think we
> > >> should try to get this patch in as soon as we can.
> > >>
> > > Yes, understand!
> > >
> > > Thanks
> > > Frank
> > >
> > >> best regards,
> > >>
> > >> -- daniel
> > >>
> > >>> Does it matter? Since XML processor should normalize the newline.
> > >>>
> > >>> Thanks
> > >>> Frank
> > >>>> best regards,
> > >>>>
> > >>>> -- daniel
> > >>>>
> > >>>> On 14/02/17 10:33, Frank Yuan wrote:
> > >>>>> Hi Joe
> > >>>>>
> > >>>>> As you suggested, I made pretty-print a little better based on the
> fix. That is when adding indentation, just check the
> > >>> beginning
> > >>>>> character(s), in case of '\n' or '\r' then, ignore it/them.
> > >>>>>
> > >>>>> Please check the new webrev:
> http://cr.openjdk.java.net/~fyuan/8174025/webrev.01/
> > >>>>>
> > >>>>>
> > >>>>> Thanks
> > >>>>> Frank
> > >>>>>
> > >>>>> -----Original Message-----
> > >>>>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
> > >>>>> Subject: should have been 8174025 -> Re: RFR [JAXP] JDK-8170192
> Regression in XML Transform caused by JDK-8087303
> > >>>>>
> > >>>>> Note that the bug id was incorrect, it should have been 8174025.
> 8170192
> > >>>>> was a test bug fix.
> > >>>>>
> > >>>>> -Joe
> > >>>>>
> > >>>>> On 2/13/2017 1:35 AM, Frank Yuan wrote:
> > >>>>>> Hi Joe and Daniel
> > >>>>>>
> > >>>>>> Thank you very much for your review!
> > >>>>>>
> > >>>>>> Frank
> > >>>>>>
> > >>>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
> > >>>>>> Subject: Re: RFR [JAXP] JDK-8170192 Regression in XML Transform
> caused by JDK-8087303
> > >>>>>>
> > >>>>>> +1 from me too.
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>> Joe
> > >>>>>>
> > >>>>>> On 2/10/2017 5:25 AM, Daniel Fuchs wrote:
> > >>>>>>> Hi Frank,
> > >>>>>>>
> > >>>>>>> Thanks for fixing this!
> > >>>>>>>
> > >>>>>>> I imported your patch and played with it a bit.
> > >>>>>>> Also ran the jaxp test.
> > >>>>>>>
> > >>>>>>> Both issues reported have indeed disappeared.
> > >>>>>>>
> > >>>>>>> So that's a +1 from me.
> > >>>>>>>
> > >>>>>>> best regards,
> > >>>>>>>
> > >>>>>>> -- daniel
> > >>>>>>>
> > >>>>>>> On 10/02/17 11:03, Frank Yuan wrote:
> > >>>>>>>> Hi All
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Would you like to review
> > >>>>>>>> http://cr.openjdk.java.net/~fyuan/8174025/webrev.00/?
> > >>>>>>>>
> > >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174025
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> JDK-8087303 introduced 2 issues:
> > >>>>>>>>
> > >>>>>>>> 1.       Flaw when xlst uses disable-output-escaping attribute
> > >>>>>>>>
> > >>>>>>>> 2.       Eat the whitespace between html inline elements
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> This patch fixed the issues.
> > >>>>>>>>
> > >>>>>>>> To fix the second issue, we decide to keep the compatibility
> with JDK 8
> > >>>>>>>> on the whitespace handling, that is only LSSerializer cleans
> the extra
> > >>>>>>>> whitespaces in if pretty-print is on, but XSLT doesn't.
> > >>>>>>>>
> > >>>>>>>> I modified the behavior of getIndent() method in class
> ToStream, to make
> > >>>>>>>> LSSerializer be sensitive of current state from ToStream. This
> should be
> > >>>>>>>> safe because ToStream is an internal class and getIndent()
> method is
> > >>>>>>>> never used before.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Thanks
> > >>>>>>>>
> > >>>>>>>> Frank
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>
> > >>>
> > >



From huizhe.wang at oracle.com  Wed Feb 15 03:35:13 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 14 Feb 2017 19:35:13 -0800
Subject: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by
 JDK-8087303
In-Reply-To: <06b901d2873a$bef73290$3ce597b0$@oracle.com>
References: <045901d286ad$c1f21e20$45d65a60$@oracle.com>
 <5d9c5098-e11c-1190-b2d8-b3c675de7ac7@oracle.com>
 <05c301d286c8$51439350$f3cab9f0$@oracle.com>
 <6c08a0b5-90e5-bd2c-eb02-b53a83e11469@oracle.com>
 <05e801d286d2$c83fbc40$58bf34c0$@oracle.com>
 <6728500c-a89e-1e2b-493d-7c50d0f5f5e6@oracle.com>
 <069d01d28723$1bb27110$53175330$@oracle.com>
 <06b901d2873a$bef73290$3ce597b0$@oracle.com>
Message-ID: <8b17faeb-6a9d-03a6-c9e4-ff1b775f1546@oracle.com>

Sounds good. The change to check LF only looks good.

Thanks,
Joe

On 2/14/2017 7:22 PM, Frank Yuan wrote:
> Hi Joe and Daniel
>
> I tested more and checked the code, both of you are right.
>
> CRLF, CR, LF in the xml file are all normalized to LF, and finally output to the platform-related line.separator if it's serialized.
> The serializer only handle LF as newline. User can create CR text node programmatically or there may be some case that CR is sent to
> the serializer intentionally, but anyway in these cases, CR is not regarded as a newline. So the change as Joe's comment and I
> stated in previous mail is made:
> http://cr.openjdk.java.net/~fyuan/8174025/webrev.02/
>
> Thanks
> Frank
>
>> -----Original Message-----
>> From: Frank Yuan [mailto:frank.yuan at oracle.com]
>> Subject: RE: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by JDK-8087303
>>
>>
>>> -----Original Message-----
>>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
>>> Subject: Re: RFR [JAXP] JDK-8174025 Regression in XML Transform caused
>> by JDK-8087303
>>> Looks good to me as well.
>>>
>>> For the CR and LF question, XML processors are required by the
>>> specification to normalize and translate both CRLF sequence and any CR
>>> not followed by LF to a single LF.  For that reason, you don't have
>>> check CR since the content the serializer gets is parsed.
>>>
>> Thank you very much for explanation, since that, I will remove the check
>> for CR as below:
>> 3439c3439
>> <                     while (skipBeginningNewlines && (text[start] == '\n'
>> || text[start] == '\r')) {
>> ---
>>>                      while (skipBeginningNewlines && text[start] == '\n')
>> {
>> 3498c3498
>> <                         while (skipBeginningNewlines && (text[start] ==
>> '\n' || text[start] == '\r')) {
>> ---
>>>                          while (skipBeginningNewlines && text[start] ==
>> '\n') {
>>
>> Once it is passed by all tests, I will push the change.
>>
>> Thanks
>> Frank
>>


From frank.yuan at oracle.com  Wed Feb 15 03:53:10 2017
From: frank.yuan at oracle.com (Frank Yuan)
Date: Wed, 15 Feb 2017 11:53:10 +0800
Subject: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by
 JDK-8087303
In-Reply-To: <8b17faeb-6a9d-03a6-c9e4-ff1b775f1546@oracle.com>
References: <045901d286ad$c1f21e20$45d65a60$@oracle.com>
 <5d9c5098-e11c-1190-b2d8-b3c675de7ac7@oracle.com>
 <05c301d286c8$51439350$f3cab9f0$@oracle.com>
 <6c08a0b5-90e5-bd2c-eb02-b53a83e11469@oracle.com>
 <05e801d286d2$c83fbc40$58bf34c0$@oracle.com>
 <6728500c-a89e-1e2b-493d-7c50d0f5f5e6@oracle.com>
 <069d01d28723$1bb27110$53175330$@oracle.com>
 <06b901d2873a$bef73290$3ce597b0$@oracle.com>
 <8b17faeb-6a9d-03a6-c9e4-ff1b775f1546@oracle.com>
Message-ID: <06f001d2873f$07b4e230$171ea690$@oracle.com>

Thank you very much for the check! Pushed.

Frank

> -----Original Message-----
> From: huizhe wang [mailto:huizhe.wang at oracle.com]
> Sent: Wednesday, February 15, 2017 11:35 AM
> To: Frank Yuan; 'Daniel Fuchs'
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by JDK-8087303
> 
> Sounds good. The change to check LF only looks good.
> 
> Thanks,
> Joe
> 
> On 2/14/2017 7:22 PM, Frank Yuan wrote:
> > Hi Joe and Daniel
> >
> > I tested more and checked the code, both of you are right.
> >
> > CRLF, CR, LF in the xml file are all normalized to LF, and finally output to the platform-related line.separator if it's
serialized.
> > The serializer only handle LF as newline. User can create CR text node programmatically or there may be some case that CR is
sent to
> > the serializer intentionally, but anyway in these cases, CR is not regarded as a newline. So the change as Joe's comment and I
> > stated in previous mail is made:
> > http://cr.openjdk.java.net/~fyuan/8174025/webrev.02/
> >
> > Thanks
> > Frank
> >
> >> -----Original Message-----
> >> From: Frank Yuan [mailto:frank.yuan at oracle.com]
> >> Subject: RE: RFR [JAXP] JDK-8174025 Regression in XML Transform caused by JDK-8087303
> >>
> >>
> >>> -----Original Message-----
> >>> From: huizhe wang [mailto:huizhe.wang at oracle.com]
> >>> Subject: Re: RFR [JAXP] JDK-8174025 Regression in XML Transform caused
> >> by JDK-8087303
> >>> Looks good to me as well.
> >>>
> >>> For the CR and LF question, XML processors are required by the
> >>> specification to normalize and translate both CRLF sequence and any CR
> >>> not followed by LF to a single LF.  For that reason, you don't have
> >>> check CR since the content the serializer gets is parsed.
> >>>
> >> Thank you very much for explanation, since that, I will remove the check
> >> for CR as below:
> >> 3439c3439
> >> <                     while (skipBeginningNewlines && (text[start] == '\n'
> >> || text[start] == '\r')) {
> >> ---
> >>>                      while (skipBeginningNewlines && text[start] == '\n')
> >> {
> >> 3498c3498
> >> <                         while (skipBeginningNewlines && (text[start] ==
> >> '\n' || text[start] == '\r')) {
> >> ---
> >>>                          while (skipBeginningNewlines && text[start] ==
> >> '\n') {
> >>
> >> Once it is passed by all tests, I will push the change.
> >>
> >> Thanks
> >> Frank
> >>



From Alan.Bateman at oracle.com  Wed Feb 15 07:53:54 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 15 Feb 2017 07:53:54 +0000
Subject: RFR 8165035 jar --help-extra should provide information on the
 -n/--normalize option
In-Reply-To: <C20EF805-F579-4CC9-BD39-B0C13B7B486F@oracle.com>
References: <C20EF805-F579-4CC9-BD39-B0C13B7B486F@oracle.com>
Message-ID: <462340b4-529f-ef11-9d80-7222390def96@oracle.com>

On 14/02/2017 20:45, Paul Sandoz wrote:

> Hi,
>
> Please review this minor fix to the --help-extra option to to report the -n/--normalize option:
>
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8165035-jar-tool-n/webrev/
>
> It will report the following (and will be formatted correctly for a fixed width font):
>
> "
>   Operation modifiers valid only in create mode:
>
>    -n, --normalize            Normalize information in the new jar archive
>                               after creation
> ?
>
This looks to me.

-Alan

From volker.simonis at gmail.com  Wed Feb 15 08:31:28 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 15 Feb 2017 09:31:28 +0100
Subject: RFR(XS): 8174950: Gracefully handle null Supplier in
 Objects.requireNonNull
In-Reply-To: <d91adb62-f1f2-04ec-e4ed-522550375974@oracle.com>
References: <CA+3eh122aWwsYgWL9O+xYF9r+9PK4puM2ySHr47RCc7ACC7gZg@mail.gmail.com>
 <d91adb62-f1f2-04ec-e4ed-522550375974@oracle.com>
Message-ID: <CA+3eh108pp3CyRT-4qjcYinFUHqMvqKXp3J35Sf=STiB20zfmA@mail.gmail.com>

Thanks everybody! This was a real tough one :)
Maybe I'll ask Mark to put it on the Java 9 achievements slide at next
JavaOne :)


On Wed, Feb 15, 2017 at 3:03 AM, David Holmes <david.holmes at oracle.com> wrote:
> Looks good to me!
>
> Thanks,
> David
>
>
> On 15/02/2017 4:52 AM, Volker Simonis wrote:
>>
>> Hi,
>>
>> can I please have another review for the following trivial fix:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2017/8174950/
>> https://bugs.openjdk.java.net/browse/JDK-8174950
>>
>> This change has already been discussed in length on the mailing list:
>>
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-February/thread.html#46324
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/thread.html#24989
>>
>> and in the bug comments at:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8033909
>>
>> So I'll give just (yet another) short summary here:
>>
>> - Objects.requireNonNull(T, Supplier) does not check for the Supplier
>> argument being null. Instead it relies on the fact, that the VM will
>> implicitly throw a NullPointerException when it calls .get on the
>> Supplier argument during the creation of the explicit
>> NullPointerException which it is supposed to throw.
>>
>> - this behavior slightly differs from Objects.requireNonNull(T,
>> String) which simply creates a NullPointerException with a null
>> message in the case where the String argument is null.
>>
>> - the difference is not evident in the OpenJDK, because the HotSpot VM
>> creates a NPE with a null message by default if we call a method on a
>> null object.
>>
>> - however creating such a NPE with a null message when invoking a
>> method on a null object is not enforced by the standard, and other
>> implementations can do better :) For the following trivial program:
>>
>> public class NonNull {
>>   public static void main(String[] args) {
>>     Supplier<String> ss = null;
>>     Object o = Objects.requireNonNull(null, ss);
>>   }
>> }
>>
>> the current OpenJDK implementation returns:
>>
>> Exception in thread "main" java.lang.NullPointerException
>>     at java.util.Objects.requireNonNull(Objects.java:290)
>>     at NonNull.main(NonNull.java:8)
>>
>> but the SAP JVM will print:
>>
>> Exception in thread "main" java.lang.NullPointerException: while
>> trying to invoke the method java.util.function.Supplier.get() of a
>> null object loaded from local variable 'messageSupplier'
>>     at java.util.Objects.requireNonNull(Objects.java:290)
>>     at NonNull.main(NonNull.java:8)
>>
>> which is at least confusing for a call to Objects.requireNonNul() with
>> a null Supplier. We think the exception should be the same like the
>> one we get when invoking Objects.requireNonNul() with a null String.
>>
>> - because of this difference (and because we like our extended
>> Exception messages :) the JCK test for Objects.requireNonNul(T,
>> Supplier) (i.e.
>> api/java_util/Objects/index.html#RequireNonNullMessageSupplier) was
>> removed from TCK 8 and is still commented out in TCK 9
>> (npe_checkingNullSupplier() in RequireNonNullMessageSupplier.java).
>>
>> I really think that the simplest and most natural fix for this problem
>> is to simply check for a null Supplier argument and create the NPE
>> with an explicit null message in that case (as outlined in the
>> webrev). This:
>>  - makes the two requireNonNul() overloads for String and Supplier
>> behave the same (which I think was the initial intention).
>>  - doesn't require documentation changes
>>  - makes it possible to write a simple and conforming TCK test
>>
>> Regards,
>> Volker
>>
>

From matthias.baesken at sap.com  Wed Feb 15 08:37:28 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 15 Feb 2017 08:37:28 +0000
Subject: jdk10 : simplify jexec build settings
In-Reply-To: <026d9dec-a64a-bd98-d95f-7cce061819f5@oracle.com>
References: <92a51f307d33465faca64e8d43c176bc@DEWDFE13DE14.global.corp.sap>
 <abf8e046-3528-1c9c-ad12-ce786239b385@oracle.com>
 <20161b2fc66242b6930e179f0bbdf121@DEWDFE13DE14.global.corp.sap>
 <ec35e180-114b-d2c0-c9ff-7ff17674898d@oracle.com>
 <13388daa72314ad6869c4235b71de083@DEWDFE13DE14.global.corp.sap>
 <026d9dec-a64a-bd98-d95f-7cce061819f5@oracle.com>
Message-ID: <c43c33272a8a4806a914e862c872105c@DEWDFE13DE14.global.corp.sap>

?  Fixing jexec is a separate issue and not really build related.

Yes that's true, I created a separate bug for this :

https://bugs.openjdk.java.net/browse/JDK-8175000

Regards, Matthias


From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
Sent: Dienstag, 14. Februar 2017 17:57
To: Baesken, Matthias <matthias.baesken at sap.com>; build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
Cc: Langer, Christoph <christoph.langer at sap.com>; Simonis, Volker <volker.simonis at sap.com>
Subject: Re: jdk10 : simplify jexec build settings


Hello,

Looks good to me.
Fixing jexec is a separate issue and not really build related.

/Erik
On 2017-02-14 17:27, Baesken, Matthias wrote:
Hello,  here is  the webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8174242/<http://cr.openjdk.java.net/%7Embaesken/webrevs/8174242/>

bug :

https://bugs.openjdk.java.net/browse/JDK-8174242


As discussed , I deleted the macosx   jexec.c    .


Btw. I found out  that   jexec  does not work (fully?)  in jdk8 / 9     ( seems  this has to do with the change  8156478: 3 Buffer overrun defect groups in jexec.c   )
Executing a         helloworld.jar  with  jexec   leads to
     "invalid file (bad magic number): Exec format error"  .

Should I open another bug for this ?

Best regards, Matthias



From: Baesken, Matthias
Sent: Freitag, 10. Februar 2017 13:19
To: 'Erik Joelsson' <erik.joelsson at oracle.com><mailto:erik.joelsson at oracle.com>; build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com><mailto:christoph.langer at sap.com>
Subject: RE: jdk10 : simplify jexec build settings

Hi Eric, thanks for the comment, I think I'll remove the macosx source file .
Btw. is there already some test  for jexec (a "fast grep" through the  jdk  tests did not show me much) ?

Best regards, Matthias



From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
Sent: Freitag, 10. Februar 2017 09:49
To: Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>; build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Subject: Re: jdk10 : simplify jexec build settings


Since the file has never been built, I would say remove the macosx source file. You can point directly to the unix source dir if you prefer too. No need to have dead logic for macosx in the makefile.

/Erik

On 2017-02-09 15:27, Baesken, Matthias wrote:
I compared the  jexec.c  versions for  macosx and unix

( jdk/src/java.base/macosx/native/launcher/jexec.c    and    jdk/src/java.base/unix/native/launcher/jexec.c )

And to me it looks like  the  unix version could be used for macosx too  (just in case there is a need to reenable the  build of jexec.c  for macosx one day again).

Comments / suggestions ?

Best regards, Matthias


From: Baesken, Matthias
Sent: Donnerstag, 9. Februar 2017 14:10
To: 'Erik Joelsson' <erik.joelsson at oracle.com><mailto:erik.joelsson at oracle.com>; build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>; 'core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>' <core-libs-dev at openjdk.java.net><mailto:core-libs-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com><mailto:christoph.langer at sap.com>
Subject: RE: jdk10 : simplify jexec build settings

Hello Erik, thanks for the comments .

>>Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) :
>
>This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think.

I include core-libs-dev , can someone comment on  jexec on macosx ?
Currently  jexec.c  is not compiled for macosx (jdk9/10), see  jdk/make/launcher/Launcher-java.base.gmk  .
It is just compiled on linux .

So I wonder -  is it ok to remove  the macosx handling  in the mentioned  makefile   jdk/make/launcher/Launcher-java.base.gmk   for  jexec ?

>This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name.
>Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time.

>From what I observe in the linux  build log,  just jexec.c  is  compiled into jexec.o and then this single object is used to create the executable ("program")  jexec.
Other src files are not used in the compilation of jexec, so  just using   $(JDK_TOPDIR)/src/$(MODULE)/unix/native/launcher   would be fine (as long as macosx can be dropped).



Best regards, Matthias


From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
Sent: Donnerstag, 9. Februar 2017 13:42
To: Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>; build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Subject: Re: jdk10 : simplify jexec build settings


Hello,

On 2017-02-09 12:36, Baesken, Matthias wrote:
Hello ,  while adjusting the jspawnhelper build settings with 8174086, it has been noticed that the jexec build settings need some simplification as well.

The bug

https://bugs.openjdk.java.net/browse/JDK-8174242

has been created for this.

When looking into it,  I had some questions :

http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/ae7afa9abe67/make/launcher/Launcher-java.base.gmk

The makefile  (make/launcher/Launcher-java.base.gmk )  handles Solaris 32bit,  but is this really  supported  in jdk 9 or 10  ( I think it was removed in 9 and only 64bit Solaris support remains ) ?
We do not support 32bit Solaris. The issue with jexec for Solaris was raised a while back and the conclusion was to scrap support, so no need to build it for Solaris at all.


ifeq ($(OPENJDK_TARGET_OS), solaris)
  ifeq ($(OPENJDK_TARGET_CPU_BITS), 32)
    BUILD_JEXEC := 1
  endif
endif

ifeq ($(OPENJDK_TARGET_OS), linux)
  BUILD_JEXEC := 1
endif # OPENJDK_TARGET_OS

#
# jdk/make/java/jexec/Makefile
#
ifeq ($(BUILD_JEXEC), 1)

Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) :
This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think.

The makefile logic shouldn't need to be that specific though. Our modern pattern for this is something like this:

SRC := $(call uniq, $(wildcard \
      $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS)/native/launcher \
      $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS_TYPE)/native/launcher \
      $(JDK_TOPDIR)/src/$(MODULE)/share/native/launcher))

This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name. Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time.

For libraries, we have abstracted this construct in the macro FindSrcDirForLib (LibCommon.gmk) but we haven't done the same for launchers yet.

/Erik



  ifeq ($(OPENJDK_TARGET_OS), windows)
  else ifeq ($(OPENJDK_TARGET_OS), macosx)
    BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/macosx/native/launcher
  else
    BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/unix/native/launcher
  endif

Should I remove  the solaris 32bit / macosx handling  for jexec  from   make/launcher/Launcher-java.base.gmk ?

Regards, Matthias








From roman.grigoriadi at oracle.com  Wed Feb 15 12:40:18 2017
From: roman.grigoriadi at oracle.com (Roman Grigoriadi)
Date: Wed, 15 Feb 2017 13:40:18 +0100
Subject: RFR: 8174735 Update JAX-WS RI integration to latest version
In-Reply-To: <195829C4-7072-42C5-ABBF-B522EEE85453@oracle.com>
References: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
 <195829C4-7072-42C5-ABBF-B522EEE85453@oracle.com>
Message-ID: <b4116abb-9a5e-ba70-5fbe-6e26dc6fbcad@oracle.com>

Hi Lance,

On 02/14/2017 09:28 PM, Lance Andersen wrote:
> Hi Roman,
>
> I made a pass through the changes.  And here are some general comments 
> which are mostly minor in nature?.
>
> HTH
>
> Best
> Lance
> ----------------------
> JAXBRIContext.java:
> - The comment ?If true, despite of the specification?.?;  This does 
> not read well can this be clarified?
We have changed it to:
* If true and element namespace is not specified, namespace of parent 
element will be used.
* The default value is false.
Hope this is acceptable.
>
> Generated.java, PostConstruct.java, PreDestroy.java,Resource.java
>          -  Be nice to use {@code} vs <code></code> for readability
>          -  Do you really need <p></p>?  I am assuming there are no 
> doclint errors on Generated?
>          - Was there a CCC for the changes as there were some minor 
> semantic updates
These are from JSR 250 we don't own sources.
>
>
> MimeMultipart.java.:
>        - createMimeBodyPart @param len does not align properly
>
> SharedInputStream.java
>        - writeTo @param out does not align
>
> NameImpl.java
>        -  Some comments have a blank line before the params, others do 
> not.  It would be nice to be consistent
fixed
>
> ParserPool.java
>        - Can you explain the status regarding returnParser() and 
> https://jaxp.dev.java.net/issues/show_bug.cgi?id=59
removed //TODO and commented method, Aleksej will provide patch for 
resetting symbol table on parser.reset()
> SAAJUtil.java
>        - getSystemClassLoader, do you really need to check for a 
> SecurityManager?  Why not just AccessController.doPrivilege(could also 
> use a lambda also)
Removed SecurityManager check, lambda cannot be used without utilizing 
multirelease-jar for saaj, our min supported version is 1.7
>
> MethodUtil.java
>        - Looks like the alignment is off in the changes in invoke
There are 5 of them in the sync. I reformatted new ones. Can't see any 
wrong indentation in updated ones. Also fixed package in some comments/logs.
>
> ContextClassloaderLocal.java
>         -  getContextClassLoader could be changed to use a lambda with 
> AccessController.doPrivilege if you desire
>
> FactoryFinder.java
>        - getSystemProperty, it looks like you were using a lambda and 
> removed it for the AccessController.doPrivilege?
both no lambda for min target 1.7
>
> SecureLoader.java
>       - same comment as SAAJUtil.java
I don't know the reason why SecurityManager presence check is present 
there. Maybe performance? But there are 14 copies of SecureLoader class 
in JAXB, if we do remove unnecessary check we should replace all of 
them. Lets postpone it.
> NGCCRuntimeEx.java
>       - copyLocater, createValidationContext @return comment needs 
> checked
fixed
>
> package-info.java
>       - Seem the new files include a 2003/2004/1997, 2017, copyright, 
> should just be 2017 i believe
fixed

we are working on a new webrev, hopefully will post it later today.

Roman


>
>> On Feb 14, 2017, at 7:00 AM, Roman Grigoriadi 
>> <roman.grigoriadi at oracle.com <mailto:roman.grigoriadi at oracle.com>> wrote:
>>
>> Hi,
>>
>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8174735
>> Webrev: 
>> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/00/ 
>> <http://cr.openjdk.java.net/%7Eaefimov/jaxws-integrations/8174735/00/>
>>
>> You can find change list in the description of JBS and its linked 
>> issues. Most diffs are for SAAJ-RI related to JDK-8166745 - remove 
>> dependencies on jdks Xerces internal classes.
>>
>> Thanks,
>> Roman
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>
>
>
>


From roman.grigoriadi at oracle.com  Wed Feb 15 12:42:22 2017
From: roman.grigoriadi at oracle.com (Roman Grigoriadi)
Date: Wed, 15 Feb 2017 13:42:22 +0100
Subject: RFR: 8174735 Update JAX-WS RI integration to latest version
In-Reply-To: <DF61C6F3-48D0-4EB1-A93D-C09F523D2FB4@oracle.com>
References: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
 <DF61C6F3-48D0-4EB1-A93D-C09F523D2FB4@oracle.com>
Message-ID: <e606f4b8-962a-d321-6f8c-726993117704@oracle.com>

Hi Mandy,

On 02/14/2017 11:53 PM, Mandy Chung wrote:
>> On Feb 14, 2017, at 4:00 AM, Roman Grigoriadi <roman.grigoriadi at oracle.com> wrote:
>>
>> Hi,
>>
>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8174735
>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/00/
>
> jaxws/src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java
>
> -    /** JAXWS module name. JAXWS dependency is mandatory in generated Java module. */
> -    private static final String JAXWS_MODULE = "java.xml.ws";
> +    /** JAXB module name. JAXB dependency is mandatory in generated Java module. */
> +    private static final String JAXWS_PACKAGE = "java.xml.ws?;
this looks to be merge failure on our side, will fix it again.
>
> JAXWS_MODULE is the right name as we discussed in the last JAX-WS integration to jdk9. This change should be reverted and the upstream project  should be fixed.
>
> +                    if ("-release".equals(opt) && 9 >= getVersion(javacOptions.get(i + 1))) {
thanks, will be fixed to --release
>
> javac supports `?-release` (double dashes, GNU long form style) but not the single dash option.  Is this new option in wsimport and wsgen tools?  It should probably be consistent with javac.
>
> You can run jdeps ?-check java.base,java.xml option to double check if any remaining qualified exports to these modules.
>
> Otherwise looks okay.
>
> Mandy
>


From roman.grigoriadi at oracle.com  Wed Feb 15 13:36:57 2017
From: roman.grigoriadi at oracle.com (Roman Grigoriadi)
Date: Wed, 15 Feb 2017 14:36:57 +0100
Subject: RFR: 8174735 Update JAX-WS RI integration to latest version
In-Reply-To: <b4116abb-9a5e-ba70-5fbe-6e26dc6fbcad@oracle.com>
References: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
 <195829C4-7072-42C5-ABBF-B522EEE85453@oracle.com>
 <b4116abb-9a5e-ba70-5fbe-6e26dc6fbcad@oracle.com>
Message-ID: <6e59a636-1838-923e-35b4-96697013333c@oracle.com>

Adding Lukas


On 02/15/2017 01:40 PM, Roman Grigoriadi wrote:
>
> Hi Lance,
>
> On 02/14/2017 09:28 PM, Lance Andersen wrote:
>> Hi Roman,
>>
>> I made a pass through the changes.  And here are some general 
>> comments which are mostly minor in nature?.
>>
>> HTH
>>
>> Best
>> Lance
>> ----------------------
>> JAXBRIContext.java:
>> - The comment ?If true, despite of the specification?.?;  This does 
>> not read well can this be clarified?
> We have changed it to:
> * If true and element namespace is not specified, namespace of parent 
> element will be used.
> * The default value is false.
> Hope this is acceptable.
>>
>> Generated.java, PostConstruct.java, PreDestroy.java,Resource.java
>>          -  Be nice to use {@code} vs <code></code> for readability
>>          -  Do you really need <p></p>?  I am assuming there are no 
>> doclint errors on Generated?
>>          - Was there a CCC for the changes as there were some minor 
>> semantic updates
> These are from JSR 250 we don't own sources.
>>
>>
>> MimeMultipart.java.:
>>        - createMimeBodyPart @param len does not align properly
>>
>> SharedInputStream.java
>>        - writeTo @param out does not align
>>
>> NameImpl.java
>>        -  Some comments have a blank line before the params, others 
>> do not.  It would be nice to be consistent
> fixed
>>
>> ParserPool.java
>>        - Can you explain the status regarding returnParser() and 
>> https://jaxp.dev.java.net/issues/show_bug.cgi?id=59
> removed //TODO and commented method, Aleksej will provide patch for 
> resetting symbol table on parser.reset()
>> SAAJUtil.java
>>        - getSystemClassLoader, do you really need to check for a 
>> SecurityManager?  Why not just AccessController.doPrivilege(could 
>> also use a lambda also)
> Removed SecurityManager check, lambda cannot be used without utilizing 
> multirelease-jar for saaj, our min supported version is 1.7
>>
>> MethodUtil.java
>>        - Looks like the alignment is off in the changes in invoke
> There are 5 of them in the sync. I reformatted new ones. Can't see any 
> wrong indentation in updated ones. Also fixed package in some 
> comments/logs.
>>
>> ContextClassloaderLocal.java
>>         -  getContextClassLoader could be changed to use a lambda 
>> with AccessController.doPrivilege if you desire
>>
>> FactoryFinder.java
>>        - getSystemProperty, it looks like you were using a lambda and 
>> removed it for the AccessController.doPrivilege?
> both no lambda for min target 1.7
>>
>> SecureLoader.java
>>       - same comment as SAAJUtil.java
> I don't know the reason why SecurityManager presence check is present 
> there. Maybe performance? But there are 14 copies of SecureLoader 
> class in JAXB, if we do remove unnecessary check we should replace all 
> of them. Lets postpone it.
>> NGCCRuntimeEx.java
>>       - copyLocater, createValidationContext @return comment needs 
>> checked
> fixed
>>
>> package-info.java
>>       - Seem the new files include a 2003/2004/1997, 2017, copyright, 
>> should just be 2017 i believe
> fixed
>
> we are working on a new webrev, hopefully will post it later today.
>
> Roman
>
>
>>
>>> On Feb 14, 2017, at 7:00 AM, Roman Grigoriadi 
>>> <roman.grigoriadi at oracle.com <mailto:roman.grigoriadi at oracle.com>> 
>>> wrote:
>>>
>>> Hi,
>>>
>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8174735
>>> Webrev: 
>>> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/00/ 
>>> <http://cr.openjdk.java.net/%7Eaefimov/jaxws-integrations/8174735/00/>
>>>
>>> You can find change list in the description of JBS and its linked 
>>> issues. Most diffs are for SAAJ-RI related to JDK-8166745 - remove 
>>> dependencies on jdks Xerces internal classes.
>>>
>>> Thanks,
>>> Roman
>>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>
>>
>>
>>
>


From lukas.jungmann at oracle.com  Wed Feb 15 13:58:23 2017
From: lukas.jungmann at oracle.com (Lukas Jungmann)
Date: Wed, 15 Feb 2017 14:58:23 +0100
Subject: RFR: 8174735 Update JAX-WS RI integration to latest version
In-Reply-To: <6e59a636-1838-923e-35b4-96697013333c@oracle.com>
References: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
 <195829C4-7072-42C5-ABBF-B522EEE85453@oracle.com>
 <b4116abb-9a5e-ba70-5fbe-6e26dc6fbcad@oracle.com>
 <6e59a636-1838-923e-35b4-96697013333c@oracle.com>
Message-ID: <d847c97a-5757-32cd-2329-057c1841acb9@oracle.com>

Hi,

comments wrt JSR-250 inline, also adding Linda who maintains it these 
days to the loop

On 2/15/17 2:36 PM, Roman Grigoriadi wrote:
>
> Adding Lukas
>
>
> On 02/15/2017 01:40 PM, Roman Grigoriadi wrote:
>>
>> Hi Lance,
>>
>> On 02/14/2017 09:28 PM, Lance Andersen wrote:
>>> Hi Roman,
>>>
>>> I made a pass through the changes.  And here are some general 
>>> comments which are mostly minor in nature?.
>>>
>>> HTH
>>>
>>> Best
>>> Lance
>>> ----------------------
>>> JAXBRIContext.java:
>>> - The comment ?If true, despite of the specification?.?;  This does 
>>> not read well can this be clarified?
>> We have changed it to:
>> * If true and element namespace is not specified, namespace of parent 
>> element will be used.
>> * The default value is false.
>> Hope this is acceptable.
>>>
>>> Generated.java, PostConstruct.java, PreDestroy.java,Resource.java
>>>          -  Be nice to use {@code} vs <code></code> for readability
>>>          -  Do you really need <p></p>?  I am assuming there are no 
>>> doclint errors on Generated?
>>>          - Was there a CCC for the changes as there were some minor 
>>> semantic updates
>> These are from JSR 250 we don't own sources.

for the first two points - this is up to Linda, we - in JAX-WS are just 
consuming what JSR-250 provides, filtering out what is not needed and 
delivering the result into JDK; it does not make much sense for us to 
'alter' what we get (in terms of explicit code edits) ...

as for CCC - good question. Since there is no change in what has been 
delivered to JDK since its version 6, I believe that that was done in 
the past. All I know about 'CCC' is that in our sources I can see 
Miran's comment from 2013 'CCC would be created to include this into 
JDK?' related to the explicit exclusion of @javax.annotation.Priority 
from jsr-250.jar during jdk integration part. Do we have to go through 
'CCC' (whatever does it mean) even because of mostly javadoc related 
changes? If so, would it be possible to consider adding additional 
content into what's delivered into JDK? I've heard some comments that 
@Priority in particular would be quite useful for frameworks...

thanks,
--lukas

>>>
>>>
>>> MimeMultipart.java.:
>>>        - createMimeBodyPart @param len does not align properly
>>>
>>> SharedInputStream.java
>>>        - writeTo @param out does not align
>>>
>>> NameImpl.java
>>>        -  Some comments have a blank line before the params, others 
>>> do not.  It would be nice to be consistent
>> fixed
>>>
>>> ParserPool.java
>>>        - Can you explain the status regarding returnParser() and 
>>> https://jaxp.dev.java.net/issues/show_bug.cgi?id=59
>> removed //TODO and commented method, Aleksej will provide patch for 
>> resetting symbol table on parser.reset()
>>> SAAJUtil.java
>>>        - getSystemClassLoader, do you really need to check for a 
>>> SecurityManager?  Why not just AccessController.doPrivilege(could 
>>> also use a lambda also)
>> Removed SecurityManager check, lambda cannot be used without 
>> utilizing multirelease-jar for saaj, our min supported version is 1.7
>>>
>>> MethodUtil.java
>>>        - Looks like the alignment is off in the changes in invoke
>> There are 5 of them in the sync. I reformatted new ones. Can't see 
>> any wrong indentation in updated ones. Also fixed package in some 
>> comments/logs.
>>>
>>> ContextClassloaderLocal.java
>>>         -  getContextClassLoader could be changed to use a lambda 
>>> with AccessController.doPrivilege if you desire
>>>
>>> FactoryFinder.java
>>>        - getSystemProperty, it looks like you were using a lambda 
>>> and removed it for the AccessController.doPrivilege?
>> both no lambda for min target 1.7
>>>
>>> SecureLoader.java
>>>       - same comment as SAAJUtil.java
>> I don't know the reason why SecurityManager presence check is present 
>> there. Maybe performance? But there are 14 copies of SecureLoader 
>> class in JAXB, if we do remove unnecessary check we should replace 
>> all of them. Lets postpone it.
>>> NGCCRuntimeEx.java
>>>       - copyLocater, createValidationContext @return comment needs 
>>> checked
>> fixed
>>>
>>> package-info.java
>>>       - Seem the new files include a 2003/2004/1997, 2017, 
>>> copyright, should just be 2017 i believe
>> fixed
>>
>> we are working on a new webrev, hopefully will post it later today.
>>
>> Roman
>>
>>
>>>
>>>> On Feb 14, 2017, at 7:00 AM, Roman Grigoriadi 
>>>> <roman.grigoriadi at oracle.com <mailto:roman.grigoriadi at oracle.com>> 
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8174735
>>>> Webrev: 
>>>> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/00/ 
>>>> <http://cr.openjdk.java.net/%7Eaefimov/jaxws-integrations/8174735/00/>
>>>>
>>>> You can find change list in the description of JBS and its linked 
>>>> issues. Most diffs are for SAAJ-RI related to JDK-8166745 - remove 
>>>> dependencies on jdks Xerces internal classes.
>>>>
>>>> Thanks,
>>>> Roman
>>>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>
>>>
>>>
>>>
>>
>


From mark.sheppard at oracle.com  Wed Feb 15 14:21:24 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 15 Feb 2017 14:21:24 +0000
Subject: RFR: JDK-8146299 - Disable rmic -Xnew
Message-ID: <86ab8e07-5bdd-4c48-e307-c6dd5f5129cb@oracle.com>

Hi
   please oblige and review the following change:
http://cr.openjdk.java.net/~msheppar/8146299-II/webrev.03/

to address the issue:
https://bugs.openjdk.java.net/browse/JDK-8146299

which is to disables a currently undocumented, and unsupported feature 
in rmic

* the parsing of the commandline option -Xnew is commented out
* a set of tests are disabled using the @ignore tag
* the ProblemList.txt is amended accordingly

regards
Mark

From chris.hegarty at oracle.com  Wed Feb 15 15:05:33 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 15 Feb 2017 15:05:33 +0000
Subject: RFR: JDK-8146299 - Disable rmic -Xnew
In-Reply-To: <86ab8e07-5bdd-4c48-e307-c6dd5f5129cb@oracle.com>
References: <86ab8e07-5bdd-4c48-e307-c6dd5f5129cb@oracle.com>
Message-ID: <01629505-09E9-4B4B-B05D-F2700E524EA9@oracle.com>


> On 15 Feb 2017, at 14:21, Mark Sheppard <mark.sheppard at oracle.com> wrote:
> 
> Hi
>  please oblige and review the following change:
> http://cr.openjdk.java.net/~msheppar/8146299-II/webrev.03/

This looks good to me Mark.

-Chris.

> to address the issue:
> https://bugs.openjdk.java.net/browse/JDK-8146299
> 
> which is to disables a currently undocumented, and unsupported feature in rmic
> 
> * the parsing of the commandline option -Xnew is commented out
> * a set of tests are disabled using the @ignore tag
> * the ProblemList.txt is amended accordingly
> 
> regards
> Mark


From mark.sheppard at oracle.com  Wed Feb 15 15:15:07 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 15 Feb 2017 15:15:07 +0000
Subject: RFR: JDK-8146299 - Disable rmic -Xnew
In-Reply-To: <01629505-09E9-4B4B-B05D-F2700E524EA9@oracle.com>
References: <86ab8e07-5bdd-4c48-e307-c6dd5f5129cb@oracle.com>
 <01629505-09E9-4B4B-B05D-F2700E524EA9@oracle.com>
Message-ID: <3ccd25e0-7f21-cf0a-d199-be7eca576329@oracle.com>

thanks Chris


On 15/02/2017 15:05, Chris Hegarty wrote:
>> On 15 Feb 2017, at 14:21, Mark Sheppard <mark.sheppard at oracle.com> wrote:
>>
>> Hi
>>   please oblige and review the following change:
>> http://cr.openjdk.java.net/~msheppar/8146299-II/webrev.03/
> This looks good to me Mark.
>
> -Chris.
>
>> to address the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8146299
>>
>> which is to disables a currently undocumented, and unsupported feature in rmic
>>
>> * the parsing of the commandline option -Xnew is commented out
>> * a set of tests are disabled using the @ignore tag
>> * the ProblemList.txt is amended accordingly
>>
>> regards
>> Mark


From Roger.Riggs at Oracle.com  Wed Feb 15 15:35:24 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 15 Feb 2017 10:35:24 -0500
Subject: RFR: JDK-8146299 - Disable rmic -Xnew
In-Reply-To: <86ab8e07-5bdd-4c48-e307-c6dd5f5129cb@oracle.com>
References: <86ab8e07-5bdd-4c48-e307-c6dd5f5129cb@oracle.com>
Message-ID: <c234752f-f7ff-59bd-fdd3-7978a4c40e28@Oracle.com>

Looks good Mark,

Thanks, Roger

p.s.  There is a more recent version of webrev.ksh that includes 
convenient next and previous links.

http://hg.openjdk.java.net/code-tools/webrev/raw-file/d26c194772db/webrev.ksh

On 2/15/2017 9:21 AM, Mark Sheppard wrote:
> Hi
>   please oblige and review the following change:
> http://cr.openjdk.java.net/~msheppar/8146299-II/webrev.03/
>
> to address the issue:
> https://bugs.openjdk.java.net/browse/JDK-8146299
>
> which is to disables a currently undocumented, and unsupported feature 
> in rmic
>
> * the parsing of the commandline option -Xnew is commented out
> * a set of tests are disabled using the @ignore tag
> * the ProblemList.txt is amended accordingly
>
> regards
> Mark


From mark.sheppard at oracle.com  Wed Feb 15 15:50:28 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 15 Feb 2017 15:50:28 +0000
Subject: RFR: JDK-8146299 - Disable rmic -Xnew
In-Reply-To: <c234752f-f7ff-59bd-fdd3-7978a4c40e28@Oracle.com>
References: <86ab8e07-5bdd-4c48-e307-c6dd5f5129cb@oracle.com>
 <c234752f-f7ff-59bd-fdd3-7978a4c40e28@Oracle.com>
Message-ID: <387f3e26-fada-cfb1-f36c-1d8c46a6b79a@oracle.com>

thanks Roger

On 15/02/2017 15:35, Roger Riggs wrote:
> Looks good Mark,
>
> Thanks, Roger
>
> p.s.  There is a more recent version of webrev.ksh that includes 
> convenient next and previous links.
>
> http://hg.openjdk.java.net/code-tools/webrev/raw-file/d26c194772db/webrev.ksh 
>
>
> On 2/15/2017 9:21 AM, Mark Sheppard wrote:
>> Hi
>>   please oblige and review the following change:
>> http://cr.openjdk.java.net/~msheppar/8146299-II/webrev.03/
>>
>> to address the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8146299
>>
>> which is to disables a currently undocumented, and unsupported 
>> feature in rmic
>>
>> * the parsing of the commandline option -Xnew is commented out
>> * a set of tests are disabled using the @ignore tag
>> * the ProblemList.txt is amended accordingly
>>
>> regards
>> Mark
>


From aleksej.efimov at oracle.com  Wed Feb 15 16:31:47 2017
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Wed, 15 Feb 2017 19:31:47 +0300
Subject: [9] RFR: 8173390: Investigate SymbolTable in SAXParser
Message-ID: <f7f9d1ff-1e70-1716-893c-c840d45d8f99@oracle.com>

Hi,

Please, help to review the change required by JAXWS-RI code [1]: 
SAXParser needs to reset internal SymbolTable to enable pooling of 
parsers in SAAJ-RI code. Latest version of JAXWS-RI code (that is 
currently under review [2]) doesn't provide a workaround to reset the 
symbol table (it was done to remove module dependency on Xerces internal 
classes). So the solution is to reset the SymbolTable during SAXParser 
reset. The webrev with the changes and simple test that reproduces 
SAAJ-RI behavior:
     http://cr.openjdk.java.net/~aefimov/8173390/9/00/

The fix was tested with all JDK/JCK (JAX[P|B|WS] related tests. No 
failures observed.


Thank you,
Aleksej

[1] https://bugs.openjdk.java.net/browse/JDK-8173390
[2] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-February/046386.html


From vicente.romero at oracle.com  Wed Feb 15 17:03:08 2017
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 15 Feb 2017 12:03:08 -0500
Subject: Review Request: JDK-8174694: improve error message shown when main
 class can't be loaded
Message-ID: <f372ccaf-fa6b-2c26-d3fb-5da7e17a207d@oracle.com>

Hi,

Please review the fix for bug [1]. The fix is improving an already 
existing error message. The public patch can be reached at [2]

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8174694
[2] http://cr.openjdk.java.net/~vromero/8174694/webrev.00/jdk.patch

From Alan.Bateman at oracle.com  Wed Feb 15 17:12:38 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 15 Feb 2017 17:12:38 +0000
Subject: Review Request: JDK-8174694: improve error message shown when
 main class can't be loaded
In-Reply-To: <f372ccaf-fa6b-2c26-d3fb-5da7e17a207d@oracle.com>
References: <f372ccaf-fa6b-2c26-d3fb-5da7e17a207d@oracle.com>
Message-ID: <f3cf0c39-0aad-50bd-eeeb-3a13072bae00@oracle.com>

On 15/02/2017 17:03, Vicente Romero wrote:

> Hi,
>
> Please review the fix for bug [1]. The fix is improving an already 
> existing error message. The public patch can be reached at [2]
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8174694
> [2] http://cr.openjdk.java.net/~vromero/8174694/webrev.00/jdk.patch
Can you provide one or two examples to see the difference? I ask because 
it looks like "was not found" is changed to "is not defined" which looks 
a bit odd.

-Alan

From huizhe.wang at oracle.com  Wed Feb 15 17:16:34 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 15 Feb 2017 09:16:34 -0800
Subject: [9] RFR: 8173390: Investigate SymbolTable in SAXParser
In-Reply-To: <f7f9d1ff-1e70-1716-893c-c840d45d8f99@oracle.com>
References: <f7f9d1ff-1e70-1716-893c-c840d45d8f99@oracle.com>
Message-ID: <690391de-2b61-ecb8-a17f-1d333642e0b7@oracle.com>

Hi Aleksej,

I just realized there were other dependencies on the SymbolTable 
instance initialized in the constructor (line 575 in your new code), 
which was probably why you kept the code from 574 through 579 after 
adding new SymbolTable for each parsing process (850 - 854). As a 
result, the SymbolTable will be created twice for the first parsing 
process. One way to solve the issue is to check whether the SymbolTable 
instance is new, or otherwise adding a reset function would work as 
well. In both cases, there will be a bit change to the SymbolTable to 
expose the count. What would you think?

Thanks,
Joe

On 2/15/2017 8:31 AM, Aleks Efimov wrote:
> Hi,
>
> Please, help to review the change required by JAXWS-RI code [1]: 
> SAXParser needs to reset internal SymbolTable to enable pooling of 
> parsers in SAAJ-RI code. Latest version of JAXWS-RI code (that is 
> currently under review [2]) doesn't provide a workaround to reset the 
> symbol table (it was done to remove module dependency on Xerces 
> internal classes). So the solution is to reset the SymbolTable during 
> SAXParser reset. The webrev with the changes and simple test that 
> reproduces SAAJ-RI behavior:
>     http://cr.openjdk.java.net/~aefimov/8173390/9/00/
>
> The fix was tested with all JDK/JCK (JAX[P|B|WS] related tests. No 
> failures observed.
>
>
> Thank you,
> Aleksej
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8173390
> [2] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-February/046386.html
>


From mandy.chung at oracle.com  Wed Feb 15 17:18:38 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 15 Feb 2017 09:18:38 -0800
Subject: RFR: JDK-8146299 - Disable rmic -Xnew
In-Reply-To: <86ab8e07-5bdd-4c48-e307-c6dd5f5129cb@oracle.com>
References: <86ab8e07-5bdd-4c48-e307-c6dd5f5129cb@oracle.com>
Message-ID: <502AF6C1-DF45-4ABE-A0F5-1E694D45975D@oracle.com>


> On Feb 15, 2017, at 6:21 AM, Mark Sheppard <mark.sheppard at oracle.com> wrote:
> 
> Hi
>  please oblige and review the following change:
> http://cr.openjdk.java.net/~msheppar/8146299-II/webrev.03/

Looks okay.

For the test, can you move @ignore to the top after @test which makes it easier to tell this test is ignored.

It?d be good to have the bug number after @ignore like this:
  @ignore 8145980 and 8146299 until further discussion on the rmic -Xnew feature

Mandy

From vicente.romero at oracle.com  Wed Feb 15 17:21:39 2017
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 15 Feb 2017 12:21:39 -0500
Subject: Review Request: JDK-8174694: improve error message shown when
 main class can't be loaded
In-Reply-To: <f3cf0c39-0aad-50bd-eeeb-3a13072bae00@oracle.com>
References: <f372ccaf-fa6b-2c26-d3fb-5da7e17a207d@oracle.com>
 <f3cf0c39-0aad-50bd-eeeb-3a13072bae00@oracle.com>
Message-ID: <8b74af6e-96e8-2c42-3ed6-d85242a3ca6e@oracle.com>

The simplest reproductor for this issue is:

------------------------------------------------------------------------------------------------ 

public class A extends B {
     public static void main(String... args) {}
}
------------------------------------------------------------------------------------------------ 

class B {}
------------------------------------------------------------------------------------------------ 


$javac -d out A.java B.java
$rm out/B.class

before this patch this command:
$java -cp out A

produces this output
Error: Could not find or load main class A

with the current patch, the output produced is:
Error: Could not find or load main class A
because class B is not defined.

if while loading the main class ClassNotFoundException is produced then 
the second part of the message will be: "because class Foo is not defined."
if NoClassDefFoundError is produced then it will be: "because class Foo 
is not defined"

Thanks,
Vicente

On 02/15/2017 12:12 PM, Alan Bateman wrote:
> On 15/02/2017 17:03, Vicente Romero wrote:
>
>> Hi,
>>
>> Please review the fix for bug [1]. The fix is improving an already 
>> existing error message. The public patch can be reached at [2]
>>
>> Thanks,
>> Vicente
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8174694
>> [2] http://cr.openjdk.java.net/~vromero/8174694/webrev.00/jdk.patch
> Can you provide one or two examples to see the difference? I ask 
> because it looks like "was not found" is changed to "is not defined" 
> which looks a bit odd.
>
> -Alan


From daniel.fuchs at oracle.com  Wed Feb 15 17:37:57 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 15 Feb 2017 17:37:57 +0000
Subject: [9] RFR: 8173390: Investigate SymbolTable in SAXParser
In-Reply-To: <f7f9d1ff-1e70-1716-893c-c840d45d8f99@oracle.com>
References: <f7f9d1ff-1e70-1716-893c-c840d45d8f99@oracle.com>
Message-ID: <d692b060-d433-654b-be3b-44690ec2dcf6@oracle.com>

Hi Aleksej,

In the test:

   75         Assert.assertNotEquals(symTable1, symTable2, "Symbol table 
refence is the same");

I guess you meant Assert.assertNotSame - if what you want to do
is compare references.
(+ there is a typo in the message: refence => reference)

best regards,

-- daniel

On 15/02/17 16:31, Aleks Efimov wrote:
> Hi,
>
> Please, help to review the change required by JAXWS-RI code [1]:
> SAXParser needs to reset internal SymbolTable to enable pooling of
> parsers in SAAJ-RI code. Latest version of JAXWS-RI code (that is
> currently under review [2]) doesn't provide a workaround to reset the
> symbol table (it was done to remove module dependency on Xerces internal
> classes). So the solution is to reset the SymbolTable during SAXParser
> reset. The webrev with the changes and simple test that reproduces
> SAAJ-RI behavior:
>     http://cr.openjdk.java.net/~aefimov/8173390/9/00/
>
> The fix was tested with all JDK/JCK (JAX[P|B|WS] related tests. No
> failures observed.
>
>
> Thank you,
> Aleksej
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8173390
> [2]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-February/046386.html
>
>


From Alan.Bateman at oracle.com  Wed Feb 15 18:39:03 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 15 Feb 2017 18:39:03 +0000
Subject: Review Request: JDK-8174694: improve error message shown when
 main class can't be loaded
In-Reply-To: <8b74af6e-96e8-2c42-3ed6-d85242a3ca6e@oracle.com>
References: <f372ccaf-fa6b-2c26-d3fb-5da7e17a207d@oracle.com>
 <f3cf0c39-0aad-50bd-eeeb-3a13072bae00@oracle.com>
 <8b74af6e-96e8-2c42-3ed6-d85242a3ca6e@oracle.com>
Message-ID: <d5bae7ca-fa95-a92e-a347-4b3ae09af876@oracle.com>

On 15/02/2017 17:21, Vicente Romero wrote:

> The simplest reproductor for this issue is:
>
> ------------------------------------------------------------------------------------------------ 
>
> public class A extends B {
>     public static void main(String... args) {}
> }
> ------------------------------------------------------------------------------------------------ 
>
> class B {}
> ------------------------------------------------------------------------------------------------ 
>
>
> $javac -d out A.java B.java
> $rm out/B.class
>
> before this patch this command:
> $java -cp out A
>
> produces this output
> Error: Could not find or load main class A
>
> with the current patch, the output produced is:
> Error: Could not find or load main class A
> because class B is not defined.
>
> if while loading the main class ClassNotFoundException is produced 
> then the second part of the message will be: "because class Foo is not 
> defined."
> if NoClassDefFoundError is produced then it will be: "because class 
> Foo is not defined"
It's good that "B" is shown in the output but "because class B is not 
defined" looks very strange to me. Have you consider something more 
useful like:

Error: Could not find or load main class A
Caused by: java.lang.NoClassDefFoundError: B

-Alan



From stuart.marks at oracle.com  Wed Feb 15 18:57:56 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 15 Feb 2017 10:57:56 -0800
Subject: RFR: JDK-8146299 - Disable rmic -Xnew
In-Reply-To: <502AF6C1-DF45-4ABE-A0F5-1E694D45975D@oracle.com>
References: <86ab8e07-5bdd-4c48-e307-c6dd5f5129cb@oracle.com>
 <502AF6C1-DF45-4ABE-A0F5-1E694D45975D@oracle.com>
Message-ID: <20990ac0-ef3e-cf98-86db-b19f1b2e7927@oracle.com>



On 2/15/17 9:18 AM, Mandy Chung wrote:
>> On Feb 15, 2017, at 6:21 AM, Mark Sheppard <mark.sheppard at oracle.com> wrote:
>>  please oblige and review the following change:
>> http://cr.openjdk.java.net/~msheppar/8146299-II/webrev.03/
>
> For the test, can you move @ignore to the top after @test which makes it easier to tell this test is ignored.

Hi Mandy,

When Mark sent this for a preliminary review internally I had asked him to move 
the @ignore tag after the @library tag. I was prompted to do this because, when 
jtreg is run without the -ignore:quiet tag, the result is

TEST RESULT: Error. Parse Exception: `@library' must appear before first action tag

and oddly enough, @ignore is an action tag. But it seems like all of our test 
runs specify -ignore:quiet, which accepts @ignore pretty much anywhere, and 
other tests that use @ignore pretty much place it anywhere. So it's pretty much 
useless to run jtreg with anything other than -ignore:quiet.

Mark, I'd suggest following Mandy's advice to put @ignore right after @test, and 
to disregard what I had told you previously. Sorry for the confusion.

s'marks

From kumar.x.srinivasan at oracle.com  Wed Feb 15 19:06:44 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 15 Feb 2017 11:06:44 -0800
Subject: Review Request: JDK-8174694: improve error message shown when
 main class can't be loaded
In-Reply-To: <d5bae7ca-fa95-a92e-a347-4b3ae09af876@oracle.com>
References: <f372ccaf-fa6b-2c26-d3fb-5da7e17a207d@oracle.com>
 <f3cf0c39-0aad-50bd-eeeb-3a13072bae00@oracle.com>
 <8b74af6e-96e8-2c42-3ed6-d85242a3ca6e@oracle.com>
 <d5bae7ca-fa95-a92e-a347-4b3ae09af876@oracle.com>
Message-ID: <58A4A6C4.4070501@oracle.com>


On 2/15/2017 10:39 AM, Alan Bateman wrote:
> On 15/02/2017 17:21, Vicente Romero wrote:
>
>> The simplest reproductor for this issue is:
>>
>> ------------------------------------------------------------------------------------------------ 
>>
>> public class A extends B {
>>     public static void main(String... args) {}
>> }
>> ------------------------------------------------------------------------------------------------ 
>>
>> class B {}
>> ------------------------------------------------------------------------------------------------ 
>>
>>
>> $javac -d out A.java B.java
>> $rm out/B.class
>>
>> before this patch this command:
>> $java -cp out A
>>
>> produces this output
>> Error: Could not find or load main class A
>>
>> with the current patch, the output produced is:
>> Error: Could not find or load main class A
>> because class B is not defined.
>>
>> if while loading the main class ClassNotFoundException is produced 
>> then the second part of the message will be: "because class Foo is 
>> not defined."
>> if NoClassDefFoundError is produced then it will be: "because class 
>> Foo is not defined"
> It's good that "B" is shown in the output but "because class B is not 
> defined" looks very strange to me. Have you consider something more 
> useful like:
>
> Error: Could not find or load main class A
> Caused by: java.lang.NoClassDefFoundError: B

Yes this will also solve the translation issue thus we can go back to
one property.

Kumar

>
> -Alan
>
>


From vicente.romero at oracle.com  Wed Feb 15 20:41:39 2017
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 15 Feb 2017 15:41:39 -0500
Subject: Review Request: JDK-8174694: improve error message shown when
 main class can't be loaded
In-Reply-To: <58A4A6C4.4070501@oracle.com>
References: <f372ccaf-fa6b-2c26-d3fb-5da7e17a207d@oracle.com>
 <f3cf0c39-0aad-50bd-eeeb-3a13072bae00@oracle.com>
 <8b74af6e-96e8-2c42-3ed6-d85242a3ca6e@oracle.com>
 <d5bae7ca-fa95-a92e-a347-4b3ae09af876@oracle.com>
 <58A4A6C4.4070501@oracle.com>
Message-ID: <bb48defd-4a19-b901-f8ae-14e544eeaa32@oracle.com>

Hi,

Thanks guys for your comments. I have uploaded another iteration of the 
review at [1],

Vicente

[1] http://cr.openjdk.java.net/~vromero/8174694/webrev.01/jdk.patch

On 02/15/2017 02:06 PM, Kumar Srinivasan wrote:
>
> On 2/15/2017 10:39 AM, Alan Bateman wrote:
>> On 15/02/2017 17:21, Vicente Romero wrote:
>>
>>> The simplest reproductor for this issue is:
>>>
>>> ------------------------------------------------------------------------------------------------ 
>>>
>>> public class A extends B {
>>>     public static void main(String... args) {}
>>> }
>>> ------------------------------------------------------------------------------------------------ 
>>>
>>> class B {}
>>> ------------------------------------------------------------------------------------------------ 
>>>
>>>
>>> $javac -d out A.java B.java
>>> $rm out/B.class
>>>
>>> before this patch this command:
>>> $java -cp out A
>>>
>>> produces this output
>>> Error: Could not find or load main class A
>>>
>>> with the current patch, the output produced is:
>>> Error: Could not find or load main class A
>>> because class B is not defined.
>>>
>>> if while loading the main class ClassNotFoundException is produced 
>>> then the second part of the message will be: "because class Foo is 
>>> not defined."
>>> if NoClassDefFoundError is produced then it will be: "because class 
>>> Foo is not defined"
>> It's good that "B" is shown in the output but "because class B is not 
>> defined" looks very strange to me. Have you consider something more 
>> useful like:
>>
>> Error: Could not find or load main class A
>> Caused by: java.lang.NoClassDefFoundError: B
>
> Yes this will also solve the translation issue thus we can go back to
> one property.
>
> Kumar
>
>>
>> -Alan
>>
>>
>


From brian.burkhalter at oracle.com  Wed Feb 15 21:04:16 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 15 Feb 2017 13:04:16 -0800
Subject: JDK 9 RFR of 8175042: Add success message to
 java/io/FileInputStream/LargeFileAvailable.java
Message-ID: <5CDDE081-4B99-4228-87F6-46EDA75A01B4@oracle.com>

Please review this trivial fix [1] for [2]. The intent is to add to the test log evidence that the test in fact completed. Also cf. [3].

Thanks,

Brian

[1] diff

--- a/test/java/io/FileInputStream/LargeFileAvailable.java
+++ b/test/java/io/FileInputStream/LargeFileAvailable.java
@@ -71,6 +71,9 @@
         } finally {
             file.delete();
         }
+
+        System.out.println("Test succeeded.");
+        System.out.flush();
     }

[2] https://bugs.openjdk.java.net/browse/JDK-8175042
[3] http://mail.openjdk.java.net/pipermail/nio-dev/2017-February/004130.html

From kumar.x.srinivasan at oracle.com  Wed Feb 15 21:12:24 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 15 Feb 2017 13:12:24 -0800
Subject: Review Request: JDK-8174694: improve error message shown when
 main class can't be loaded
In-Reply-To: <bb48defd-4a19-b901-f8ae-14e544eeaa32@oracle.com>
References: <f372ccaf-fa6b-2c26-d3fb-5da7e17a207d@oracle.com>
 <f3cf0c39-0aad-50bd-eeeb-3a13072bae00@oracle.com>
 <8b74af6e-96e8-2c42-3ed6-d85242a3ca6e@oracle.com>
 <d5bae7ca-fa95-a92e-a347-4b3ae09af876@oracle.com>
 <58A4A6C4.4070501@oracle.com>
 <bb48defd-4a19-b901-f8ae-14e544eeaa32@oracle.com>
Message-ID: <58A4C438.7030404@oracle.com>

Hi Vicente,

Looks good.

Mucho gracias for fixing this!.

Kumar

> Hi,
>
> Thanks guys for your comments. I have uploaded another iteration of 
> the review at [1],
>
> Vicente
>
> [1] http://cr.openjdk.java.net/~vromero/8174694/webrev.01/jdk.patch
>
> On 02/15/2017 02:06 PM, Kumar Srinivasan wrote:
>>
>> On 2/15/2017 10:39 AM, Alan Bateman wrote:
>>> On 15/02/2017 17:21, Vicente Romero wrote:
>>>
>>>> The simplest reproductor for this issue is:
>>>>
>>>> ------------------------------------------------------------------------------------------------ 
>>>>
>>>> public class A extends B {
>>>>     public static void main(String... args) {}
>>>> }
>>>> ------------------------------------------------------------------------------------------------ 
>>>>
>>>> class B {}
>>>> ------------------------------------------------------------------------------------------------ 
>>>>
>>>>
>>>> $javac -d out A.java B.java
>>>> $rm out/B.class
>>>>
>>>> before this patch this command:
>>>> $java -cp out A
>>>>
>>>> produces this output
>>>> Error: Could not find or load main class A
>>>>
>>>> with the current patch, the output produced is:
>>>> Error: Could not find or load main class A
>>>> because class B is not defined.
>>>>
>>>> if while loading the main class ClassNotFoundException is produced 
>>>> then the second part of the message will be: "because class Foo is 
>>>> not defined."
>>>> if NoClassDefFoundError is produced then it will be: "because class 
>>>> Foo is not defined"
>>> It's good that "B" is shown in the output but "because class B is 
>>> not defined" looks very strange to me. Have you consider something 
>>> more useful like:
>>>
>>> Error: Could not find or load main class A
>>> Caused by: java.lang.NoClassDefFoundError: B
>>
>> Yes this will also solve the translation issue thus we can go back to
>> one property.
>>
>> Kumar
>>
>>>
>>> -Alan
>>>
>>>
>>
>


From vicente.romero at oracle.com  Wed Feb 15 21:14:52 2017
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 15 Feb 2017 16:14:52 -0500
Subject: Review Request: JDK-8174694: improve error message shown when
 main class can't be loaded
In-Reply-To: <58A4C438.7030404@oracle.com>
References: <f372ccaf-fa6b-2c26-d3fb-5da7e17a207d@oracle.com>
 <f3cf0c39-0aad-50bd-eeeb-3a13072bae00@oracle.com>
 <8b74af6e-96e8-2c42-3ed6-d85242a3ca6e@oracle.com>
 <d5bae7ca-fa95-a92e-a347-4b3ae09af876@oracle.com>
 <58A4A6C4.4070501@oracle.com>
 <bb48defd-4a19-b901-f8ae-14e544eeaa32@oracle.com>
 <58A4C438.7030404@oracle.com>
Message-ID: <069fa9a9-2e82-d7c9-fc4b-6cc85eb3c9f7@oracle.com>



On 02/15/2017 04:12 PM, Kumar Srinivasan wrote:
> Hi Vicente,
>
> Looks good.
>
> Mucho gracias for fixing this!.

thanks!

>
> Kumar

Vicente

>
>> Hi,
>>
>> Thanks guys for your comments. I have uploaded another iteration of 
>> the review at [1],
>>
>> Vicente
>>
>> [1] http://cr.openjdk.java.net/~vromero/8174694/webrev.01/jdk.patch
>>
>> On 02/15/2017 02:06 PM, Kumar Srinivasan wrote:
>>>
>>> On 2/15/2017 10:39 AM, Alan Bateman wrote:
>>>> On 15/02/2017 17:21, Vicente Romero wrote:
>>>>
>>>>> The simplest reproductor for this issue is:
>>>>>
>>>>> ------------------------------------------------------------------------------------------------ 
>>>>>
>>>>> public class A extends B {
>>>>>     public static void main(String... args) {}
>>>>> }
>>>>> ------------------------------------------------------------------------------------------------ 
>>>>>
>>>>> class B {}
>>>>> ------------------------------------------------------------------------------------------------ 
>>>>>
>>>>>
>>>>> $javac -d out A.java B.java
>>>>> $rm out/B.class
>>>>>
>>>>> before this patch this command:
>>>>> $java -cp out A
>>>>>
>>>>> produces this output
>>>>> Error: Could not find or load main class A
>>>>>
>>>>> with the current patch, the output produced is:
>>>>> Error: Could not find or load main class A
>>>>> because class B is not defined.
>>>>>
>>>>> if while loading the main class ClassNotFoundException is produced 
>>>>> then the second part of the message will be: "because class Foo is 
>>>>> not defined."
>>>>> if NoClassDefFoundError is produced then it will be: "because 
>>>>> class Foo is not defined"
>>>> It's good that "B" is shown in the output but "because class B is 
>>>> not defined" looks very strange to me. Have you consider something 
>>>> more useful like:
>>>>
>>>> Error: Could not find or load main class A
>>>> Caused by: java.lang.NoClassDefFoundError: B
>>>
>>> Yes this will also solve the translation issue thus we can go back to
>>> one property.
>>>
>>> Kumar
>>>
>>>>
>>>> -Alan
>>>>
>>>>
>>>
>>
>


From Alan.Bateman at oracle.com  Wed Feb 15 21:25:07 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 15 Feb 2017 21:25:07 +0000
Subject: Review Request: JDK-8174694: improve error message shown when
 main class can't be loaded
In-Reply-To: <bb48defd-4a19-b901-f8ae-14e544eeaa32@oracle.com>
References: <f372ccaf-fa6b-2c26-d3fb-5da7e17a207d@oracle.com>
 <f3cf0c39-0aad-50bd-eeeb-3a13072bae00@oracle.com>
 <8b74af6e-96e8-2c42-3ed6-d85242a3ca6e@oracle.com>
 <d5bae7ca-fa95-a92e-a347-4b3ae09af876@oracle.com>
 <58A4A6C4.4070501@oracle.com>
 <bb48defd-4a19-b901-f8ae-14e544eeaa32@oracle.com>
Message-ID: <7fdfa06c-3c5d-5742-10a7-c88cb46cd124@oracle.com>

On 15/02/2017 20:41, Vicente Romero wrote:

> Hi,
>
> Thanks guys for your comments. I have uploaded another iteration of 
> the review at [1],
>
> Vicente
>
> [1] http://cr.openjdk.java.net/~vromero/8174694/webrev.01/jdk.patch
>
I assume you use getClass + getMessage to avoid calling the exception's 
toString, is that right? The output looks good to me.

-Alan

From martinrb at google.com  Wed Feb 15 21:48:58 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 15 Feb 2017 13:48:58 -0800
Subject: JDK 9 RFR of 8175042: Add success message to
 java/io/FileInputStream/LargeFileAvailable.java
In-Reply-To: <5CDDE081-4B99-4228-87F6-46EDA75A01B4@oracle.com>
References: <5CDDE081-4B99-4228-87F6-46EDA75A01B4@oracle.com>
Message-ID: <CA+kOe0_fDPSLgccd0yqNPHVL7ytTr3_+c3L1aot6xAq-mEpoSg@mail.gmail.com>

I don't like these "success" messages.  I think they're appropriate for
debugging, but not the final form of a test.

The call to flush() is likely a no-op; see Java Puzzlers item "Charred
beyond recognition."

If the main method fails to terminate, then  jtreg will catch that, and
more usefully, recent jtregs will show a stack trace of the final hung state

On Wed, Feb 15, 2017 at 1:04 PM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> Please review this trivial fix [1] for [2]. The intent is to add to the
> test log evidence that the test in fact completed. Also cf. [3].
>
> Thanks,
>
> Brian
>
> [1] diff
>
> --- a/test/java/io/FileInputStream/LargeFileAvailable.java
> +++ b/test/java/io/FileInputStream/LargeFileAvailable.java
> @@ -71,6 +71,9 @@
>          } finally {
>              file.delete();
>          }
> +
> +        System.out.println("Test succeeded.");
> +        System.out.flush();
>      }
>
> [2] https://bugs.openjdk.java.net/browse/JDK-8175042
> [3] http://mail.openjdk.java.net/pipermail/nio-dev/2017-
> February/004130.html

From lance.andersen at oracle.com  Wed Feb 15 21:49:30 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 15 Feb 2017 16:49:30 -0500
Subject: JDK 9 RFR of 8175042: Add success message to
 java/io/FileInputStream/LargeFileAvailable.java
In-Reply-To: <5CDDE081-4B99-4228-87F6-46EDA75A01B4@oracle.com>
References: <5CDDE081-4B99-4228-87F6-46EDA75A01B4@oracle.com>
Message-ID: <9AE293B6-1866-4778-8B45-4ECA171CDB1B@oracle.com>

+1

> On Feb 15, 2017, at 4:04 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> Please review this trivial fix [1] for [2]. The intent is to add to the test log evidence that the test in fact completed. Also cf. [3].
> 
> Thanks,
> 
> Brian
> 
> [1] diff
> 
> --- a/test/java/io/FileInputStream/LargeFileAvailable.java
> +++ b/test/java/io/FileInputStream/LargeFileAvailable.java
> @@ -71,6 +71,9 @@
>         } finally {
>             file.delete();
>         }
> +
> +        System.out.println("Test succeeded.");
> +        System.out.flush();
>     }
> 
> [2] https://bugs.openjdk.java.net/browse/JDK-8175042
> [3] http://mail.openjdk.java.net/pipermail/nio-dev/2017-February/004130.html

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From brian.burkhalter at oracle.com  Wed Feb 15 21:51:41 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 15 Feb 2017 13:51:41 -0800
Subject: JDK 9 RFR of 8175042: Add success message to
 java/io/FileInputStream/LargeFileAvailable.java
In-Reply-To: <CA+kOe0_fDPSLgccd0yqNPHVL7ytTr3_+c3L1aot6xAq-mEpoSg@mail.gmail.com>
References: <5CDDE081-4B99-4228-87F6-46EDA75A01B4@oracle.com>
 <CA+kOe0_fDPSLgccd0yqNPHVL7ytTr3_+c3L1aot6xAq-mEpoSg@mail.gmail.com>
Message-ID: <E3D462F3-F343-4534-A9B7-F412102C7DC5@oracle.com>

As background there are four tests failing with an Agent timeout where the tests appear to succeed. Two of the four have similar messages to this so this was intended to round out the set perhaps better to point to a harness problem as opposed to test problems.

On Feb 15, 2017, at 1:48 PM, Martin Buchholz <martinrb at google.com> wrote:

> I don't like these "success" messages.  I think they're appropriate for debugging, but not the final form of a test.
> 
> The call to flush() is likely a no-op; see Java Puzzlers item "Charred beyond recognition."
> 
> If the main method fails to terminate, then  jtreg will catch that, and more usefully, recent jtregs will show a stack trace of the final hung state
> 
> On Wed, Feb 15, 2017 at 1:04 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> Please review this trivial fix [1] for [2]. The intent is to add to the test log evidence that the test in fact completed. Also cf. [3].
> 
> Thanks,
> 
> Brian
> 
> [1] diff
> 
> --- a/test/java/io/FileInputStream/LargeFileAvailable.java
> +++ b/test/java/io/FileInputStream/LargeFileAvailable.java
> @@ -71,6 +71,9 @@
>          } finally {
>              file.delete();
>          }
> +
> +        System.out.println("Test succeeded.");
> +        System.out.flush();
>      }
> 
> [2] https://bugs.openjdk.java.net/browse/JDK-8175042
> [3] http://mail.openjdk.java.net/pipermail/nio-dev/2017-February/004130.html
> 


From vicente.romero at oracle.com  Wed Feb 15 22:03:56 2017
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 15 Feb 2017 17:03:56 -0500
Subject: Review Request: JDK-8174694: improve error message shown when
 main class can't be loaded
In-Reply-To: <7fdfa06c-3c5d-5742-10a7-c88cb46cd124@oracle.com>
References: <f372ccaf-fa6b-2c26-d3fb-5da7e17a207d@oracle.com>
 <f3cf0c39-0aad-50bd-eeeb-3a13072bae00@oracle.com>
 <8b74af6e-96e8-2c42-3ed6-d85242a3ca6e@oracle.com>
 <d5bae7ca-fa95-a92e-a347-4b3ae09af876@oracle.com>
 <58A4A6C4.4070501@oracle.com>
 <bb48defd-4a19-b901-f8ae-14e544eeaa32@oracle.com>
 <7fdfa06c-3c5d-5742-10a7-c88cb46cd124@oracle.com>
Message-ID: <5c4a72f0-7d1c-aa44-9a11-e80a0d2408a4@oracle.com>



On 02/15/2017 04:25 PM, Alan Bateman wrote:
> On 15/02/2017 20:41, Vicente Romero wrote:
>
>> Hi,
>>
>> Thanks guys for your comments. I have uploaded another iteration of 
>> the review at [1],
>>
>> Vicente
>>
>> [1] http://cr.openjdk.java.net/~vromero/8174694/webrev.01/jdk.patch
>>
> I assume you use getClass + getMessage to avoid calling the 
> exception's toString, is that right? The output looks good to me.

yes that's correct. Thanks for your approval

>
> -Alan

Vicente

From mark.sheppard at oracle.com  Wed Feb 15 23:42:17 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 15 Feb 2017 23:42:17 +0000
Subject: RFR: JDK-8146299 - Disable rmic -Xnew
In-Reply-To: <20990ac0-ef3e-cf98-86db-b19f1b2e7927@oracle.com>
References: <86ab8e07-5bdd-4c48-e307-c6dd5f5129cb@oracle.com>
 <502AF6C1-DF45-4ABE-A0F5-1E694D45975D@oracle.com>
 <20990ac0-ef3e-cf98-86db-b19f1b2e7927@oracle.com>
Message-ID: <cd3b4ccd-f8d0-2eb9-a465-41a4d41d8522@oracle.com>


oki doki ... np ... amendments have been made  ... verification testing 
in progress

regards
Mark

On 15/02/2017 18:57, Stuart Marks wrote:
>
>
> On 2/15/17 9:18 AM, Mandy Chung wrote:
>>> On Feb 15, 2017, at 6:21 AM, Mark Sheppard 
>>> <mark.sheppard at oracle.com> wrote:
>>>  please oblige and review the following change:
>>> http://cr.openjdk.java.net/~msheppar/8146299-II/webrev.03/
>>
>> For the test, can you move @ignore to the top after @test which makes 
>> it easier to tell this test is ignored.
>
> Hi Mandy,
>
> When Mark sent this for a preliminary review internally I had asked 
> him to move the @ignore tag after the @library tag. I was prompted to 
> do this because, when jtreg is run without the -ignore:quiet tag, the 
> result is
>
> TEST RESULT: Error. Parse Exception: `@library' must appear before 
> first action tag
>
> and oddly enough, @ignore is an action tag. But it seems like all of 
> our test runs specify -ignore:quiet, which accepts @ignore pretty much 
> anywhere, and other tests that use @ignore pretty much place it 
> anywhere. So it's pretty much useless to run jtreg with anything other 
> than -ignore:quiet.
>
> Mark, I'd suggest following Mandy's advice to put @ignore right after 
> @test, and to disregard what I had told you previously. Sorry for the 
> confusion.
>
> s'marks


From david.holmes at oracle.com  Wed Feb 15 23:44:01 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 16 Feb 2017 09:44:01 +1000
Subject: Review Request: JDK-8174694: improve error message shown when
 main class can't be loaded
In-Reply-To: <7fdfa06c-3c5d-5742-10a7-c88cb46cd124@oracle.com>
References: <f372ccaf-fa6b-2c26-d3fb-5da7e17a207d@oracle.com>
 <f3cf0c39-0aad-50bd-eeeb-3a13072bae00@oracle.com>
 <8b74af6e-96e8-2c42-3ed6-d85242a3ca6e@oracle.com>
 <d5bae7ca-fa95-a92e-a347-4b3ae09af876@oracle.com>
 <58A4A6C4.4070501@oracle.com>
 <bb48defd-4a19-b901-f8ae-14e544eeaa32@oracle.com>
 <7fdfa06c-3c5d-5742-10a7-c88cb46cd124@oracle.com>
Message-ID: <573d4c09-da7a-f691-3288-d199224501fc@oracle.com>

On 16/02/2017 7:25 AM, Alan Bateman wrote:
> On 15/02/2017 20:41, Vicente Romero wrote:
>
>> Hi,
>>
>> Thanks guys for your comments. I have uploaded another iteration of
>> the review at [1],
>>
>> Vicente
>>
>> [1] http://cr.openjdk.java.net/~vromero/8174694/webrev.01/jdk.patch
>>
> I assume you use getClass + getMessage to avoid calling the exception's
> toString, is that right? The output looks good to me.

I find the distinction between ClassNotFoundException and 
NoClassdefFoundError to be troubling. Seems to me the real problem was 
not printing the full exception chain in the NCDFE case. This looks very 
ad-hoc and special-cased.

David

> -Alan

From aleksej.efimov at oracle.com  Wed Feb 15 23:49:46 2017
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Thu, 16 Feb 2017 02:49:46 +0300
Subject: RFR: 8174735 Update JAX-WS RI integration to latest version
In-Reply-To: <e606f4b8-962a-d321-6f8c-726993117704@oracle.com>
References: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
 <DF61C6F3-48D0-4EB1-A93D-C09F523D2FB4@oracle.com>
 <e606f4b8-962a-d321-6f8c-726993117704@oracle.com>
Message-ID: <ba87aea7-cb4f-956c-0ce2-98afab7660ac@oracle.com>

Hi,

The new webrev with addressed comments was uploaded here:
http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/01

Best,
Aleksej


On 15/02/17 15:42, Roman Grigoriadi wrote:
> Hi Mandy,
>
> On 02/14/2017 11:53 PM, Mandy Chung wrote:
>>> On Feb 14, 2017, at 4:00 AM, Roman Grigoriadi 
>>> <roman.grigoriadi at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8174735
>>> Webrev: 
>>> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/00/
>>
>> jaxws/src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java 
>>
>>
>> -    /** JAXWS module name. JAXWS dependency is mandatory in 
>> generated Java module. */
>> -    private static final String JAXWS_MODULE = "java.xml.ws";
>> +    /** JAXB module name. JAXB dependency is mandatory in generated 
>> Java module. */
>> +    private static final String JAXWS_PACKAGE = "java.xml.ws?;
> this looks to be merge failure on our side, will fix it again.
>>
>> JAXWS_MODULE is the right name as we discussed in the last JAX-WS 
>> integration to jdk9. This change should be reverted and the upstream 
>> project  should be fixed.
>>
>> +                    if ("-release".equals(opt) && 9 >= 
>> getVersion(javacOptions.get(i + 1))) {
> thanks, will be fixed to --release
>>
>> javac supports `?-release` (double dashes, GNU long form style) but 
>> not the single dash option.  Is this new option in wsimport and wsgen 
>> tools?  It should probably be consistent with javac.
>>
>> You can run jdeps ?-check java.base,java.xml option to double check 
>> if any remaining qualified exports to these modules.
>>
>> Otherwise looks okay.
>>
>> Mandy
>>
>


From aleksej.efimov at oracle.com  Wed Feb 15 23:56:55 2017
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Thu, 16 Feb 2017 02:56:55 +0300
Subject: [9] RFR: 8173390: Investigate SymbolTable in SAXParser
In-Reply-To: <690391de-2b61-ecb8-a17f-1d333642e0b7@oracle.com>
References: <f7f9d1ff-1e70-1716-893c-c840d45d8f99@oracle.com>
 <690391de-2b61-ecb8-a17f-1d333642e0b7@oracle.com>
Message-ID: <017a06ac-d39d-92b9-0e9c-d59231bfd46f@oracle.com>

Hi Joe,

Thank you for your suggestions. New webrev can be found here:
http://cr.openjdk.java.net/~aefimov/8173390/9/01

Hi Daniel,
You're right that assertNotSame suites better here, i.e. it has nice 
output in case of failure. Because of that I removed the sout.println's 
from the test too.

With Best Regards,
Aleksej


On 15/02/17 20:16, huizhe wang wrote:
> Hi Aleksej,
>
> I just realized there were other dependencies on the SymbolTable 
> instance initialized in the constructor (line 575 in your new code), 
> which was probably why you kept the code from 574 through 579 after 
> adding new SymbolTable for each parsing process (850 - 854). As a 
> result, the SymbolTable will be created twice for the first parsing 
> process. One way to solve the issue is to check whether the 
> SymbolTable instance is new, or otherwise adding a reset function 
> would work as well. In both cases, there will be a bit change to the 
> SymbolTable to expose the count. What would you think?
>
> Thanks,
> Joe
>
> On 2/15/2017 8:31 AM, Aleks Efimov wrote:
>> Hi,
>>
>> Please, help to review the change required by JAXWS-RI code [1]: 
>> SAXParser needs to reset internal SymbolTable to enable pooling of 
>> parsers in SAAJ-RI code. Latest version of JAXWS-RI code (that is 
>> currently under review [2]) doesn't provide a workaround to reset the 
>> symbol table (it was done to remove module dependency on Xerces 
>> internal classes). So the solution is to reset the SymbolTable during 
>> SAXParser reset. The webrev with the changes and simple test that 
>> reproduces SAAJ-RI behavior:
>>     http://cr.openjdk.java.net/~aefimov/8173390/9/00/
>>
>> The fix was tested with all JDK/JCK (JAX[P|B|WS] related tests. No 
>> failures observed.
>>
>>
>> Thank you,
>> Aleksej
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8173390
>> [2] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-February/046386.html
>>
>


From huizhe.wang at oracle.com  Thu Feb 16 00:07:49 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 15 Feb 2017 16:07:49 -0800
Subject: [9] RFR: 8173390: Investigate SymbolTable in SAXParser
In-Reply-To: <017a06ac-d39d-92b9-0e9c-d59231bfd46f@oracle.com>
References: <f7f9d1ff-1e70-1716-893c-c840d45d8f99@oracle.com>
 <690391de-2b61-ecb8-a17f-1d333642e0b7@oracle.com>
 <017a06ac-d39d-92b9-0e9c-d59231bfd46f@oracle.com>
Message-ID: <1a8ccab4-4868-b71d-63af-36d93a0aa3a1@oracle.com>

Looks good to me.

Thanks,
Joe

On 2/15/2017 3:56 PM, Aleks Efimov wrote:
> Hi Joe,
>
> Thank you for your suggestions. New webrev can be found here:
> http://cr.openjdk.java.net/~aefimov/8173390/9/01
>
> Hi Daniel,
> You're right that assertNotSame suites better here, i.e. it has nice 
> output in case of failure. Because of that I removed the 
> sout.println's from the test too.
>
> With Best Regards,
> Aleksej
>
>
> On 15/02/17 20:16, huizhe wang wrote:
>> Hi Aleksej,
>>
>> I just realized there were other dependencies on the SymbolTable 
>> instance initialized in the constructor (line 575 in your new code), 
>> which was probably why you kept the code from 574 through 579 after 
>> adding new SymbolTable for each parsing process (850 - 854). As a 
>> result, the SymbolTable will be created twice for the first parsing 
>> process. One way to solve the issue is to check whether the 
>> SymbolTable instance is new, or otherwise adding a reset function 
>> would work as well. In both cases, there will be a bit change to the 
>> SymbolTable to expose the count. What would you think?
>>
>> Thanks,
>> Joe
>>
>> On 2/15/2017 8:31 AM, Aleks Efimov wrote:
>>> Hi,
>>>
>>> Please, help to review the change required by JAXWS-RI code [1]: 
>>> SAXParser needs to reset internal SymbolTable to enable pooling of 
>>> parsers in SAAJ-RI code. Latest version of JAXWS-RI code (that is 
>>> currently under review [2]) doesn't provide a workaround to reset 
>>> the symbol table (it was done to remove module dependency on Xerces 
>>> internal classes). So the solution is to reset the SymbolTable 
>>> during SAXParser reset. The webrev with the changes and simple test 
>>> that reproduces SAAJ-RI behavior:
>>>     http://cr.openjdk.java.net/~aefimov/8173390/9/00/
>>>
>>> The fix was tested with all JDK/JCK (JAX[P|B|WS] related tests. No 
>>> failures observed.
>>>
>>>
>>> Thank you,
>>> Aleksej
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8173390
>>> [2] 
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-February/046386.html
>>>
>>
>


From aleksej.efimov at oracle.com  Thu Feb 16 00:09:12 2017
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Thu, 16 Feb 2017 03:09:12 +0300
Subject: [9] RFR: 8173390: Investigate SymbolTable in SAXParser
In-Reply-To: <1a8ccab4-4868-b71d-63af-36d93a0aa3a1@oracle.com>
References: <f7f9d1ff-1e70-1716-893c-c840d45d8f99@oracle.com>
 <690391de-2b61-ecb8-a17f-1d333642e0b7@oracle.com>
 <017a06ac-d39d-92b9-0e9c-d59231bfd46f@oracle.com>
 <1a8ccab4-4868-b71d-63af-36d93a0aa3a1@oracle.com>
Message-ID: <08ba5f63-089b-41ab-be0e-fc1737bc3307@oracle.com>

Thank you Joe!


On 16/02/17 03:07, huizhe wang wrote:
> Looks good to me.
>
> Thanks,
> Joe
>
> On 2/15/2017 3:56 PM, Aleks Efimov wrote:
>> Hi Joe,
>>
>> Thank you for your suggestions. New webrev can be found here:
>> http://cr.openjdk.java.net/~aefimov/8173390/9/01
>>
>> Hi Daniel,
>> You're right that assertNotSame suites better here, i.e. it has nice 
>> output in case of failure. Because of that I removed the 
>> sout.println's from the test too.
>>
>> With Best Regards,
>> Aleksej
>>
>>
>> On 15/02/17 20:16, huizhe wang wrote:
>>> Hi Aleksej,
>>>
>>> I just realized there were other dependencies on the SymbolTable 
>>> instance initialized in the constructor (line 575 in your new code), 
>>> which was probably why you kept the code from 574 through 579 after 
>>> adding new SymbolTable for each parsing process (850 - 854). As a 
>>> result, the SymbolTable will be created twice for the first parsing 
>>> process. One way to solve the issue is to check whether the 
>>> SymbolTable instance is new, or otherwise adding a reset function 
>>> would work as well. In both cases, there will be a bit change to the 
>>> SymbolTable to expose the count. What would you think?
>>>
>>> Thanks,
>>> Joe
>>>
>>> On 2/15/2017 8:31 AM, Aleks Efimov wrote:
>>>> Hi,
>>>>
>>>> Please, help to review the change required by JAXWS-RI code [1]: 
>>>> SAXParser needs to reset internal SymbolTable to enable pooling of 
>>>> parsers in SAAJ-RI code. Latest version of JAXWS-RI code (that is 
>>>> currently under review [2]) doesn't provide a workaround to reset 
>>>> the symbol table (it was done to remove module dependency on Xerces 
>>>> internal classes). So the solution is to reset the SymbolTable 
>>>> during SAXParser reset. The webrev with the changes and simple test 
>>>> that reproduces SAAJ-RI behavior:
>>>>     http://cr.openjdk.java.net/~aefimov/8173390/9/00/
>>>>
>>>> The fix was tested with all JDK/JCK (JAX[P|B|WS] related tests. No 
>>>> failures observed.
>>>>
>>>>
>>>> Thank you,
>>>> Aleksej
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8173390
>>>> [2] 
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-February/046386.html
>>>>
>>>
>>
>


From mandy.chung at oracle.com  Thu Feb 16 00:14:07 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 15 Feb 2017 16:14:07 -0800
Subject: RFR: 8174735 Update JAX-WS RI integration to latest version
In-Reply-To: <ba87aea7-cb4f-956c-0ce2-98afab7660ac@oracle.com>
References: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
 <DF61C6F3-48D0-4EB1-A93D-C09F523D2FB4@oracle.com>
 <e606f4b8-962a-d321-6f8c-726993117704@oracle.com>
 <ba87aea7-cb4f-956c-0ce2-98afab7660ac@oracle.com>
Message-ID: <AF97D5D9-29FA-4338-868A-3F7903903783@oracle.com>

I checked module-info.java, default.policy and also the tools `?-release` option.  This version looks fine to me.

Mandy

> On Feb 15, 2017, at 3:49 PM, Aleks Efimov <aleksej.efimov at oracle.com> wrote:
> 
> Hi,
> 
> The new webrev with addressed comments was uploaded here:
> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/01
> 
> Best,
> Aleksej


From lance.andersen at oracle.com  Thu Feb 16 00:42:22 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 15 Feb 2017 19:42:22 -0500
Subject: RFR: 8174735 Update JAX-WS RI integration to latest version
In-Reply-To: <AF97D5D9-29FA-4338-868A-3F7903903783@oracle.com>
References: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
 <DF61C6F3-48D0-4EB1-A93D-C09F523D2FB4@oracle.com>
 <e606f4b8-962a-d321-6f8c-726993117704@oracle.com>
 <ba87aea7-cb4f-956c-0ce2-98afab7660ac@oracle.com>
 <AF97D5D9-29FA-4338-868A-3F7903903783@oracle.com>
Message-ID: <A903FBB3-5A42-4B51-AE00-AD33F67DD34F@oracle.com>

Hi Roman, Aleks,


This looks better.

There are several files in Datatype/helper such as arameterlessDatatypeBuilder.java. who had the copyright date changed but there are not other updates.  Not sure that you want that

Best
Lance

> On Feb 15, 2017, at 7:14 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> I checked module-info.java, default.policy and also the tools `?-release` option.  This version looks fine to me.
> 
> Mandy
> 
>> On Feb 15, 2017, at 3:49 PM, Aleks Efimov <aleksej.efimov at oracle.com> wrote:
>> 
>> Hi,
>> 
>> The new webrev with addressed comments was uploaded here:
>> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/01
>> 
>> Best,
>> Aleksej
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From amy.lu at oracle.com  Thu Feb 16 07:10:25 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 16 Feb 2017 15:10:25 +0800
Subject: JDK 9 RFR of JDK-8175062: Mark
 java/nio/channels/AsyncCloseAndInterrupt.java as intermittently failing
Message-ID: <0b341bb0-83c0-addd-b425-a4c94e470551@oracle.com>

java/nio/channels/AsyncCloseAndInterrupt.java

This test is known to fail intermittently (JDK-8172045), this patch is 
to mark the test accordingly with keyword 'intermittent'.

Please review.

bug: https://bugs.openjdk.java.net/browse/JDK-8175062
webrev: http://cr.openjdk.java.net/~amlu/8175062/webrev.00/

Thanks,
Amy

--- old/test/java/nio/channels/AsyncCloseAndInterrupt.java	2017-02-16 15:06:51.000000000 +0800
+++ new/test/java/nio/channels/AsyncCloseAndInterrupt.java	2017-02-16 15:06:51.000000000 +0800
@@ -25,6 +25,7 @@
   * @bug 4460583 4470470 4840199 6419424 6710579 6596323 6824135 6395224 7142919
   *      8151582 8068693 8153209
   * @run main/othervm AsyncCloseAndInterrupt
+ * @key intermittent
   * @summary Comprehensive test of asynchronous closing and interruption
   * @author Mark Reinhold
   */



From frank.yuan at oracle.com  Thu Feb 16 08:03:20 2017
From: frank.yuan at oracle.com (Frank Yuan)
Date: Thu, 16 Feb 2017 16:03:20 +0800
Subject: RFR [JAXP] [TESTBUG] JDK-8175043 Multiple jaxp tests failing across
 platforms
Message-ID: <035101d2882b$2525c810$6f715830$@oracle.com>

Hi Max and All

 

Would you like to review http://cr.openjdk.java.net/~fyuan/8175043/webrev.00/?

Bug: https://bugs.openjdk.java.net/browse/JDK-8175043

 

Some JAXP tests are impacted by JDK-8168410, to fix the issue, I added the pull path name to the file name in the tests, and added a
temporary FilePermission for the specified file names in XSLTFunctionsTest.java.

 

To Max

 

I didn't take your proposal because we do want to assign FilePermission for the specified userdir, not for ".". To avoid assigning
potentially extra permission now or future, I used the explicit full file path in the test.

 

Thanks

Frank

 


From weijun.wang at oracle.com  Thu Feb 16 08:34:55 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 16 Feb 2017 16:34:55 +0800
Subject: RFR [JAXP] [TESTBUG] JDK-8175043 Multiple jaxp tests failing
 across platforms
In-Reply-To: <035101d2882b$2525c810$6f715830$@oracle.com>
References: <035101d2882b$2525c810$6f715830$@oracle.com>
Message-ID: <0ac2e9b5-4105-a105-5206-ef266488a4e6@oracle.com>

Hi Frank

You got the idea here correctly, that is to say, the path used in 
permission granting must match the style of how you access the file. The 
fix should work.

On the other hand, the code change touches too many files. You'll need 
someone in the JAXP field to confirm if this is the best way.

Thanks
Max

On 02/16/2017 04:03 PM, Frank Yuan wrote:
> Hi Max and All
>
> Would you like to review
> http://cr.openjdk.java.net/~fyuan/8175043/webrev.00/?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8175043
>
> Some JAXP tests are impacted by JDK-8168410, to fix the issue, I added
> the pull path name to the file name in the tests, and added a temporary
> FilePermission for the specified file names in XSLTFunctionsTest.java.
>
> To Max
>
> I didn?t take your proposal because we do want to assign FilePermission
> for the specified userdir, not for ?.?. To avoid assigning potentially
> extra permission now or future, I used the explicit full file path in
> the test.
>
> Thanks
> Frank
>
>
>

From frank.yuan at oracle.com  Thu Feb 16 08:56:56 2017
From: frank.yuan at oracle.com (Frank Yuan)
Date: Thu, 16 Feb 2017 16:56:56 +0800
Subject: RFR [JAXP] [TESTBUG] JDK-8175043 Multiple jaxp tests failing
 across platforms
In-Reply-To: <0ac2e9b5-4105-a105-5206-ef266488a4e6@oracle.com>
References: <035101d2882b$2525c810$6f715830$@oracle.com>
 <0ac2e9b5-4105-a105-5206-ef266488a4e6@oracle.com>
Message-ID: <037f01d28832$a20b2f30$e6218d90$@oracle.com>

> -----Original Message-----
> From: Weijun Wang [mailto:weijun.wang at oracle.com]
> Subject: Re: RFR [JAXP] [TESTBUG] JDK-8175043 Multiple jaxp tests failing across platforms
> 
> Hi Frank
> 
> You got the idea here correctly, that is to say, the path used in
> permission granting must match the style of how you access the file. The
> fix should work.
> 
> On the other hand, the code change touches too many files. You'll need
> someone in the JAXP field to confirm if this is the best way.

Alright, thank you very much for the review!

Frank

> 
> Thanks
> Max
> 
> On 02/16/2017 04:03 PM, Frank Yuan wrote:
> > Hi Max and All
> >
> > Would you like to review
> > http://cr.openjdk.java.net/~fyuan/8175043/webrev.00/?
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8175043
> >
> > Some JAXP tests are impacted by JDK-8168410, to fix the issue, I added
> > the pull path name to the file name in the tests, and added a temporary
> > FilePermission for the specified file names in XSLTFunctionsTest.java.
> >
> > To Max
> >
> > I didn't take your proposal because we do want to assign FilePermission
> > for the specified userdir, not for ".". To avoid assigning potentially
> > extra permission now or future, I used the explicit full file path in
> > the test.
> >
> > Thanks
> > Frank
> >
> >
> >


From daniel.fuchs at oracle.com  Thu Feb 16 10:39:17 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 16 Feb 2017 10:39:17 +0000
Subject: RFR: 8174735 Update JAX-WS RI integration to latest version
In-Reply-To: <ba87aea7-cb4f-956c-0ce2-98afab7660ac@oracle.com>
References: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
 <DF61C6F3-48D0-4EB1-A93D-C09F523D2FB4@oracle.com>
 <e606f4b8-962a-d321-6f8c-726993117704@oracle.com>
 <ba87aea7-cb4f-956c-0ce2-98afab7660ac@oracle.com>
Message-ID: <a8d43957-b705-888a-fa08-f4c37b59802e@oracle.com>

Hi Aleksej,

On 15/02/17 23:49, Aleks Efimov wrote:
> Hi,
>
> The new webrev with addressed comments was uploaded here:
> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/01

This is probably a question for the upstream project, but I'm
puzzled by this change:

http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/01/jaxws/src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JModuleDirective.java.frames.html

... and even more since Integer.hashCode() calls Integer.hashCode(int) 
which just returns the value of the integer...
What's the purpose of calling valueOf which 1. contradict the javadoc
comment and 2. might trigger the creation of a new Integer instance?


Nit: There are also some files which present some strange
      formatting/misalignment where new code/comment was added.
      I have noted them below:

There's strange formatting for the anonymous subclass
of AbstractList in this file:

http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/01/jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/InternetHeaders.java.frames.html

  324             headerValueView = new AbstractList<String>() {
  325                 @Override
  326                                 public String get(int index) {
  327                     return headers.get(index).line;
  328                 }
  329
  330                 @Override
  331                                 public int size() {
  332                     return headers.size();
  333                 }
  334             };

and
http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/01/jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimePartDataSource.java.frames.html

has also some alignment issues where @Overrides were added.

The following file has some comment alignment issues which impair
readability:

http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/01/jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/ASCIIUtility.java.frames.html

best regards,

-- daniel

>
> Best,
> Aleksej
>
>
> On 15/02/17 15:42, Roman Grigoriadi wrote:
>> Hi Mandy,
>>
>> On 02/14/2017 11:53 PM, Mandy Chung wrote:
>>>> On Feb 14, 2017, at 4:00 AM, Roman Grigoriadi
>>>> <roman.grigoriadi at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8174735
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/00/
>>>
>>> jaxws/src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java
>>>
>>>
>>> -    /** JAXWS module name. JAXWS dependency is mandatory in
>>> generated Java module. */
>>> -    private static final String JAXWS_MODULE = "java.xml.ws";
>>> +    /** JAXB module name. JAXB dependency is mandatory in generated
>>> Java module. */
>>> +    private static final String JAXWS_PACKAGE = "java.xml.ws?;
>> this looks to be merge failure on our side, will fix it again.
>>>
>>> JAXWS_MODULE is the right name as we discussed in the last JAX-WS
>>> integration to jdk9. This change should be reverted and the upstream
>>> project  should be fixed.
>>>
>>> +                    if ("-release".equals(opt) && 9 >=
>>> getVersion(javacOptions.get(i + 1))) {
>> thanks, will be fixed to --release
>>>
>>> javac supports `?-release` (double dashes, GNU long form style) but
>>> not the single dash option.  Is this new option in wsimport and wsgen
>>> tools?  It should probably be consistent with javac.
>>>
>>> You can run jdeps ?-check java.base,java.xml option to double check
>>> if any remaining qualified exports to these modules.
>>>
>>> Otherwise looks okay.
>>>
>>> Mandy
>>>
>>
>


From frank.yuan at oracle.com  Thu Feb 16 13:36:05 2017
From: frank.yuan at oracle.com (Frank Yuan)
Date: Thu, 16 Feb 2017 21:36:05 +0800
Subject: RFR [JAXP] [TESTBUG] JDK-8175043 Multiple jaxp tests failing
 across platforms
In-Reply-To: <0ac2e9b5-4105-a105-5206-ef266488a4e6@oracle.com>
References: <035101d2882b$2525c810$6f715830$@oracle.com>
 <0ac2e9b5-4105-a105-5206-ef266488a4e6@oracle.com>
Message-ID: <039d01d28859$a0ea6b30$e2bf4190$@oracle.com>

Since no one has more comment, and Joe agree this solution, I will push the change.

Thanks
Frank

> -----Original Message-----
> From: Weijun Wang [mailto:weijun.wang at oracle.com]
> Sent: Thursday, February 16, 2017 4:35 PM
> To: Frank Yuan; 'Daniel Fuchs'; core-libs-dev at openjdk.java.net
> Subject: Re: RFR [JAXP] [TESTBUG] JDK-8175043 Multiple jaxp tests failing across platforms
> 
> Hi Frank
> 
> You got the idea here correctly, that is to say, the path used in
> permission granting must match the style of how you access the file. The
> fix should work.
> 
> On the other hand, the code change touches too many files. You'll need
> someone in the JAXP field to confirm if this is the best way.
> 
> Thanks
> Max
> 
> On 02/16/2017 04:03 PM, Frank Yuan wrote:
> > Hi Max and All
> >
> > Would you like to review
> > http://cr.openjdk.java.net/~fyuan/8175043/webrev.00/?
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8175043
> >
> > Some JAXP tests are impacted by JDK-8168410, to fix the issue, I added
> > the pull path name to the file name in the tests, and added a temporary
> > FilePermission for the specified file names in XSLTFunctionsTest.java.
> >
> > To Max
> >
> > I didn't take your proposal because we do want to assign FilePermission
> > for the specified userdir, not for ".". To avoid assigning potentially
> > extra permission now or future, I used the explicit full file path in
> > the test.
> >
> > Thanks
> > Frank
> >
> >
> >


From christoph.langer at sap.com  Thu Feb 16 13:53:45 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 16 Feb 2017 13:53:45 +0000
Subject: rmid on Unix fails with Exception - maybe aftermath of JDK-8173607 ??
Message-ID: <3c618ce8a236424cb72444ce3c0c744e@derote13de46.global.corp.sap>

Hi Daniel,

when starting "rmid" from current builds on Linux (and probably other Unix platforms as well) we are currently getting the exception below.

It looks as if on that path libnio was not loaded and hence we're getting an UnsatisfiedLinkError. In UnixNativeDispatcher.java one can find a static initialization block which should do that, however, it needs elevated access. Maybe rmid is missing a permission for that?

Any thoughts?

Thanks & best regards
Christoph


...>/jdk9-build-dir/images/jdk/bin/rmid
Exception in thread "main" java.lang.UnsatisfiedLinkError: sun.nio.fs.UnixNativeDispatcher.getcwd()[B
        at java.base/sun.nio.fs.UnixNativeDispatcher.getcwd(Native Method)
        at java.base/sun.nio.fs.UnixFileSystem.<init>(UnixFileSystem.java:66)
        at java.base/sun.nio.fs.LinuxFileSystem.<init>(LinuxFileSystem.java:39)
        at java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:46)
        at java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:39)
        at java.base/sun.nio.fs.UnixFileSystemProvider.<init>(UnixFileSystemProvider.java:56)
        at java.base/sun.nio.fs.LinuxFileSystemProvider.<init>(LinuxFileSystemProvider.java:41)
        at java.base/sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemProvider.java:41)
        at java.base/java.io.FilePermission.<clinit>(FilePermission.java:206)
        at java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:899)
        at java.base/java.io.File.exists(File.java:815)
        at java.base/java.lang.ClassLoader$2.run(ClassLoader.java:2513)
        at java.base/java.lang.ClassLoader$2.run(ClassLoader.java:2510)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2509)
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2478)
        at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:873)
        at java.base/java.lang.System.loadLibrary(System.java:1818)
        at java.base/sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java:611)
        at java.base/sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java:609)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/sun.nio.fs.UnixNativeDispatcher.<clinit>(UnixNativeDispatcher.java:609)
        at java.base/sun.nio.fs.UnixFileSystem.<init>(UnixFileSystem.java:66)
        at java.base/sun.nio.fs.LinuxFileSystem.<init>(LinuxFileSystem.java:39)
        at java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:46)
        at java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:39)
        at java.base/sun.nio.fs.UnixFileSystemProvider.<init>(UnixFileSystemProvider.java:56)
        at java.base/sun.nio.fs.LinuxFileSystemProvider.<init>(LinuxFileSystemProvider.java:41)
        at java.base/sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemProvider.java:41)
        at java.base/java.nio.file.FileSystems.<clinit>(FileSystems.java:91)
        at java.base/java.nio.file.Paths.get(Paths.java:84)
        at java.base/jdk.internal.jimage.ImageReaderFactory.<clinit>(ImageReaderFactory.java:50)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/sun.net.www.protocol.jrt.JavaRuntimeURLConnection.<clinit>(JavaRuntimeURLConnection.java:59)
        at java.base/sun.net.www.protocol.jrt.Handler.openConnection(Handler.java:42)
        at java.base/java.net.URL.openConnection(URL.java:1049)
        at java.base/jdk.internal.module.SystemModuleFinder$ImageModuleReader.checkPermissionToConnect(SystemModuleFinder.java:287)
        at java.base/jdk.internal.module.SystemModuleFinder$ImageModuleReader.<init>(SystemModuleFinder.java:296)
        at java.base/jdk.internal.module.SystemModuleFinder$1.get(SystemModuleFinder.java:245)
        at java.base/jdk.internal.module.SystemModuleFinder$1.get(SystemModuleFinder.java:242)
        at java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferenceImpl.java:83)
        at java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(BuiltinClassLoader.java:934)
        at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1719)
        at java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinClassLoader.java:926)
        at java.base/jdk.internal.loader.BuiltinClassLoader.access$100(BuiltinClassLoader.java:92)
        at java.base/jdk.internal.loader.BuiltinClassLoader$1.run(BuiltinClassLoader.java:356)
        at java.base/jdk.internal.loader.BuiltinClassLoader$1.run(BuiltinClassLoader.java:351)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/jdk.internal.loader.BuiltinClassLoader.findMiscResource(BuiltinClassLoader.java:350)
        at java.base/jdk.internal.loader.BuiltinClassLoader.findResources(BuiltinClassLoader.java:311)
        at java.base/jdk.internal.loader.BootLoader.findResources(BootLoader.java:156)
        at java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1430)
        at java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1428)
        at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1082)
        at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.access$1200(ServiceLoader.java:1004)
        at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(ServiceLoader.java:1131)
        at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(ServiceLoader.java:1130)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1133)
        at java.base/java.util.ServiceLoader$1.hasNext(ServiceLoader.java:1163)
        at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1258)
        at java.base/java.nio.channels.spi.SelectorProvider.loadProviderAsService(SelectorProvider.java:122)
        at java.base/java.nio.channels.spi.SelectorProvider.access$200(SelectorProvider.java:69)
        at java.base/java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.java:180)
        at java.base/java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.java:176)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/java.nio.channels.spi.SelectorProvider.provider(SelectorProvider.java:175)
        at java.base/java.lang.System.inheritedChannel(System.java:276)
        at java.rmi/sun.rmi.server.Activation$2.run(Activation.java:1960)
        at java.rmi/sun.rmi.server.Activation$2.run(Activation.java:1958)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.rmi/sun.rmi.server.Activation.main(Activation.java:1957)


From roman.grigoriadi at oracle.com  Thu Feb 16 14:25:16 2017
From: roman.grigoriadi at oracle.com (Roman Grigoriadi)
Date: Thu, 16 Feb 2017 15:25:16 +0100
Subject: RFR: 8174735 Update JAX-WS RI integration to latest version
In-Reply-To: <a8d43957-b705-888a-fa08-f4c37b59802e@oracle.com>
References: <3bce345d-f768-466d-e4a5-4149ccea6cda@oracle.com>
 <DF61C6F3-48D0-4EB1-A93D-C09F523D2FB4@oracle.com>
 <e606f4b8-962a-d321-6f8c-726993117704@oracle.com>
 <ba87aea7-cb4f-956c-0ce2-98afab7660ac@oracle.com>
 <a8d43957-b705-888a-fa08-f4c37b59802e@oracle.com>
Message-ID: <220277f7-129b-a55a-1a3b-b1e9c73718b7@oracle.com>

Hi Daniel,


On 02/16/2017 11:39 AM, Daniel Fuchs wrote:
> Hi Aleksej,
>
> On 15/02/17 23:49, Aleks Efimov wrote:
>> Hi,
>>
>> The new webrev with addressed comments was uploaded here:
>> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/01
>
> This is probably a question for the upstream project, but I'm
> puzzled by this change:
>
> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/01/jaxws/src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JModuleDirective.java.frames.html 
>
>
> ... and even more since Integer.hashCode() calls Integer.hashCode(int) 
> which just returns the value of the integer...
> What's the purpose of calling valueOf which 1. contradict the javadoc
> comment and 2. might trigger the creation of a new Integer instance?
Thanks for pointing out, we have removed both Integer#valueOf and 
Integer#hashCode calls, it doesn't make any sense to be there. This 
puzzling line resulted from useless Ingeger#hashCode(...) call which got 
refactored to be target 1.7 compatible.
>
>
> Nit: There are also some files which present some strange
>      formatting/misalignment where new code/comment was added.
>      I have noted them below:
>
> There's strange formatting for the anonymous subclass
> of AbstractList in this file:
>
> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/01/jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/InternetHeaders.java.frames.html 
>
>
>  324             headerValueView = new AbstractList<String>() {
>  325                 @Override
>  326                                 public String get(int index) {
>  327                     return headers.get(index).line;
>  328                 }
>  329
>  330                 @Override
>  331                                 public int size() {
>  332                     return headers.size();
>  333                 }
>  334             };
>
> and
> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/01/jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimePartDataSource.java.frames.html 
>
>
> has also some alignment issues where @Overrides were added.
>
> The following file has some comment alignment issues which impair
> readability:
>
> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/01/jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/ASCIIUtility.java.frames.html 
>
I have fixed the alignment in SAAJ.
Both changes will get to JDK next sync.
>
> best regards,
Thanks for comments,
Roman
>
> -- daniel
>
>>
>> Best,
>> Aleksej
>>
>>
>> On 15/02/17 15:42, Roman Grigoriadi wrote:
>>> Hi Mandy,
>>>
>>> On 02/14/2017 11:53 PM, Mandy Chung wrote:
>>>>> On Feb 14, 2017, at 4:00 AM, Roman Grigoriadi
>>>>> <roman.grigoriadi at oracle.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws 
>>>>> repo.
>>>>>
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8174735
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/00/
>>>>
>>>> jaxws/src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java 
>>>>
>>>>
>>>>
>>>> -    /** JAXWS module name. JAXWS dependency is mandatory in
>>>> generated Java module. */
>>>> -    private static final String JAXWS_MODULE = "java.xml.ws";
>>>> +    /** JAXB module name. JAXB dependency is mandatory in generated
>>>> Java module. */
>>>> +    private static final String JAXWS_PACKAGE = "java.xml.ws?;
>>> this looks to be merge failure on our side, will fix it again.
>>>>
>>>> JAXWS_MODULE is the right name as we discussed in the last JAX-WS
>>>> integration to jdk9. This change should be reverted and the upstream
>>>> project  should be fixed.
>>>>
>>>> +                    if ("-release".equals(opt) && 9 >=
>>>> getVersion(javacOptions.get(i + 1))) {
>>> thanks, will be fixed to --release
>>>>
>>>> javac supports `?-release` (double dashes, GNU long form style) but
>>>> not the single dash option.  Is this new option in wsimport and wsgen
>>>> tools?  It should probably be consistent with javac.
>>>>
>>>> You can run jdeps ?-check java.base,java.xml option to double check
>>>> if any remaining qualified exports to these modules.
>>>>
>>>> Otherwise looks okay.
>>>>
>>>> Mandy
>>>>
>>>
>>
>


From daniel.fuchs at oracle.com  Thu Feb 16 14:52:39 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 16 Feb 2017 14:52:39 +0000
Subject: rmid on Unix fails with Exception - maybe aftermath of
 JDK-8173607 ??
In-Reply-To: <3c618ce8a236424cb72444ce3c0c744e@derote13de46.global.corp.sap>
References: <3c618ce8a236424cb72444ce3c0c744e@derote13de46.global.corp.sap>
Message-ID: <d9c5ab08-86ef-88f4-eb14-4eb96ecef5b3@oracle.com>

Hi Christoph,

It looks like one of the dreaded class initialization cycle
issues.

If you look at the stack trace, you will see that
UnixNativeDispatcher.<clinit>:609
calls System.loadLibrary at line 611
which later down the road calls the
native UnixNativeDispatcher.getcwd command
from sun.nio.fs.UnixFileSystem.<init>

But at this point UnixNativeDispatcher has not
finished initializing: we're still trying to load
the nio lib...

I don't think this has anything to do with JDK-8173607.
JDK-8173607 just splitted the JMX RMI Connector out of
java.management - and rmid has nothing to do with JMX.

rmid doesn't depend on either java.management or
java.management.rmi, and I don't see anything
on the exception path that would involve either
of these modules.
So I suspect the culprit is probably elsewhere.

best regards,

-- daniel



On 16/02/17 13:53, Langer, Christoph wrote:
> Hi Daniel,
>
>
>
> when starting ?rmid? from current builds on Linux (and probably other
> Unix platforms as well) we are currently getting the exception below.
>
>
>
> It looks as if on that path libnio was not loaded and hence we?re
> getting an UnsatisfiedLinkError. In UnixNativeDispatcher.java one can
> find a static initialization block which should do that, however, it
> needs elevated access. Maybe rmid is missing a permission for that?
>
>
>
> Any thoughts?
>
>
>
> Thanks & best regards
>
> Christoph
>
>
>
>
>
> ...>/jdk9-build-dir/images/jdk/bin/rmid
>
> Exception in thread "main" java.lang.UnsatisfiedLinkError:
> sun.nio.fs.UnixNativeDispatcher.getcwd()[B
>
>         at java.base/sun.nio.fs.UnixNativeDispatcher.getcwd(Native Method)
>
>         at
> java.base/sun.nio.fs.UnixFileSystem.<init>(UnixFileSystem.java:66)
>
>         at
> java.base/sun.nio.fs.LinuxFileSystem.<init>(LinuxFileSystem.java:39)
>
>         at
> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:46)
>
>         at
> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:39)
>
>         at
> java.base/sun.nio.fs.UnixFileSystemProvider.<init>(UnixFileSystemProvider.java:56)
>
>         at
> java.base/sun.nio.fs.LinuxFileSystemProvider.<init>(LinuxFileSystemProvider.java:41)
>
>         at
> java.base/sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemProvider.java:41)
>
>         at
> java.base/java.io.FilePermission.<clinit>(FilePermission.java:206)
>
>         at
> java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:899)
>
>         at java.base/java.io.File.exists(File.java:815)
>
>         at java.base/java.lang.ClassLoader$2.run(ClassLoader.java:2513)
>
>         at java.base/java.lang.ClassLoader$2.run(ClassLoader.java:2510)
>
>         at java.base/java.security.AccessController.doPrivileged(Native
> Method)
>
>         at
> java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2509)
>
>         at
> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2478)
>
>         at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:873)
>
>         at java.base/java.lang.System.loadLibrary(System.java:1818)
>
>         at
> java.base/sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java:611)
>
>         at
> java.base/sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java:609)
>
>         at java.base/java.security.AccessController.doPrivileged(Native
> Method)
>
>         at
> java.base/sun.nio.fs.UnixNativeDispatcher.<clinit>(UnixNativeDispatcher.java:609)
>
>         at
> java.base/sun.nio.fs.UnixFileSystem.<init>(UnixFileSystem.java:66)
>
>         at
> java.base/sun.nio.fs.LinuxFileSystem.<init>(LinuxFileSystem.java:39)
>
>         at
> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:46)
>
>         at
> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:39)
>
>         at
> java.base/sun.nio.fs.UnixFileSystemProvider.<init>(UnixFileSystemProvider.java:56)
>
>         at
> java.base/sun.nio.fs.LinuxFileSystemProvider.<init>(LinuxFileSystemProvider.java:41)
>
>         at
> java.base/sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemProvider.java:41)
>
>         at java.base/java.nio.file.FileSystems.<clinit>(FileSystems.java:91)
>
>         at java.base/java.nio.file.Paths.get(Paths.java:84)
>
>         at
> java.base/jdk.internal.jimage.ImageReaderFactory.<clinit>(ImageReaderFactory.java:50)
>
>         at java.base/java.security.AccessController.doPrivileged(Native
> Method)
>
>         at
> java.base/sun.net.www.protocol.jrt.JavaRuntimeURLConnection.<clinit>(JavaRuntimeURLConnection.java:59)
>
>         at
> java.base/sun.net.www.protocol.jrt.Handler.openConnection(Handler.java:42)
>
>         at java.base/java.net.URL.openConnection(URL.java:1049)
>
>         at
> java.base/jdk.internal.module.SystemModuleFinder$ImageModuleReader.checkPermissionToConnect(SystemModuleFinder.java:287)
>
>         at
> java.base/jdk.internal.module.SystemModuleFinder$ImageModuleReader.<init>(SystemModuleFinder.java:296)
>
>         at
> java.base/jdk.internal.module.SystemModuleFinder$1.get(SystemModuleFinder.java:245)
>
>         at
> java.base/jdk.internal.module.SystemModuleFinder$1.get(SystemModuleFinder.java:242)
>
>         at
> java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferenceImpl.java:83)
>
>         at
> java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(BuiltinClassLoader.java:934)
>
>         at
> java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1719)
>
>         at
> java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinClassLoader.java:926)
>
>         at
> java.base/jdk.internal.loader.BuiltinClassLoader.access$100(BuiltinClassLoader.java:92)
>
>         at
> java.base/jdk.internal.loader.BuiltinClassLoader$1.run(BuiltinClassLoader.java:356)
>
>         at
> java.base/jdk.internal.loader.BuiltinClassLoader$1.run(BuiltinClassLoader.java:351)
>
>         at java.base/java.security.AccessController.doPrivileged(Native
> Method)
>
>         at
> java.base/jdk.internal.loader.BuiltinClassLoader.findMiscResource(BuiltinClassLoader.java:350)
>
>         at
> java.base/jdk.internal.loader.BuiltinClassLoader.findResources(BuiltinClassLoader.java:311)
>
>         at
> java.base/jdk.internal.loader.BootLoader.findResources(BootLoader.java:156)
>
>         at
> java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1430)
>
>         at
> java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1428)
>
>         at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1082)
>
>         at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.access$1200(ServiceLoader.java:1004)
>
>         at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(ServiceLoader.java:1131)
>
>         at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(ServiceLoader.java:1130)
>
>         at java.base/java.security.AccessController.doPrivileged(Native
> Method)
>
>         at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1133)
>
>         at
> java.base/java.util.ServiceLoader$1.hasNext(ServiceLoader.java:1163)
>
>         at
> java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1258)
>
>         at
> java.base/java.nio.channels.spi.SelectorProvider.loadProviderAsService(SelectorProvider.java:122)
>
>         at
> java.base/java.nio.channels.spi.SelectorProvider.access$200(SelectorProvider.java:69)
>
>         at
> java.base/java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.java:180)
>
>         at
> java.base/java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.java:176)
>
>         at java.base/java.security.AccessController.doPrivileged(Native
> Method)
>
>         at
> java.base/java.nio.channels.spi.SelectorProvider.provider(SelectorProvider.java:175)
>
>         at java.base/java.lang.System.inheritedChannel(System.java:276)
>
>         at java.rmi/sun.rmi.server.Activation$2.run(Activation.java:1960)
>
>         at java.rmi/sun.rmi.server.Activation$2.run(Activation.java:1958)
>
>         at java.base/java.security.AccessController.doPrivileged(Native
> Method)
>
>         at java.rmi/sun.rmi.server.Activation.main(Activation.java:1957)
>
>
>


From christoph.langer at sap.com  Thu Feb 16 15:22:28 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 16 Feb 2017 15:22:28 +0000
Subject: rmid on Unix fails with Exception - maybe aftermath of
 JDK-8173607 ??
In-Reply-To: <d9c5ab08-86ef-88f4-eb14-4eb96ecef5b3@oracle.com>
References: <3c618ce8a236424cb72444ce3c0c744e@derote13de46.global.corp.sap>
 <d9c5ab08-86ef-88f4-eb14-4eb96ecef5b3@oracle.com>
Message-ID: <a195468fbc714f6fb84ffb0cd491516e@derote13de46.global.corp.sap>

Hi Daniel,

thanks for your hints - I should probably have seen that myself if I would have had a more thorough look...

I'm cc-ing nio-dev, maybe somebody has an idea. I probably won't be able to analyze this short term.

Best regards
Christoph

> -----Original Message-----
> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> Sent: Donnerstag, 16. Februar 2017 15:53
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: Zeller, Arno <arno.zeller at sap.com>; Baesken, Matthias
> <matthias.baesken at sap.com>; core-libs-dev at openjdk.java.net
> Subject: Re: rmid on Unix fails with Exception - maybe aftermath of JDK-
> 8173607 ??
> 
> Hi Christoph,
> 
> It looks like one of the dreaded class initialization cycle
> issues.
> 
> If you look at the stack trace, you will see that
> UnixNativeDispatcher.<clinit>:609
> calls System.loadLibrary at line 611
> which later down the road calls the
> native UnixNativeDispatcher.getcwd command
> from sun.nio.fs.UnixFileSystem.<init>
> 
> But at this point UnixNativeDispatcher has not
> finished initializing: we're still trying to load
> the nio lib...
> 
> I don't think this has anything to do with JDK-8173607.
> JDK-8173607 just splitted the JMX RMI Connector out of
> java.management - and rmid has nothing to do with JMX.
> 
> rmid doesn't depend on either java.management or
> java.management.rmi, and I don't see anything
> on the exception path that would involve either
> of these modules.
> So I suspect the culprit is probably elsewhere.
> 
> best regards,
> 
> -- daniel
> 
> 
> 
> On 16/02/17 13:53, Langer, Christoph wrote:
> > Hi Daniel,
> >
> >
> >
> > when starting "rmid" from current builds on Linux (and probably other
> > Unix platforms as well) we are currently getting the exception below.
> >
> >
> >
> > It looks as if on that path libnio was not loaded and hence we're
> > getting an UnsatisfiedLinkError. In UnixNativeDispatcher.java one can
> > find a static initialization block which should do that, however, it
> > needs elevated access. Maybe rmid is missing a permission for that?
> >
> >
> >
> > Any thoughts?
> >
> >
> >
> > Thanks & best regards
> >
> > Christoph
> >
> >
> >
> >
> >
> > ...>/jdk9-build-dir/images/jdk/bin/rmid
> >
> > Exception in thread "main" java.lang.UnsatisfiedLinkError:
> > sun.nio.fs.UnixNativeDispatcher.getcwd()[B
> >
> >         at java.base/sun.nio.fs.UnixNativeDispatcher.getcwd(Native Method)
> >
> >         at
> > java.base/sun.nio.fs.UnixFileSystem.<init>(UnixFileSystem.java:66)
> >
> >         at
> > java.base/sun.nio.fs.LinuxFileSystem.<init>(LinuxFileSystem.java:39)
> >
> >         at
> >
> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste
> mProvider.java:46)
> >
> >         at
> >
> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste
> mProvider.java:39)
> >
> >         at
> >
> java.base/sun.nio.fs.UnixFileSystemProvider.<init>(UnixFileSystemProvider.
> java:56)
> >
> >         at
> >
> java.base/sun.nio.fs.LinuxFileSystemProvider.<init>(LinuxFileSystemProvide
> r.java:41)
> >
> >         at
> >
> java.base/sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemPr
> ovider.java:41)
> >
> >         at
> > java.base/java.io.FilePermission.<clinit>(FilePermission.java:206)
> >
> >         at
> >
> java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:899)
> >
> >         at java.base/java.io.File.exists(File.java:815)
> >
> >         at java.base/java.lang.ClassLoader$2.run(ClassLoader.java:2513)
> >
> >         at java.base/java.lang.ClassLoader$2.run(ClassLoader.java:2510)
> >
> >         at java.base/java.security.AccessController.doPrivileged(Native
> > Method)
> >
> >         at
> > java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2509)
> >
> >         at
> > java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2478)
> >
> >         at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:873)
> >
> >         at java.base/java.lang.System.loadLibrary(System.java:1818)
> >
> >         at
> >
> java.base/sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java
> :611)
> >
> >         at
> >
> java.base/sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java
> :609)
> >
> >         at java.base/java.security.AccessController.doPrivileged(Native
> > Method)
> >
> >         at
> >
> java.base/sun.nio.fs.UnixNativeDispatcher.<clinit>(UnixNativeDispatcher.jav
> a:609)
> >
> >         at
> > java.base/sun.nio.fs.UnixFileSystem.<init>(UnixFileSystem.java:66)
> >
> >         at
> > java.base/sun.nio.fs.LinuxFileSystem.<init>(LinuxFileSystem.java:39)
> >
> >         at
> >
> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste
> mProvider.java:46)
> >
> >         at
> >
> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste
> mProvider.java:39)
> >
> >         at
> >
> java.base/sun.nio.fs.UnixFileSystemProvider.<init>(UnixFileSystemProvider.
> java:56)
> >
> >         at
> >
> java.base/sun.nio.fs.LinuxFileSystemProvider.<init>(LinuxFileSystemProvide
> r.java:41)
> >
> >         at
> >
> java.base/sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemPr
> ovider.java:41)
> >
> >         at java.base/java.nio.file.FileSystems.<clinit>(FileSystems.java:91)
> >
> >         at java.base/java.nio.file.Paths.get(Paths.java:84)
> >
> >         at
> >
> java.base/jdk.internal.jimage.ImageReaderFactory.<clinit>(ImageReaderFact
> ory.java:50)
> >
> >         at java.base/java.security.AccessController.doPrivileged(Native
> > Method)
> >
> >         at
> >
> java.base/sun.net.www.protocol.jrt.JavaRuntimeURLConnection.<clinit>(Jav
> aRuntimeURLConnection.java:59)
> >
> >         at
> >
> java.base/sun.net.www.protocol.jrt.Handler.openConnection(Handler.java:
> 42)
> >
> >         at java.base/java.net.URL.openConnection(URL.java:1049)
> >
> >         at
> >
> java.base/jdk.internal.module.SystemModuleFinder$ImageModuleReader.c
> heckPermissionToConnect(SystemModuleFinder.java:287)
> >
> >         at
> >
> java.base/jdk.internal.module.SystemModuleFinder$ImageModuleReader.<
> init>(SystemModuleFinder.java:296)
> >
> >         at
> >
> java.base/jdk.internal.module.SystemModuleFinder$1.get(SystemModuleFi
> nder.java:245)
> >
> >         at
> >
> java.base/jdk.internal.module.SystemModuleFinder$1.get(SystemModuleFi
> nder.java:242)
> >
> >         at
> >
> java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferen
> ceImpl.java:83)
> >
> >         at
> >
> java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(Builtin
> ClassLoader.java:934)
> >
> >         at
> >
> java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(Concu
> rrentHashMap.java:1719)
> >
> >         at
> >
> java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinCla
> ssLoader.java:926)
> >
> >         at
> >
> java.base/jdk.internal.loader.BuiltinClassLoader.access$100(BuiltinClassLoad
> er.java:92)
> >
> >         at
> >
> java.base/jdk.internal.loader.BuiltinClassLoader$1.run(BuiltinClassLoader.jav
> a:356)
> >
> >         at
> >
> java.base/jdk.internal.loader.BuiltinClassLoader$1.run(BuiltinClassLoader.jav
> a:351)
> >
> >         at java.base/java.security.AccessController.doPrivileged(Native
> > Method)
> >
> >         at
> >
> java.base/jdk.internal.loader.BuiltinClassLoader.findMiscResource(BuiltinCla
> ssLoader.java:350)
> >
> >         at
> >
> java.base/jdk.internal.loader.BuiltinClassLoader.findResources(BuiltinClassLo
> ader.java:311)
> >
> >         at
> >
> java.base/jdk.internal.loader.BootLoader.findResources(BootLoader.java:15
> 6)
> >
> >         at
> > java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1430)
> >
> >         at
> > java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1428)
> >
> >         at
> >
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextServi
> ce(ServiceLoader.java:1082)
> >
> >         at
> >
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.access$1200(
> ServiceLoader.java:1004)
> >
> >         at
> >
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Servic
> eLoader.java:1131)
> >
> >         at
> >
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Servic
> eLoader.java:1130)
> >
> >         at java.base/java.security.AccessController.doPrivileged(Native
> > Method)
> >
> >         at
> >
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(Ser
> viceLoader.java:1133)
> >
> >         at
> > java.base/java.util.ServiceLoader$1.hasNext(ServiceLoader.java:1163)
> >
> >         at
> > java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1258)
> >
> >         at
> >
> java.base/java.nio.channels.spi.SelectorProvider.loadProviderAsService(Sele
> ctorProvider.java:122)
> >
> >         at
> >
> java.base/java.nio.channels.spi.SelectorProvider.access$200(SelectorProvide
> r.java:69)
> >
> >         at
> >
> java.base/java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.jav
> a:180)
> >
> >         at
> >
> java.base/java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.jav
> a:176)
> >
> >         at java.base/java.security.AccessController.doPrivileged(Native
> > Method)
> >
> >         at
> >
> java.base/java.nio.channels.spi.SelectorProvider.provider(SelectorProvider.j
> ava:175)
> >
> >         at java.base/java.lang.System.inheritedChannel(System.java:276)
> >
> >         at java.rmi/sun.rmi.server.Activation$2.run(Activation.java:1960)
> >
> >         at java.rmi/sun.rmi.server.Activation$2.run(Activation.java:1958)
> >
> >         at java.base/java.security.AccessController.doPrivileged(Native
> > Method)
> >
> >         at java.rmi/sun.rmi.server.Activation.main(Activation.java:1957)
> >
> >
> >


From Alan.Bateman at oracle.com  Thu Feb 16 16:01:37 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 16 Feb 2017 16:01:37 +0000
Subject: rmid on Unix fails with Exception - maybe aftermath of
 JDK-8173607 ??
In-Reply-To: <d9c5ab08-86ef-88f4-eb14-4eb96ecef5b3@oracle.com>
References: <3c618ce8a236424cb72444ce3c0c744e@derote13de46.global.corp.sap>
 <d9c5ab08-86ef-88f4-eb14-4eb96ecef5b3@oracle.com>
Message-ID: <ade8e7bb-fa60-3e03-451a-a2b2253fdc37@oracle.com>

On 16/02/2017 14:52, Daniel Fuchs wrote:

> :
>
> I don't think this has anything to do with JDK-8173607.
> JDK-8173607 just splitted the JMX RMI Connector out of
> java.management - and rmid has nothing to do with JMX.
>
> rmid doesn't depend on either java.management or
> java.management.rmi, and I don't see anything
> on the exception path that would involve either
> of these modules.
> So I suspect the culprit is probably elsewhere.
Right, this is nothing to do with the JMX changes. I think this is 
tickled by the recent change from Claes to create the image reader 
lazily. I guess the rmid tests might be disabled because it would have 
otherwise been seen before now.

-Alan

From daniel.fuchs at oracle.com  Thu Feb 16 16:02:15 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 16 Feb 2017 16:02:15 +0000
Subject: rmid on Unix fails with Exception - maybe aftermath of
 JDK-8173607 ??
In-Reply-To: <a195468fbc714f6fb84ffb0cd491516e@derote13de46.global.corp.sap>
References: <3c618ce8a236424cb72444ce3c0c744e@derote13de46.global.corp.sap>
 <d9c5ab08-86ef-88f4-eb14-4eb96ecef5b3@oracle.com>
 <a195468fbc714f6fb84ffb0cd491516e@derote13de46.global.corp.sap>
Message-ID: <8d01d5b9-56a4-af3a-8336-ce123235619c@oracle.com>

On 16/02/17 15:22, Langer, Christoph wrote:
> Hi Daniel,
>
> thanks for your hints - I should probably have seen that myself if I would have had a more thorough look...
>
> I'm cc-ing nio-dev, maybe somebody has an idea. I probably won't be able to analyze this short term.

No problem. Do you know when that started showing up?

best regards,

-- daniel

>
> Best regards
> Christoph
>
>> -----Original Message-----
>> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
>> Sent: Donnerstag, 16. Februar 2017 15:53
>> To: Langer, Christoph <christoph.langer at sap.com>
>> Cc: Zeller, Arno <arno.zeller at sap.com>; Baesken, Matthias
>> <matthias.baesken at sap.com>; core-libs-dev at openjdk.java.net
>> Subject: Re: rmid on Unix fails with Exception - maybe aftermath of JDK-
>> 8173607 ??
>>
>> Hi Christoph,
>>
>> It looks like one of the dreaded class initialization cycle
>> issues.
>>
>> If you look at the stack trace, you will see that
>> UnixNativeDispatcher.<clinit>:609
>> calls System.loadLibrary at line 611
>> which later down the road calls the
>> native UnixNativeDispatcher.getcwd command
>> from sun.nio.fs.UnixFileSystem.<init>
>>
>> But at this point UnixNativeDispatcher has not
>> finished initializing: we're still trying to load
>> the nio lib...
>>
>> I don't think this has anything to do with JDK-8173607.
>> JDK-8173607 just splitted the JMX RMI Connector out of
>> java.management - and rmid has nothing to do with JMX.
>>
>> rmid doesn't depend on either java.management or
>> java.management.rmi, and I don't see anything
>> on the exception path that would involve either
>> of these modules.
>> So I suspect the culprit is probably elsewhere.
>>
>> best regards,
>>
>> -- daniel
>>
>>
>>
>> On 16/02/17 13:53, Langer, Christoph wrote:
>>> Hi Daniel,
>>>
>>>
>>>
>>> when starting "rmid" from current builds on Linux (and probably other
>>> Unix platforms as well) we are currently getting the exception below.
>>>
>>>
>>>
>>> It looks as if on that path libnio was not loaded and hence we're
>>> getting an UnsatisfiedLinkError. In UnixNativeDispatcher.java one can
>>> find a static initialization block which should do that, however, it
>>> needs elevated access. Maybe rmid is missing a permission for that?
>>>
>>>
>>>
>>> Any thoughts?
>>>
>>>
>>>
>>> Thanks & best regards
>>>
>>> Christoph
>>>
>>>
>>>
>>>
>>>
>>> ...>/jdk9-build-dir/images/jdk/bin/rmid
>>>
>>> Exception in thread "main" java.lang.UnsatisfiedLinkError:
>>> sun.nio.fs.UnixNativeDispatcher.getcwd()[B
>>>
>>>         at java.base/sun.nio.fs.UnixNativeDispatcher.getcwd(Native Method)
>>>
>>>         at
>>> java.base/sun.nio.fs.UnixFileSystem.<init>(UnixFileSystem.java:66)
>>>
>>>         at
>>> java.base/sun.nio.fs.LinuxFileSystem.<init>(LinuxFileSystem.java:39)
>>>
>>>         at
>>>
>> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste
>> mProvider.java:46)
>>>
>>>         at
>>>
>> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste
>> mProvider.java:39)
>>>
>>>         at
>>>
>> java.base/sun.nio.fs.UnixFileSystemProvider.<init>(UnixFileSystemProvider.
>> java:56)
>>>
>>>         at
>>>
>> java.base/sun.nio.fs.LinuxFileSystemProvider.<init>(LinuxFileSystemProvide
>> r.java:41)
>>>
>>>         at
>>>
>> java.base/sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemPr
>> ovider.java:41)
>>>
>>>         at
>>> java.base/java.io.FilePermission.<clinit>(FilePermission.java:206)
>>>
>>>         at
>>>
>> java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:899)
>>>
>>>         at java.base/java.io.File.exists(File.java:815)
>>>
>>>         at java.base/java.lang.ClassLoader$2.run(ClassLoader.java:2513)
>>>
>>>         at java.base/java.lang.ClassLoader$2.run(ClassLoader.java:2510)
>>>
>>>         at java.base/java.security.AccessController.doPrivileged(Native
>>> Method)
>>>
>>>         at
>>> java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2509)
>>>
>>>         at
>>> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2478)
>>>
>>>         at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:873)
>>>
>>>         at java.base/java.lang.System.loadLibrary(System.java:1818)
>>>
>>>         at
>>>
>> java.base/sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java
>> :611)
>>>
>>>         at
>>>
>> java.base/sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java
>> :609)
>>>
>>>         at java.base/java.security.AccessController.doPrivileged(Native
>>> Method)
>>>
>>>         at
>>>
>> java.base/sun.nio.fs.UnixNativeDispatcher.<clinit>(UnixNativeDispatcher.jav
>> a:609)
>>>
>>>         at
>>> java.base/sun.nio.fs.UnixFileSystem.<init>(UnixFileSystem.java:66)
>>>
>>>         at
>>> java.base/sun.nio.fs.LinuxFileSystem.<init>(LinuxFileSystem.java:39)
>>>
>>>         at
>>>
>> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste
>> mProvider.java:46)
>>>
>>>         at
>>>
>> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste
>> mProvider.java:39)
>>>
>>>         at
>>>
>> java.base/sun.nio.fs.UnixFileSystemProvider.<init>(UnixFileSystemProvider.
>> java:56)
>>>
>>>         at
>>>
>> java.base/sun.nio.fs.LinuxFileSystemProvider.<init>(LinuxFileSystemProvide
>> r.java:41)
>>>
>>>         at
>>>
>> java.base/sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemPr
>> ovider.java:41)
>>>
>>>         at java.base/java.nio.file.FileSystems.<clinit>(FileSystems.java:91)
>>>
>>>         at java.base/java.nio.file.Paths.get(Paths.java:84)
>>>
>>>         at
>>>
>> java.base/jdk.internal.jimage.ImageReaderFactory.<clinit>(ImageReaderFact
>> ory.java:50)
>>>
>>>         at java.base/java.security.AccessController.doPrivileged(Native
>>> Method)
>>>
>>>         at
>>>
>> java.base/sun.net.www.protocol.jrt.JavaRuntimeURLConnection.<clinit>(Jav
>> aRuntimeURLConnection.java:59)
>>>
>>>         at
>>>
>> java.base/sun.net.www.protocol.jrt.Handler.openConnection(Handler.java:
>> 42)
>>>
>>>         at java.base/java.net.URL.openConnection(URL.java:1049)
>>>
>>>         at
>>>
>> java.base/jdk.internal.module.SystemModuleFinder$ImageModuleReader.c
>> heckPermissionToConnect(SystemModuleFinder.java:287)
>>>
>>>         at
>>>
>> java.base/jdk.internal.module.SystemModuleFinder$ImageModuleReader.<
>> init>(SystemModuleFinder.java:296)
>>>
>>>         at
>>>
>> java.base/jdk.internal.module.SystemModuleFinder$1.get(SystemModuleFi
>> nder.java:245)
>>>
>>>         at
>>>
>> java.base/jdk.internal.module.SystemModuleFinder$1.get(SystemModuleFi
>> nder.java:242)
>>>
>>>         at
>>>
>> java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferen
>> ceImpl.java:83)
>>>
>>>         at
>>>
>> java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(Builtin
>> ClassLoader.java:934)
>>>
>>>         at
>>>
>> java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(Concu
>> rrentHashMap.java:1719)
>>>
>>>         at
>>>
>> java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinCla
>> ssLoader.java:926)
>>>
>>>         at
>>>
>> java.base/jdk.internal.loader.BuiltinClassLoader.access$100(BuiltinClassLoad
>> er.java:92)
>>>
>>>         at
>>>
>> java.base/jdk.internal.loader.BuiltinClassLoader$1.run(BuiltinClassLoader.jav
>> a:356)
>>>
>>>         at
>>>
>> java.base/jdk.internal.loader.BuiltinClassLoader$1.run(BuiltinClassLoader.jav
>> a:351)
>>>
>>>         at java.base/java.security.AccessController.doPrivileged(Native
>>> Method)
>>>
>>>         at
>>>
>> java.base/jdk.internal.loader.BuiltinClassLoader.findMiscResource(BuiltinCla
>> ssLoader.java:350)
>>>
>>>         at
>>>
>> java.base/jdk.internal.loader.BuiltinClassLoader.findResources(BuiltinClassLo
>> ader.java:311)
>>>
>>>         at
>>>
>> java.base/jdk.internal.loader.BootLoader.findResources(BootLoader.java:15
>> 6)
>>>
>>>         at
>>> java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1430)
>>>
>>>         at
>>> java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1428)
>>>
>>>         at
>>>
>> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextServi
>> ce(ServiceLoader.java:1082)
>>>
>>>         at
>>>
>> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.access$1200(
>> ServiceLoader.java:1004)
>>>
>>>         at
>>>
>> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Servic
>> eLoader.java:1131)
>>>
>>>         at
>>>
>> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Servic
>> eLoader.java:1130)
>>>
>>>         at java.base/java.security.AccessController.doPrivileged(Native
>>> Method)
>>>
>>>         at
>>>
>> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(Ser
>> viceLoader.java:1133)
>>>
>>>         at
>>> java.base/java.util.ServiceLoader$1.hasNext(ServiceLoader.java:1163)
>>>
>>>         at
>>> java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1258)
>>>
>>>         at
>>>
>> java.base/java.nio.channels.spi.SelectorProvider.loadProviderAsService(Sele
>> ctorProvider.java:122)
>>>
>>>         at
>>>
>> java.base/java.nio.channels.spi.SelectorProvider.access$200(SelectorProvide
>> r.java:69)
>>>
>>>         at
>>>
>> java.base/java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.jav
>> a:180)
>>>
>>>         at
>>>
>> java.base/java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.jav
>> a:176)
>>>
>>>         at java.base/java.security.AccessController.doPrivileged(Native
>>> Method)
>>>
>>>         at
>>>
>> java.base/java.nio.channels.spi.SelectorProvider.provider(SelectorProvider.j
>> ava:175)
>>>
>>>         at java.base/java.lang.System.inheritedChannel(System.java:276)
>>>
>>>         at java.rmi/sun.rmi.server.Activation$2.run(Activation.java:1960)
>>>
>>>         at java.rmi/sun.rmi.server.Activation$2.run(Activation.java:1958)
>>>
>>>         at java.base/java.security.AccessController.doPrivileged(Native
>>> Method)
>>>
>>>         at java.rmi/sun.rmi.server.Activation.main(Activation.java:1957)
>>>
>>>
>>>
>


From christoph.langer at sap.com  Thu Feb 16 16:03:48 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 16 Feb 2017 16:03:48 +0000
Subject: rmid on Unix fails with Exception - maybe aftermath of
 JDK-8173607 ??
In-Reply-To: <8d01d5b9-56a4-af3a-8336-ce123235619c@oracle.com>
References: <3c618ce8a236424cb72444ce3c0c744e@derote13de46.global.corp.sap>
 <d9c5ab08-86ef-88f4-eb14-4eb96ecef5b3@oracle.com>
 <a195468fbc714f6fb84ffb0cd491516e@derote13de46.global.corp.sap>
 <8d01d5b9-56a4-af3a-8336-ce123235619c@oracle.com>
Message-ID: <ba5b821f148047ef91f81c20f4fcd3e9@derote13de46.global.corp.sap>

The colleagues tell me that it was about two weeks ago. But I guess it's rather a felt experience than a concrete date ;-)

> -----Original Message-----
> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> Sent: Donnerstag, 16. Februar 2017 17:02
> To: Langer, Christoph <christoph.langer at sap.com>; nio-
> dev at openjdk.java.net
> Cc: Zeller, Arno <arno.zeller at sap.com>; Baesken, Matthias
> <matthias.baesken at sap.com>; core-libs-dev at openjdk.java.net
> Subject: Re: rmid on Unix fails with Exception - maybe aftermath of JDK-
> 8173607 ??
> 
> On 16/02/17 15:22, Langer, Christoph wrote:
> > Hi Daniel,
> >
> > thanks for your hints - I should probably have seen that myself if I would
> have had a more thorough look...
> >
> > I'm cc-ing nio-dev, maybe somebody has an idea. I probably won't be able
> to analyze this short term.
> 
> No problem. Do you know when that started showing up?
> 
> best regards,
> 
> -- daniel
> 
> >
> > Best regards
> > Christoph
> >
> >> -----Original Message-----
> >> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> >> Sent: Donnerstag, 16. Februar 2017 15:53
> >> To: Langer, Christoph <christoph.langer at sap.com>
> >> Cc: Zeller, Arno <arno.zeller at sap.com>; Baesken, Matthias
> >> <matthias.baesken at sap.com>; core-libs-dev at openjdk.java.net
> >> Subject: Re: rmid on Unix fails with Exception - maybe aftermath of JDK-
> >> 8173607 ??
> >>
> >> Hi Christoph,
> >>
> >> It looks like one of the dreaded class initialization cycle
> >> issues.
> >>
> >> If you look at the stack trace, you will see that
> >> UnixNativeDispatcher.<clinit>:609
> >> calls System.loadLibrary at line 611
> >> which later down the road calls the
> >> native UnixNativeDispatcher.getcwd command
> >> from sun.nio.fs.UnixFileSystem.<init>
> >>
> >> But at this point UnixNativeDispatcher has not
> >> finished initializing: we're still trying to load
> >> the nio lib...
> >>
> >> I don't think this has anything to do with JDK-8173607.
> >> JDK-8173607 just splitted the JMX RMI Connector out of
> >> java.management - and rmid has nothing to do with JMX.
> >>
> >> rmid doesn't depend on either java.management or
> >> java.management.rmi, and I don't see anything
> >> on the exception path that would involve either
> >> of these modules.
> >> So I suspect the culprit is probably elsewhere.
> >>
> >> best regards,
> >>
> >> -- daniel
> >>
> >>
> >>
> >> On 16/02/17 13:53, Langer, Christoph wrote:
> >>> Hi Daniel,
> >>>
> >>>
> >>>
> >>> when starting "rmid" from current builds on Linux (and probably other
> >>> Unix platforms as well) we are currently getting the exception below.
> >>>
> >>>
> >>>
> >>> It looks as if on that path libnio was not loaded and hence we're
> >>> getting an UnsatisfiedLinkError. In UnixNativeDispatcher.java one can
> >>> find a static initialization block which should do that, however, it
> >>> needs elevated access. Maybe rmid is missing a permission for that?
> >>>
> >>>
> >>>
> >>> Any thoughts?
> >>>
> >>>
> >>>
> >>> Thanks & best regards
> >>>
> >>> Christoph
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ...>/jdk9-build-dir/images/jdk/bin/rmid
> >>>
> >>> Exception in thread "main" java.lang.UnsatisfiedLinkError:
> >>> sun.nio.fs.UnixNativeDispatcher.getcwd()[B
> >>>
> >>>         at java.base/sun.nio.fs.UnixNativeDispatcher.getcwd(Native
> Method)
> >>>
> >>>         at
> >>> java.base/sun.nio.fs.UnixFileSystem.<init>(UnixFileSystem.java:66)
> >>>
> >>>         at
> >>> java.base/sun.nio.fs.LinuxFileSystem.<init>(LinuxFileSystem.java:39)
> >>>
> >>>         at
> >>>
> >>
> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste
> >> mProvider.java:46)
> >>>
> >>>         at
> >>>
> >>
> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste
> >> mProvider.java:39)
> >>>
> >>>         at
> >>>
> >>
> java.base/sun.nio.fs.UnixFileSystemProvider.<init>(UnixFileSystemProvider.
> >> java:56)
> >>>
> >>>         at
> >>>
> >>
> java.base/sun.nio.fs.LinuxFileSystemProvider.<init>(LinuxFileSystemProvide
> >> r.java:41)
> >>>
> >>>         at
> >>>
> >>
> java.base/sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemPr
> >> ovider.java:41)
> >>>
> >>>         at
> >>> java.base/java.io.FilePermission.<clinit>(FilePermission.java:206)
> >>>
> >>>         at
> >>>
> >>
> java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:899)
> >>>
> >>>         at java.base/java.io.File.exists(File.java:815)
> >>>
> >>>         at java.base/java.lang.ClassLoader$2.run(ClassLoader.java:2513)
> >>>
> >>>         at java.base/java.lang.ClassLoader$2.run(ClassLoader.java:2510)
> >>>
> >>>         at java.base/java.security.AccessController.doPrivileged(Native
> >>> Method)
> >>>
> >>>         at
> >>> java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2509)
> >>>
> >>>         at
> >>> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2478)
> >>>
> >>>         at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:873)
> >>>
> >>>         at java.base/java.lang.System.loadLibrary(System.java:1818)
> >>>
> >>>         at
> >>>
> >>
> java.base/sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java
> >> :611)
> >>>
> >>>         at
> >>>
> >>
> java.base/sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java
> >> :609)
> >>>
> >>>         at java.base/java.security.AccessController.doPrivileged(Native
> >>> Method)
> >>>
> >>>         at
> >>>
> >>
> java.base/sun.nio.fs.UnixNativeDispatcher.<clinit>(UnixNativeDispatcher.jav
> >> a:609)
> >>>
> >>>         at
> >>> java.base/sun.nio.fs.UnixFileSystem.<init>(UnixFileSystem.java:66)
> >>>
> >>>         at
> >>> java.base/sun.nio.fs.LinuxFileSystem.<init>(LinuxFileSystem.java:39)
> >>>
> >>>         at
> >>>
> >>
> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste
> >> mProvider.java:46)
> >>>
> >>>         at
> >>>
> >>
> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste
> >> mProvider.java:39)
> >>>
> >>>         at
> >>>
> >>
> java.base/sun.nio.fs.UnixFileSystemProvider.<init>(UnixFileSystemProvider.
> >> java:56)
> >>>
> >>>         at
> >>>
> >>
> java.base/sun.nio.fs.LinuxFileSystemProvider.<init>(LinuxFileSystemProvide
> >> r.java:41)
> >>>
> >>>         at
> >>>
> >>
> java.base/sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemPr
> >> ovider.java:41)
> >>>
> >>>         at java.base/java.nio.file.FileSystems.<clinit>(FileSystems.java:91)
> >>>
> >>>         at java.base/java.nio.file.Paths.get(Paths.java:84)
> >>>
> >>>         at
> >>>
> >>
> java.base/jdk.internal.jimage.ImageReaderFactory.<clinit>(ImageReaderFact
> >> ory.java:50)
> >>>
> >>>         at java.base/java.security.AccessController.doPrivileged(Native
> >>> Method)
> >>>
> >>>         at
> >>>
> >>
> java.base/sun.net.www.protocol.jrt.JavaRuntimeURLConnection.<clinit>(Jav
> >> aRuntimeURLConnection.java:59)
> >>>
> >>>         at
> >>>
> >>
> java.base/sun.net.www.protocol.jrt.Handler.openConnection(Handler.java:
> >> 42)
> >>>
> >>>         at java.base/java.net.URL.openConnection(URL.java:1049)
> >>>
> >>>         at
> >>>
> >>
> java.base/jdk.internal.module.SystemModuleFinder$ImageModuleReader.c
> >> heckPermissionToConnect(SystemModuleFinder.java:287)
> >>>
> >>>         at
> >>>
> >>
> java.base/jdk.internal.module.SystemModuleFinder$ImageModuleReader.<
> >> init>(SystemModuleFinder.java:296)
> >>>
> >>>         at
> >>>
> >>
> java.base/jdk.internal.module.SystemModuleFinder$1.get(SystemModuleFi
> >> nder.java:245)
> >>>
> >>>         at
> >>>
> >>
> java.base/jdk.internal.module.SystemModuleFinder$1.get(SystemModuleFi
> >> nder.java:242)
> >>>
> >>>         at
> >>>
> >>
> java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferen
> >> ceImpl.java:83)
> >>>
> >>>         at
> >>>
> >>
> java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(Builtin
> >> ClassLoader.java:934)
> >>>
> >>>         at
> >>>
> >>
> java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(Concu
> >> rrentHashMap.java:1719)
> >>>
> >>>         at
> >>>
> >>
> java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinCla
> >> ssLoader.java:926)
> >>>
> >>>         at
> >>>
> >>
> java.base/jdk.internal.loader.BuiltinClassLoader.access$100(BuiltinClassLoad
> >> er.java:92)
> >>>
> >>>         at
> >>>
> >>
> java.base/jdk.internal.loader.BuiltinClassLoader$1.run(BuiltinClassLoader.jav
> >> a:356)
> >>>
> >>>         at
> >>>
> >>
> java.base/jdk.internal.loader.BuiltinClassLoader$1.run(BuiltinClassLoader.jav
> >> a:351)
> >>>
> >>>         at java.base/java.security.AccessController.doPrivileged(Native
> >>> Method)
> >>>
> >>>         at
> >>>
> >>
> java.base/jdk.internal.loader.BuiltinClassLoader.findMiscResource(BuiltinCla
> >> ssLoader.java:350)
> >>>
> >>>         at
> >>>
> >>
> java.base/jdk.internal.loader.BuiltinClassLoader.findResources(BuiltinClassLo
> >> ader.java:311)
> >>>
> >>>         at
> >>>
> >>
> java.base/jdk.internal.loader.BootLoader.findResources(BootLoader.java:15
> >> 6)
> >>>
> >>>         at
> >>> java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1430)
> >>>
> >>>         at
> >>> java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1428)
> >>>
> >>>         at
> >>>
> >>
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextServi
> >> ce(ServiceLoader.java:1082)
> >>>
> >>>         at
> >>>
> >>
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.access$1200(
> >> ServiceLoader.java:1004)
> >>>
> >>>         at
> >>>
> >>
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Servic
> >> eLoader.java:1131)
> >>>
> >>>         at
> >>>
> >>
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Servic
> >> eLoader.java:1130)
> >>>
> >>>         at java.base/java.security.AccessController.doPrivileged(Native
> >>> Method)
> >>>
> >>>         at
> >>>
> >>
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(Ser
> >> viceLoader.java:1133)
> >>>
> >>>         at
> >>> java.base/java.util.ServiceLoader$1.hasNext(ServiceLoader.java:1163)
> >>>
> >>>         at
> >>> java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1258)
> >>>
> >>>         at
> >>>
> >>
> java.base/java.nio.channels.spi.SelectorProvider.loadProviderAsService(Sele
> >> ctorProvider.java:122)
> >>>
> >>>         at
> >>>
> >>
> java.base/java.nio.channels.spi.SelectorProvider.access$200(SelectorProvide
> >> r.java:69)
> >>>
> >>>         at
> >>>
> >>
> java.base/java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.jav
> >> a:180)
> >>>
> >>>         at
> >>>
> >>
> java.base/java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.jav
> >> a:176)
> >>>
> >>>         at java.base/java.security.AccessController.doPrivileged(Native
> >>> Method)
> >>>
> >>>         at
> >>>
> >>
> java.base/java.nio.channels.spi.SelectorProvider.provider(SelectorProvider.j
> >> ava:175)
> >>>
> >>>         at java.base/java.lang.System.inheritedChannel(System.java:276)
> >>>
> >>>         at java.rmi/sun.rmi.server.Activation$2.run(Activation.java:1960)
> >>>
> >>>         at java.rmi/sun.rmi.server.Activation$2.run(Activation.java:1958)
> >>>
> >>>         at java.base/java.security.AccessController.doPrivileged(Native
> >>> Method)
> >>>
> >>>         at java.rmi/sun.rmi.server.Activation.main(Activation.java:1957)
> >>>
> >>>
> >>>
> >


From claes.redestad at oracle.com  Thu Feb 16 16:11:23 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 16 Feb 2017 17:11:23 +0100
Subject: rmid on Unix fails with Exception - maybe aftermath of
 JDK-8173607 ??
In-Reply-To: <ade8e7bb-fa60-3e03-451a-a2b2253fdc37@oracle.com>
References: <3c618ce8a236424cb72444ce3c0c744e@derote13de46.global.corp.sap>
 <d9c5ab08-86ef-88f4-eb14-4eb96ecef5b3@oracle.com>
 <ade8e7bb-fa60-3e03-451a-a2b2253fdc37@oracle.com>
Message-ID: <9cebee17-090c-309e-5724-a69b8d29d96b@oracle.com>

Yes, verified that reverting to eager initialization of the system image 
reader avoids this issue. I guess we need to back this optimization out 
and see if we can improve things in the future:

diff -r 32cb9898b630 
src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
--- 
a/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java 
Thu Feb 16 17:05:48 2017 +0100
+++ 
b/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java 
Thu Feb 16 17:08:12 2017 +0100
@@ -115,12 +115,7 @@
          long t0 = System.nanoTime();

          // system modules (may be patched)
-        ModuleFinder systemModules;
-        if (SystemModules.MODULE_NAMES.length > 0) {
-            systemModules = SystemModuleFinder.getInstance();
-        } else {
-            systemModules = ModuleFinder.ofSystem();
-        }
+        ModuleFinder systemModules = ModuleFinder.ofSystem();

          PerfCounters.systemModulesTime.addElapsedTimeFrom(t0);



/Claes

On 02/16/2017 05:01 PM, Alan Bateman wrote:
> On 16/02/2017 14:52, Daniel Fuchs wrote:
>
>> :
>>
>> I don't think this has anything to do with JDK-8173607.
>> JDK-8173607 just splitted the JMX RMI Connector out of
>> java.management - and rmid has nothing to do with JMX.
>>
>> rmid doesn't depend on either java.management or
>> java.management.rmi, and I don't see anything
>> on the exception path that would involve either
>> of these modules.
>> So I suspect the culprit is probably elsewhere.
> Right, this is nothing to do with the JMX changes. I think this is 
> tickled by the recent change from Claes to create the image reader 
> lazily. I guess the rmid tests might be disabled because it would have 
> otherwise been seen before now.
>
> -Alan


From matthias.baesken at sap.com  Thu Feb 16 16:13:54 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 16 Feb 2017 16:13:54 +0000
Subject: rmid on Unix fails with Exception - maybe aftermath of
 JDK-8173607 ??
In-Reply-To: <ba5b821f148047ef91f81c20f4fcd3e9@derote13de46.global.corp.sap>
References: <3c618ce8a236424cb72444ce3c0c744e@derote13de46.global.corp.sap>
 <d9c5ab08-86ef-88f4-eb14-4eb96ecef5b3@oracle.com>
 <a195468fbc714f6fb84ffb0cd491516e@derote13de46.global.corp.sap>
 <8d01d5b9-56a4-af3a-8336-ce123235619c@oracle.com>
 <ba5b821f148047ef91f81c20f4fcd3e9@derote13de46.global.corp.sap>
Message-ID: <0d45e9c147604306ab1785df85112592@DEWDFE13DE14.global.corp.sap>

It started showing up  ~ 5 / 6 th  February  (talking about  openjdk 9  dev ).

Regards, Matthias


> -----Original Message-----
> From: Langer, Christoph
> Sent: Donnerstag, 16. Februar 2017 17:04
> To: Daniel Fuchs <daniel.fuchs at oracle.com>; nio-dev at openjdk.java.net
> Cc: Zeller, Arno <arno.zeller at sap.com>; Baesken, Matthias
> <matthias.baesken at sap.com>; core-libs-dev at openjdk.java.net
> Subject: RE: rmid on Unix fails with Exception - maybe aftermath of JDK-
> 8173607 ??
> 
> The colleagues tell me that it was about two weeks ago. But I guess it's rather
> a felt experience than a concrete date ;-)
> 
> > -----Original Message-----
> > From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> > Sent: Donnerstag, 16. Februar 2017 17:02
> > To: Langer, Christoph <christoph.langer at sap.com>; nio-
> > dev at openjdk.java.net
> > Cc: Zeller, Arno <arno.zeller at sap.com>; Baesken, Matthias
> > <matthias.baesken at sap.com>; core-libs-dev at openjdk.java.net
> > Subject: Re: rmid on Unix fails with Exception - maybe aftermath of JDK-
> > 8173607 ??
> >
> > On 16/02/17 15:22, Langer, Christoph wrote:
> > > Hi Daniel,
> > >
> > > thanks for your hints - I should probably have seen that myself if I would
> > have had a more thorough look...
> > >
> > > I'm cc-ing nio-dev, maybe somebody has an idea. I probably won't be
> able
> > to analyze this short term.
> >
> > No problem. Do you know when that started showing up?
> >
> > best regards,
> >
> > -- daniel
> >
> > >
> > > Best regards
> > > Christoph
> > >
> > >> -----Original Message-----
> > >> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> > >> Sent: Donnerstag, 16. Februar 2017 15:53
> > >> To: Langer, Christoph <christoph.langer at sap.com>
> > >> Cc: Zeller, Arno <arno.zeller at sap.com>; Baesken, Matthias
> > >> <matthias.baesken at sap.com>; core-libs-dev at openjdk.java.net
> > >> Subject: Re: rmid on Unix fails with Exception - maybe aftermath of JDK-
> > >> 8173607 ??
> > >>
> > >> Hi Christoph,
> > >>
> > >> It looks like one of the dreaded class initialization cycle
> > >> issues.
> > >>
> > >> If you look at the stack trace, you will see that
> > >> UnixNativeDispatcher.<clinit>:609
> > >> calls System.loadLibrary at line 611
> > >> which later down the road calls the
> > >> native UnixNativeDispatcher.getcwd command
> > >> from sun.nio.fs.UnixFileSystem.<init>
> > >>
> > >> But at this point UnixNativeDispatcher has not
> > >> finished initializing: we're still trying to load
> > >> the nio lib...
> > >>
> > >> I don't think this has anything to do with JDK-8173607.
> > >> JDK-8173607 just splitted the JMX RMI Connector out of
> > >> java.management - and rmid has nothing to do with JMX.
> > >>
> > >> rmid doesn't depend on either java.management or
> > >> java.management.rmi, and I don't see anything
> > >> on the exception path that would involve either
> > >> of these modules.
> > >> So I suspect the culprit is probably elsewhere.
> > >>
> > >> best regards,
> > >>
> > >> -- daniel
> > >>
> > >>
> > >>
> > >> On 16/02/17 13:53, Langer, Christoph wrote:
> > >>> Hi Daniel,
> > >>>
> > >>>
> > >>>
> > >>> when starting "rmid" from current builds on Linux (and probably other
> > >>> Unix platforms as well) we are currently getting the exception below.
> > >>>
> > >>>
> > >>>
> > >>> It looks as if on that path libnio was not loaded and hence we're
> > >>> getting an UnsatisfiedLinkError. In UnixNativeDispatcher.java one can
> > >>> find a static initialization block which should do that, however, it
> > >>> needs elevated access. Maybe rmid is missing a permission for that?
> > >>>
> > >>>
> > >>>
> > >>> Any thoughts?
> > >>>
> > >>>
> > >>>
> > >>> Thanks & best regards
> > >>>
> > >>> Christoph
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> ...>/jdk9-build-dir/images/jdk/bin/rmid
> > >>>
> > >>> Exception in thread "main" java.lang.UnsatisfiedLinkError:
> > >>> sun.nio.fs.UnixNativeDispatcher.getcwd()[B
> > >>>
> > >>>         at java.base/sun.nio.fs.UnixNativeDispatcher.getcwd(Native
> > Method)
> > >>>
> > >>>         at
> > >>> java.base/sun.nio.fs.UnixFileSystem.<init>(UnixFileSystem.java:66)
> > >>>
> > >>>         at
> > >>> java.base/sun.nio.fs.LinuxFileSystem.<init>(LinuxFileSystem.java:39)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste
> > >> mProvider.java:46)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste
> > >> mProvider.java:39)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/sun.nio.fs.UnixFileSystemProvider.<init>(UnixFileSystemProvider.
> > >> java:56)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/sun.nio.fs.LinuxFileSystemProvider.<init>(LinuxFileSystemProvide
> > >> r.java:41)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemPr
> > >> ovider.java:41)
> > >>>
> > >>>         at
> > >>> java.base/java.io.FilePermission.<clinit>(FilePermission.java:206)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:899)
> > >>>
> > >>>         at java.base/java.io.File.exists(File.java:815)
> > >>>
> > >>>         at java.base/java.lang.ClassLoader$2.run(ClassLoader.java:2513)
> > >>>
> > >>>         at java.base/java.lang.ClassLoader$2.run(ClassLoader.java:2510)
> > >>>
> > >>>         at java.base/java.security.AccessController.doPrivileged(Native
> > >>> Method)
> > >>>
> > >>>         at
> > >>> java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2509)
> > >>>
> > >>>         at
> > >>> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2478)
> > >>>
> > >>>         at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:873)
> > >>>
> > >>>         at java.base/java.lang.System.loadLibrary(System.java:1818)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java
> > >> :611)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/sun.nio.fs.UnixNativeDispatcher$1.run(UnixNativeDispatcher.java
> > >> :609)
> > >>>
> > >>>         at java.base/java.security.AccessController.doPrivileged(Native
> > >>> Method)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/sun.nio.fs.UnixNativeDispatcher.<clinit>(UnixNativeDispatcher.jav
> > >> a:609)
> > >>>
> > >>>         at
> > >>> java.base/sun.nio.fs.UnixFileSystem.<init>(UnixFileSystem.java:66)
> > >>>
> > >>>         at
> > >>> java.base/sun.nio.fs.LinuxFileSystem.<init>(LinuxFileSystem.java:39)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste
> > >> mProvider.java:46)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSyste
> > >> mProvider.java:39)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/sun.nio.fs.UnixFileSystemProvider.<init>(UnixFileSystemProvider.
> > >> java:56)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/sun.nio.fs.LinuxFileSystemProvider.<init>(LinuxFileSystemProvide
> > >> r.java:41)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemPr
> > >> ovider.java:41)
> > >>>
> > >>>         at java.base/java.nio.file.FileSystems.<clinit>(FileSystems.java:91)
> > >>>
> > >>>         at java.base/java.nio.file.Paths.get(Paths.java:84)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/jdk.internal.jimage.ImageReaderFactory.<clinit>(ImageReaderFact
> > >> ory.java:50)
> > >>>
> > >>>         at java.base/java.security.AccessController.doPrivileged(Native
> > >>> Method)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/sun.net.www.protocol.jrt.JavaRuntimeURLConnection.<clinit>(Jav
> > >> aRuntimeURLConnection.java:59)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/sun.net.www.protocol.jrt.Handler.openConnection(Handler.java:
> > >> 42)
> > >>>
> > >>>         at java.base/java.net.URL.openConnection(URL.java:1049)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/jdk.internal.module.SystemModuleFinder$ImageModuleReader.c
> > >> heckPermissionToConnect(SystemModuleFinder.java:287)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/jdk.internal.module.SystemModuleFinder$ImageModuleReader.<
> > >> init>(SystemModuleFinder.java:296)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/jdk.internal.module.SystemModuleFinder$1.get(SystemModuleFi
> > >> nder.java:245)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/jdk.internal.module.SystemModuleFinder$1.get(SystemModuleFi
> > >> nder.java:242)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/jdk.internal.module.ModuleReferenceImpl.open(ModuleReferen
> > >> ceImpl.java:83)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/jdk.internal.loader.BuiltinClassLoader.createModuleReader(Builtin
> > >> ClassLoader.java:934)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(Concu
> > >> rrentHashMap.java:1719)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(BuiltinCla
> > >> ssLoader.java:926)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/jdk.internal.loader.BuiltinClassLoader.access$100(BuiltinClassLoad
> > >> er.java:92)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/jdk.internal.loader.BuiltinClassLoader$1.run(BuiltinClassLoader.jav
> > >> a:356)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/jdk.internal.loader.BuiltinClassLoader$1.run(BuiltinClassLoader.jav
> > >> a:351)
> > >>>
> > >>>         at java.base/java.security.AccessController.doPrivileged(Native
> > >>> Method)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/jdk.internal.loader.BuiltinClassLoader.findMiscResource(BuiltinCla
> > >> ssLoader.java:350)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/jdk.internal.loader.BuiltinClassLoader.findResources(BuiltinClassLo
> > >> ader.java:311)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/jdk.internal.loader.BootLoader.findResources(BootLoader.java:15
> > >> 6)
> > >>>
> > >>>         at
> > >>> java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1430)
> > >>>
> > >>>         at
> > >>> java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1428)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextServi
> > >> ce(ServiceLoader.java:1082)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.access$1200(
> > >> ServiceLoader.java:1004)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Servic
> > >> eLoader.java:1131)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Servic
> > >> eLoader.java:1130)
> > >>>
> > >>>         at java.base/java.security.AccessController.doPrivileged(Native
> > >>> Method)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(Ser
> > >> viceLoader.java:1133)
> > >>>
> > >>>         at
> > >>> java.base/java.util.ServiceLoader$1.hasNext(ServiceLoader.java:1163)
> > >>>
> > >>>         at
> > >>> java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1258)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/java.nio.channels.spi.SelectorProvider.loadProviderAsService(Sele
> > >> ctorProvider.java:122)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/java.nio.channels.spi.SelectorProvider.access$200(SelectorProvide
> > >> r.java:69)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.jav
> > >> a:180)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.jav
> > >> a:176)
> > >>>
> > >>>         at java.base/java.security.AccessController.doPrivileged(Native
> > >>> Method)
> > >>>
> > >>>         at
> > >>>
> > >>
> >
> java.base/java.nio.channels.spi.SelectorProvider.provider(SelectorProvider.j
> > >> ava:175)
> > >>>
> > >>>         at java.base/java.lang.System.inheritedChannel(System.java:276)
> > >>>
> > >>>         at java.rmi/sun.rmi.server.Activation$2.run(Activation.java:1960)
> > >>>
> > >>>         at java.rmi/sun.rmi.server.Activation$2.run(Activation.java:1958)
> > >>>
> > >>>         at java.base/java.security.AccessController.doPrivileged(Native
> > >>> Method)
> > >>>
> > >>>         at java.rmi/sun.rmi.server.Activation.main(Activation.java:1957)
> > >>>
> > >>>
> > >>>
> > >


From Alan.Bateman at oracle.com  Thu Feb 16 16:17:40 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 16 Feb 2017 16:17:40 +0000
Subject: rmid on Unix fails with Exception - maybe aftermath of
 JDK-8173607 ??
In-Reply-To: <9cebee17-090c-309e-5724-a69b8d29d96b@oracle.com>
References: <3c618ce8a236424cb72444ce3c0c744e@derote13de46.global.corp.sap>
 <d9c5ab08-86ef-88f4-eb14-4eb96ecef5b3@oracle.com>
 <ade8e7bb-fa60-3e03-451a-a2b2253fdc37@oracle.com>
 <9cebee17-090c-309e-5724-a69b8d29d96b@oracle.com>
Message-ID: <66518fdf-05f4-e338-533f-783ac25470ef@oracle.com>

Make sense for now, you can also change System.initPhase3 is not trigger 
eager initialization. I guess the rmid tests must be disabled as 
otherwise this would have been noticed, it's the odd man because it sets 
the security manager in its main method rather than on the command line.

-Alan

On 16/02/2017 16:11, Claes Redestad wrote:
> Yes, verified that reverting to eager initialization of the system 
> image reader avoids this issue. I guess we need to back this 
> optimization out and see if we can improve things in the future:
>
> diff -r 32cb9898b630 
> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
> --- 
> a/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java 
> Thu Feb 16 17:05:48 2017 +0100
> +++ 
> b/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java 
> Thu Feb 16 17:08:12 2017 +0100
> @@ -115,12 +115,7 @@
>          long t0 = System.nanoTime();
>
>          // system modules (may be patched)
> -        ModuleFinder systemModules;
> -        if (SystemModules.MODULE_NAMES.length > 0) {
> -            systemModules = SystemModuleFinder.getInstance();
> -        } else {
> -            systemModules = ModuleFinder.ofSystem();
> -        }
> +        ModuleFinder systemModules = ModuleFinder.ofSystem();
>
>          PerfCounters.systemModulesTime.addElapsedTimeFrom(t0);


From claes.redestad at oracle.com  Thu Feb 16 16:32:24 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 16 Feb 2017 17:32:24 +0100
Subject: rmid on Unix fails with Exception - maybe aftermath of
 JDK-8173607 ??
In-Reply-To: <66518fdf-05f4-e338-533f-783ac25470ef@oracle.com>
References: <3c618ce8a236424cb72444ce3c0c744e@derote13de46.global.corp.sap>
 <d9c5ab08-86ef-88f4-eb14-4eb96ecef5b3@oracle.com>
 <ade8e7bb-fa60-3e03-451a-a2b2253fdc37@oracle.com>
 <9cebee17-090c-309e-5724-a69b8d29d96b@oracle.com>
 <66518fdf-05f4-e338-533f-783ac25470ef@oracle.com>
Message-ID: <f76b0581-c13f-1575-c43e-29460f1bb334@oracle.com>

Done, filed https://bugs.openjdk.java.net/browse/JDK-8175079 and pushed 
a fix which also cleans up the hack in System.initPhase3.

/Claes

On 02/16/2017 05:17 PM, Alan Bateman wrote:
> Make sense for now, you can also change System.initPhase3 is not 
> trigger eager initialization. I guess the rmid tests must be disabled 
> as otherwise this would have been noticed, it's the odd man because it 
> sets the security manager in its main method rather than on the 
> command line.
>
> -Alan
>
> On 16/02/2017 16:11, Claes Redestad wrote:
>> Yes, verified that reverting to eager initialization of the system 
>> image reader avoids this issue. I guess we need to back this 
>> optimization out and see if we can improve things in the future:
>>
>> diff -r 32cb9898b630 
>> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
>> --- 
>> a/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java 
>> Thu Feb 16 17:05:48 2017 +0100
>> +++ 
>> b/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java 
>> Thu Feb 16 17:08:12 2017 +0100
>> @@ -115,12 +115,7 @@
>>          long t0 = System.nanoTime();
>>
>>          // system modules (may be patched)
>> -        ModuleFinder systemModules;
>> -        if (SystemModules.MODULE_NAMES.length > 0) {
>> -            systemModules = SystemModuleFinder.getInstance();
>> -        } else {
>> -            systemModules = ModuleFinder.ofSystem();
>> -        }
>> +        ModuleFinder systemModules = ModuleFinder.ofSystem();
>>
>>          PerfCounters.systemModulesTime.addElapsedTimeFrom(t0);
>


From huizhe.wang at oracle.com  Thu Feb 16 17:24:31 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 16 Feb 2017 09:24:31 -0800
Subject: RFR [JAXP] [TESTBUG] JDK-8175043 Multiple jaxp tests failing
 across platforms
In-Reply-To: <039d01d28859$a0ea6b30$e2bf4190$@oracle.com>
References: <035101d2882b$2525c810$6f715830$@oracle.com>
 <0ac2e9b5-4105-a105-5206-ef266488a4e6@oracle.com>
 <039d01d28859$a0ea6b30$e2bf4190$@oracle.com>
Message-ID: <4e39c6a8-5c16-af92-51bd-4f26d02b96a5@oracle.com>

+1.  Yes, specific permission is desirable. Thanks for the quick fix!

-Joe

On 2/16/2017 5:36 AM, Frank Yuan wrote:
> Since no one has more comment, and Joe agree this solution, I will push the change.
>
> Thanks
> Frank
>
>> -----Original Message-----
>> From: Weijun Wang [mailto:weijun.wang at oracle.com]
>> Sent: Thursday, February 16, 2017 4:35 PM
>> To: Frank Yuan; 'Daniel Fuchs'; core-libs-dev at openjdk.java.net
>> Subject: Re: RFR [JAXP] [TESTBUG] JDK-8175043 Multiple jaxp tests failing across platforms
>>
>> Hi Frank
>>
>> You got the idea here correctly, that is to say, the path used in
>> permission granting must match the style of how you access the file. The
>> fix should work.
>>
>> On the other hand, the code change touches too many files. You'll need
>> someone in the JAXP field to confirm if this is the best way.
>>
>> Thanks
>> Max
>>
>> On 02/16/2017 04:03 PM, Frank Yuan wrote:
>>> Hi Max and All
>>>
>>> Would you like to review
>>> http://cr.openjdk.java.net/~fyuan/8175043/webrev.00/?
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175043
>>>
>>> Some JAXP tests are impacted by JDK-8168410, to fix the issue, I added
>>> the pull path name to the file name in the tests, and added a temporary
>>> FilePermission for the specified file names in XSLTFunctionsTest.java.
>>>
>>> To Max
>>>
>>> I didn't take your proposal because we do want to assign FilePermission
>>> for the specified userdir, not for ".". To avoid assigning potentially
>>> extra permission now or future, I used the explicit full file path in
>>> the test.
>>>
>>> Thanks
>>> Frank
>>>
>>>
>>>


From xueming.shen at oracle.com  Thu Feb 16 20:09:32 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 16 Feb 2017 12:09:32 -0800
Subject: RFR JDK-8174996: jar leaves temporary file when exception occur in
 creating jar
Message-ID: <58A606FC.4030208@oracle.com>

Hi,

Please help review the change for

issue: https://bugs.openjdk.java.net/browse/JDK-8174996
webrev: http://cr.openjdk.java.net/~sherman/8174996/webrev

The cause/trigger of this "regression" is that the jdk9 jar implementation now builds
the target jar file on a temporary file first  and then copies it to the the target
destination, after sanity check if any. Same as what the "update" operation has been
implemented (which means this is A problem for "update" operation as well, if
ZipException/IOException gets thrown in the middle of the operation the temporary
file is left un-deleted. In case of "update" operation, the temp file is at the same
directory as the existing target jar file, if the "jar" is not from the stdin).

In fact, in releases before jdk9, even there is no temporary file left behind in this
situation, the destination jar file is left as a "broken jar" without being deleted. So
for the use scenario described in this issue report, with jdk 8 or earlier, command

jar cf test.jar -C a test test

will create a broken jar file "test.jar", after the exception thrown.

So strictly speaking, this is a not really a "regression", but a bug in different
form, though it is still desired to be addressed/fixed. Given the nature the temporary
file, it is relatively hard to create a regression test to check/verify the remove
of the temporary after the exception. I'm not adding an auto regression test
for this fix, though the fix has been verified manually.


Thanks,
Sherman


From brian.burkhalter at oracle.com  Thu Feb 16 22:47:48 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 16 Feb 2017 14:47:48 -0800
Subject: JDK 9 RFR of JDK-8175062: Mark
 java/nio/channels/AsyncCloseAndInterrupt.java as intermittently failing
In-Reply-To: <0b341bb0-83c0-addd-b425-a4c94e470551@oracle.com>
References: <0b341bb0-83c0-addd-b425-a4c94e470551@oracle.com>
Message-ID: <CF358E73-3D68-4B0A-A8EA-8DE089762716@oracle.com>

[Re-directing to nio-dev]

Looks OK.

Thanks,

Brian

On Feb 15, 2017, at 11:10 PM, Amy Lu <amy.lu at oracle.com> wrote:

> java/nio/channels/AsyncCloseAndInterrupt.java
> 
> This test is known to fail intermittently (JDK-8172045), this patch is to mark the test accordingly with keyword 'intermittent'.
> 
> Please review.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8175062
> webrev: http://cr.openjdk.java.net/~amlu/8175062/webrev.00/


From paul.sandoz at oracle.com  Fri Feb 17 00:54:23 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 16 Feb 2017 16:54:23 -0800
Subject: RFR JDK-8174996: jar leaves temporary file when exception occur
 in creating jar
In-Reply-To: <58A606FC.4030208@oracle.com>
References: <58A606FC.4030208@oracle.com>
Message-ID: <6199AB8B-6F4C-4D90-9645-6F48AF1D4823@oracle.com>

Hi Sherman,

Can you use File.deleteOnExit instead of explicitly deleting?

Paul.

> On 16 Feb 2017, at 12:09, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> Hi,
> 
> Please help review the change for
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8174996
> webrev: http://cr.openjdk.java.net/~sherman/8174996/webrev
> 
> The cause/trigger of this "regression" is that the jdk9 jar implementation now builds
> the target jar file on a temporary file first  and then copies it to the the target
> destination, after sanity check if any. Same as what the "update" operation has been
> implemented (which means this is A problem for "update" operation as well, if
> ZipException/IOException gets thrown in the middle of the operation the temporary
> file is left un-deleted. In case of "update" operation, the temp file is at the same
> directory as the existing target jar file, if the "jar" is not from the stdin).
> 
> In fact, in releases before jdk9, even there is no temporary file left behind in this
> situation, the destination jar file is left as a "broken jar" without being deleted. So
> for the use scenario described in this issue report, with jdk 8 or earlier, command
> 
> jar cf test.jar -C a test test
> 
> will create a broken jar file "test.jar", after the exception thrown.
> 
> So strictly speaking, this is a not really a "regression", but a bug in different
> form, though it is still desired to be addressed/fixed. Given the nature the temporary
> file, it is relatively hard to create a regression test to check/verify the remove
> of the temporary after the exception. I'm not adding an auto regression test
> for this fix, though the fix has been verified manually.
> 
> 
> Thanks,
> Sherman
> 


From joe.darcy at oracle.com  Fri Feb 17 02:29:11 2017
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 16 Feb 2017 18:29:11 -0800
Subject: JDK 10 RFR of JDK-8172928: Add doc link from System.identityHashCode
 to Object.hashCode
Message-ID: <58A65FF7.1020400@oracle.com>

Hello,

Please review the patch below to address

     JDK-8172928: Add doc link from System.identityHashCode to 
Object.hashCode

Thanks,

-Joe

diff -r e405d4bf5c56 src/java.base/share/classes/java/lang/System.java
--- a/src/java.base/share/classes/java/lang/System.java    Tue Feb 14 
16:56:12 2017 +0100
+++ b/src/java.base/share/classes/java/lang/System.java    Thu Feb 16 
18:26:54 2017 -0800
@@ -534,6 +534,8 @@
       * @param x object for which the hashCode is to be calculated
       * @return  the hashCode
       * @since   1.1
+     * @see Object#hashCode
+     * @see java.util.Objects#hashCode(Object)
       */
      @HotSpotIntrinsicCandidate
      public static native int identityHashCode(Object x);

From Lance.Andersen at oracle.com  Fri Feb 17 02:36:00 2017
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Thu, 16 Feb 2017 21:36:00 -0500
Subject: JDK 10 RFR of JDK-8172928: Add doc link from
 System.identityHashCode to Object.hashCode
In-Reply-To: <58A65FF7.1020400@oracle.com>
References: <58A65FF7.1020400@oracle.com>
Message-ID: <58A7A96C-300F-4890-85AD-08DF3360E189@oracle.com>

Looks fine 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

Sent from my iPhone

> On Feb 16, 2017, at 9:29 PM, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> Please review the patch below to address
> 
>    JDK-8172928: Add doc link from System.identityHashCode to Object.hashCode
> 
> Thanks,
> 
> -Joe
> 
> diff -r e405d4bf5c56 src/java.base/share/classes/java/lang/System.java
> --- a/src/java.base/share/classes/java/lang/System.java    Tue Feb 14 16:56:12 2017 +0100
> +++ b/src/java.base/share/classes/java/lang/System.java    Thu Feb 16 18:26:54 2017 -0800
> @@ -534,6 +534,8 @@
>      * @param x object for which the hashCode is to be calculated
>      * @return  the hashCode
>      * @since   1.1
> +     * @see Object#hashCode
> +     * @see java.util.Objects#hashCode(Object)
>      */
>     @HotSpotIntrinsicCandidate
>     public static native int identityHashCode(Object x);

From martinrb at google.com  Fri Feb 17 03:27:42 2017
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 16 Feb 2017 19:27:42 -0800
Subject: JDK 10 RFR of JDK-8172928: Add doc link from
 System.identityHashCode to Object.hashCode
In-Reply-To: <58A65FF7.1020400@oracle.com>
References: <58A65FF7.1020400@oracle.com>
Message-ID: <CA+kOe0_uvWjOnDGo5UZUK7ceJCupnzgnzr1wZ3mWzFBe5pyafQ@mail.gmail.com>

Ever since @link became available, it's been preferable to find some way to
use @link instead of @see.  Why not @linkify the existing reference to
Object.hashCode somehow?  Less obvious is how to do that for
Objects.hashCode - this may indeed be a good use for @see.

On Thu, Feb 16, 2017 at 6:29 PM, Joseph D. Darcy <joe.darcy at oracle.com>
wrote:

> Hello,
>
> Please review the patch below to address
>
>     JDK-8172928: Add doc link from System.identityHashCode to
> Object.hashCode
>
> Thanks,
>
> -Joe
>
> diff -r e405d4bf5c56 src/java.base/share/classes/java/lang/System.java
> --- a/src/java.base/share/classes/java/lang/System.java    Tue Feb 14
> 16:56:12 2017 +0100
> +++ b/src/java.base/share/classes/java/lang/System.java    Thu Feb 16
> 18:26:54 2017 -0800
> @@ -534,6 +534,8 @@
>       * @param x object for which the hashCode is to be calculated
>       * @return  the hashCode
>       * @since   1.1
> +     * @see Object#hashCode
> +     * @see java.util.Objects#hashCode(Object)
>       */
>      @HotSpotIntrinsicCandidate
>      public static native int identityHashCode(Object x);
>

From christoph.langer at sap.com  Fri Feb 17 08:29:25 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 17 Feb 2017 08:29:25 +0000
Subject: rmid on Unix fails with Exception - maybe aftermath of
 JDK-8173607 ??
In-Reply-To: <f76b0581-c13f-1575-c43e-29460f1bb334@oracle.com>
References: <3c618ce8a236424cb72444ce3c0c744e@derote13de46.global.corp.sap>
 <d9c5ab08-86ef-88f4-eb14-4eb96ecef5b3@oracle.com>
 <ade8e7bb-fa60-3e03-451a-a2b2253fdc37@oracle.com>
 <9cebee17-090c-309e-5724-a69b8d29d96b@oracle.com>
 <66518fdf-05f4-e338-533f-783ac25470ef@oracle.com>
 <f76b0581-c13f-1575-c43e-29460f1bb334@oracle.com>
Message-ID: <0e7927d4e2b3410c9bd6795b99cd6d49@derote13de46.global.corp.sap>

Hi,

great, it works, our rmid issue is gone.

Thanks Claes for the fix and all for the quick help/resolution.

Best regards
Christoph

> -----Original Message-----
> From: Claes Redestad [mailto:claes.redestad at oracle.com]
> Sent: Donnerstag, 16. Februar 2017 17:32
> To: Alan Bateman <Alan.Bateman at oracle.com>; Daniel Fuchs
> <daniel.fuchs at oracle.com>; Langer, Christoph <christoph.langer at sap.com>
> Cc: core-libs-dev at openjdk.java.net; Zeller, Arno <arno.zeller at sap.com>;
> Baesken, Matthias <matthias.baesken at sap.com>
> Subject: Re: rmid on Unix fails with Exception - maybe aftermath of JDK-
> 8173607 ??
> 
> Done, filed https://bugs.openjdk.java.net/browse/JDK-8175079 and pushed
> a fix which also cleans up the hack in System.initPhase3.
> 
> /Claes
> 
> On 02/16/2017 05:17 PM, Alan Bateman wrote:
> > Make sense for now, you can also change System.initPhase3 is not
> > trigger eager initialization. I guess the rmid tests must be disabled
> > as otherwise this would have been noticed, it's the odd man because it
> > sets the security manager in its main method rather than on the
> > command line.
> >
> > -Alan
> >
> > On 16/02/2017 16:11, Claes Redestad wrote:
> >> Yes, verified that reverting to eager initialization of the system
> >> image reader avoids this issue. I guess we need to back this
> >> optimization out and see if we can improve things in the future:
> >>
> >> diff -r 32cb9898b630
> >> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
> >> ---
> >>
> a/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
> >> Thu Feb 16 17:05:48 2017 +0100
> >> +++
> >>
> b/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
> >> Thu Feb 16 17:08:12 2017 +0100
> >> @@ -115,12 +115,7 @@
> >>          long t0 = System.nanoTime();
> >>
> >>          // system modules (may be patched)
> >> -        ModuleFinder systemModules;
> >> -        if (SystemModules.MODULE_NAMES.length > 0) {
> >> -            systemModules = SystemModuleFinder.getInstance();
> >> -        } else {
> >> -            systemModules = ModuleFinder.ofSystem();
> >> -        }
> >> +        ModuleFinder systemModules = ModuleFinder.ofSystem();
> >>
> >>          PerfCounters.systemModulesTime.addElapsedTimeFrom(t0);
> >


From xueming.shen at oracle.com  Fri Feb 17 17:17:31 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 17 Feb 2017 09:17:31 -0800
Subject: RFR JDK-8174996: jar leaves temporary file when exception occur
 in creating jar
In-Reply-To: <6199AB8B-6F4C-4D90-9645-6F48AF1D4823@oracle.com>
References: <58A606FC.4030208@oracle.com>
 <6199AB8B-6F4C-4D90-9645-6F48AF1D4823@oracle.com>
Message-ID: <5bd29314-eb3b-2527-0931-cc9ab3dffc6a@oracle.com>

On 2/16/17 4:54 PM, Paul Sandoz wrote:
>
> Can you use File.deleteOnExit instead of explicitly deleting?

Hi Paul,

What's the benefit of delaying the delete till vm exists?

Another considerable alternative is to 
Files.deleteIfExists(tmpFile.toPath) with the benefit
of throwing another IOException (to indicate the failure of deletion).

Sherman

>
>> On 16 Feb 2017, at 12:09, Xueming Shen <xueming.shen at oracle.com> wrote:
>>
>> Hi,
>>
>> Please help review the change for
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8174996
>> webrev: http://cr.openjdk.java.net/~sherman/8174996/webrev
>>
>> The cause/trigger of this "regression" is that the jdk9 jar implementation now builds
>> the target jar file on a temporary file first  and then copies it to the the target
>> destination, after sanity check if any. Same as what the "update" operation has been
>> implemented (which means this is A problem for "update" operation as well, if
>> ZipException/IOException gets thrown in the middle of the operation the temporary
>> file is left un-deleted. In case of "update" operation, the temp file is at the same
>> directory as the existing target jar file, if the "jar" is not from the stdin).
>>
>> In fact, in releases before jdk9, even there is no temporary file left behind in this
>> situation, the destination jar file is left as a "broken jar" without being deleted. So
>> for the use scenario described in this issue report, with jdk 8 or earlier, command
>>
>> jar cf test.jar -C a test test
>>
>> will create a broken jar file "test.jar", after the exception thrown.
>>
>> So strictly speaking, this is a not really a "regression", but a bug in different
>> form, though it is still desired to be addressed/fixed. Given the nature the temporary
>> file, it is relatively hard to create a regression test to check/verify the remove
>> of the temporary after the exception. I'm not adding an auto regression test
>> for this fix, though the fix has been verified manually.
>>
>>
>> Thanks,
>> Sherman
>>


From amy.lu at oracle.com  Mon Feb 20 03:00:05 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Mon, 20 Feb 2017 11:00:05 +0800
Subject: JDK 9 RFR of JDK-8175240: Problem list
 org/omg/CORBA/OrbPropertiesTest.java
Message-ID: <00f01ee7-36d9-7b12-a964-625aa1992b3b@oracle.com>

org/omg/CORBA/OrbPropertiesTest.java

This test changes the JDK under testing and may affect other tests 
(JDK-8175177).

Please review this patch to put the test to problem list until issues 
addressed.

bug: https://bugs.openjdk.java.net/browse/JDK-8175240
webrev: http://cr.openjdk.java.net/~amlu/8175240/webrev.00/

Thanks,
Amy

--- old/test/ProblemList.txt	2017-02-20 10:57:10.000000000 +0800
+++ new/test/ProblemList.txt	2017-02-20 10:57:10.000000000 +0800
@@ -310,4 +310,6 @@
  
  javax/xml/ws/clientjar/TestWsImport.java			8173317 generic-all
  
+org/omg/CORBA/OrbPropertiesTest.java			        8175177 generic-all
+
  ############################################################################



From Alan.Bateman at oracle.com  Mon Feb 20 07:27:32 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 20 Feb 2017 07:27:32 +0000
Subject: JDK 9 RFR of JDK-8175240: Problem list
 org/omg/CORBA/OrbPropertiesTest.java
In-Reply-To: <00f01ee7-36d9-7b12-a964-625aa1992b3b@oracle.com>
References: <00f01ee7-36d9-7b12-a964-625aa1992b3b@oracle.com>
Message-ID: <0f31f3bc-3260-9e05-e6ec-93effb8bca1d@oracle.com>

On 20/02/2017 03:00, Amy Lu wrote:

> org/omg/CORBA/OrbPropertiesTest.java
>
> This test changes the JDK under testing and may affect other tests 
> (JDK-8175177).
>
> Please review this patch to put the test to problem list until issues 
> addressed.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8175240
> webrev: http://cr.openjdk.java.net/~amlu/8175240/webrev.00/
I'm surprised that OrbPropertiesTest.java doesn't copy the run-time 
image before changing it. Exclude it temporarily until it is fixed seems 
right to me.

-Alan

From claes.redestad at oracle.com  Mon Feb 20 14:24:54 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 20 Feb 2017 15:24:54 +0100
Subject: [10] RFR: 8175233: Remove LambdaForm.debugName
Message-ID: <dd9edf5c-0158-200e-c898-2e6415a9f676@oracle.com>

Hi,

the LambdaForm.debugName field is useful for debugging, but names
are generated and retained in this field also for production code, which
is then used to name generated methods and classes.

This patch suggests to extract this field and make the debug name an
external mapping that is only generated (and used) when actually debugging,
while using LambdaForm.Kinds to guide the naming of classes and methods
generated in production mode.

This also fixes(?) a subtle bug that when transforming a LambdaForm using
LambdaFormEditors the debugName was retained through all transformations,
which leads to confusing/surprising results (since many transformations 
starts
out with a BMH.reinvoker and is then transformed via editor manipulations,
most generated forms appear to be BMH.reinvokers when in fact they aren't).

Bug:
https://bugs.openjdk.java.net/browse/JDK-8175233

Webrevs:
http://cr.openjdk.java.net/~redestad/8175233/jdk.01/
http://cr.openjdk.java.net/~redestad/8175233/hotspot.01/

Testing:
- Pre-checkin testing on all platforms
- Locally tested java.lang.invoke tests with and without 
-Djava.lang.invoke.MethodHandle.DEBUG_NAMES=true
- Ensured -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true behaves 
as intended
- Made sure the changes don't clash with JDK-8172298

Thanks!

/Claes

From pavel.bucek at oracle.com  Tue Feb 21 09:16:51 2017
From: pavel.bucek at oracle.com (Pavel Bucek)
Date: Tue, 21 Feb 2017 10:16:51 +0100
Subject: SubmissionPublisher - Subscriber#onComplete() not invoked when
 publisher is closed
Message-ID: <632c7e51-cd14-4902-c3c6-401da4de1947@oracle.com>

Hi all,

firstly - please let me know if this is is a wrong place to send this; I 
wasn't able to find list specific to concurrency.

Consider following example:

{
     SubmissionPublisher<String> publisher =new SubmissionPublisher<>();
     publisher.subscribe(new Flow.Subscriber<String>() {
         @Override public void onSubscribe(Flow.Subscription subscription) { }

         @Override public void onNext(String item) { }

         @Override public void onError(Throwable throwable) {
             System.out.println("onError()");
         }

         @Override public void onComplete() {
             System.out.println("onComplete()");
         }
     });
     publisher.submit("item");// if this is commented out, #onComplete is invoked. publisher.close();
}

I'd expect that Subscriber#onComplete is invoked after calling 
publisher.close(), but it is not happening. Curiously, when I comment 
out 'publisher.submit("item")', Subscriber#onComplete is indeed invoked.

SubmissionPublisher#close() javadoc says:

/** * Unless already closed, issues {@link * 
Flow.Subscriber#onComplete() onComplete} signals to current * 
subscribers, and disallows subsequent attempts to publish. * Upon 
return, this method does <em>NOT</em>guarantee that all * subscribers 
have yet completed. */

So it seems like it will be invoked in different thread or something 
like that, but it is not invoked ever (or more precisely - not during 10 
second after the publisher is closed. There is nothing else running on 
that particular jvm instance).

Also, publisher#isClosed() returns true and 
publisher#getNumberOfSubscribers() returns 0.

I'm using Java(TM) SE Runtime Environment (build 
9-ea+157-jigsaw-nightly-h6115-20170219)

What am I doing wrong?

Thanks and regards, Pavel


From pavel.bucek at oracle.com  Tue Feb 21 09:24:32 2017
From: pavel.bucek at oracle.com (Pavel Bucek)
Date: Tue, 21 Feb 2017 10:24:32 +0100
Subject: SubmissionPublisher - Subscriber#onComplete() not invoked when
 publisher is closed
In-Reply-To: <632c7e51-cd14-4902-c3c6-401da4de1947@oracle.com>
References: <632c7e51-cd14-4902-c3c6-401da4de1947@oracle.com>
Message-ID: <c413c0c9-70e8-867c-46ad-0641766e7e24@oracle.com>

there is a formatting issue in the code snippet, publisher.close() 
should be on the new line:

{
     SubmissionPublisher<String> publisher =new SubmissionPublisher<>();
     publisher.subscribe(new Flow.Subscriber<String>() {
         @Override public void onSubscribe(Flow.Subscription 
subscription) { }

         @Override public void onNext(String item) { }

         @Override public void onError(Throwable throwable) {
             System.out.println("onError()");
         }

         @Override public void onComplete() {
             System.out.println("onComplete()");
         }
     });
     publisher.submit("item");// if this is commented out, #onComplete 
is invoked.

     publisher.close();
}


On 21/02/2017 10:16, Pavel Bucek wrote:
> Hi all,
>
> firstly - please let me know if this is is a wrong place to send this; 
> I wasn't able to find list specific to concurrency.
>
> Consider following example:
>
> {
>     SubmissionPublisher<String> publisher =new SubmissionPublisher<>();
>     publisher.subscribe(new Flow.Subscriber<String>() {
>         @Override public void onSubscribe(Flow.Subscription 
> subscription) { }
>
>         @Override public void onNext(String item) { }
>
>         @Override public void onError(Throwable throwable) {
>             System.out.println("onError()");
>         }
>
>         @Override public void onComplete() {
>             System.out.println("onComplete()");
>         }
>     });
>     publisher.submit("item");// if this is commented out, #onComplete 
> is invoked. publisher.close();
> }
>
> I'd expect that Subscriber#onComplete is invoked after calling 
> publisher.close(), but it is not happening. Curiously, when I comment 
> out 'publisher.submit("item")', Subscriber#onComplete is indeed invoked.
>
> SubmissionPublisher#close() javadoc says:
>
> /** * Unless already closed, issues {@link * 
> Flow.Subscriber#onComplete() onComplete} signals to current * 
> subscribers, and disallows subsequent attempts to publish. * Upon 
> return, this method does <em>NOT</em>guarantee that all * subscribers 
> have yet completed. */
>
> So it seems like it will be invoked in different thread or something 
> like that, but it is not invoked ever (or more precisely - not during 
> 10 second after the publisher is closed. There is nothing else running 
> on that particular jvm instance).
>
> Also, publisher#isClosed() returns true and 
> publisher#getNumberOfSubscribers() returns 0.
>
> I'm using Java(TM) SE Runtime Environment (build 
> 9-ea+157-jigsaw-nightly-h6115-20170219)
>
> What am I doing wrong?
>
> Thanks and regards, Pavel
>


From michael.x.mcmahon at oracle.com  Tue Feb 21 10:09:16 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Tue, 21 Feb 2017 10:09:16 +0000
Subject: SubmissionPublisher - Subscriber#onComplete() not invoked when
 publisher is closed
In-Reply-To: <c413c0c9-70e8-867c-46ad-0641766e7e24@oracle.com>
References: <632c7e51-cd14-4902-c3c6-401da4de1947@oracle.com>
 <c413c0c9-70e8-867c-46ad-0641766e7e24@oracle.com>
Message-ID: <58AC11CC.1060406@oracle.com>

Sounds like a bug. It seems like the fact there isn't a call to 
Subscription.request()
is what causes the problem. But by my reading of the spec, 
Subscriber.onComplete()
should still be called, as it is known that " no additional Subscriber 
method invocations will occur".

- Michael.

On 21/02/2017, 09:24, Pavel Bucek wrote:
> there is a formatting issue in the code snippet, publisher.close() 
> should be on the new line:
>
> {
>     SubmissionPublisher<String> publisher =new SubmissionPublisher<>();
>     publisher.subscribe(new Flow.Subscriber<String>() {
>         @Override public void onSubscribe(Flow.Subscription 
> subscription) { }
>
>         @Override public void onNext(String item) { }
>
>         @Override public void onError(Throwable throwable) {
>             System.out.println("onError()");
>         }
>
>         @Override public void onComplete() {
>             System.out.println("onComplete()");
>         }
>     });
>     publisher.submit("item");// if this is commented out, #onComplete 
> is invoked.
>
>     publisher.close();
> }
>
>
> On 21/02/2017 10:16, Pavel Bucek wrote:
>> Hi all,
>>
>> firstly - please let me know if this is is a wrong place to send 
>> this; I wasn't able to find list specific to concurrency.
>>
>> Consider following example:
>>
>> {
>>     SubmissionPublisher<String> publisher =new SubmissionPublisher<>();
>>     publisher.subscribe(new Flow.Subscriber<String>() {
>>         @Override public void onSubscribe(Flow.Subscription 
>> subscription) { }
>>
>>         @Override public void onNext(String item) { }
>>
>>         @Override public void onError(Throwable throwable) {
>>             System.out.println("onError()");
>>         }
>>
>>         @Override public void onComplete() {
>>             System.out.println("onComplete()");
>>         }
>>     });
>>     publisher.submit("item");// if this is commented out, #onComplete 
>> is invoked. publisher.close();
>> }
>>
>> I'd expect that Subscriber#onComplete is invoked after calling 
>> publisher.close(), but it is not happening. Curiously, when I comment 
>> out 'publisher.submit("item")', Subscriber#onComplete is indeed invoked.
>>
>> SubmissionPublisher#close() javadoc says:
>>
>> /** * Unless already closed, issues {@link * 
>> Flow.Subscriber#onComplete() onComplete} signals to current * 
>> subscribers, and disallows subsequent attempts to publish. * Upon 
>> return, this method does <em>NOT</em>guarantee that all * subscribers 
>> have yet completed. */
>>
>> So it seems like it will be invoked in different thread or something 
>> like that, but it is not invoked ever (or more precisely - not during 
>> 10 second after the publisher is closed. There is nothing else 
>> running on that particular jvm instance).
>>
>> Also, publisher#isClosed() returns true and 
>> publisher#getNumberOfSubscribers() returns 0.
>>
>> I'm using Java(TM) SE Runtime Environment (build 
>> 9-ea+157-jigsaw-nightly-h6115-20170219)
>>
>> What am I doing wrong?
>>
>> Thanks and regards, Pavel
>>
>

From pavel.rappo at oracle.com  Tue Feb 21 11:15:15 2017
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 21 Feb 2017 11:15:15 +0000
Subject: SubmissionPublisher - Subscriber#onComplete() not invoked when
 publisher is closed
In-Reply-To: <c413c0c9-70e8-867c-46ad-0641766e7e24@oracle.com>
References: <632c7e51-cd14-4902-c3c6-401da4de1947@oracle.com>
 <c413c0c9-70e8-867c-46ad-0641766e7e24@oracle.com>
Message-ID: <9C4F8285-67DD-400C-8B95-0AC073ED9958@oracle.com>

I believe, the most appropriate place for concurrency-related questions is

    http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

As for the question itself. I don't think this behaviour is a bug.
SubmissionPublisher.close() seems to be a graceful way of shutting down (in
contrast with SubmissionPublisher.closeExceptionally()), akin to putting a EOF
on an input stream.

My reading of the javadoc is that after SubmissionPublisher.close has been
invoked, the publisher will no longer accept any attempts to publish items and
will call Subscriber.onClose() *eventually*.

> On 21 Feb 2017, at 09:24, Pavel Bucek <pavel.bucek at oracle.com> wrote:
> 
> there is a formatting issue in the code snippet, publisher.close() should be on the new line:
> 
> {
>    SubmissionPublisher<String> publisher =new SubmissionPublisher<>();
>    publisher.subscribe(new Flow.Subscriber<String>() {
>        @Override public void onSubscribe(Flow.Subscription subscription) { }
> 
>        @Override public void onNext(String item) { }
> 
>        @Override public void onError(Throwable throwable) {
>            System.out.println("onError()");
>        }
> 
>        @Override public void onComplete() {
>            System.out.println("onComplete()");
>        }
>    });
>    publisher.submit("item");// if this is commented out, #onComplete is invoked.
> 
>    publisher.close();
> }
> 
> 
> On 21/02/2017 10:16, Pavel Bucek wrote:
>> Hi all,
>> 
>> firstly - please let me know if this is is a wrong place to send this; I wasn't able to find list specific to concurrency.
>> 
>> Consider following example:
>> 
>> {
>>    SubmissionPublisher<String> publisher =new SubmissionPublisher<>();
>>    publisher.subscribe(new Flow.Subscriber<String>() {
>>        @Override public void onSubscribe(Flow.Subscription subscription) { }
>> 
>>        @Override public void onNext(String item) { }
>> 
>>        @Override public void onError(Throwable throwable) {
>>            System.out.println("onError()");
>>        }
>> 
>>        @Override public void onComplete() {
>>            System.out.println("onComplete()");
>>        }
>>    });
>>    publisher.submit("item");// if this is commented out, #onComplete is invoked. publisher.close();
>> }
>> 
>> I'd expect that Subscriber#onComplete is invoked after calling publisher.close(), but it is not happening. Curiously, when I comment out 'publisher.submit("item")', Subscriber#onComplete is indeed invoked.
>> 
>> SubmissionPublisher#close() javadoc says:
>> 
>> /** * Unless already closed, issues {@link * Flow.Subscriber#onComplete() onComplete} signals to current * subscribers, and disallows subsequent attempts to publish. * Upon return, this method does <em>NOT</em>guarantee that all * subscribers have yet completed. */
>> 
>> So it seems like it will be invoked in different thread or something like that, but it is not invoked ever (or more precisely - not during 10 second after the publisher is closed. There is nothing else running on that particular jvm instance).
>> 
>> Also, publisher#isClosed() returns true and publisher#getNumberOfSubscribers() returns 0.
>> 
>> I'm using Java(TM) SE Runtime Environment (build 9-ea+157-jigsaw-nightly-h6115-20170219)
>> 
>> What am I doing wrong?
>> 
>> Thanks and regards, Pavel
>> 
> 


From pavel.bucek at oracle.com  Tue Feb 21 11:32:55 2017
From: pavel.bucek at oracle.com (Pavel Bucek)
Date: Tue, 21 Feb 2017 12:32:55 +0100
Subject: SubmissionPublisher - Subscriber#onComplete() not invoked when
 publisher is closed
In-Reply-To: <9C4F8285-67DD-400C-8B95-0AC073ED9958@oracle.com>
References: <632c7e51-cd14-4902-c3c6-401da4de1947@oracle.com>
 <c413c0c9-70e8-867c-46ad-0641766e7e24@oracle.com>
 <9C4F8285-67DD-400C-8B95-0AC073ED9958@oracle.com>
Message-ID: <8a9495f7-e00b-4933-e463-a586b51d0bda@oracle.com>

SubmissionPublisher#closeExceptionally does trigger Subscriber#onError, 
but based on javadoc, I cannot really be sure that it will be called, 
since it contains exactly the same wording as SubmissionPublisher#close

/** * Unless already closed, issues {@link * 
Flow.Subscriber#onError(Throwable) onError} signals to current * 
subscribers with the given error, and disallows subsequent * attempts to 
publish. Future subscribers also receive the given * error. Upon return, 
this method does <em>NOT</em>guarantee * that all subscribers have yet 
completed. * * @param error the {@code onError} argument sent to 
subscribers * @throws NullPointerException if error is null */

So, Pavel, if that is not a bug, how can the SubmissionPublisher be 
closed in a way that subscribers are notified?

Thanks for the link to the other mailing list - do I understand it 
correctly that I should move this thread there?

Thanks and regards,
Pavel


On 21/02/2017 12:15, Pavel Rappo wrote:
> I believe, the most appropriate place for concurrency-related questions is
>
>      http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> As for the question itself. I don't think this behaviour is a bug.
> SubmissionPublisher.close() seems to be a graceful way of shutting down (in
> contrast with SubmissionPublisher.closeExceptionally()), akin to putting a EOF
> on an input stream.
>
> My reading of the javadoc is that after SubmissionPublisher.close has been
> invoked, the publisher will no longer accept any attempts to publish items and
> will call Subscriber.onClose() *eventually*.
>
>> On 21 Feb 2017, at 09:24, Pavel Bucek <pavel.bucek at oracle.com> wrote:
>>
>> there is a formatting issue in the code snippet, publisher.close() should be on the new line:
>>
>> {
>>     SubmissionPublisher<String> publisher =new SubmissionPublisher<>();
>>     publisher.subscribe(new Flow.Subscriber<String>() {
>>         @Override public void onSubscribe(Flow.Subscription subscription) { }
>>
>>         @Override public void onNext(String item) { }
>>
>>         @Override public void onError(Throwable throwable) {
>>             System.out.println("onError()");
>>         }
>>
>>         @Override public void onComplete() {
>>             System.out.println("onComplete()");
>>         }
>>     });
>>     publisher.submit("item");// if this is commented out, #onComplete is invoked.
>>
>>     publisher.close();
>> }
>>
>>
>> On 21/02/2017 10:16, Pavel Bucek wrote:
>>> Hi all,
>>>
>>> firstly - please let me know if this is is a wrong place to send this; I wasn't able to find list specific to concurrency.
>>>
>>> Consider following example:
>>>
>>> {
>>>     SubmissionPublisher<String> publisher =new SubmissionPublisher<>();
>>>     publisher.subscribe(new Flow.Subscriber<String>() {
>>>         @Override public void onSubscribe(Flow.Subscription subscription) { }
>>>
>>>         @Override public void onNext(String item) { }
>>>
>>>         @Override public void onError(Throwable throwable) {
>>>             System.out.println("onError()");
>>>         }
>>>
>>>         @Override public void onComplete() {
>>>             System.out.println("onComplete()");
>>>         }
>>>     });
>>>     publisher.submit("item");// if this is commented out, #onComplete is invoked. publisher.close();
>>> }
>>>
>>> I'd expect that Subscriber#onComplete is invoked after calling publisher.close(), but it is not happening. Curiously, when I comment out 'publisher.submit("item")', Subscriber#onComplete is indeed invoked.
>>>
>>> SubmissionPublisher#close() javadoc says:
>>>
>>> /** * Unless already closed, issues {@link * Flow.Subscriber#onComplete() onComplete} signals to current * subscribers, and disallows subsequent attempts to publish. * Upon return, this method does <em>NOT</em>guarantee that all * subscribers have yet completed. */
>>>
>>> So it seems like it will be invoked in different thread or something like that, but it is not invoked ever (or more precisely - not during 10 second after the publisher is closed. There is nothing else running on that particular jvm instance).
>>>
>>> Also, publisher#isClosed() returns true and publisher#getNumberOfSubscribers() returns 0.
>>>
>>> I'm using Java(TM) SE Runtime Environment (build 9-ea+157-jigsaw-nightly-h6115-20170219)
>>>
>>> What am I doing wrong?
>>>
>>> Thanks and regards, Pavel
>>>


From pavel.rappo at oracle.com  Tue Feb 21 11:36:10 2017
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 21 Feb 2017 11:36:10 +0000
Subject: SubmissionPublisher - Subscriber#onComplete() not invoked when
 publisher is closed
In-Reply-To: <8a9495f7-e00b-4933-e463-a586b51d0bda@oracle.com>
References: <632c7e51-cd14-4902-c3c6-401da4de1947@oracle.com>
 <c413c0c9-70e8-867c-46ad-0641766e7e24@oracle.com>
 <9C4F8285-67DD-400C-8B95-0AC073ED9958@oracle.com>
 <8a9495f7-e00b-4933-e463-a586b51d0bda@oracle.com>
Message-ID: <BF796268-9444-4C25-9F35-EF637D04BA4D@oracle.com>

Only if you want an answer from the concurrency uber geeks :-)

> On 21 Feb 2017, at 11:32, Pavel Bucek <pavel.bucek at oracle.com> wrote:
> 
> Thanks for the link to the other mailing list - do I understand it correctly that I should move this thread there?


From michael.x.mcmahon at oracle.com  Tue Feb 21 11:37:50 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Tue, 21 Feb 2017 11:37:50 +0000
Subject: SubmissionPublisher - Subscriber#onComplete() not invoked when
 publisher is closed
In-Reply-To: <9C4F8285-67DD-400C-8B95-0AC073ED9958@oracle.com>
References: <632c7e51-cd14-4902-c3c6-401da4de1947@oracle.com>
 <c413c0c9-70e8-867c-46ad-0641766e7e24@oracle.com>
 <9C4F8285-67DD-400C-8B95-0AC073ED9958@oracle.com>
Message-ID: <58AC268E.4040303@oracle.com>



On 21/02/2017, 11:15, Pavel Rappo wrote:
> I believe, the most appropriate place for concurrency-related questions is
>
>      http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> As for the question itself. I don't think this behaviour is a bug.
> SubmissionPublisher.close() seems to be a graceful way of shutting down (in
> contrast with SubmissionPublisher.closeExceptionally()), akin to putting a EOF
> on an input stream.
>
> My reading of the javadoc is that after SubmissionPublisher.close has been
> invoked, the publisher will no longer accept any attempts to publish items and
> will call Subscriber.onClose() *eventually*.
Yes, you are right. You can close the SubmissionPublisher, then
call Subscription.request() and then receive notification of the item.

- Michael.
>> On 21 Feb 2017, at 09:24, Pavel Bucek<pavel.bucek at oracle.com>  wrote:
>>
>> there is a formatting issue in the code snippet, publisher.close() should be on the new line:
>>
>> {
>>     SubmissionPublisher<String>  publisher =new SubmissionPublisher<>();
>>     publisher.subscribe(new Flow.Subscriber<String>() {
>>         @Override public void onSubscribe(Flow.Subscription subscription) { }
>>
>>         @Override public void onNext(String item) { }
>>
>>         @Override public void onError(Throwable throwable) {
>>             System.out.println("onError()");
>>         }
>>
>>         @Override public void onComplete() {
>>             System.out.println("onComplete()");
>>         }
>>     });
>>     publisher.submit("item");// if this is commented out, #onComplete is invoked.
>>
>>     publisher.close();
>> }
>>
>>
>> On 21/02/2017 10:16, Pavel Bucek wrote:
>>> Hi all,
>>>
>>> firstly - please let me know if this is is a wrong place to send this; I wasn't able to find list specific to concurrency.
>>>
>>> Consider following example:
>>>
>>> {
>>>     SubmissionPublisher<String>  publisher =new SubmissionPublisher<>();
>>>     publisher.subscribe(new Flow.Subscriber<String>() {
>>>         @Override public void onSubscribe(Flow.Subscription subscription) { }
>>>
>>>         @Override public void onNext(String item) { }
>>>
>>>         @Override public void onError(Throwable throwable) {
>>>             System.out.println("onError()");
>>>         }
>>>
>>>         @Override public void onComplete() {
>>>             System.out.println("onComplete()");
>>>         }
>>>     });
>>>     publisher.submit("item");// if this is commented out, #onComplete is invoked. publisher.close();
>>> }
>>>
>>> I'd expect that Subscriber#onComplete is invoked after calling publisher.close(), but it is not happening. Curiously, when I comment out 'publisher.submit("item")', Subscriber#onComplete is indeed invoked.
>>>
>>> SubmissionPublisher#close() javadoc says:
>>>
>>> /** * Unless already closed, issues {@link * Flow.Subscriber#onComplete() onComplete} signals to current * subscribers, and disallows subsequent attempts to publish. * Upon return, this method does<em>NOT</em>guarantee that all * subscribers have yet completed. */
>>>
>>> So it seems like it will be invoked in different thread or something like that, but it is not invoked ever (or more precisely - not during 10 second after the publisher is closed. There is nothing else running on that particular jvm instance).
>>>
>>> Also, publisher#isClosed() returns true and publisher#getNumberOfSubscribers() returns 0.
>>>
>>> I'm using Java(TM) SE Runtime Environment (build 9-ea+157-jigsaw-nightly-h6115-20170219)
>>>
>>> What am I doing wrong?
>>>
>>> Thanks and regards, Pavel
>>>

From dl at cs.oswego.edu  Tue Feb 21 11:49:39 2017
From: dl at cs.oswego.edu (Doug Lea)
Date: Tue, 21 Feb 2017 06:49:39 -0500
Subject: SubmissionPublisher - Subscriber#onComplete() not invoked when
 publisher is closed
In-Reply-To: <BF796268-9444-4C25-9F35-EF637D04BA4D@oracle.com>
References: <632c7e51-cd14-4902-c3c6-401da4de1947@oracle.com>
 <c413c0c9-70e8-867c-46ad-0641766e7e24@oracle.com>
 <9C4F8285-67DD-400C-8B95-0AC073ED9958@oracle.com>
 <8a9495f7-e00b-4933-e463-a586b51d0bda@oracle.com>
 <BF796268-9444-4C25-9F35-EF637D04BA4D@oracle.com>
Message-ID: <483e9c23-c4d0-427a-433d-fa97ab552b09@cs.oswego.edu>

On 02/21/2017 06:36 AM, Pavel Rappo wrote:
> Only if you want an answer from the concurrency uber geeks :-)

There seems to be no need for a further answer anyway!
Thanks for pointing out that Subscription.request must be called to 
receive any items, and given this, the example works as expected.

-Doug



>
>> On 21 Feb 2017, at 11:32, Pavel Bucek <pavel.bucek at oracle.com> wrote:
>>
>> Thanks for the link to the other mailing list - do I understand it correctly that I should move this thread there?
>
>


From michael.x.mcmahon at oracle.com  Tue Feb 21 12:04:11 2017
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Tue, 21 Feb 2017 12:04:11 +0000
Subject: SubmissionPublisher - Subscriber#onComplete() not invoked when
 publisher is closed
In-Reply-To: <8a9495f7-e00b-4933-e463-a586b51d0bda@oracle.com>
References: <632c7e51-cd14-4902-c3c6-401da4de1947@oracle.com>
 <c413c0c9-70e8-867c-46ad-0641766e7e24@oracle.com>
 <9C4F8285-67DD-400C-8B95-0AC073ED9958@oracle.com>
 <8a9495f7-e00b-4933-e463-a586b51d0bda@oracle.com>
Message-ID: <58AC2CBB.2060104@oracle.com>

Maybe the spec could be tighter around this, but it's not unreasonable 
that there is a
delay in receiving onComplete() notification because of the subscriber 
controlled flow control.
Notifying onError() is not subject to flow control; so you might expect 
that it would be triggered immediately.

Michael.

On 21/02/2017, 11:32, Pavel Bucek wrote:
> SubmissionPublisher#closeExceptionally does trigger 
> Subscriber#onError, but based on javadoc, I cannot really be sure that 
> it will be called, since it contains exactly the same wording as 
> SubmissionPublisher#close
>
> /** * Unless already closed, issues {@link * 
> Flow.Subscriber#onError(Throwable) onError} signals to current * 
> subscribers with the given error, and disallows subsequent * attempts 
> to publish. Future subscribers also receive the given * error. Upon 
> return, this method does <em>NOT</em>guarantee * that all subscribers 
> have yet completed. * * @param error the {@code onError} argument sent 
> to subscribers * @throws NullPointerException if error is null */
>
> So, Pavel, if that is not a bug, how can the SubmissionPublisher be 
> closed in a way that subscribers are notified?
>
> Thanks for the link to the other mailing list - do I understand it 
> correctly that I should move this thread there?
>
> Thanks and regards,
> Pavel
>
>
> On 21/02/2017 12:15, Pavel Rappo wrote:
>> I believe, the most appropriate place for concurrency-related 
>> questions is
>>
>>      http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>> As for the question itself. I don't think this behaviour is a bug.
>> SubmissionPublisher.close() seems to be a graceful way of shutting 
>> down (in
>> contrast with SubmissionPublisher.closeExceptionally()), akin to 
>> putting a EOF
>> on an input stream.
>>
>> My reading of the javadoc is that after SubmissionPublisher.close has 
>> been
>> invoked, the publisher will no longer accept any attempts to publish 
>> items and
>> will call Subscriber.onClose() *eventually*.
>>
>>> On 21 Feb 2017, at 09:24, Pavel Bucek <pavel.bucek at oracle.com> wrote:
>>>
>>> there is a formatting issue in the code snippet, publisher.close() 
>>> should be on the new line:
>>>
>>> {
>>>     SubmissionPublisher<String> publisher =new SubmissionPublisher<>();
>>>     publisher.subscribe(new Flow.Subscriber<String>() {
>>>         @Override public void onSubscribe(Flow.Subscription 
>>> subscription) { }
>>>
>>>         @Override public void onNext(String item) { }
>>>
>>>         @Override public void onError(Throwable throwable) {
>>>             System.out.println("onError()");
>>>         }
>>>
>>>         @Override public void onComplete() {
>>>             System.out.println("onComplete()");
>>>         }
>>>     });
>>>     publisher.submit("item");// if this is commented out, 
>>> #onComplete is invoked.
>>>
>>>     publisher.close();
>>> }
>>>
>>>
>>> On 21/02/2017 10:16, Pavel Bucek wrote:
>>>> Hi all,
>>>>
>>>> firstly - please let me know if this is is a wrong place to send 
>>>> this; I wasn't able to find list specific to concurrency.
>>>>
>>>> Consider following example:
>>>>
>>>> {
>>>>     SubmissionPublisher<String> publisher =new 
>>>> SubmissionPublisher<>();
>>>>     publisher.subscribe(new Flow.Subscriber<String>() {
>>>>         @Override public void onSubscribe(Flow.Subscription 
>>>> subscription) { }
>>>>
>>>>         @Override public void onNext(String item) { }
>>>>
>>>>         @Override public void onError(Throwable throwable) {
>>>>             System.out.println("onError()");
>>>>         }
>>>>
>>>>         @Override public void onComplete() {
>>>>             System.out.println("onComplete()");
>>>>         }
>>>>     });
>>>>     publisher.submit("item");// if this is commented out, 
>>>> #onComplete is invoked. publisher.close();
>>>> }
>>>>
>>>> I'd expect that Subscriber#onComplete is invoked after calling 
>>>> publisher.close(), but it is not happening. Curiously, when I 
>>>> comment out 'publisher.submit("item")', Subscriber#onComplete is 
>>>> indeed invoked.
>>>>
>>>> SubmissionPublisher#close() javadoc says:
>>>>
>>>> /** * Unless already closed, issues {@link * 
>>>> Flow.Subscriber#onComplete() onComplete} signals to current * 
>>>> subscribers, and disallows subsequent attempts to publish. * Upon 
>>>> return, this method does <em>NOT</em>guarantee that all * 
>>>> subscribers have yet completed. */
>>>>
>>>> So it seems like it will be invoked in different thread or 
>>>> something like that, but it is not invoked ever (or more precisely 
>>>> - not during 10 second after the publisher is closed. There is 
>>>> nothing else running on that particular jvm instance).
>>>>
>>>> Also, publisher#isClosed() returns true and 
>>>> publisher#getNumberOfSubscribers() returns 0.
>>>>
>>>> I'm using Java(TM) SE Runtime Environment (build 
>>>> 9-ea+157-jigsaw-nightly-h6115-20170219)
>>>>
>>>> What am I doing wrong?
>>>>
>>>> Thanks and regards, Pavel
>>>>
>

From pavel.bucek at oracle.com  Tue Feb 21 12:36:21 2017
From: pavel.bucek at oracle.com (Pavel Bucek)
Date: Tue, 21 Feb 2017 13:36:21 +0100
Subject: SubmissionPublisher - Subscriber#onComplete() not invoked when
 publisher is closed
In-Reply-To: <483e9c23-c4d0-427a-433d-fa97ab552b09@cs.oswego.edu>
References: <632c7e51-cd14-4902-c3c6-401da4de1947@oracle.com>
 <c413c0c9-70e8-867c-46ad-0641766e7e24@oracle.com>
 <9C4F8285-67DD-400C-8B95-0AC073ED9958@oracle.com>
 <8a9495f7-e00b-4933-e463-a586b51d0bda@oracle.com>
 <BF796268-9444-4C25-9F35-EF637D04BA4D@oracle.com>
 <483e9c23-c4d0-427a-433d-fa97ab552b09@cs.oswego.edu>
Message-ID: <63cf6fea-f214-ef7e-3041-05a56686fc90@oracle.com>

Thanks for all responses.

I understand how it works and it makes sense, but I believe the javadoc 
is not exact; SubsmissionPublisher#close doesn't mention any condition 
for the Subscriber#onComplete() invocation, but there obviously is one.

Thanks again,
Pavel


On 21/02/2017 12:49, Doug Lea wrote:
> On 02/21/2017 06:36 AM, Pavel Rappo wrote:
>> Only if you want an answer from the concurrency uber geeks :-)
>
> There seems to be no need for a further answer anyway!
> Thanks for pointing out that Subscription.request must be called to 
> receive any items, and given this, the example works as expected.
>
> -Doug
>
>
>
>>
>>> On 21 Feb 2017, at 11:32, Pavel Bucek <pavel.bucek at oracle.com> wrote:
>>>
>>> Thanks for the link to the other mailing list - do I understand it 
>>> correctly that I should move this thread there?
>>
>>
>


From christoph.langer at sap.com  Tue Feb 21 18:19:05 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 21 Feb 2017 18:19:05 +0000
Subject: [10] RFR: 8168664 [JAXP] XALAN: xsl:element generates namespace
 prefixes if namespace is given as URI only
Message-ID: <7875d4aac8304edea4fe73af099c0f29@derote13de46.global.corp.sap>

Hi Joe,

please finally review this fix for JDK10: http://cr.openjdk.java.net/~clanger/webrevs/8168664-10.1/

This version contains the Java property "jdk.xml.generatePrefix" which we should have no matter on which default we decide. In my customer base I have customers that need it either way - depending from where their legacy apps or custom developments come, XALAN XSLTC or other XML frameworks.

This proposal sets the prefix generation default for xsl:element to false - maybe we should try it for 10? Also, do we need a ccc for 10?

I would appreciate if I could get this item completed soon as I want to get it out of my backlog.

Thanks and best regards
Christoph

From: Langer, Christoph
Sent: Montag, 13. Februar 2017 16:15
To: 'huizhe wang' <huizhe.wang at oracle.com>
Cc: core-libs-dev at openjdk.java.net; Aleksej Efimov <aleksej.efimov at oracle.com>
Subject: RE: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only

Hi Joe,

here is the change, rebased for JDK10:
http://cr.openjdk.java.net/~clanger/webrevs/8168664-10.0/

This version would never generate prefixes for xsl:element and hence I removed the check for the property. Also Aleksej's test test/javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java needs to go then as it would be obsolete and would fail. Other than that, I ran the jtreg tests and found no other issues.

Thanks
Christoph


From: huizhe wang [mailto:huizhe.wang at oracle.com]
Sent: Donnerstag, 9. Februar 2017 17:25
To: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Cc: core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>; Aleksej Efimov <aleksej.efimov at oracle.com<mailto:aleksej.efimov at oracle.com>>
Subject: Re: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only


On 2/7/2017 11:28 PM, Langer, Christoph wrote:
Hi Joe,

welcome back.

Thanks!

This sounds reasonable. I'll prepare a change for JDK10.

Hopefully it'd open soon so that you don't have to keep it for too long.

Best,
Joe


Thanks
Christoph

From: Joe Wang [mailto:huizhe.wang at oracle.com]
Sent: Mittwoch, 8. Februar 2017 01:39
To: Langer, Christoph <christoph.langer at sap.com><mailto:christoph.langer at sap.com>
Cc: core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>; Aleksej Efimov <aleksej.efimov at oracle.com><mailto:aleksej.efimov at oracle.com>
Subject: Re: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only

Hi Christoph,

As we discussed, let's target this for JDK 10 as a spec change at this stage for JDK 9 is too late. Removing the namespace generation would be another reason to do this in JDK 10 since then, we wouldn't need the additional property.

Thanks,
Joe

On 1/31/17, 11:02 AM, Langer, Christoph wrote:
Hi Joe,

evenutally I have updated my webrev for this issue: http://cr.openjdk.java.net/~clanger/webrevs/8168664.1/<http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664.1/>

I've implemented your suggestion to add a property "jdk.xml.generatePrefix" which is true by default. I also added a testcase which tests the correct behavior with "-Djdk.xml.generatePrefix=false".

Generally, I think namespace prefix generation at this place is not needed. Or would you know of or be able to construct a case where it is really required? If not, I rather think namespace generation at this place should be thrown out unconditionally. Maybe for JDK10? In case it is removed, it would render the test javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java which was implemented recently by Alex for bug https://bugs.openjdk.java.net/browse/JDK-8167179 obsolete in its current form. However, the namespace generation function is still used some place for attribute namespaces.

For JDK9 I can imagine the change of this webrev going in - however, as we already discussed, you would have to do a ccc for me.

Thanks & Best regards
Christoph

From: Langer, Christoph
Sent: Dienstag, 25. Oktober 2016 15:39
To: core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>
Subject: RFR (JAXP): 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only

Hi JAXP experts,

please review a fix for a new issue regarding namespace handling in Xalan with xsl:element.

Bug: https://bugs.openjdk.java.net/browse/JDK-8168664
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8168664.0/<http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664.0/>

I'm not 100% sure if this is the right way to go or if it would break some correct behavior elsewhere. But I think the current behavior is either not correct or at least it is not required to generate new xsl namespace prefixes if the namespace comes in as URI only to an xsl:element node. The interpretative transformer from the Apache Xalan project will also produce the expected output, different to the compiled XSLTC here.

In the webrev, my changes to XslElement.java are only cosmetical/comments, the behavior does not change. In BasisLibrary.java I also took the opportunity to remove the $Id tag and the unused method "nodeList2IteratorUsingHandleFromNode".

If you think my change is good, I'll also add a test that runs the transformation which can be found in the bug...

Thanks & best regards
Christoph



From paul.sandoz at oracle.com  Tue Feb 21 22:46:21 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 21 Feb 2017 14:46:21 -0800
Subject: [10] RFR: 8175233: Remove LambdaForm.debugName
In-Reply-To: <dd9edf5c-0158-200e-c898-2e6415a9f676@oracle.com>
References: <dd9edf5c-0158-200e-c898-2e6415a9f676@oracle.com>
Message-ID: <E907B0B6-BAA3-4F53-A252-B644A4668FBF@oracle.com>


> On 20 Feb 2017, at 06:24, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi,
> 
> the LambdaForm.debugName field is useful for debugging, but names
> are generated and retained in this field also for production code, which
> is then used to name generated methods and classes.
> 
> This patch suggests to extract this field and make the debug name an
> external mapping that is only generated (and used) when actually debugging,
> while using LambdaForm.Kinds to guide the naming of classes and methods
> generated in production mode.
> 
> This also fixes(?) a subtle bug that when transforming a LambdaForm using
> LambdaFormEditors the debugName was retained through all transformations,
> which leads to confusing/surprising results (since many transformations starts
> out with a BMH.reinvoker and is then transformed via editor manipulations,
> most generated forms appear to be BMH.reinvokers when in fact they aren't).
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8175233
> 
> Webrevs:
> http://cr.openjdk.java.net/~redestad/8175233/jdk.01/
> http://cr.openjdk.java.net/~redestad/8175233/hotspot.01/
> 


LambdaForm
?

You might wanna consider colocating "lambdaName? with ?generateDebugName?, then it?s easier to see that the latter is called from within a synchronized block of the former.



> Testing:
> - Pre-checkin testing on all platforms
> - Locally tested java.lang.invoke tests with and without -Djava.lang.invoke.MethodHandle.DEBUG_NAMES=true
> - Ensured -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true behaves as intended
> - Made sure the changes don't clash with JDK-8172298
> 

Thanks, i keep forgetting to push the patch for JDK-8172298, now done.

Paul.


From claes.redestad at oracle.com  Wed Feb 22 00:19:01 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 22 Feb 2017 01:19:01 +0100
Subject: [10] RFR: 8175233: Remove LambdaForm.debugName
In-Reply-To: <E907B0B6-BAA3-4F53-A252-B644A4668FBF@oracle.com>
References: <dd9edf5c-0158-200e-c898-2e6415a9f676@oracle.com>
 <E907B0B6-BAA3-4F53-A252-B644A4668FBF@oracle.com>
Message-ID: <c7df0fb3-e9e0-de3f-002d-524d6efdb345@oracle.com>

Hi Paul,

On 2017-02-21 23:46, Paul Sandoz wrote:
>
>> On 20 Feb 2017, at 06:24, Claes Redestad <claes.redestad at oracle.com> wrote:
>>
>> Hi,
>>
>> the LambdaForm.debugName field is useful for debugging, but names
>> are generated and retained in this field also for production code, which
>> is then used to name generated methods and classes.
>>
>> This patch suggests to extract this field and make the debug name an
>> external mapping that is only generated (and used) when actually debugging,
>> while using LambdaForm.Kinds to guide the naming of classes and methods
>> generated in production mode.
>>
>> This also fixes(?) a subtle bug that when transforming a LambdaForm using
>> LambdaFormEditors the debugName was retained through all transformations,
>> which leads to confusing/surprising results (since many transformations starts
>> out with a BMH.reinvoker and is then transformed via editor manipulations,
>> most generated forms appear to be BMH.reinvokers when in fact they aren't).
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8175233
>>
>> Webrevs:
>> http://cr.openjdk.java.net/~redestad/8175233/jdk.01/
>> http://cr.openjdk.java.net/~redestad/8175233/hotspot.01/
>>
>
>
> LambdaForm
> ?
>
> You might wanna consider colocating "lambdaName? with ?generateDebugName?, then it?s easier to see that the latter is called from within a synchronized block of the former.
>

yes, updated in-place.

Thanks!

/Claes

>
>> Testing:
>> - Pre-checkin testing on all platforms
>> - Locally tested java.lang.invoke tests with and without -Djava.lang.invoke.MethodHandle.DEBUG_NAMES=true
>> - Ensured -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true behaves as intended
>> - Made sure the changes don't clash with JDK-8172298
>>
>
> Thanks, i keep forgetting to push the patch for JDK-8172298, now done.
>
> Paul.
>

From paul.sandoz at oracle.com  Wed Feb 22 00:31:35 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 21 Feb 2017 16:31:35 -0800
Subject: [10] RFR: 8175233: Remove LambdaForm.debugName
In-Reply-To: <c7df0fb3-e9e0-de3f-002d-524d6efdb345@oracle.com>
References: <dd9edf5c-0158-200e-c898-2e6415a9f676@oracle.com>
 <E907B0B6-BAA3-4F53-A252-B644A4668FBF@oracle.com>
 <c7df0fb3-e9e0-de3f-002d-524d6efdb345@oracle.com>
Message-ID: <7DA044D6-A11A-40A7-8B62-DBF654FC64D9@oracle.com>


> On 21 Feb 2017, at 16:19, Claes Redestad <claes.redestad at oracle.com> wrote:
>> 
>> LambdaForm
>> ?
>> 
>> You might wanna consider colocating "lambdaName? with ?generateDebugName?, then it?s easier to see that the latter is called from within a synchronized block of the former.
>> 
> 
> yes, updated in-place.
> 

+1

Paul.

From john.r.rose at oracle.com  Wed Feb 22 06:20:30 2017
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 21 Feb 2017 22:20:30 -0800
Subject: [10] RFR: 8175233: Remove LambdaForm.debugName
In-Reply-To: <dd9edf5c-0158-200e-c898-2e6415a9f676@oracle.com>
References: <dd9edf5c-0158-200e-c898-2e6415a9f676@oracle.com>
Message-ID: <2FBE1A1B-7C27-46AE-9E4B-9DE1DCFEB5F2@oracle.com>

On Feb 20, 2017, at 6:24 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> the LambdaForm.debugName field is useful for debugging, but names
> are generated and retained in this field also for production code, which
> is then used to name generated methods and classes.

Reviewed.  This is a good change; thank you.

From claes.redestad at oracle.com  Wed Feb 22 10:19:39 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 22 Feb 2017 11:19:39 +0100
Subject: [10] RFR: 8175233: Remove LambdaForm.debugName
In-Reply-To: <2FBE1A1B-7C27-46AE-9E4B-9DE1DCFEB5F2@oracle.com>
References: <dd9edf5c-0158-200e-c898-2e6415a9f676@oracle.com>
 <2FBE1A1B-7C27-46AE-9E4B-9DE1DCFEB5F2@oracle.com>
Message-ID: <004c77ae-a3c1-244a-71d3-e6124f78b275@oracle.com>



On 2017-02-22 07:20, John Rose wrote:
> On Feb 20, 2017, at 6:24 AM, Claes Redestad wrote:
>>
>> the LambdaForm.debugName field is useful for debugging, but names
>> are generated and retained in this field also for production code, which
>> is then used to name generated methods and classes.
>
> Reviewed.  This is a good change; thank you.

Thanks!

Pushed.

/Claes

From vladimir.x.ivanov at oracle.com  Wed Feb 22 13:15:53 2017
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 22 Feb 2017 16:15:53 +0300
Subject: [10] RFR: 8175233: Remove LambdaForm.debugName
In-Reply-To: <dd9edf5c-0158-200e-c898-2e6415a9f676@oracle.com>
References: <dd9edf5c-0158-200e-c898-2e6415a9f676@oracle.com>
Message-ID: <4cd6ff76-8cc0-a918-4729-edd2009f5494@oracle.com>

Nice cleanup, Claes! Reviewed.

Best regards,
Vladimir Ivanov

On 2/20/17 5:24 PM, Claes Redestad wrote:
> Hi,
>
> the LambdaForm.debugName field is useful for debugging, but names
> are generated and retained in this field also for production code, which
> is then used to name generated methods and classes.
>
> This patch suggests to extract this field and make the debug name an
> external mapping that is only generated (and used) when actually debugging,
> while using LambdaForm.Kinds to guide the naming of classes and methods
> generated in production mode.
>
> This also fixes(?) a subtle bug that when transforming a LambdaForm using
> LambdaFormEditors the debugName was retained through all transformations,
> which leads to confusing/surprising results (since many transformations
> starts
> out with a BMH.reinvoker and is then transformed via editor manipulations,
> most generated forms appear to be BMH.reinvokers when in fact they aren't).
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8175233
>
> Webrevs:
> http://cr.openjdk.java.net/~redestad/8175233/jdk.01/
> http://cr.openjdk.java.net/~redestad/8175233/hotspot.01/
>
> Testing:
> - Pre-checkin testing on all platforms
> - Locally tested java.lang.invoke tests with and without
> -Djava.lang.invoke.MethodHandle.DEBUG_NAMES=true
> - Ensured -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true behaves
> as intended
> - Made sure the changes don't clash with JDK-8172298
>
> Thanks!
>
> /Claes

From matthias.baesken at sap.com  Wed Feb 22 17:16:25 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 22 Feb 2017 17:16:25 +0000
Subject: RFR [XS] :  8175000 : jexec fails to execute simple helloworld.jar
Message-ID: <2d3cb556f1b1469391698d8f5068f08a@DEWDFE13DE14.global.corp.sap>

Hello , when looking into  the jexec build I noticed   that  execution of a simple helloworld.jar   with jexec does not work any more.

I did a little patch for this which adjusted the addition done with  CR  8156478: 3 Buffer overrun defect groups in jexec.c<https://javapartner.oracle.com/mproxy/repository/technology/java2/jdk9/jdk/rev/4f96129b45ee>  .

Could I have a review ( just a diff this time is provided because of infrastructure issues) for it ?


Thanks, Matthias

Bug :
https://bugs.openjdk.java.net/browse/JDK-8175000


Diff for jdk10  :

# HG changeset patch
# User mbaesken
# Date 1487782485 -3600
#      Wed Feb 22 17:54:45 2017 +0100
# Node ID 93d55a711f3b1c3f282e6889c24d13f16d4a4548
# Parent  884872263accabd4ab68d005abd4e5393144aa4f
8175000: jexec fails to execute simple helloworld.jar

diff --git a/src/java.base/unix/native/launcher/jexec.c b/src/java.base/unix/native/launcher/jexec.c
--- a/src/java.base/unix/native/launcher/jexec.c
+++ b/src/java.base/unix/native/launcher/jexec.c
@@ -331,8 +331,9 @@
                 off_t end   = start  + xlen;
                 if (end <= count) {
-                    end -= 4; // make sure there are 4 bytes to read at start
-                    while (start < end) {
+                    // make sure there are 4 bytes to read at start
+                    end -= 3;
+                    while ((start < end) && (start < count-3)) {
                         off_t xhid  = SH(buf, start);
                         off_t xdlen = SH(buf, start + 2);


From martinrb at google.com  Wed Feb 22 20:30:39 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 22 Feb 2017 12:30:39 -0800
Subject: RFR: jsr166 jdk? integration wave ?
Message-ID: <CA+kOe08ErkzH8CgEYDGQZ=LFNgwjCj8O4eEkDWEbsHDKj+dGqw@mail.gmail.com>

We half promised "no more jdk9 changes", but ...

http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/

as usual, I think they should go into jdk9, but y'all probably tell me it's
too late (and that's OK; we can retarget for jdk10)

There's only one line of production code change, in ArrayBlockingQueue.
The rest is test and javadoc wording improvements, so the risk to the jdk9
release is rather low.

Because test changes cannot delay a release, I think rampdown rules should
not apply to them the same way.

From huizhe.wang at oracle.com  Wed Feb 22 21:16:12 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 22 Feb 2017 13:16:12 -0800
Subject: [10] RFR: 8168664 [JAXP] XALAN: xsl:element generates namespace
 prefixes if namespace is given as URI only
In-Reply-To: <7875d4aac8304edea4fe73af099c0f29@derote13de46.global.corp.sap>
References: <7875d4aac8304edea4fe73af099c0f29@derote13de46.global.corp.sap>
Message-ID: <94c0fa0e-282e-63e6-a8e1-ede063ea28f7@oracle.com>

Hi Christoph,

I totally understand the desire to get it out of your backlog. However, 
we do need a compatibility review for this change. The details for JDK 
10 Compatibility & Specification Review are still in the works. It's 
unfortunate that we do have to wait a bit. Please refer to 
http://mail.openjdk.java.net/pipermail/announce/2017-February/000219.html.

For the change, the property jdk.xml.generatePrefix needs to be 
supported by the API as well as a System property since it's more 
specifically a XML Transform feature.  Take a look at 
jdk.xml.internal.JdkXmlFeatures, you may add a feature for 
jdk.xml.generatePrefix similar to USE_CATALOG, set the default value 
(the 3rd parameter) to false, e.g.:

        GENERATE_PREFIX(PROPERTY_GENERATE_PREFIX, SP_GENERATE_PREFIX, 
false, false, true, false);

JdkXmlFeatures can then be used to manage the new feature. Test then 
needs to be added to verify the support of the feature by the Transform 
API (e.g. factory.setFeature).

Thanks,
Joe

On 2/21/2017 10:19 AM, Langer, Christoph wrote:
>
> Hi Joe,
>
> please finally review this fix for JDK10: 
> http://cr.openjdk.java.net/~clanger/webrevs/8168664-10.1/ 
> <http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664-10.1/>
>
> This version contains the Java property ?jdk.xml.generatePrefix? which 
> we should have no matter on which default we decide. In my customer 
> base I have customers that need it either way ? depending from where 
> their legacy apps or custom developments come, XALAN XSLTC or other 
> XML frameworks.
>
> This proposal sets the prefix generation default for xsl:element to 
> false ? maybe we should try it for 10? Also, do we need a ccc for 10?
>
> I would appreciate if I could get this item completed soon as I want 
> to get it out of my backlog.
>
> Thanks and best regards
>
> Christoph
>
> *From:*Langer, Christoph
> *Sent:* Montag, 13. Februar 2017 16:15
> *To:* 'huizhe wang' <huizhe.wang at oracle.com>
> *Cc:* core-libs-dev at openjdk.java.net; Aleksej Efimov 
> <aleksej.efimov at oracle.com>
> *Subject:* RE: RFR - Update: 8168664 [JAXP] XALAN: xsl:element 
> generates namespace prefixes if namespace is given as URI only
>
> Hi Joe,
>
> here is the change, rebased for JDK10:
>
> http://cr.openjdk.java.net/~clanger/webrevs/8168664-10.0/ 
> <http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664-10.0/>
>
> This version would never generate prefixes for xsl:element and hence I 
> removed the check for the property. Also Aleksej?s test 
> test/javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java needs 
> to go then as it would be obsolete and would fail. Other than that, I 
> ran the jtreg tests and found no other issues.
>
> Thanks
>
> Christoph
>
> *From:*huizhe wang [mailto:huizhe.wang at oracle.com]
> *Sent:* Donnerstag, 9. Februar 2017 17:25
> *To:* Langer, Christoph <christoph.langer at sap.com 
> <mailto:christoph.langer at sap.com>>
> *Cc:* core-libs-dev at openjdk.java.net 
> <mailto:core-libs-dev at openjdk.java.net>; Aleksej Efimov 
> <aleksej.efimov at oracle.com <mailto:aleksej.efimov at oracle.com>>
> *Subject:* Re: RFR - Update: 8168664 [JAXP] XALAN: xsl:element 
> generates namespace prefixes if namespace is given as URI only
>
> On 2/7/2017 11:28 PM, Langer, Christoph wrote:
>
>     Hi Joe,
>
>     welcome back.
>
>
> Thanks!
>
>     This sounds reasonable. I?ll prepare a change for JDK10.
>
>
> Hopefully it'd open soon so that you don't have to keep it for too long.
>
> Best,
> Joe
>
>     Thanks
>
>     Christoph
>
>     *From:*Joe Wang [mailto:huizhe.wang at oracle.com]
>     *Sent:* Mittwoch, 8. Februar 2017 01:39
>     *To:* Langer, Christoph <christoph.langer at sap.com>
>     <mailto:christoph.langer at sap.com>
>     *Cc:* core-libs-dev at openjdk.java.net
>     <mailto:core-libs-dev at openjdk.java.net>; Aleksej Efimov
>     <aleksej.efimov at oracle.com> <mailto:aleksej.efimov at oracle.com>
>     *Subject:* Re: RFR - Update: 8168664 [JAXP] XALAN: xsl:element
>     generates namespace prefixes if namespace is given as URI only
>
>     Hi Christoph,
>
>     As we discussed, let's target this for JDK 10 as a spec change at
>     this stage for JDK 9 is too late. Removing the namespace
>     generation would be another reason to do this in JDK 10 since
>     then, we wouldn't need the additional property.
>
>     Thanks,
>     Joe
>
>     On 1/31/17, 11:02 AM, Langer, Christoph wrote:
>
>         Hi Joe,
>
>         evenutally I have updated my webrev for this issue:
>         http://cr.openjdk.java.net/~clanger/webrevs/8168664.1/
>         <http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664.1/>
>
>         I?ve implemented your suggestion to add a property
>         ?jdk.xml.generatePrefix? which is true by default. I also
>         added a testcase which tests the correct behavior with
>         ?-Djdk.xml.generatePrefix=false?.
>
>         Generally, I think namespace prefix generation at this place
>         is not needed. Or would you know of or be able to construct a
>         case where it is really required? If not, I rather think
>         namespace generation at this place should be thrown out
>         unconditionally. Maybe for JDK10? In case it is removed, it
>         would render the test
>         javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java
>         which was implemented recently by Alex for bug
>         https://bugs.openjdk.java.net/browse/JDK-8167179 obsolete in
>         its current form. However, the namespace generation function
>         is still used some place for attribute namespaces.
>
>         For JDK9 I can imagine the change of this webrev going in ?
>         however, as we already discussed, you would have to do a ccc
>         for me.
>
>         Thanks & Best regards
>
>         Christoph
>
>         *From:*Langer, Christoph
>         *Sent:* Dienstag, 25. Oktober 2016 15:39
>         *To:* core-libs-dev at openjdk.java.net
>         <mailto:core-libs-dev at openjdk.java.net>
>         *Subject:* RFR (JAXP): 8168664 [JAXP] XALAN: xsl:element
>         generates namespace prefixes if namespace is given as URI only
>
>         Hi JAXP experts,
>
>         please review a fix for a new issue regarding namespace
>         handling in Xalan with xsl:element.
>
>         Bug: https://bugs.openjdk.java.net/browse/JDK-8168664
>         <https://bugs.openjdk.java.net/browse/JDK-8168664>
>
>         Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8168664.0/
>         <http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664.0/>
>
>         I?m not 100% sure if this is the right way to go or if it
>         would break some correct behavior elsewhere. But I think the
>         current behavior is either not correct or at least it is not
>         required to generate new xsl namespace prefixes if the
>         namespace comes in as URI only to an xsl:element node. The
>         interpretative transformer from the Apache Xalan project will
>         also produce the expected output, different to the compiled
>         XSLTC here.
>
>         In the webrev, my changes to XslElement.java are only
>         cosmetical/comments, the behavior does not change. In
>         BasisLibrary.java I also took the opportunity to remove the
>         $Id tag and the unused method
>         ?nodeList2IteratorUsingHandleFromNode?.
>
>         If you think my change is good, I?ll also add a test that runs
>         the transformation which can be found in the bug?
>
>         Thanks & best regards
>
>         Christoph
>


From paul.sandoz at oracle.com  Wed Feb 22 21:19:45 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 22 Feb 2017 13:19:45 -0800
Subject: RFR 8175360 Error in Collectors.averagingXXX Java Doc
Message-ID: <E3CFDBF7-0BEF-4BAB-AA11-C6237240A02C@oracle.com>

Hi

Please review this small documentation fix to the averaging functions on java.util.stream.Collectors.

Paul.

diff -r 29059b8ecc7f src/java.base/share/classes/java/util/stream/Collectors.java
--- a/src/java.base/share/classes/java/util/stream/Collectors.java	Tue Feb 21 05:58:23 2017 -0800
+++ b/src/java.base/share/classes/java/util/stream/Collectors.java	Wed Feb 22 12:59:06 2017 -0800
@@ -720,8 +720,9 @@
      * the result is 0.
      *
      * @param <T> the type of the input elements
-     * @param mapper a function extracting the property to be summed
-     * @return a {@code Collector} that produces the sum of a derived property
+     * @param mapper a function extracting the property to be averaged
+     * @return a {@code Collector} that produces the arithmetic mean of a
+     * derived property
      */
     public static <T> Collector<T, ?, Double>
     averagingInt(ToIntFunction<? super T> mapper) {
@@ -738,8 +739,9 @@
      * the result is 0.
      *
      * @param <T> the type of the input elements
-     * @param mapper a function extracting the property to be summed
-     * @return a {@code Collector} that produces the sum of a derived property
+     * @param mapper a function extracting the property to be averaged
+     * @return a {@code Collector} that produces the arithmetic mean of a
+     * derived property
      */
     public static <T> Collector<T, ?, Double>
     averagingLong(ToLongFunction<? super T> mapper) {
@@ -769,8 +771,9 @@
      * 2<sup>53</sup>, leading to additional numerical errors.
      *
      * @param <T> the type of the input elements
-     * @param mapper a function extracting the property to be summed
-     * @return a {@code Collector} that produces the sum of a derived property
+     * @param mapper a function extracting the property to be averaged
+     * @return a {@code Collector} that produces the arithmetic mean of a
+     * derived property
      */
     public static <T> Collector<T, ?, Double>
     averagingDouble(ToDoubleFunction<? super T> mapper) {


From shade at redhat.com  Wed Feb 22 21:20:44 2017
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 22 Feb 2017 22:20:44 +0100
Subject: RFR 8175360 Error in Collectors.averagingXXX Java Doc
In-Reply-To: <E3CFDBF7-0BEF-4BAB-AA11-C6237240A02C@oracle.com>
References: <E3CFDBF7-0BEF-4BAB-AA11-C6237240A02C@oracle.com>
Message-ID: <1a3a77de-f27c-d6d8-a421-a1990e9fd2d5@redhat.com>

+1

-Aleksey

On 02/22/2017 10:19 PM, Paul Sandoz wrote:
> Hi
> 
> Please review this small documentation fix to the averaging functions on java.util.stream.Collectors.
> 
> Paul.
> 
> diff -r 29059b8ecc7f src/java.base/share/classes/java/util/stream/Collectors.java
> --- a/src/java.base/share/classes/java/util/stream/Collectors.java	Tue Feb 21 05:58:23 2017 -0800
> +++ b/src/java.base/share/classes/java/util/stream/Collectors.java	Wed Feb 22 12:59:06 2017 -0800
> @@ -720,8 +720,9 @@
>       * the result is 0.
>       *
>       * @param <T> the type of the input elements
> -     * @param mapper a function extracting the property to be summed
> -     * @return a {@code Collector} that produces the sum of a derived property
> +     * @param mapper a function extracting the property to be averaged
> +     * @return a {@code Collector} that produces the arithmetic mean of a
> +     * derived property
>       */
>      public static <T> Collector<T, ?, Double>
>      averagingInt(ToIntFunction<? super T> mapper) {
> @@ -738,8 +739,9 @@
>       * the result is 0.
>       *
>       * @param <T> the type of the input elements
> -     * @param mapper a function extracting the property to be summed
> -     * @return a {@code Collector} that produces the sum of a derived property
> +     * @param mapper a function extracting the property to be averaged
> +     * @return a {@code Collector} that produces the arithmetic mean of a
> +     * derived property
>       */
>      public static <T> Collector<T, ?, Double>
>      averagingLong(ToLongFunction<? super T> mapper) {
> @@ -769,8 +771,9 @@
>       * 2<sup>53</sup>, leading to additional numerical errors.
>       *
>       * @param <T> the type of the input elements
> -     * @param mapper a function extracting the property to be summed
> -     * @return a {@code Collector} that produces the sum of a derived property
> +     * @param mapper a function extracting the property to be averaged
> +     * @return a {@code Collector} that produces the arithmetic mean of a
> +     * derived property
>       */
>      public static <T> Collector<T, ?, Double>
>      averagingDouble(ToDoubleFunction<? super T> mapper) {
> 


From joe.darcy at oracle.com  Thu Feb 23 05:43:49 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 22 Feb 2017 21:43:49 -0800
Subject: [10] RFR: 8168664 [JAXP] XALAN: xsl:element generates namespace
 prefixes if namespace is given as URI only
In-Reply-To: <94c0fa0e-282e-63e6-a8e1-ede063ea28f7@oracle.com>
References: <7875d4aac8304edea4fe73af099c0f29@derote13de46.global.corp.sap>
 <94c0fa0e-282e-63e6-a8e1-ede063ea28f7@oracle.com>
Message-ID: <4178b0f6-6b39-6c4e-396d-6a42db6a9615@oracle.com>

Hello,

Yes, as Joe (Wang) stated, we are working on bringing up the CSR process 
for JDK 10 so we aren't ready to accept proposals quite yet.

Thanks,

-Joe


On 2/22/2017 1:16 PM, huizhe wang wrote:
> Hi Christoph,
>
> I totally understand the desire to get it out of your backlog. 
> However, we do need a compatibility review for this change. The 
> details for JDK 10 Compatibility & Specification Review are still in 
> the works. It's unfortunate that we do have to wait a bit. Please 
> refer to 
> http://mail.openjdk.java.net/pipermail/announce/2017-February/000219.html.
>
> For the change, the property jdk.xml.generatePrefix needs to be 
> supported by the API as well as a System property since it's more 
> specifically a XML Transform feature.  Take a look at 
> jdk.xml.internal.JdkXmlFeatures, you may add a feature for 
> jdk.xml.generatePrefix similar to USE_CATALOG, set the default value 
> (the 3rd parameter) to false, e.g.:
>
>        GENERATE_PREFIX(PROPERTY_GENERATE_PREFIX, SP_GENERATE_PREFIX, 
> false, false, true, false);
>
> JdkXmlFeatures can then be used to manage the new feature. Test then 
> needs to be added to verify the support of the feature by the 
> Transform API (e.g. factory.setFeature).
>
> Thanks,
> Joe
>
> On 2/21/2017 10:19 AM, Langer, Christoph wrote:
>>
>> Hi Joe,
>>
>> please finally review this fix for JDK10: 
>> http://cr.openjdk.java.net/~clanger/webrevs/8168664-10.1/ 
>> <http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664-10.1/>
>>
>> This version contains the Java property ?jdk.xml.generatePrefix? 
>> which we should have no matter on which default we decide. In my 
>> customer base I have customers that need it either way ? depending 
>> from where their legacy apps or custom developments come, XALAN XSLTC 
>> or other XML frameworks.
>>
>> This proposal sets the prefix generation default for xsl:element to 
>> false ? maybe we should try it for 10? Also, do we need a ccc for 10?
>>
>> I would appreciate if I could get this item completed soon as I want 
>> to get it out of my backlog.
>>
>> Thanks and best regards
>>
>> Christoph
>>
>> *From:*Langer, Christoph
>> *Sent:* Montag, 13. Februar 2017 16:15
>> *To:* 'huizhe wang' <huizhe.wang at oracle.com>
>> *Cc:* core-libs-dev at openjdk.java.net; Aleksej Efimov 
>> <aleksej.efimov at oracle.com>
>> *Subject:* RE: RFR - Update: 8168664 [JAXP] XALAN: xsl:element 
>> generates namespace prefixes if namespace is given as URI only
>>
>> Hi Joe,
>>
>> here is the change, rebased for JDK10:
>>
>> http://cr.openjdk.java.net/~clanger/webrevs/8168664-10.0/ 
>> <http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664-10.0/>
>>
>> This version would never generate prefixes for xsl:element and hence 
>> I removed the check for the property. Also Aleksej?s test 
>> test/javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java needs 
>> to go then as it would be obsolete and would fail. Other than that, I 
>> ran the jtreg tests and found no other issues.
>>
>> Thanks
>>
>> Christoph
>>
>> *From:*huizhe wang [mailto:huizhe.wang at oracle.com]
>> *Sent:* Donnerstag, 9. Februar 2017 17:25
>> *To:* Langer, Christoph <christoph.langer at sap.com 
>> <mailto:christoph.langer at sap.com>>
>> *Cc:* core-libs-dev at openjdk.java.net 
>> <mailto:core-libs-dev at openjdk.java.net>; Aleksej Efimov 
>> <aleksej.efimov at oracle.com <mailto:aleksej.efimov at oracle.com>>
>> *Subject:* Re: RFR - Update: 8168664 [JAXP] XALAN: xsl:element 
>> generates namespace prefixes if namespace is given as URI only
>>
>> On 2/7/2017 11:28 PM, Langer, Christoph wrote:
>>
>>     Hi Joe,
>>
>>     welcome back.
>>
>>
>> Thanks!
>>
>>     This sounds reasonable. I?ll prepare a change for JDK10.
>>
>>
>> Hopefully it'd open soon so that you don't have to keep it for too long.
>>
>> Best,
>> Joe
>>
>>     Thanks
>>
>>     Christoph
>>
>>     *From:*Joe Wang [mailto:huizhe.wang at oracle.com]
>>     *Sent:* Mittwoch, 8. Februar 2017 01:39
>>     *To:* Langer, Christoph <christoph.langer at sap.com>
>>     <mailto:christoph.langer at sap.com>
>>     *Cc:* core-libs-dev at openjdk.java.net
>>     <mailto:core-libs-dev at openjdk.java.net>; Aleksej Efimov
>>     <aleksej.efimov at oracle.com> <mailto:aleksej.efimov at oracle.com>
>>     *Subject:* Re: RFR - Update: 8168664 [JAXP] XALAN: xsl:element
>>     generates namespace prefixes if namespace is given as URI only
>>
>>     Hi Christoph,
>>
>>     As we discussed, let's target this for JDK 10 as a spec change at
>>     this stage for JDK 9 is too late. Removing the namespace
>>     generation would be another reason to do this in JDK 10 since
>>     then, we wouldn't need the additional property.
>>
>>     Thanks,
>>     Joe
>>
>>     On 1/31/17, 11:02 AM, Langer, Christoph wrote:
>>
>>         Hi Joe,
>>
>>         evenutally I have updated my webrev for this issue:
>>         http://cr.openjdk.java.net/~clanger/webrevs/8168664.1/
>> <http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664.1/>
>>
>>         I?ve implemented your suggestion to add a property
>>         ?jdk.xml.generatePrefix? which is true by default. I also
>>         added a testcase which tests the correct behavior with
>>         ?-Djdk.xml.generatePrefix=false?.
>>
>>         Generally, I think namespace prefix generation at this place
>>         is not needed. Or would you know of or be able to construct a
>>         case where it is really required? If not, I rather think
>>         namespace generation at this place should be thrown out
>>         unconditionally. Maybe for JDK10? In case it is removed, it
>>         would render the test
>> javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java
>>         which was implemented recently by Alex for bug
>>         https://bugs.openjdk.java.net/browse/JDK-8167179 obsolete in
>>         its current form. However, the namespace generation function
>>         is still used some place for attribute namespaces.
>>
>>         For JDK9 I can imagine the change of this webrev going in ?
>>         however, as we already discussed, you would have to do a ccc
>>         for me.
>>
>>         Thanks & Best regards
>>
>>         Christoph
>>
>>         *From:*Langer, Christoph
>>         *Sent:* Dienstag, 25. Oktober 2016 15:39
>>         *To:* core-libs-dev at openjdk.java.net
>>         <mailto:core-libs-dev at openjdk.java.net>
>>         *Subject:* RFR (JAXP): 8168664 [JAXP] XALAN: xsl:element
>>         generates namespace prefixes if namespace is given as URI only
>>
>>         Hi JAXP experts,
>>
>>         please review a fix for a new issue regarding namespace
>>         handling in Xalan with xsl:element.
>>
>>         Bug: https://bugs.openjdk.java.net/browse/JDK-8168664
>>         <https://bugs.openjdk.java.net/browse/JDK-8168664>
>>
>>         Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8168664.0/
>> <http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664.0/>
>>
>>         I?m not 100% sure if this is the right way to go or if it
>>         would break some correct behavior elsewhere. But I think the
>>         current behavior is either not correct or at least it is not
>>         required to generate new xsl namespace prefixes if the
>>         namespace comes in as URI only to an xsl:element node. The
>>         interpretative transformer from the Apache Xalan project will
>>         also produce the expected output, different to the compiled
>>         XSLTC here.
>>
>>         In the webrev, my changes to XslElement.java are only
>>         cosmetical/comments, the behavior does not change. In
>>         BasisLibrary.java I also took the opportunity to remove the
>>         $Id tag and the unused method
>>         ?nodeList2IteratorUsingHandleFromNode?.
>>
>>         If you think my change is good, I?ll also add a test that runs
>>         the transformation which can be found in the bug?
>>
>>         Thanks & best regards
>>
>>         Christoph
>>
>


From matthias.baesken at sap.com  Thu Feb 23 06:39:04 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 23 Feb 2017 06:39:04 +0000
Subject: RFR [XS] :  8175000 : jexec fails to execute simple helloworld.jar
Message-ID: <33cb21c837774572add457222d2f5103@DEWDFE13DE14.global.corp.sap>

Hello,  probably I should add the info that the fix is needed  in jdk9 as well , not only jdk10 .

Without the fix jdk9/10    show this error  when executing a small  example jar :

/myjdk9/images/jdk/lib/jexec      /java_test/hellojar/helloworld.jar
invalid file (bad magic number): Exec format error

with the fix :

jdk/lib/jexec    /java_test/hellojar/helloworld.jar
Hello world from a jar file


And btw I really wonder  - is  jexec still needed in future jdk's like jdk10  ? Seems it is not used much .

Best regards, Matthias


From: Baesken, Matthias
Sent: Mittwoch, 22. Februar 2017 18:16
To: core-libs-dev at openjdk.java.net
Cc: Langer, Christoph <christoph.langer at sap.com>; Erik Joelsson (erik.joelsson at oracle.com) <erik.joelsson at oracle.com>
Subject: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar

Hello , when looking into  the jexec build I noticed   that  execution of a simple helloworld.jar   with jexec does not work any more.

I did a little patch for this which adjusted the addition done with  CR  8156478: 3 Buffer overrun defect groups in jexec.c<https://javapartner.oracle.com/mproxy/repository/technology/java2/jdk9/jdk/rev/4f96129b45ee>  .

Could I have a review ( just a diff this time is provided because of infrastructure issues) for it ?


Thanks, Matthias

Bug :
https://bugs.openjdk.java.net/browse/JDK-8175000


Diff for jdk10  :

# HG changeset patch
# User mbaesken
# Date 1487782485 -3600
#      Wed Feb 22 17:54:45 2017 +0100
# Node ID 93d55a711f3b1c3f282e6889c24d13f16d4a4548
# Parent  884872263accabd4ab68d005abd4e5393144aa4f
8175000: jexec fails to execute simple helloworld.jar

diff --git a/src/java.base/unix/native/launcher/jexec.c b/src/java.base/unix/native/launcher/jexec.c
--- a/src/java.base/unix/native/launcher/jexec.c
+++ b/src/java.base/unix/native/launcher/jexec.c
@@ -331,8 +331,9 @@
                 off_t end   = start  + xlen;

                 if (end <= count) {
-                    end -= 4; // make sure there are 4 bytes to read at start
-                    while (start < end) {
+                    // make sure there are 4 bytes to read at start
+                    end -= 3;
+                    while ((start < end) && (start < count-3)) {
                         off_t xhid  = SH(buf, start);
                         off_t xdlen = SH(buf, start + 2);


From matthias.baesken at sap.com  Thu Feb 23 11:27:59 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 23 Feb 2017 11:27:59 +0000
Subject: RFR [XS] :  8175000 : jexec fails to execute simple helloworld.jar
Message-ID: <677dba9c09f24fb881924515a78b2753@DEWDFE13DE14.global.corp.sap>

Here is  the webrev for jdk9 :

http://cr.openjdk.java.net/~mbaesken/webrevs/8175000/


?  And btw I really wonder  - is  jexec still needed in future jdk's like jdk10  ? Seems it is not used much .

?

In case  jexec will stay in  the jdk  I might add a test for the tool as well, if there is interest  ( could not really find one that tests execution of a simple jar-file with jexec).

Best regards, Matthias


From: Baesken, Matthias
Sent: Donnerstag, 23. Februar 2017 07:39
To: 'core-libs-dev at openjdk.java.net' <core-libs-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com>; Erik Joelsson (erik.joelsson at oracle.com) <erik.joelsson at oracle.com>
Subject: RE: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar

Hello,  probably I should add the info that the fix is needed  in jdk9 as well , not only jdk10 .

Without the fix jdk9/10    show this error  when executing a small  example jar :

/myjdk9/images/jdk/lib/jexec      /java_test/hellojar/helloworld.jar
invalid file (bad magic number): Exec format error

with the fix :

jdk/lib/jexec    /java_test/hellojar/helloworld.jar
Hello world from a jar file


And btw I really wonder  - is  jexec still needed in future jdk's like jdk10  ? Seems it is not used much .

Best regards, Matthias


From: Baesken, Matthias
Sent: Mittwoch, 22. Februar 2017 18:16
To: core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>; Erik Joelsson (erik.joelsson at oracle.com<mailto:erik.joelsson at oracle.com>) <erik.joelsson at oracle.com<mailto:erik.joelsson at oracle.com>>
Subject: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar

Hello , when looking into  the jexec build I noticed   that  execution of a simple helloworld.jar   with jexec does not work any more.

I did a little patch for this which adjusted the addition done with  CR  8156478: 3 Buffer overrun defect groups in jexec.c<https://javapartner.oracle.com/mproxy/repository/technology/java2/jdk9/jdk/rev/4f96129b45ee>  .

Could I have a review ( just a diff this time is provided because of infrastructure issues) for it ?


Thanks, Matthias

Bug :
https://bugs.openjdk.java.net/browse/JDK-8175000


Diff for jdk10  :

# HG changeset patch
# User mbaesken
# Date 1487782485 -3600
#      Wed Feb 22 17:54:45 2017 +0100
# Node ID 93d55a711f3b1c3f282e6889c24d13f16d4a4548
# Parent  884872263accabd4ab68d005abd4e5393144aa4f
8175000: jexec fails to execute simple helloworld.jar

diff --git a/src/java.base/unix/native/launcher/jexec.c b/src/java.base/unix/native/launcher/jexec.c
--- a/src/java.base/unix/native/launcher/jexec.c
+++ b/src/java.base/unix/native/launcher/jexec.c
@@ -331,8 +331,9 @@
                 off_t end   = start  + xlen;

                 if (end <= count) {
-                    end -= 4; // make sure there are 4 bytes to read at start
-                    while (start < end) {
+                    // make sure there are 4 bytes to read at start
+                    end -= 3;
+                    while ((start < end) && (start < count-3)) {
                         off_t xhid  = SH(buf, start);
                         off_t xdlen = SH(buf, start + 2);


From vitalyd at gmail.com  Thu Feb 23 17:26:14 2017
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 23 Feb 2017 12:26:14 -0500
Subject: Future plans for sun.misc.Contended
Message-ID: <CAHjP37Gt8wEKt4UgDptSqFCU5JS3fW31LmWmi6VCh_tUQ0TLkA@mail.gmail.com>

Hi all,

I'm curious if anyone knows the future plans for this annotation,
specifically if it's slated to become officially supported in Java SE and
if so, what the timeline looks like (if that exists).

My understanding was it's in sun.misc as an experimental/"unstable"
annotation, but that it was incubating there before being made supported
(and moved out of that package) as it's a legitimately useful feature (the
manual padding one does today with class hierarchy and unused padding
fields is atrocious, as some of you may know).

Thanks

From aph at redhat.com  Thu Feb 23 17:41:17 2017
From: aph at redhat.com (Andrew Haley)
Date: Thu, 23 Feb 2017 17:41:17 +0000
Subject: Future plans for sun.misc.Contended
In-Reply-To: <CAHjP37Gt8wEKt4UgDptSqFCU5JS3fW31LmWmi6VCh_tUQ0TLkA@mail.gmail.com>
References: <CAHjP37Gt8wEKt4UgDptSqFCU5JS3fW31LmWmi6VCh_tUQ0TLkA@mail.gmail.com>
Message-ID: <e111e6e4-9ab9-59dd-648e-bd962a024af4@redhat.com>

On 23/02/17 17:26, Vitaly Davidovich wrote:
> My understanding was it's in sun.misc as an experimental/"unstable"
> annotation, but that it was incubating there before being made supported
> (and moved out of that package) as it's a legitimately useful feature (the
> manual padding one does today with class hierarchy and unused padding
> fields is atrocious, as some of you may know).

John Rose spoke about this before.

"There's a misunderstanding here.  Sadly, it relates to security
policy.

"The shadowy figures with the liberal usage of sharp-edged features
are not dumb users, nor are they smart users like you whom we
unaccountably view as "dumb and misinformed", but black hat attackers
(or security researchers of any stripe), who take sharp stuff like
that and use it backwards and upside down, in ways neither dumb nor
smart users would ever dream of, to coax the JVM into disallowed
states.

"The overflow Paul refers to would not be a heap OOM but
(hypothetically) size indicators in the implementation of the JVM.
Adding @C to the public mix gives a determined attacker 3 more bits of
dynamic range to maximum instance sizes.

"I personally don't think there is any specific way to weaponize that,
but I do know, from bitter experience, that some such expansions
produce bugs.  (Think 16-bit overflow: It has happened, it hurts when
it happens.)  Adding @C to the public mix means we have to race the
black hats to find any bug tail due to the extra degrees of freedom in
instance layout.  It's not a race I want to run or need to run, so we
are not making @C public.

"As we do value types we are having to open up object layout to many
more degrees of freedom.  This will be carefully reviewed and
stress-tested.  At that point it will be very safe to add other layout
hacks like @C.  In fact, it is likely that we will be able to factor
field-semantic hacks like @C (and WeakReference and Optional and
various other interesting variable types) into value type wrappers of
the base type."

Andrew.


From vitalyd at gmail.com  Thu Feb 23 17:52:36 2017
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 23 Feb 2017 12:52:36 -0500
Subject: Future plans for sun.misc.Contended
In-Reply-To: <e111e6e4-9ab9-59dd-648e-bd962a024af4@redhat.com>
References: <CAHjP37Gt8wEKt4UgDptSqFCU5JS3fW31LmWmi6VCh_tUQ0TLkA@mail.gmail.com>
 <e111e6e4-9ab9-59dd-648e-bd962a024af4@redhat.com>
Message-ID: <CAHjP37FQ2mHMyy37NFTcVpGEfuYZiFSwTOQKyN1sSscXTzp2Rg@mail.gmail.com>

Thanks Andrew - I recall reading that, but wasn't sure if that was still
the final thinking.  Unfortunately, I'm seeing this annotation slip into
codebases (with the corresponding -XX:-RestrictContended), and jigsaw is
surfacing these instances.  Looks like we have to wait for panama/valhalla
then to see where layout control lands.

On Thu, Feb 23, 2017 at 12:41 PM, Andrew Haley <aph at redhat.com> wrote:

> On 23/02/17 17:26, Vitaly Davidovich wrote:
> > My understanding was it's in sun.misc as an experimental/"unstable"
> > annotation, but that it was incubating there before being made supported
> > (and moved out of that package) as it's a legitimately useful feature
> (the
> > manual padding one does today with class hierarchy and unused padding
> > fields is atrocious, as some of you may know).
>
> John Rose spoke about this before.
>
> "There's a misunderstanding here.  Sadly, it relates to security
> policy.
>
> "The shadowy figures with the liberal usage of sharp-edged features
> are not dumb users, nor are they smart users like you whom we
> unaccountably view as "dumb and misinformed", but black hat attackers
> (or security researchers of any stripe), who take sharp stuff like
> that and use it backwards and upside down, in ways neither dumb nor
> smart users would ever dream of, to coax the JVM into disallowed
> states.
>
> "The overflow Paul refers to would not be a heap OOM but
> (hypothetically) size indicators in the implementation of the JVM.
> Adding @C to the public mix gives a determined attacker 3 more bits of
> dynamic range to maximum instance sizes.
>
> "I personally don't think there is any specific way to weaponize that,
> but I do know, from bitter experience, that some such expansions
> produce bugs.  (Think 16-bit overflow: It has happened, it hurts when
> it happens.)  Adding @C to the public mix means we have to race the
> black hats to find any bug tail due to the extra degrees of freedom in
> instance layout.  It's not a race I want to run or need to run, so we
> are not making @C public.
>
> "As we do value types we are having to open up object layout to many
> more degrees of freedom.  This will be carefully reviewed and
> stress-tested.  At that point it will be very safe to add other layout
> hacks like @C.  In fact, it is likely that we will be able to factor
> field-semantic hacks like @C (and WeakReference and Optional and
> various other interesting variable types) into value type wrappers of
> the base type."
>
> Andrew.
>
>

From mark.sheppard at oracle.com  Fri Feb 24 00:00:21 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Fri, 24 Feb 2017 00:00:21 +0000
Subject: RFR: JDK-8175177 - org/omg/CORBA/OrbPropertiesTest.java changes JDK
 under test
Message-ID: <aac3d4c8-598c-3a3c-b0da-e14ce69ffdf8@oracle.com>

Hi,
    please oblige and review the following change
http://cr.openjdk.java.net/~msheppar/8175177/webrev/

for the issue reported in
https://bugs.openjdk.java.net/browse/JDK-8175177

the test now explicitly removes the orb.properties file created by the test.

regards
Mark

From dbrosius at mebigfatguy.com  Fri Feb 24 00:17:13 2017
From: dbrosius at mebigfatguy.com (Dave Brosius)
Date: Thu, 23 Feb 2017 19:17:13 -0500
Subject: Soften interface for javax.management.ObjectName.getInstance and
 friends
In-Reply-To: <CAMU_jUPGFY4smLzcjDs5h1C31tygFcVF9iTiGO+-+0--+1=E7w@mail.gmail.com>
References: <CAMU_jUPGFY4smLzcjDs5h1C31tygFcVF9iTiGO+-+0--+1=E7w@mail.gmail.com>
Message-ID: <41720970-031e-6302-4056-d7301856b3c8@mebigfatguy.com>

Greetings. the method

public static ObjectName getInstance(String domain,
Hashtable<String,String> table)
         throws MalformedObjectNameException {
         return new ObjectName(domain, table);
     }

in javax.management.ObjectName allows for a provided Hashtable to 
specify properties for the objectname.

The semantics of an ObjectName don't consider the order of these 
properties, however certain tools like jconsole (when used as a name for 
a jmx property) does consider the order.

If you wish to create a folder structure to report metrics in jmx, you 
need to use this properties map to specify the folder names. JConsole, 
then, uses order of iteration to determine the order of the folder 
hierarchy.

Suppose you want a folder hierarchy similar to a package name, you may 
specify properties like

table.put("a0", "com");
table.put("a1", "acme");
table.put("name", "MyMetric");

in hopes of producing a metric in JConsole in the folder structure, 
com/acme/MyMetric.

The problem is of course, that the argument is a Hashtable, not a Map, 
and so the items are not ordered at all, yet JConsole uses iteration 
order to build the path, so you may get

acme/ao/MyMetric or MyMetric/acme/ao or .....

This means if you really want to have ordered packages, you have to 
derive from Hashtable, and override the entrySet() method, including 
that set's iterator() to return the values in the order you wish to have 
them shown.

That is really janky.

I'm proposing that the interface for getInstance be softened to

public static ObjectName getInstance(String domain,
                                          Map<String,String> table)

as well as

public ObjectName(String domain, Map<String, String> table)

thoughts?



From mandy.chung at oracle.com  Fri Feb 24 00:31:28 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 23 Feb 2017 16:31:28 -0800
Subject: Soften interface for javax.management.ObjectName.getInstance and
 friends
In-Reply-To: <41720970-031e-6302-4056-d7301856b3c8@mebigfatguy.com>
References: <CAMU_jUPGFY4smLzcjDs5h1C31tygFcVF9iTiGO+-+0--+1=E7w@mail.gmail.com>
 <41720970-031e-6302-4056-d7301856b3c8@mebigfatguy.com>
Message-ID: <8B5BC129-7A42-4DD8-9FD5-5D50EC747A55@oracle.com>

You should send this topic to serviceability-dev which is the mailing list for JMX and other serviceability related issues.

Mandy

> On Feb 23, 2017, at 4:17 PM, Dave Brosius <dbrosius at mebigfatguy.com> wrote:
> 
> Greetings. the method
> 
> public static ObjectName getInstance(String domain,
> Hashtable<String,String> table)
>        throws MalformedObjectNameException {
>        return new ObjectName(domain, table);
>    }
> 
> in javax.management.ObjectName allows for a provided Hashtable to specify properties for the objectname.
> 
> The semantics of an ObjectName don't consider the order of these properties, however certain tools like jconsole (when used as a name for a jmx property) does consider the order.
> 
> If you wish to create a folder structure to report metrics in jmx, you need to use this properties map to specify the folder names. JConsole, then, uses order of iteration to determine the order of the folder hierarchy.
> 
> Suppose you want a folder hierarchy similar to a package name, you may specify properties like
> 
> table.put("a0", "com");
> table.put("a1", "acme");
> table.put("name", "MyMetric");
> 
> in hopes of producing a metric in JConsole in the folder structure, com/acme/MyMetric.
> 
> The problem is of course, that the argument is a Hashtable, not a Map, and so the items are not ordered at all, yet JConsole uses iteration order to build the path, so you may get
> 
> acme/ao/MyMetric or MyMetric/acme/ao or .....
> 
> This means if you really want to have ordered packages, you have to derive from Hashtable, and override the entrySet() method, including that set's iterator() to return the values in the order you wish to have them shown.
> 
> That is really janky.
> 
> I'm proposing that the interface for getInstance be softened to
> 
> public static ObjectName getInstance(String domain,
>                                         Map<String,String> table)
> 
> as well as
> 
> public ObjectName(String domain, Map<String, String> table)
> 
> thoughts?
> 
> 


From lance.andersen at oracle.com  Fri Feb 24 00:31:58 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 23 Feb 2017 19:31:58 -0500
Subject: RFR: JDK-8175177 - org/omg/CORBA/OrbPropertiesTest.java changes
 JDK under test
In-Reply-To: <aac3d4c8-598c-3a3c-b0da-e14ce69ffdf8@oracle.com>
References: <aac3d4c8-598c-3a3c-b0da-e14ce69ffdf8@oracle.com>
Message-ID: <D5A7C4C5-2672-4A22-9FF4-20BC30AD444E@oracle.com>

Looks OK Mark.

Best
Lance
> On Feb 23, 2017, at 7:00 PM, Mark Sheppard <mark.sheppard at oracle.com> wrote:
> 
> Hi,
>   please oblige and review the following change
> http://cr.openjdk.java.net/~msheppar/8175177/webrev/
> 
> for the issue reported in
> https://bugs.openjdk.java.net/browse/JDK-8175177
> 
> the test now explicitly removes the orb.properties file created by the test.
> 
> regards
> Mark

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>




From joe.darcy at oracle.com  Fri Feb 24 01:14:05 2017
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 23 Feb 2017 17:14:05 -0800
Subject: RFR: JDK-8175177 - org/omg/CORBA/OrbPropertiesTest.java changes
 JDK under test
In-Reply-To: <aac3d4c8-598c-3a3c-b0da-e14ce69ffdf8@oracle.com>
References: <aac3d4c8-598c-3a3c-b0da-e14ce69ffdf8@oracle.com>
Message-ID: <58AF88DD.6080006@oracle.com>

Hello,

I strongly recommend this test *not* write to java.home in any way, 
including undoing the changes afterward.

If that is not possible, I think the test should be updated as suggested 
and also turned into a manual test.

Cheers,

-Joe

On 2/23/2017 4:00 PM, Mark Sheppard wrote:
> Hi,
>    please oblige and review the following change
> http://cr.openjdk.java.net/~msheppar/8175177/webrev/
>
> for the issue reported in
> https://bugs.openjdk.java.net/browse/JDK-8175177
>
> the test now explicitly removes the orb.properties file created by the 
> test.
>
> regards
> Mark


From Alan.Bateman at oracle.com  Fri Feb 24 10:28:42 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 24 Feb 2017 10:28:42 +0000
Subject: RFR: JDK-8175177 - org/omg/CORBA/OrbPropertiesTest.java changes
 JDK under test
In-Reply-To: <aac3d4c8-598c-3a3c-b0da-e14ce69ffdf8@oracle.com>
References: <aac3d4c8-598c-3a3c-b0da-e14ce69ffdf8@oracle.com>
Message-ID: <67ef459a-485c-dce9-4e62-27415e219322@oracle.com>

On 24/02/2017 00:00, Mark Sheppard wrote:

> Hi,
>    please oblige and review the following change
> http://cr.openjdk.java.net/~msheppar/8175177/webrev/
>
> for the issue reported in
> https://bugs.openjdk.java.net/browse/JDK-8175177
>
> the test now explicitly removes the orb.properties file created by the 
> test.
I assume this approach will still be problematic when running tests 
concurrently. Also I assume it won't work when the runtime under test is 
on a read-only file system. Have you considered just copying the runtime 
into the work directory so you can modify there? I think there are a few 
i18n tests that do the same.

-Alan

From chris.hegarty at oracle.com  Fri Feb 24 10:59:01 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 24 Feb 2017 10:59:01 +0000
Subject: RFR: jsr166 jdk? integration wave ?
In-Reply-To: <CA+kOe08ErkzH8CgEYDGQZ=LFNgwjCj8O4eEkDWEbsHDKj+dGqw@mail.gmail.com>
References: <CA+kOe08ErkzH8CgEYDGQZ=LFNgwjCj8O4eEkDWEbsHDKj+dGqw@mail.gmail.com>
Message-ID: <B79D6629-6F4D-479B-8B2D-DB4788252ABF@oracle.com>

Martin,

> On 22 Feb 2017, at 20:30, Martin Buchholz <martinrb at google.com> wrote:
> 
> We half promised "no more jdk9 changes", but ...
> 
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
> 
> as usual, I think they should go into jdk9, but y'all probably tell me it's
> too late (and that's OK; we can retarget for jdk10)

Are there any spec changes, or all rewordings that do not affect spec
(there?s quite a bit of noise in the webrevs )?

> There's only one line of production code change, in ArrayBlockingQueue.
> The rest is test and javadoc wording improvements, so the risk to the jdk9
> release is rather low.

Sure. Sounds ok.

> Because test changes cannot delay a release, I think rampdown rules should
> not apply to them the same way.

Right, I think that the test changes are fine to be pushed to jdk9/dev.

-Chris.

From mark.sheppard at oracle.com  Fri Feb 24 11:52:46 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Fri, 24 Feb 2017 11:52:46 +0000
Subject: RFR: JDK-8175177 - org/omg/CORBA/OrbPropertiesTest.java changes
 JDK under test
In-Reply-To: <67ef459a-485c-dce9-4e62-27415e219322@oracle.com>
References: <aac3d4c8-598c-3a3c-b0da-e14ce69ffdf8@oracle.com>
 <67ef459a-485c-dce9-4e62-27415e219322@oracle.com>
Message-ID: <0f08d060-91db-e93e-138b-369833a3bf67@oracle.com>

thanks for the feedback Alan, Joe, Lance

I'll look into the I18N runtime copy strategy  ... might go with the 
expeditious manual test option for this one

regards
Mark

On 24/02/2017 10:28, Alan Bateman wrote:
> On 24/02/2017 00:00, Mark Sheppard wrote:
>
>> Hi,
>>    please oblige and review the following change
>> http://cr.openjdk.java.net/~msheppar/8175177/webrev/
>>
>> for the issue reported in
>> https://bugs.openjdk.java.net/browse/JDK-8175177
>>
>> the test now explicitly removes the orb.properties file created by 
>> the test.
> I assume this approach will still be problematic when running tests 
> concurrently. Also I assume it won't work when the runtime under test 
> is on a read-only file system. Have you considered just copying the 
> runtime into the work directory so you can modify there? I think there 
> are a few i18n tests that do the same.
>
> -Alan


From Alan.Bateman at oracle.com  Fri Feb 24 13:00:45 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 24 Feb 2017 13:00:45 +0000
Subject: RFR: JDK-8175177 - org/omg/CORBA/OrbPropertiesTest.java changes
 JDK under test
In-Reply-To: <0f08d060-91db-e93e-138b-369833a3bf67@oracle.com>
References: <aac3d4c8-598c-3a3c-b0da-e14ce69ffdf8@oracle.com>
 <67ef459a-485c-dce9-4e62-27415e219322@oracle.com>
 <0f08d060-91db-e93e-138b-369833a3bf67@oracle.com>
Message-ID: <cfd8c1cd-7669-8089-4033-4e83e1057040@oracle.com>

On 24/02/2017 11:52, Mark Sheppard wrote:

> thanks for the feedback Alan, Joe, Lance
>
> I'll look into the I18N runtime copy strategy  ... might go with the 
> expeditious manual test option for this one
>
An alternative is to have the test run jlink to create a runtime image 
with java.corba, you'll see examples in the jlink tests.

-Alan

From daniel.fuchs at oracle.com  Fri Feb 24 13:44:04 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 24 Feb 2017 13:44:04 +0000
Subject: Soften interface for javax.management.ObjectName.getInstance and
 friends
In-Reply-To: <41720970-031e-6302-4056-d7301856b3c8@mebigfatguy.com>
References: <CAMU_jUPGFY4smLzcjDs5h1C31tygFcVF9iTiGO+-+0--+1=E7w@mail.gmail.com>
 <41720970-031e-6302-4056-d7301856b3c8@mebigfatguy.com>
Message-ID: <ccbf78c7-9bb8-788f-6d92-c7e2df09a51b@oracle.com>

Hi Dave,

I'm not sure this is quite a good idea because
order doesn't count when comparing ObjectNames.

So the folder analogy would just be a lure:
/a/b/c would be equal to /a/c/b

That said - I can see value in trying to get rid
of the legacy Hashtable - so adding a new method
that takes a Map<String,String> wouldn't necessarily
be a bad thing :-)

A work around for your use case would be to use:

  static ObjectName getInstance(String name)

instead of

  static ObjectName getInstance(String domain
                                Hashtable<String,String> table)

An object name has both a string representation
and a canonical representation.
IIRC we did try to preserve the original string
representation, even if it's not canonical.
It's also preserved in the serial form.

See:
https://docs.oracle.com/javase/8/docs/api/javax/management/ObjectName.html#getKeyPropertyListString--

Hope this helps,

-- daniel


On 24/02/17 00:17, Dave Brosius wrote:
> Greetings. the method
>
> public static ObjectName getInstance(String domain,
> Hashtable<String,String> table)
>         throws MalformedObjectNameException {
>         return new ObjectName(domain, table);
>     }
>
> in javax.management.ObjectName allows for a provided Hashtable to
> specify properties for the objectname.
>
> The semantics of an ObjectName don't consider the order of these
> properties, however certain tools like jconsole (when used as a name for
> a jmx property) does consider the order.
>
> If you wish to create a folder structure to report metrics in jmx, you
> need to use this properties map to specify the folder names. JConsole,
> then, uses order of iteration to determine the order of the folder
> hierarchy.
>
> Suppose you want a folder hierarchy similar to a package name, you may
> specify properties like
>
> table.put("a0", "com");
> table.put("a1", "acme");
> table.put("name", "MyMetric");
>
> in hopes of producing a metric in JConsole in the folder structure,
> com/acme/MyMetric.
>
> The problem is of course, that the argument is a Hashtable, not a Map,
> and so the items are not ordered at all, yet JConsole uses iteration
> order to build the path, so you may get
>
> acme/ao/MyMetric or MyMetric/acme/ao or .....
>
> This means if you really want to have ordered packages, you have to
> derive from Hashtable, and override the entrySet() method, including
> that set's iterator() to return the values in the order you wish to have
> them shown.
>
> That is really janky.
>
> I'm proposing that the interface for getInstance be softened to
>
> public static ObjectName getInstance(String domain,
>                                          Map<String,String> table)
>
> as well as
>
> public ObjectName(String domain, Map<String, String> table)
>
> thoughts?
>


From martinrb at google.com  Fri Feb 24 15:11:08 2017
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 24 Feb 2017 07:11:08 -0800
Subject: RFR: jsr166 jdk? integration wave ?
In-Reply-To: <B79D6629-6F4D-479B-8B2D-DB4788252ABF@oracle.com>
References: <CA+kOe08ErkzH8CgEYDGQZ=LFNgwjCj8O4eEkDWEbsHDKj+dGqw@mail.gmail.com>
 <B79D6629-6F4D-479B-8B2D-DB4788252ABF@oracle.com>
Message-ID: <CA+kOe0_xhHDhr25S5wEE1nk3VqAVuxKmWWO1+OCFk=xtBQ0ELg@mail.gmail.com>

On Fri, Feb 24, 2017 at 2:59 AM, Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> Martin,
>
> > On 22 Feb 2017, at 20:30, Martin Buchholz <martinrb at google.com> wrote:
> >
> > We half promised "no more jdk9 changes", but ...
> >
> > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/
> jsr166-jdk9-integration/
> >
> > as usual, I think they should go into jdk9, but y'all probably tell me
> it's
> > too late (and that's OK; we can retarget for jdk10)
>
> Are there any spec changes, or all rewordings that do not affect spec
> (there?s quite a bit of noise in the webrevs )?
>

There's only the "spec change" in ThreadPoolExecutor.java.  I don't count
that as a "real" spec change, because the original intent is clear enough,
but you might disagree.

From weijun.wang at oracle.com  Sun Feb 26 10:32:43 2017
From: weijun.wang at oracle.com (Wang Weijun)
Date: Sun, 26 Feb 2017 18:32:43 +0800
Subject: On 8175846: Provide javadoc descriptions for jdk.policytool and
 jdk.crypto.ec modules
Message-ID: <ae7bc9fb-1c6a-9e51-21c8-f9e8277d918f@oracle.com>

Hi All

I'm looking at this bug and have several questions:

1. jdk.jartool is newly introduced in jdk9 (well, all modules are new) 
but the main class inside it -- sun.security.tools.policytool.PolicyTool 
-- is already deprecated. Can I also add @deprecated/@Deprecated to the 
module-info.java of this module?

2. I try to run javadoc on this single module but see the following 
error. Not sure what it means. Shall I provide more arguments?

  $ javadoc --module jdk.jartool -d /tmp
javadoc: error - fatal error encountered: 
java.lang.IllegalArgumentException: location is not an output location 
or a module-oriented location: CLASS_PATH
javadoc: error - Please file a bug against the javadoc tool via the Java 
bug reporting page
(http://bugreport.java.com) after checking the Bug Database 
(http://bugs.java.com)
for duplicates. Include error messages and the following diagnostic in 
your report. Thank you.
java.lang.IllegalArgumentException: location is not an output location 
or a module-oriented location: CLASS_PATH
         at 
jdk.compiler/com.sun.tools.javac.file.JavacFileManager.checkModuleOrientedOrOutputLocation(JavacFileManager.java:1114)
         at 
jdk.compiler/com.sun.tools.javac.file.JavacFileManager.getLocationForModule(JavacFileManager.java:955)
         at 
jdk.javadoc/jdk.javadoc.internal.tool.ElementsTable.getModuleLocation(ElementsTable.java:796)
         at 
jdk.javadoc/jdk.javadoc.internal.tool.ElementsTable.scanSpecifiedItems(ElementsTable.java:352)
         at 
jdk.javadoc/jdk.javadoc.internal.tool.JavadocTool.getEnvironment(JavadocTool.java:189)
         at 
jdk.javadoc/jdk.javadoc.internal.tool.Start.parseAndExecute(Start.java:591)
         at 
jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:424)
         at 
jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:341)
         at jdk.javadoc/jdk.javadoc.internal.tool.Main.execute(Main.java:63)
         at jdk.javadoc/jdk.javadoc.internal.tool.Main.main(Main.java:52)

Thanks
Max

From Alan.Bateman at oracle.com  Sun Feb 26 11:58:41 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 26 Feb 2017 11:58:41 +0000
Subject: On 8175846: Provide javadoc descriptions for jdk.policytool and
 jdk.crypto.ec modules
In-Reply-To: <ae7bc9fb-1c6a-9e51-21c8-f9e8277d918f@oracle.com>
References: <ae7bc9fb-1c6a-9e51-21c8-f9e8277d918f@oracle.com>
Message-ID: <ba8eba27-6f53-91a5-6932-1c49b02f8c8b@oracle.com>

On 26/02/2017 10:32, Wang Weijun wrote:

> Hi All
>
> I'm looking at this bug and have several questions:
>
> 1. jdk.jartool is newly introduced in jdk9 (well, all modules are new) 
> but the main class inside it -- 
> sun.security.tools.policytool.PolicyTool -- is already deprecated. Can 
> I also add @deprecated/@Deprecated to the module-info.java of this 
> module?
Do you mean jdk.policytool (not jdk.jartool)? I don't see an issue 
adding @Deprecated although it will be visible in the javadoc 
(jdk.policy doesn't export an API to it seem unlikely that anyone will 
`requires jdk.policytool` and see the compile-time warning).

-Alan


>
> 2. I try to run javadoc on this single module but see the following 
> error. Not sure what it means. Shall I provide more arguments?
>
>  $ javadoc --module jdk.jartool -d /tmp
> javadoc: error - fatal error encountered: 
> java.lang.IllegalArgumentException: location is not an output location 
> or a module-oriented location: CLASS_PATH
> javadoc: error - Please file a bug against the javadoc tool via the 
> Java bug reporting page
> (http://bugreport.java.com) after checking the Bug Database 
> (http://bugs.java.com)
> for duplicates. Include error messages and the following diagnostic in 
> your report. Thank you.
> java.lang.IllegalArgumentException: location is not an output location 
> or a module-oriented location: CLASS_PATH
>         at 
> jdk.compiler/com.sun.tools.javac.file.JavacFileManager.checkModuleOrientedOrOutputLocation(JavacFileManager.java:1114)
>         at 
> jdk.compiler/com.sun.tools.javac.file.JavacFileManager.getLocationForModule(JavacFileManager.java:955)
>         at 
> jdk.javadoc/jdk.javadoc.internal.tool.ElementsTable.getModuleLocation(ElementsTable.java:796)
>         at 
> jdk.javadoc/jdk.javadoc.internal.tool.ElementsTable.scanSpecifiedItems(ElementsTable.java:352)
>         at 
> jdk.javadoc/jdk.javadoc.internal.tool.JavadocTool.getEnvironment(JavadocTool.java:189)
>         at 
> jdk.javadoc/jdk.javadoc.internal.tool.Start.parseAndExecute(Start.java:591)
>         at 
> jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:424)
>         at 
> jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:341)
>         at 
> jdk.javadoc/jdk.javadoc.internal.tool.Main.execute(Main.java:63)
>         at jdk.javadoc/jdk.javadoc.internal.tool.Main.main(Main.java:52)
>
> Thanks
> Max


From amy.lu at oracle.com  Tue Feb 28 06:18:53 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 28 Feb 2017 14:18:53 +0800
Subject: JDK 9 RFR for JDK-8175972: Remove
 javax/xml/ws/clientjar/TestWsImport.java from ProblemList
Message-ID: <020406db-6616-1ae8-2a85-5e7c3d11c0a8@oracle.com>

javax/xml/ws/clientjar/TestWsImport.java

This test in ProblemList was associated with JDK-8170370. Though 
JDK-8170370 has been resolved, this test is still in ProblemList.txt. 
Test has been re-visited and verified in JDK-8173317, no issue.

Please review this patch to remove this test from ProblemList.txt

bug: https://bugs.openjdk.java.net/browse/JDK-8175972

Thanks,
Amy

--- old/test/ProblemList.txt    2017-02-28 14:02:27.000000000 +0800
+++ new/test/ProblemList.txt    2017-02-28 14:02:27.000000000 +0800
@@ -309,8 +309,6 @@

  javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 
8169737 linux-all

-javax/xml/ws/clientjar/TestWsImport.java            8173317 generic-all
-
  org/omg/CORBA/OrbPropertiesTest.java                    8175177 
generic-all

  ############################################################################


From Alan.Bateman at oracle.com  Tue Feb 28 07:39:31 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 28 Feb 2017 07:39:31 +0000
Subject: JDK 9 RFR for JDK-8175972: Remove
 javax/xml/ws/clientjar/TestWsImport.java from ProblemList
In-Reply-To: <020406db-6616-1ae8-2a85-5e7c3d11c0a8@oracle.com>
References: <020406db-6616-1ae8-2a85-5e7c3d11c0a8@oracle.com>
Message-ID: <a513d957-980a-3802-a962-185563e58376@oracle.com>



On 28/02/2017 06:18, Amy Lu wrote:
> javax/xml/ws/clientjar/TestWsImport.java
>
> This test in ProblemList was associated with JDK-8170370. Though 
> JDK-8170370 has been resolved, this test is still in ProblemList.txt. 
> Test has been re-visited and verified in JDK-8173317, no issue.
>
> Please review this patch to remove this test from ProblemList.txt
Looks fine.