Re: [PATCH] enhancement proposal for String concatenation

[Roger Riggs]

Hi,

Copy/paste is almost always brings more of a liability than an asset
due to long term maintenance, skew, etc.

Another possibility for StringJoiner is to look at the approach being 
investigated

for String.format in JEP 348[1].

It leverages the work already done to support String concatenation ("+") 
in JEP 280[2].


[1] https://openjdk.java.net/jeps/348
[2] https://openjdk.java.net/jeps/280

Regards, Roger

On 3/8/19 8:00 PM, Ivan Gerasimov wrote:

Hi Sergei!

As you said, this new class is pretty much like StringJoiner with 
reduced functionality.


For appending all elements of an Iterable you could use list.forEach(s 
-> sj.add(s)).


With kind regards,
Ivan

On 3/8/19 11:22 AM, Сергей Цыпанов wrote:

Hello,

I have an enhancement proposal for some cases of String concatenation 
in Java.


Currently we concat Strings mostly using java.lang.StringBuilder. The 
main disadvantage of StringBuilder is underlying char array or rather 
a need to resize it when the capacity is about to exceed array length 
and subsequent copying of array content into newly allocated array.


One alternative solution existing is StringJoiner. Before JDK 9 it 
was a kind of decorator over StringBuilder, but later it was reworked 
in order to store appended Strings into String[] and overall capacity 
accumulated into int field. This makes it possible to allocate char[] 
only once and of exact size in toString() method reducing allocation 
cost.


My proposal is to copy-paste the code of StringJoinder into newly 
created class java.util.StringChain, drop the code responsible for 
delimiter, prefix and suffix and use it instead of StringBuilder in 
common StringBuilder::append concatenation pattern.


Possible use-cases for proposed code are:
- plain String concatenation
- String::chain (new methods)
- Stream.collect(Collectors.joining())
- StringConcatFactory

We can create new methods String.chain(Iterable) and 
String.chain(CharSequence...) which allow to encapsulate boilerplate 
code like



   StringBuilder sb = new StringBuilder();
   for (CharSequence cs : charSequences) {
 sb.append(cs);
   }
   String result = sb.toString():


into one line:


   String result = String.chain(charSequences);



As of performance I've done some measurements using JMH on my work 
machine (Intel i7-7700) for both Latin and non-Latin Strings of 
different size and count.

Here are the results:

https://github.com/stsypanov/string-chain/blob/master/results/StringBuilderVsStringChainBenchmark.txt 



There is a few corner cases (e.g. 1000 Strings of length 1 appended) 
when StringBuilder takes over StringChain constructed with default 
capacity of 8, but StringChain constructed with exact added Strings 
count almost always wins, especially when dealing with non-Latin 
chars (Russian in my case).


I've also created a separate repo on GitHub with benchmarks:

https://github.com/stsypanov/string-chain

Key feature here is ability to allocate String array of exact size is 
cases we know added elements count.
Thus I think that if the change will be accepted we can add also an 
overloaded method String.chain(Collection) as 
Collection::size allows to contruct StringChain of exact size.


Patch is attached.

Kind regards,
Sergei Tsypanov

RFR: JDK-8215574 : Investigate and document usage of --category, --copyright, --vendor and --description

[Alexander Matveev]

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Removed unused TITLE which is just APP_NAME.
- Fix maintainer for DEB packages "vendor " instead of vendor or 
just email.

- Fixed description for RPM, used to be just app name.
- Fixed version and description for .exe installers.
- Removed Comments and added Manufacturer attribute to Wix config file. 
Comments is not needed and Manufacturer is optional based on spec.


[1] https://bugs.openjdk.java.net/browse/JDK-8215574

[2] http://cr.openjdk.java.net/~almatvee/8215574/webrev.00/

Thanks,
Alexander

Re: RFR: JDK-171959: add-launcher is not working when normal jar is used for first launcher and module is used for second launcher

[Alexander Matveev]

Hi Andy,

Looks good.

Thanks,
Alexander

On 3/8/2019 12:57 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8171959

[2] http://cr.openjdk.java.net/~herrick/8171959/

/Andy

RFR: JDK-171959: add-launcher is not working when normal jar is used for first launcher and module is used for second launcher

[Andy Herrick]

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8171959

[2] http://cr.openjdk.java.net/~herrick/8171959/

/Andy

Re: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull

[Mandy Chung]

On 3/8/19 12:35 PM, Martin Buchholz wrote:

On Fri, Mar 8, 2019 at 3:57 AM Tagir Valeev  wrote:


Hello!


diff -r 274361bd6915 src/java.base/share/classes/java/lang/Throwable.java
--- a/src/java.base/share/classes/java/lang/Throwable.javaThu Mar 07
10:22:19 2019 +0100
+++ b/src/java.base/share/classes/java/lang/Throwable.javaFri Mar 08
02:06:42 2019 -0800
@@ -874,8 +874,7 @@
   // Validate argument
   StackTraceElement[] defensiveCopy = stackTrace.clone();
   for (int i = 0; i < defensiveCopy.length; i++) {
-if (defensiveCopy[i] == null)
-throw new NullPointerException("stackTrace[" + i + "]");
+Objects.requireNonNull(defensiveCopy[i], "stackTrace[" + i
+ "]");


Won't it produce unnecessary garbage due to string concatenation on
the common case when all frames are non-null?



I share Tagir's doubts.  I avoid this construction in performance sensitive
code.


I see Tagir's comment after I replied.  I share Tagir's concern as well
and the  exception message would be constructed unconditionally with
this change. java.base is compiled with -XDstringConcat=inline due to
bootstrapping and so the supplier does not help here.

Mandy

Re: jpackage ALL-SYSTEM

[Michael Hall]

> On Mar 8, 2019, at 11:40 AM, Bernd Eckenfels  wrote:
> 
> Can you confir it works if you start your application with a stand-alone JDK?
>  
> I suspect you have a custom jlink Image which misses the modules. Can you 
> share your jpackage configuration or at least run „Java –list-modules“ and 
> –validate-modules in your installed app? I think you Need at least jdk.attach
>  
>  
> jdk.attach provides com.sun.tools.attach.spi.AttachProvider used by jdk.attach
> -- 
> http://bernd.eckenfels.net 
>  

Out of curiosity I tried this on a simpler test app. jconsole also can’t 
connect to this one. I thought it should be possible without the target java 
application having to do anything at all, that other properly configured 
applications should be able to attach to them?

Maybe I should take this to the other list?

Re: jpackage ALL-SYSTEM

[Michael Hall]

> On Mar 8, 2019, at 12:10 PM, Andy Herrick  wrote:
> 
> With jpackage EA 3 (build 17) the option --add-modules does not properly 
> recognize the special cases ALL-SYSTEM, ALL-DEFAULT, and ALL_MODULE_PATH.
> 
> This will be addressed in the next EA release.
> 
> The default jlink options used (in EA 3) may also not include --bind-services 
> jlink option, which it will moving forward.
> 
> In many cases the jlink options used by jpackage to construct the runtime for 
> a modular application may not be exactly what the application wants.
> 
> In that case it is advisable to run jlink first to create the optimal runtime 
> image for a specific application, then to run jpackage with --runtime-image 
> option to use that runtime image when packaging the application.
> 
> /Andy

Thanks for the suggestion, I’ll give that a try.

Re: jpackage ALL-SYSTEM

[Michael Hall]

> On Mar 8, 2019, at 11:40 AM, Bernd Eckenfels  wrote:
> 
> Can you confir it works if you start your application with a stand-alone JDK?
>  
> I suspect you have a custom jlink Image which misses the modules. Can you 
> share your jpackage configuration or at least run „Java –list-modules“ and 
> –validate-modules in your installed app? I think you Need at least jdk.attach

I think jpackage always includes a custom jlink of the runtime?

The build normally includes 

--add-modules 
java.compiler,java.desktop,java.logging,java.management,java.prefs,java.se,java.rmi,java.scripting,java.sql,java.xml,jdk.attach,jdk.jshell
 \

I remember having issues with this at Java 9 as well. I think the jigsaw forum 
suggestion of adding java.se  was what seemed to get it 
working then.

Output of —list-modules includes
___

outputdir/HalfPipe.app/Contents/PlugIns/Java.runtime/Contents/Home/bin/java 
--list-modules --validate-modules
java.base@13-internal
...
java.management@13-internal
java.management.rmi@13-internal
...
java.rmi@13-internal
java.scripting@13-internal
java.se@13-internal
...
jdk.attach@13-internal

> 
> What I get attempting  a JMX attach is…
> 2019-03-08 08:27:03.173 HalfPipe[2071:67749] No attach providers
> 2019-03-08 08:27:03.174 HalfPipe[2071:67749] 
> com.sun.tools.attach.AttachNotSupportedException: no providers installed
> 2019-03-08 08:27:03.174 HalfPipe[2071:67749]   at 
> jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:202)
> 2019-03-08 08:27:03.174 HalfPipe[2071:67749]   at 
> us.hall.scripting.PidConnect.pidConnect(PidConnect.java:44)
> 2019-03-08 08:27:03.174 HalfPipe[2071:67749]   at 
> us.hall.scripting.RhinoScriptableObject.pidConnect(RhinoScriptableObject.java:139)
>  

I think the exception does show that the jdk.attach module is included?

Re: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull

[Martin Buchholz]

On Fri, Mar 8, 2019 at 3:57 AM Tagir Valeev  wrote:

> Hello!
>
> > diff -r 274361bd6915 src/java.base/share/classes/java/lang/Throwable.java
> > --- a/src/java.base/share/classes/java/lang/Throwable.javaThu Mar 07
> > 10:22:19 2019 +0100
> > +++ b/src/java.base/share/classes/java/lang/Throwable.javaFri Mar 08
> > 02:06:42 2019 -0800
> > @@ -874,8 +874,7 @@
> >   // Validate argument
> >   StackTraceElement[] defensiveCopy = stackTrace.clone();
> >   for (int i = 0; i < defensiveCopy.length; i++) {
> > -if (defensiveCopy[i] == null)
> > -throw new NullPointerException("stackTrace[" + i + "]");
> > +Objects.requireNonNull(defensiveCopy[i], "stackTrace[" + i
> > + "]");
>
> Won't it produce unnecessary garbage due to string concatenation on
> the common case when all frames are non-null?
>

I share Tagir's doubts.  I avoid this construction in performance sensitive
code.
Java doesn't offer syntactic abstraction (can I haz macros?) so the Java
Way is to write the explicit if.

Logging frameworks have the same trouble.
https://github.com/google/flogger

Perhaps hotspot's improved automatic NPE reporting makes the message detail
here obsolete?

Re: jpackage ALL-SYSTEM

[Bernd Eckenfels]

Hm, we really should think about renaming --bind-services into --add-all-junk.

Will using the option by default make image creation even less useful (i.e. 
does not safe much) in jpackage? Will there be a option to turn it off? 
Otherwise I guess it’s best to only support --runtime-Image method.

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von Andy 
Herrick 
Gesendet: Freitag, März 8, 2019 9:13 PM
An: core-libs-dev@openjdk.java.net
Betreff: Re: jpackage ALL-SYSTEM

With jpackage EA 3 (build 17) the option --add-modules does not properly
recognize the special cases ALL-SYSTEM, ALL-DEFAULT, and ALL_MODULE_PATH.

This will be addressed in the next EA release.

The default jlink options used (in EA 3) may also not include
--bind-services jlink option, which it will moving forward.

In many cases the jlink options used by jpackage to construct the
runtime for a modular application may not be exactly what the
application wants.

In that case it is advisable to run jlink first to create the optimal
runtime image for a specific application, then to run jpackage with
--runtime-image option to use that runtime image when packaging the
application.

/Andy


On 3/8/2019 9:57 AM, Michael Hall wrote:
> I have made changes to my application that make it mostly functional with the 
> exception of JMX pid attach as built by jpackage.
> I thought I had this functionality working when I first got the application 
> to use Java 9 but it no longer appears to work again now, either with my Java 
> 9 app or my 13-internal+0-jdk13-jpackage.17 version app.
> I understand for this issue serviceability-dev might be a better list for 
> this but there may be one jpackage issue concerned as well.
> Again, I don’t consider this a jpackage problem, my application now builds as 
> successfully as it currently can with jpackage as-is.
> What I get attempting a JMX attach is…
> 2019-03-08 08:27:03.173 HalfPipe[2071:67749] No attach providers
> 2019-03-08 08:27:03.174 HalfPipe[2071:67749] 
> com.sun.tools.attach.AttachNotSupportedException: no providers installed
> 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at 
> jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:202)
> 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at 
> us.hall.scripting.PidConnect.pidConnect(PidConnect.java:44)
> 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at 
> us.hall.scripting.RhinoScriptableObject.pidConnect(RhinoScriptableObject.java:139)
>
> The application also can’t be connected to from jconsole. Eclipse can be, so 
> can a Java 8 app (Weka 3-8-2). jconsole shows Eclipse doing —add-modules 
> ALL-SYSTEM
> I was going to try this with my application but it did not work. The error 
> persisted on that as a jvm argument.
> Using it as a jpackage —add-modules parameter gets...
> Module ALL-SYSTEM does not exist.
>
> The one question I would have for jpackage is should this work as a 
> —add-modules parameter?
>
> However, if anyone has any suggestions on getting JMX attach to work besides 
> adding serviceability-dev to my forums that would be appreciated as well.
>
> Thanks.

Re: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull

[Mandy Chung]

Looks good to me.

Mandy

On 3/8/19 3:08 AM, Joe Darcy wrote:

Hello,

The code in java.lang.Throwable has various explicit null checks that 
could be rewritten to use Objects.requireNonNull.


Please review the patch below which implements this refactoring.

Thanks,

-Joe

diff -r 274361bd6915 src/java.base/share/classes/java/lang/Throwable.java
--- a/src/java.base/share/classes/java/lang/Throwable.java    Thu Mar 07 
10:22:19 2019 +0100
+++ b/src/java.base/share/classes/java/lang/Throwable.java    Fri Mar 08 
02:06:42 2019 -0800

@@ -874,8 +874,7 @@
  // Validate argument
  StackTraceElement[] defensiveCopy = stackTrace.clone();
  for (int i = 0; i < defensiveCopy.length; i++) {
-    if (defensiveCopy[i] == null)
-    throw new NullPointerException("stackTrace[" + i + "]");
+    Objects.requireNonNull(defensiveCopy[i], "stackTrace[" + i 
+ "]");

  }

  synchronized (this) {
@@ -914,8 +913,7 @@
  for (Throwable t : suppressedExceptions) {
  // Enforce constraints on suppressed exceptions in
  // case of corrupt or malicious stream.
-    if (t == null)
-    throw new 
NullPointerException(NULL_CAUSE_MESSAGE);

+    Objects.requireNonNull(t, NULL_CAUSE_MESSAGE);
  if (t == this)
  throw new 
IllegalArgumentException(SELF_SUPPRESSION_MESSAGE);

  suppressed.add(t);
@@ -942,8 +940,7 @@
  stackTrace = null;
  } else { // Verify stack trace elements are non-null.
  for(StackTraceElement ste : stackTrace) {
-    if (ste == null)
-    throw new NullPointerException("null 
StackTraceElement in serial stream. ");
+    Objects.requireNonNull(ste, "null StackTraceElement 
in serial stream. ");

  }
  }
  } else {
@@ -1034,8 +1031,7 @@
  if (exception == this)
  throw new 
IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception);


-    if (exception == null)
-    throw new NullPointerException(NULL_CAUSE_MESSAGE);
+    Objects.requireNonNull(exception, NULL_CAUSE_MESSAGE);

  if (suppressedExceptions == null) // Suppressed exceptions not 
recorded

  return;

Re: [PATCH] enhancement proposal for String concatenation

[Ivan Gerasimov]

Hi Sergei!

As you said, this new class is pretty much like StringJoiner with 
reduced functionality.


For appending all elements of an Iterable you could use list.forEach(s 
-> sj.add(s)).


With kind regards,
Ivan

On 3/8/19 11:22 AM, Сергей Цыпанов wrote:

Hello,

I have an enhancement proposal for some cases of String concatenation in Java.

Currently we concat Strings mostly using java.lang.StringBuilder. The main 
disadvantage of StringBuilder is underlying char array or rather a need to 
resize it when the capacity is about to exceed array length and subsequent 
copying of array content into newly allocated array.

One alternative solution existing is StringJoiner. Before JDK 9 it was a kind 
of decorator over StringBuilder, but later it was reworked in order to store 
appended Strings into String[] and overall capacity accumulated into int field. 
This makes it possible to allocate char[] only once and of exact size in 
toString() method reducing allocation cost.

My proposal is to copy-paste the code of StringJoinder into newly created class 
java.util.StringChain, drop the code responsible for delimiter, prefix and 
suffix and use it instead of StringBuilder in common StringBuilder::append 
concatenation pattern.

Possible use-cases for proposed code are:
- plain String concatenation
- String::chain (new methods)
- Stream.collect(Collectors.joining())
- StringConcatFactory

We can create new methods String.chain(Iterable) and 
String.chain(CharSequence...) which allow to encapsulate boilerplate code like


   StringBuilder sb = new StringBuilder();
   for (CharSequence cs : charSequences) {
 sb.append(cs);
   }
   String result = sb.toString():


into one line:


   String result = String.chain(charSequences);



As of performance I've done some measurements using JMH on my work machine 
(Intel i7-7700) for both Latin and non-Latin Strings of different size and 
count.
Here are the results:

https://github.com/stsypanov/string-chain/blob/master/results/StringBuilderVsStringChainBenchmark.txt

There is a few corner cases (e.g. 1000 Strings of length 1 appended) when 
StringBuilder takes over StringChain constructed with default capacity of 8, 
but StringChain constructed with exact added Strings count almost always wins, 
especially when dealing with non-Latin chars (Russian in my case).

I've also created a separate repo on GitHub with benchmarks:

https://github.com/stsypanov/string-chain

Key feature here is ability to allocate String array of exact size is cases we 
know added elements count.
Thus I think that if the change will be accepted we can add also an overloaded method 
String.chain(Collection) as Collection::size allows to contruct 
StringChain of exact size.

Patch is attached.

Kind regards,
Sergei Tsypanov


--
With kind regards,
Ivan Gerasimov

Re: [PATCH] enhancement proposal for String concatenation

[Remi Forax]

Hi,
adding StringChain send the wrong message IMO, we already have StringBuffer, 
StringBuilder and StringJoiner,
let's try not to add another way to concatenate a variable number of Strings in 
Java.

I wonder if you can not achieve what you want by specializing String.join() and 
StringJoiner if the delimiter is an empty String ?

Rémi

- Mail original -
> De: "Сергей Цыпанов" 
> À: "core-libs-dev" 
> Envoyé: Vendredi 8 Mars 2019 20:22:10
> Objet: [PATCH] enhancement proposal for String concatenation

> Hello,
> 
> I have an enhancement proposal for some cases of String concatenation in Java.
> 
> Currently we concat Strings mostly using java.lang.StringBuilder. The main
> disadvantage of StringBuilder is underlying char array or rather a need to
> resize it when the capacity is about to exceed array length and subsequent
> copying of array content into newly allocated array.
> 
> One alternative solution existing is StringJoiner. Before JDK 9 it was a kind 
> of
> decorator over StringBuilder, but later it was reworked in order to store
> appended Strings into String[] and overall capacity accumulated into int 
> field.
> This makes it possible to allocate char[] only once and of exact size in
> toString() method reducing allocation cost.
> 
> My proposal is to copy-paste the code of StringJoinder into newly created 
> class
> java.util.StringChain, drop the code responsible for delimiter, prefix and
> suffix and use it instead of StringBuilder in common StringBuilder::append
> concatenation pattern.
> 
> Possible use-cases for proposed code are:
> - plain String concatenation
> - String::chain (new methods)
> - Stream.collect(Collectors.joining())
> - StringConcatFactory
> 
> We can create new methods String.chain(Iterable) and
> String.chain(CharSequence...) which allow to encapsulate boilerplate code like
> 
> 
>  StringBuilder sb = new StringBuilder();
>  for (CharSequence cs : charSequences) {
>    sb.append(cs);
>  }
>  String result = sb.toString():
> 
> 
> into one line:
> 
> 
>  String result = String.chain(charSequences);
> 
> 
> 
> As of performance I've done some measurements using JMH on my work machine
> (Intel i7-7700) for both Latin and non-Latin Strings of different size and
> count.
> Here are the results:
> 
> https://github.com/stsypanov/string-chain/blob/master/results/StringBuilderVsStringChainBenchmark.txt
> 
> There is a few corner cases (e.g. 1000 Strings of length 1 appended) when
> StringBuilder takes over StringChain constructed with default capacity of 8,
> but StringChain constructed with exact added Strings count almost always wins,
> especially when dealing with non-Latin chars (Russian in my case).
> 
> I've also created a separate repo on GitHub with benchmarks:
> 
> https://github.com/stsypanov/string-chain
> 
> Key feature here is ability to allocate String array of exact size is cases we
> know added elements count.
> Thus I think that if the change will be accepted we can add also an overloaded
> method String.chain(Collection) as Collection::size allows to
> contruct StringChain of exact size.
> 
> Patch is attached.
> 
> Kind regards,
> Sergei Tsypanov

[PATCH] enhancement proposal for String concatenation

[Сергей Цыпанов]

Hello,

I have an enhancement proposal for some cases of String concatenation in Java.

Currently we concat Strings mostly using java.lang.StringBuilder. The main 
disadvantage of StringBuilder is underlying char array or rather a need to 
resize it when the capacity is about to exceed array length and subsequent 
copying of array content into newly allocated array.

One alternative solution existing is StringJoiner. Before JDK 9 it was a kind 
of decorator over StringBuilder, but later it was reworked in order to store 
appended Strings into String[] and overall capacity accumulated into int field. 
This makes it possible to allocate char[] only once and of exact size in 
toString() method reducing allocation cost.

My proposal is to copy-paste the code of StringJoinder into newly created class 
java.util.StringChain, drop the code responsible for delimiter, prefix and 
suffix and use it instead of StringBuilder in common StringBuilder::append 
concatenation pattern.

Possible use-cases for proposed code are:
- plain String concatenation
- String::chain (new methods)
- Stream.collect(Collectors.joining())
- StringConcatFactory

We can create new methods String.chain(Iterable) and 
String.chain(CharSequence...) which allow to encapsulate boilerplate code like


  StringBuilder sb = new StringBuilder();
  for (CharSequence cs : charSequences) {
    sb.append(cs);
  }
  String result = sb.toString():


into one line:


  String result = String.chain(charSequences);



As of performance I've done some measurements using JMH on my work machine 
(Intel i7-7700) for both Latin and non-Latin Strings of different size and 
count.
Here are the results:

https://github.com/stsypanov/string-chain/blob/master/results/StringBuilderVsStringChainBenchmark.txt

There is a few corner cases (e.g. 1000 Strings of length 1 appended) when 
StringBuilder takes over StringChain constructed with default capacity of 8, 
but StringChain constructed with exact added Strings count almost always wins, 
especially when dealing with non-Latin chars (Russian in my case).

I've also created a separate repo on GitHub with benchmarks:

https://github.com/stsypanov/string-chain

Key feature here is ability to allocate String array of exact size is cases we 
know added elements count.
Thus I think that if the change will be accepted we can add also an overloaded 
method String.chain(Collection) as Collection::size allows to 
contruct StringChain of exact size.

Patch is attached.

Kind regards,
Sergei Tsypanovdiff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.java
--- a/src/java.base/share/classes/java/lang/String.java
+++ b/src/java.base/share/classes/java/lang/String.java
@@ -25,6 +25,7 @@
 
 package java.lang;
 
+import java.lang.StringChain;
 import java.io.ObjectStreamField;
 import java.io.UnsupportedEncodingException;
 import java.lang.annotation.Native;
@@ -2455,6 +2456,51 @@
 }
 
 /**
+ * Returns a new {@code String} composed of copies of the
+ * {@code CharSequence elements} concatenated together
+ *
+ * @param elements an {@code Iterable} that will have its {@code elements}
+ * concatenated.
+ *
+ * @return a new {@code String} that is concatenated from the {@code elements}
+ * argument
+ *
+ * @throws NullPointerException if {@code elements} is {@code null}
+ *
+ * @since 13
+ */
+public static String chain(Iterable elements) {
+Objects.requireNonNull(elements);
+StringChain chain = new StringChain();
+for (CharSequence element : elements) {
+chain.add(element);
+}
+return chain.toString();
+}
+
+/**
+ * Returns a new {@code String} composed of copies of the
+ * {@code CharSequence elements} concatenated together
+ *
+ * @param elements the elements to concatenate.
+ *
+ * @return a new {@code String} that is concatenated from the {@code elements}
+ * argument
+ *
+ * @throws NullPointerException if {@code elements} is {@code null}
+ *
+ * @since 13
+ */
+public static String chain(CharSequence... elements) {
+Objects.requireNonNull(elements);
+StringChain chain = new StringChain(elements.length);
+for (CharSequence element : elements) {
+chain.add(element);
+}
+return chain.toString();
+}
+
+/**
  * Converts all of the characters in this {@code String} to lower
  * case using the rules of the given {@code Locale}.  Case mapping is based
  * on the Unicode Standard version specified by the {@link java.lang.Character Character}
diff --git a/src/java.base/share/classes/java/lang/StringChain.java b/src/java.base/share/classes/java/lang/StringChain.java
new file mode 100644
--- /dev/null
+++ b/src/java.base/share/classes/java/lang/StringChain.java
@@ -0,0 +1,157 @@
+package java.base.sh

Re: RFR (S) 8074817: Resolve disabled warnings for libverify

[Erik Joelsson]

Looks good to me, but someone from core libs should look at the source 
changes too.


/Erik

On 2019-03-08 09:35, Aleksey Shipilev wrote:

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

Fix:
   http://cr.openjdk.java.net/~shade/8074817/webrev.03/

This hopefully resolves warnings in libverify. See bug report for warnings list.

Testing: jdk-submit, local {Linux, Windows} x86_64 builds

Thanks,
-Aleksey

Re: jpackage ALL-SYSTEM

[Andy Herrick]

With jpackage EA 3 (build 17) the option --add-modules does not properly 
recognize the special cases ALL-SYSTEM, ALL-DEFAULT, and ALL_MODULE_PATH.


This will be addressed in the next EA release.

The default jlink options used (in EA 3) may also not include 
--bind-services jlink option, which it will moving forward.


In many cases the jlink options used by jpackage to construct the 
runtime for a modular application may not be exactly what the 
application wants.


In that case it is advisable to run jlink first to create the optimal 
runtime image for a specific application, then to run jpackage with 
--runtime-image option to use that runtime image when packaging the 
application.


/Andy


On 3/8/2019 9:57 AM, Michael Hall wrote:

I have made changes to my application that make it mostly functional with the 
exception of JMX pid attach as built by jpackage.
I thought I had this functionality working when I first got the application to 
use Java 9 but it no longer appears to work again now, either with my Java 9 
app or my 13-internal+0-jdk13-jpackage.17 version app.
I understand for this issue serviceability-dev might be a better list for this 
but there may be one jpackage issue concerned as well.
Again, I don’t consider this a jpackage problem, my application now builds as 
successfully as it currently can with jpackage as-is.
What I get attempting  a JMX attach is…
2019-03-08 08:27:03.173 HalfPipe[2071:67749] No attach providers
2019-03-08 08:27:03.174 HalfPipe[2071:67749] 
com.sun.tools.attach.AttachNotSupportedException: no providers installed
2019-03-08 08:27:03.174 HalfPipe[2071:67749]at 
jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:202)
2019-03-08 08:27:03.174 HalfPipe[2071:67749]at 
us.hall.scripting.PidConnect.pidConnect(PidConnect.java:44)
2019-03-08 08:27:03.174 HalfPipe[2071:67749]at 
us.hall.scripting.RhinoScriptableObject.pidConnect(RhinoScriptableObject.java:139)

The application also can’t be connected to from jconsole. Eclipse can be, so 
can a Java 8 app (Weka 3-8-2). jconsole shows Eclipse doing —add-modules 
ALL-SYSTEM
I was going to try this with my application but it did not work. The error 
persisted on that as a jvm argument.
Using it as a jpackage —add-modules parameter gets...
Module ALL-SYSTEM does not exist.

The one question I would have for jpackage is should this work as a 
—add-modules parameter?

However, if anyone has any suggestions on getting JMX attach to work besides 
adding  serviceability-dev  to my forums that would be appreciated as well.

Thanks.

Re: RFR: 8220281 IBM-858 alias name is missing on IBM00858 charset

[naoto . sato]

Hi Takiguchi-san,

Looks good to me. I'd replace Locale.ENGLISH with Locale.ROOT for 
toLowerCase() method.


On 3/7/19 4:57 PM, Ichiroh Takiguchi wrote:

Hello.

Could you review the fix ?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8220281
Change: https://cr.openjdk.java.net/~itakiguchi/8220281/webrev.00/

I'd like to obtain a sponsor for this issue.

en_US.IBM-858 was added into AIX 7.1 [1] and 7.2 [2]
IBM00858 charset was registered into IANA Character Sets. [3]
And Java already has IBM00858.
But IBM00858 charset has IBM-858 alias.


Did you mean "does not have"? BTW, have you tested the new test case on 
other platforms, i.e., Windows/Linux/macOS?


Naoto

Because of this situation, JDK13 does not start on AIX en_US.IBM-858 
locale.


I'd like to request to add some charset aliases against following charsets:
   ibm00858, ibm01140, ibm01141, ibm01142, ibm01143, ibm01144,
   ibm01145, ibm01146, ibm01147, ibm01148, ibm01149, x-ibm833

[1] 
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.nlsgdrf/support_languages_locales.htm 

[2] 
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.nlsgdrf/support_languages_locales.htm 


[3] https://www.iana.org/assignments/character-sets/character-sets.xhtml

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

Re: [13] RFR: 8220227: Host Locale Provider getDisplayCountry returns error message under non-English Win10

[naoto . sato]

Hi Nakamura-san,

Thanks for fixing this. Since it is using a heuristic way to detect 
"unknown", I'd use String.endsWith() instead of String.contains() both 
in HostLocaleProviderAdapterImpl.java and LocaleProviders.java, which 
would be more accurate.


Naoto

On 3/7/19 10:25 PM, Toshio 5 Nakamura wrote:


Hi,

Could you review this fix? I'd like to have a sponsor of it, since I'm an
author.

Bug: https://bugs.openjdk.java.net/browse/JDK-8220227
Webrev: http://cr.openjdk.java.net/~tnakamura/8220227/webrev.00/

Issue:
Under Windows 10 non-English, Locale.getDisplayCountry() shows an error
message,
if Host Locale Provider is used (-Djava.locale.providers=HOST).

Fix proposal:
The current code compares "Unknown Region (" with the result, but it could
be translated.
I believe we can compare it with "("+RegionCode+")", which covers all 38
Language
Packs of Windows Server 2016.

Thanks,
Toshio Nakamura

Re: jpackage ALL-SYSTEM

[Bernd Eckenfels]

Can you confir it works if you start your application with a stand-alone JDK?

I suspect you have a custom jlink Image which misses the modules. Can you share 
your jpackage configuration or at least run „Java –list-modules“ and 
–validate-modules in your installed app? I think you Need at least jdk.attach


jdk.attach provides com.sun.tools.attach.spi.AttachProvider used by jdk.attach
-- 
http://bernd.eckenfels.net

Von: Michael Hall
Gesendet: Freitag, 8. März 2019 18:29
An: core-libs-dev@openjdk.java.net
Betreff: jpackage ALL-SYSTEM

I have made changes to my application that make it mostly functional with the 
exception of JMX pid attach as built by jpackage. 
I thought I had this functionality working when I first got the application to 
use Java 9 but it no longer appears to work again now, either with my Java 9 
app or my 13-internal+0-jdk13-jpackage.17 version app.
I understand for this issue serviceability-dev might be a better list for this 
but there may be one jpackage issue concerned as well.
Again, I don’t consider this a jpackage problem, my application now builds as 
successfully as it currently can with jpackage as-is.
What I get attempting  a JMX attach is…
2019-03-08 08:27:03.173 HalfPipe[2071:67749] No attach providers
2019-03-08 08:27:03.174 HalfPipe[2071:67749] 
com.sun.tools.attach.AttachNotSupportedException: no providers installed
2019-03-08 08:27:03.174 HalfPipe[2071:67749]at 
jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:202)
2019-03-08 08:27:03.174 HalfPipe[2071:67749]at 
us.hall.scripting.PidConnect.pidConnect(PidConnect.java:44)
2019-03-08 08:27:03.174 HalfPipe[2071:67749]at 
us.hall.scripting.RhinoScriptableObject.pidConnect(RhinoScriptableObject.java:139)

The application also can’t be connected to from jconsole. Eclipse can be, so 
can a Java 8 app (Weka 3-8-2). jconsole shows Eclipse doing —add-modules 
ALL-SYSTEM
I was going to try this with my application but it did not work. The error 
persisted on that as a jvm argument.
Using it as a jpackage —add-modules parameter gets... 
Module ALL-SYSTEM does not exist.

The one question I would have for jpackage is should this work as a 
—add-modules parameter?

However, if anyone has any suggestions on getting JMX attach to work besides 
adding  serviceability-dev  to my forums that would be appreciated as well.

Thanks.

RFR (S) 8074817: Resolve disabled warnings for libverify

[Aleksey Shipilev]

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

Fix:
  http://cr.openjdk.java.net/~shade/8074817/webrev.03/

This hopefully resolves warnings in libverify. See bug report for warnings list.

Testing: jdk-submit, local {Linux, Windows} x86_64 builds

Thanks,
-Aleksey

Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

[raffaello . giulietti]

On 2019-03-08 14:35, Andrew Haley wrote:
> Hi,
> 
> On 3/7/19 7:16 PM, Raffaello Giulietti wrote:
> 
>> a couple of weeks ago I tried to refactor the code assuming the 
>> existence of unsignedMultiplyHigh() (either as some future intrinsic or 
>> as a Java method) and a wider representations of g with either 127 or 
>> 128 bits:
>>  g = g1 2^64 + g0
>>
>> with either
>>  2^63 <= g1 < 2^64 (128 bits)
>>
>> or
>>  2^62 <= g1 < 2^63 (127 bits)
>>
>> Unfortunately, the resulting code of rop() isn't any simpler. That's 
>> because then an intermediate sum can overflow the 64 bits of a long. As 
>> a consequence, there's need for more elaborate logic to determine
>> the carry and other slightly more complicated computations to assemble
>> the final result. All in all, the resulting code has more operations and 
>> looks longer.
> 
> Ah, I see. I agree, we still don't quite have the full set of operations
> that we need in Java, in particular a nice way of doing an add with carry.
> 

Yes.


> Thank you for the explanation.
> 

You're welcome.


>> In the meantime I got rid of the last division. There's no division at 
>> all in the whole algorithm.
> 
> Excellent. This is looking very good indeed.
> 

Re: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux

[Andrew Haley]

On 3/8/19 2:39 PM, Langer, Christoph wrote:
> please review the CSR backport 
> https://bugs.openjdk.java.net/browse/JDK-8220362.
> 
> It is the backport of https://bugs.openjdk.java.net/browse/JDK-8214511 to 
> JDK11.
> 
> We want to backport 
> JDK-8212828 to jdk11u and 
> hence backporting the CSR is a prerequisite. The CSR is, however, more or 
> less identical for 11u.

I don't see any explanation of why this should go into jdk11.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

jpackage ALL-SYSTEM

[Michael Hall]

I have made changes to my application that make it mostly functional with the 
exception of JMX pid attach as built by jpackage. 
I thought I had this functionality working when I first got the application to 
use Java 9 but it no longer appears to work again now, either with my Java 9 
app or my 13-internal+0-jdk13-jpackage.17 version app.
I understand for this issue serviceability-dev might be a better list for this 
but there may be one jpackage issue concerned as well.
Again, I don’t consider this a jpackage problem, my application now builds as 
successfully as it currently can with jpackage as-is.
What I get attempting  a JMX attach is…
2019-03-08 08:27:03.173 HalfPipe[2071:67749] No attach providers
2019-03-08 08:27:03.174 HalfPipe[2071:67749] 
com.sun.tools.attach.AttachNotSupportedException: no providers installed
2019-03-08 08:27:03.174 HalfPipe[2071:67749]at 
jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:202)
2019-03-08 08:27:03.174 HalfPipe[2071:67749]at 
us.hall.scripting.PidConnect.pidConnect(PidConnect.java:44)
2019-03-08 08:27:03.174 HalfPipe[2071:67749]at 
us.hall.scripting.RhinoScriptableObject.pidConnect(RhinoScriptableObject.java:139)

The application also can’t be connected to from jconsole. Eclipse can be, so 
can a Java 8 app (Weka 3-8-2). jconsole shows Eclipse doing —add-modules 
ALL-SYSTEM
I was going to try this with my application but it did not work. The error 
persisted on that as a jvm argument.
Using it as a jpackage —add-modules parameter gets... 
Module ALL-SYSTEM does not exist.

The one question I would have for jpackage is should this work as a 
—add-modules parameter?

However, if anyone has any suggestions on getting JMX attach to work besides 
adding  serviceability-dev  to my forums that would be appreciated as well.

Thanks.

[11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux

[Langer, Christoph]

Hi,

please review the CSR backport https://bugs.openjdk.java.net/browse/JDK-8220362.

It is the backport of https://bugs.openjdk.java.net/browse/JDK-8214511 to JDK11.

We want to backport 
JDK-8212828 to jdk11u and 
hence backporting the CSR is a prerequisite. The CSR is, however, more or less 
identical for 11u.

Thank you and Best regards
Christoph

Re: RFR: JDK-8214566 : --win-dir-chooser does not prompt if destination folder is not empty

[Erik Joelsson]

Build changes look good.

/Erik

On 2019-03-07 14:52, Alexander Matveev wrote:

Hi Erik,

http://cr.openjdk.java.net/~almatvee/8214566/webrev.01/

- Removed $(call SET_SHARED_LIBRARY_ORIGIN), TOOLCHAIN_LINK_CXX and 
linking with libjava.


Thanks,
Alexander

On 3/7/2019 6:52 AM, Erik Joelsson wrote:

Hello Alexander,

A few notes:

$(call SET_SHARED_LIBRARY_ORIGIN) and TOOLCHAIN_LINK_CXX have no 
effect on Windows, so should be removed to avoid confusion in the 
future.


This new library does not link with libjava so I see no need to add 
that prerequisite declaration.


/Erik

On 2019-03-06 17:10, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Added custom action to check installation folder and display 
confirmation dialog to ask user to continue installation if 
destination folder is not empty. This is same behavior and 
confirmation message as for .exe.


[1] https://bugs.openjdk.java.net/browse/JDK-8214566

[2] http://cr.openjdk.java.net/~almatvee/8214566/webrev.00/

Thanks,
Alexander

Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

[Andrew Haley]

Hi,

On 3/7/19 7:16 PM, Raffaello Giulietti wrote:

> a couple of weeks ago I tried to refactor the code assuming the 
> existence of unsignedMultiplyHigh() (either as some future intrinsic or 
> as a Java method) and a wider representations of g with either 127 or 
> 128 bits:
>  g = g1 2^64 + g0
> 
> with either
>  2^63 <= g1 < 2^64 (128 bits)
> 
> or
>  2^62 <= g1 < 2^63 (127 bits)
> 
> Unfortunately, the resulting code of rop() isn't any simpler. That's 
> because then an intermediate sum can overflow the 64 bits of a long. As 
> a consequence, there's need for more elaborate logic to determine
> the carry and other slightly more complicated computations to assemble
> the final result. All in all, the resulting code has more operations and 
> looks longer.

Ah, I see. I agree, we still don't quite have the full set of operations
that we need in Java, in particular a nice way of doing an add with carry.

Thank you for the explanation.

> In the meantime I got rid of the last division. There's no division at 
> all in the whole algorithm.

Excellent. This is looking very good indeed.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull

[Tagir Valeev]

Hello!

> diff -r 274361bd6915 src/java.base/share/classes/java/lang/Throwable.java
> --- a/src/java.base/share/classes/java/lang/Throwable.javaThu Mar 07
> 10:22:19 2019 +0100
> +++ b/src/java.base/share/classes/java/lang/Throwable.javaFri Mar 08
> 02:06:42 2019 -0800
> @@ -874,8 +874,7 @@
>   // Validate argument
>   StackTraceElement[] defensiveCopy = stackTrace.clone();
>   for (int i = 0; i < defensiveCopy.length; i++) {
> -if (defensiveCopy[i] == null)
> -throw new NullPointerException("stackTrace[" + i + "]");
> +Objects.requireNonNull(defensiveCopy[i], "stackTrace[" + i
> + "]");

Won't it produce unnecessary garbage due to string concatenation on
the common case when all frames are non-null?

With best regards,
Tagir Valeev.

Re: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull

[Lance Andersen]

+1
> On Mar 8, 2019, at 6:08 AM, Joe Darcy  wrote:
> 
> Hello,
> 
> The code in java.lang.Throwable has various explicit null checks that could 
> be rewritten to use Objects.requireNonNull.
> 
> Please review the patch below which implements this refactoring.
> 
> Thanks,
> 
> -Joe
> 
> diff -r 274361bd6915 src/java.base/share/classes/java/lang/Throwable.java
> --- a/src/java.base/share/classes/java/lang/Throwable.javaThu Mar 07 
> 10:22:19 2019 +0100
> +++ b/src/java.base/share/classes/java/lang/Throwable.javaFri Mar 08 
> 02:06:42 2019 -0800
> @@ -874,8 +874,7 @@
>  // Validate argument
>  StackTraceElement[] defensiveCopy = stackTrace.clone();
>  for (int i = 0; i < defensiveCopy.length; i++) {
> -if (defensiveCopy[i] == null)
> -throw new NullPointerException("stackTrace[" + i + "]");
> +Objects.requireNonNull(defensiveCopy[i], "stackTrace[" + i + 
> "]");
>  }
> 
>  synchronized (this) {
> @@ -914,8 +913,7 @@
>  for (Throwable t : suppressedExceptions) {
>  // Enforce constraints on suppressed exceptions in
>  // case of corrupt or malicious stream.
> -if (t == null)
> -throw new NullPointerException(NULL_CAUSE_MESSAGE);
> +Objects.requireNonNull(t, NULL_CAUSE_MESSAGE);
>  if (t == this)
>  throw new 
> IllegalArgumentException(SELF_SUPPRESSION_MESSAGE);
>  suppressed.add(t);
> @@ -942,8 +940,7 @@
>  stackTrace = null;
>  } else { // Verify stack trace elements are non-null.
>  for(StackTraceElement ste : stackTrace) {
> -if (ste == null)
> -throw new NullPointerException("null 
> StackTraceElement in serial stream. ");
> +Objects.requireNonNull(ste, "null StackTraceElement in 
> serial stream. ");
>  }
>  }
>  } else {
> @@ -1034,8 +1031,7 @@
>  if (exception == this)
>  throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, 
> exception);
> 
> -if (exception == null)
> -throw new NullPointerException(NULL_CAUSE_MESSAGE);
> +Objects.requireNonNull(exception, NULL_CAUSE_MESSAGE);
> 
>  if (suppressedExceptions == null) // Suppressed exceptions not 
> recorded
>  return;
> 

 
  

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

JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull

[Joe Darcy]

Hello,

The code in java.lang.Throwable has various explicit null checks that 
could be rewritten to use Objects.requireNonNull.


Please review the patch below which implements this refactoring.

Thanks,

-Joe

diff -r 274361bd6915 src/java.base/share/classes/java/lang/Throwable.java
--- a/src/java.base/share/classes/java/lang/Throwable.java    Thu Mar 07 
10:22:19 2019 +0100
+++ b/src/java.base/share/classes/java/lang/Throwable.java    Fri Mar 08 
02:06:42 2019 -0800

@@ -874,8 +874,7 @@
 // Validate argument
 StackTraceElement[] defensiveCopy = stackTrace.clone();
 for (int i = 0; i < defensiveCopy.length; i++) {
-    if (defensiveCopy[i] == null)
-    throw new NullPointerException("stackTrace[" + i + "]");
+    Objects.requireNonNull(defensiveCopy[i], "stackTrace[" + i 
+ "]");

 }

 synchronized (this) {
@@ -914,8 +913,7 @@
 for (Throwable t : suppressedExceptions) {
 // Enforce constraints on suppressed exceptions in
 // case of corrupt or malicious stream.
-    if (t == null)
-    throw new NullPointerException(NULL_CAUSE_MESSAGE);
+    Objects.requireNonNull(t, NULL_CAUSE_MESSAGE);
 if (t == this)
 throw new 
IllegalArgumentException(SELF_SUPPRESSION_MESSAGE);

 suppressed.add(t);
@@ -942,8 +940,7 @@
 stackTrace = null;
 } else { // Verify stack trace elements are non-null.
 for(StackTraceElement ste : stackTrace) {
-    if (ste == null)
-    throw new NullPointerException("null 
StackTraceElement in serial stream. ");
+    Objects.requireNonNull(ste, "null StackTraceElement 
in serial stream. ");

 }
 }
 } else {
@@ -1034,8 +1031,7 @@
 if (exception == this)
 throw new 
IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception);


-    if (exception == null)
-    throw new NullPointerException(NULL_CAUSE_MESSAGE);
+    Objects.requireNonNull(exception, NULL_CAUSE_MESSAGE);

 if (suppressedExceptions == null) // Suppressed exceptions not 
recorded

 return;

Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

[Brian Burkhalter]

> On Mar 7, 2019, at 6:01 PM, Andrew Haley  wrote:
> 
> On 3/7/19 10:10 AM, Brian Burkhalter wrote:
>> 
>>> On Mar 7, 2019, at 10:04 AM, Andrew Haley >> > wrote:
>>> 
>>> I still believe you'd be better off defining an unsigned multiplyHigh than
>>> all that messing about with shifts and masks in rop().
>> 
>> There is in fact an open issue for unsigned multiplyHigh:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8188044 
>> 
> 
> Do you want to do it? If not I will.

Your contribution would be most welcome.

Thanks,

Brian