Re:

[Laurent Bourgès]

Hi Vladimir,


>
>>
>> The test suite was described in this paper
>>
>> Jon L. Bentley, M. Douglas McILroy
>> “Engineering a Sort Function”, 1993
>>
>> I use Java version (a little bit extended), see attachment.
>> What you need is to specified sorting classes in IntSorter.java
>> and run BentleyBasher.
>>
>
> Thanks, what is the license of this code ? Files do not have any header...
>
> If you agree, I would like to host such test code on github, as an
> opensource repository.
>

What is your decision ?
 Can I put such precious test code on github (MIT license) in my fork of
sebastian wild's nearly-optimal-mergesort ?

https://github.com/bourgesl/nearly-optimal-mergesort-code/

Cheers,
Laurent

Re: RFR JDK-8211051: jdeps usage of --dot-output doesn't provide valid output for modular jar

[Sundararajan Athijegannathan]

+1

-Sundar

On 15/11/18, 5:42 AM, Mandy Chung wrote:

This is a small fix to jdeps --dot-output option that should
name the dot file with the filename of the modular JAR rather
than its module name.

http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8211051/webrev.00/

Thanks
Mandy

[12]RFR 8210408: Refactor java.util.ResourceBundle:i18n shell tests to plain java tests

[Dora Zhou]

Hello,

Please help review the fix for refactor java.util.ResourceBundle:i18n 
shell tests to plain java tests. Thank you.


Shell Tests:
test/java/util/ResourceBundle/modules/appbasic2/appbasic2.sh
test/java/util/ResourceBundle/modules/xmlformat/xmlformat.sh
test/java/util/ResourceBundle/modules/unnamed/unnamed.sh
test/java/util/ResourceBundle/modules/appbasic/appbasic.sh
test/java/util/ResourceBundle/modules/visibility/visibility.sh
test/java/util/ResourceBundle/modules/modlocal/modlocal.sh
test/java/util/ResourceBundle/modules/simple/simple.sh
test/java/util/ResourceBundle/modules/basic/basic.sh
test/java/util/ResourceBundle/modules/layer/run.sh
test/java/util/ResourceBundle/Bug6299235Test.sh

I merged appbasic, appbasic2, basic, simple, xml, modlocal together with 
one BasicTest.main().


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

webrev: http://cr.openjdk.java.net/~dzhou/8210408/webrev.02/

Regards,
Dora

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

[Roger Riggs]

Hi,

Does --limit-modules work as intended, are there any tests?
With a command such as:

jpackager -Djlink.debug=true create-image \
    --input out/artifacts \
    --output out \
    --limit-modules java.base \
    --main-jar Hello-jar/Hello.jar \
    --class Main

It complains that:
Exception: jdk.tools.jlink.plugin.PluginException: 
java.lang.module.FindException: Module jdk.compiler not found, required 
by jdk.jdeps


After adding a few more modules it stops complaining about missing 
dependencies:
 --limit-modules 
java.base,jdk.compiler,jdk.internal.le,jdk.internal.ed,jdk.internal.opt \



But still,

The generated runtime/bin/java --show-modules includes the full list of 
jdk modules.



In the code:

JLinkBundlerHelper.ModuleHelper ignores the limitMods argument and produces
a complete set of redistributable modules.


It should be possible to build a runtime with only the java.base module.

What should I expect?

Thanks, Roger




On 11/09/2018 05:25 PM, Andy Herrick wrote:
This is an update to the Request For Review of the implementation of 
the Java Packager Tool (jpackager) as described in JEP 343: Packaging 
Tool 


This refresh renames the packages used to jdk.jpackager and 
jdk.jpackager.runtime, removes the JNLPConverter demo, adds an initial 
set of automated tests, and contains fixes to the following issues:


JDK-8213324 jpackager deletes existing app directory without warning
JDK-8213166 jpackager --argument arg is broken
JDK-8213163 --app-image arg does not work creating exe installers
JDK-8212089 Prepare packager for localization
JDK-8212537 Create method and class description comments for main 
functionality

JDK-8213332 Create minimal automated tests for jpackager
JDK-821 Fix issues found in jpackager with automated tests
JDK-8213394 Stop using Log.info() except for expected output.
JDK-8213345 Secondary Launchers broken on mac.
JDK-8213156 rename packages for jpackager
JDK-8213244 Fix all warnings in jpackager java code
JDK-8212143 Remove native code that supports UserJvmOptionsService
JDK-8213162 Association description in Inno Setup cannot contain 
double quotes


The following additional issues are targeted to be address in the next 
few weeks:

JDK-8212936 Makefile and other improvements for jpackager
JDK-8212164 resolve jre.list and jre.module.list
JDK-8213392 Enhance --help and --version
JDK-8208652 File name is not passed to main() via file association 
on OS X

JDK-8212538 Determine standard way to determine if a Modular jar
JDK-8213558 Create more unit tests

Webrev: http://cr.openjdk.java.net/~herrick/8212780/webrev.2/

please send feedback to core-libs-dev@openjdk.java.net

/Andy Herrick

Re: RFR of JDK-8211974,move testlibrary/java/util/jar/CreateMultiReleaseTestJars.java to a separate testlibrary

[Igor Ignatyev]

Hi Hamlin,

Although I understand your reasoning, I do share Amy's concerns on doing less 
than the RFEs ask for (as w/ 8211972). so I'd suggest you to split your patch 
into 4 separate patches and RFRs, one per original RFE. this won't just return 
sanity to reviewers and review, reduce chance of leaving already fixed bugs 
forgotten/forsaken, but will also make it possible to push ones which don't 
cause any concerns.

Thanks,
-- Igor 

> On Oct 11, 2018, at 11:28 PM, Amy Lu  wrote:
> 
> On 2018/10/12 2:16 PM, Hamlin Li wrote:
>> yes, e.g. https://bugs.openjdk.java.net/browse/JDK-8212033
> 
> It seems mentioned bug is duplicate with
> 
> JDK-8211972: remove testlibrary/java/util/jar/Compiler.java - "suggest 
> removing and using jdk.test.lib.compiler.InMemoryJavaCompiler instead"
> 
> which is included in this changeset.
> 
> Thanks,
> Amy
> 
>> 
>> Thank you
>> 
>> -Hamlin
>> 
>> 
>> On 2018/10/12 2:13 PM, Amy Lu wrote:
>>> Hi, Hamlin
>>> 
>>> - test/lib/jdk/test/lib/compiler/Compiler.java (was 
>>> test/jdk/lib/testlibrary/java/util/jar/Compiler.java)
>>> Any future plan to "merge" it with existing 
>>> jdk.test.lib.compiler.CompilerUtils?
>>> 
>>> - test/lib/jdk/test/lib/util/JarBuilder.java (was 
>>> test/jdk/lib/testlibrary/java/util/jar/JarBuilder.java)
>>> Any future plan to "merge" it with existing jdk.test.lib.util.JarUtils?
>>> 
>>> Thanks,
>>> Amy
>>> 
>>> On 2018/10/12 2:00 PM, Hamlin Li wrote:
 Hi Igor,
 
 It's updated in place http://cr.openjdk.java.net/~mli/8211974/webrev.00/, 
 please review it again.
 
 Thank you
 
 -Hamlin
 
 
 On 2018/10/12 1:34 PM, Igor Ignatyev wrote:
> Hi Hamlin,
> 
> could you please move jdk.test.lib.util.Compiler to j.t.l.compiler 
> package? we use this package for classes which have dependency on 
> jdk.compiler and/or java.compiler module.
> 
> it'd also be nice to put CreateMultiReleaseTestJars into a named package.
> 
> -- Igor
>> On Oct 11, 2018, at 10:23 PM, Hamlin Li  wrote:
>> 
>> would you please review the following patch?
>> 
>> bug:
>> 
>>https://bugs.openjdk.java.net/browse/JDK-8211974
>> 
>>https://bugs.openjdk.java.net/browse/JDK-8211972
>> 
>>https://bugs.openjdk.java.net/browse/JDK-8211973
>> 
>>https://bugs.openjdk.java.net/browse/JDK-8211979
>> 
>> webrev: http://cr.openjdk.java.net/~mli/8211974/webrev.00/
>> 
>> Thank you
>> 
>> -Hamlin
>> 
 
>>> 
>> 
> 

Re: RFR: XXS: JDK-8213910: Invalid HTML in java.net.http.HttpClient

[Pavel Rappo]

Looks fine to me. 

P.S. Looks like your doccheck has already started to pay off.

> On 15 Nov 2018, at 00:01, Jonathan Gibbons  
> wrote:
> 
> Please review the removal of two extraneous  in HttpClient.java.
> 
> $ hg diff -R open
> diff -r 40098289d580 
> src/java.net.http/share/classes/java/net/http/HttpClient.java
> --- a/src/java.net.http/share/classes/java/net/http/HttpClient.java Wed Nov 
> 14 12:25:15 2018 -0800
> +++ b/src/java.net.http/share/classes/java/net/http/HttpClient.java Wed Nov 
> 14 15:56:04 2018 -0800
> @@ -104,7 +104,7 @@
>   *.thenApply(HttpResponse::body)
>   *.thenAccept(System.out::println); }
>   *
> - *  Security checks
> + *  Security checks
>   *
>   *  If a security manager is present then security checks are performed by
>   * the HTTP Client's sending methods. An appropriate {@link URLPermission} is
> @@ -327,7 +327,7 @@
>   * then newly built clients will use the {@linkplain
>   * ProxySelector#getDefault() default proxy selector}, which is 
> usually
>   * adequate for client applications. The default proxy selector 
> supports
> - * a set of system properties related to
> + * a set of system properties related to
>   *  href="{@docRoot}/java.base/java/net/doc-files/net-properties.html#Proxies">
>   * proxy settings. This default behavior can be disabled by
>   * supplying an explicit proxy selector, such as {@link #NO_PROXY} or
> 
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8213910
> 
> -- Jon
> 

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

[Brian Burkhalter]

Hi Brent / Daniel,

> On Nov 9, 2018, at 4:41 PM, Brent Christian  
> wrote:
> 
> On 11/9/18 2:04 PM, Brian Burkhalter wrote:
>> An updated patch is at
>> http://cr.openjdk.java.net/~bpb/6516099/webrev.06/ 
>>  
>> > >
>> including a revision of the implementation to align with the words. The 
>> tests are not updated yet.
> 
> I think this looks quite good.
> 
> My only comment is that
> 
> 568  * If {@code n} is zero or negative, then no bytes are skipped.
> 
> seems a bit redundant, given the opening paragraph.  I could take it or leave 
> it.


If the content of the @implSpec is supposed to be self-contained, then I think 
it should remain. As that does not appear to be the case, I agree that it could 
be deleted.

> On Nov 12, 2018, at 2:48 AM, Daniel Fuchs  wrote:
> 
> But I wonder if skip(n) returning a negative value
> (ns < 0) when n has been asserted to be > 0 should be
> considered as an error, and if an IOException should
> be thrown?

I tend to agree that covering this sort of aberration is probably a good idea.

I have updated the patch per the foregoing comments and have also improved the 
Skip test:

http://cr.openjdk.java.net/~bpb/6516099/webrev.07/

Thanks,

Brian

Re: RFR 4947890 : Minimize JNI upcalls in system-properties initialization

[Roger Riggs]

Hi Brent,


On 11/14/2018 06:54 PM, Brent Christian wrote:

Hi, Roger

* I like Mandy's idea of not combining the cli/VM props and the 
well-known props into a single array.  Maybe we could then avoid 
copying between arrays (System.c L166).

yes, it would avoid the copy.


* The name "Raw" doesn't really speak to me.  It's OK as an inner 
class, though I wonder if everything could be done in SystemProps 
directly.
Raw to make it clear that these are not system properties, just data to 
be used to

create the system properties.

In some other prototyping, there were quite a few other changes in 
SystemProps
so keeping the primitive data separate was useful, possibly the class 
could be unloaded

since its use-once code.


A few other comments:

java.base/share/native/libjava/System.c:

 112  * The first FIXED_LENGTH entries are the platform defined 
property values, no names.

 113  * The remaining array indices are alternating key/value pairs
 114  * supplied by the VM including those defined on the command line
 115  * using -Dkey=value that may override the platform defined value.

Some of this would also be useful information SystemProps.java, maybe 
in the comment for Raw.initProps.  Or refer the reader to 
Java_jdk_internal_util_SystemProps_00024Raw_getRawProperties for a 
description of the layout of the array.  Or may become moot if we use 
two separate arrays.
Agreed, a more complete description would be good in the declaration of 
the native method.


--

file.encoding used to be set from sprops->encoding on Mac, and 
sprops->sun_jnu_encoding otherwise:


 382 #ifdef MACOSX
 383 /*
 384  * Since sun_jnu_encoding is now hard-coded to UTF-8 on 
Mac, we don't

 385  * want to use it to overwrite file.encoding
 386  */
 387 PUTPROP(props, "file.encoding", sprops->encoding);
 388 #else
 389 PUTPROP(props, "file.encoding", sprops->sun_jnu_encoding);
 390 #endif

There is no longer an ifdef for this.  But I guess this is OK, as
SystemProps.initProperties() will only put a value for "file.encoding" 
if there isn't one, and only uses sun.jnu.encoding if there is no 
file.encoding:


  59 putIfAbsent(props, "file.encoding",
  60 ((raw.propDefault(Raw._file_encoding_NDX) == null)
  61 ? raw.propDefault(Raw._sun_jnu_encoding_NDX)
  62 : raw.propDefault(Raw._file_encoding_NDX)));


Yes, I spent some time ensuring that the result was the same.
Thanks for confirming the logic.

--

 313 * Command line overrides with -D are copied above from 
JVM_getProperties.


s/JVM_get/JVM_Get/

right, fixed, Java naming conventions bleeding into native.



java.base/share/classes/jdk/internal/util/SystemProps.java:

 126 /**
 127  * Puts the property if it is non-null
 128  * @param props the Properties
 129  * @param key the key
 130  * @param value the value
 131  */
 132 private static void put(Properties props, String key, String 
value) {


I notice that this method is only called once.
Yes, at the moment, that is the only property that must not be 
overridden on the command line.
There are others that probably should not be overridable but for 
compatibility...


--

 175 cmdProps.put(disp, dispValue);
...
 186 cmdProps.put(fmt, fmtValue);
) {

    } else if (
Aren't L175 & L186 just putting the property that is already there ?
Oops,  that's a carryover from a different implementation that had 
separate maps.
Those can be removed since an I18N property on the command is always 
retained

only defined if the platform value is supplied and different than the base.

Thanks for the review and suggestions

Roger



Thanks,
-Brent

On 11/13/18 7:59 AM, Roger Riggs wrote:
Please review a re-implementation of the initialization of System 
properties

moving some functions from native to Java.

The upcalls from native to java for each property are replaced by a 
mechanism

to gather the platform, VM and command line properties and return them
from a single JNI call.  The creation of the Properties instance and 
applying

command line overrides is handled in Java instead of native.

The JVM_initProperties interface in Hotspot is replaced by 
JVM_getProperties.


Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-props-only-raw/

Issue:
   https://bugs.openjdk.java.net/browse/JDK-4947890

Thanks, Roger

Re: RFR 4947890 : Minimize JNI upcalls in system-properties initialization

[Roger Riggs]

Hi Mandy,

On 11/14/2018 05:18 PM, Mandy Chung wrote:

Hi Roger,

The system property initialization long for a clean up.
Thanks for looking at it.  This is a good start.  I think
it'd be good to make further improvement.
140 cmdProps = JVM_GetProperties(env); Instead of prepending the 
predefined set of properties with cmdProps, I suggest to separate 
getRawProperties into two separate methods 1. get the system 
properties defined by -D 2. the predefined properties

I considered that too, but decided a single native call was sufficient
even if the String array was dual purpose.
Perhaps with so little impact on performance two calls are insignificant.
176 PUTPROP(propArray, _java_specification_version_NDX, 
VERSION_SPECIFICATION);
177 PUTPROP(propArray, _java_specification_name_NDX, "Java Platform 
API Specification");
178 PUTPROP(propArray, _java_specification_vendor_NDX, 
JAVA_SPECIFICATION_VENDOR);

179
180 PUTPROP(propArray, _java_vendor_NDX, VENDOR);
181 PUTPROP(propArray, _java_vendor_url_NDX, VENDOR_URL);
182 PUTPROP(propArray, _java_vendor_url_bug_NDX, VENDOR_URL_BUG);
183
184 jio_snprintf(buf, sizeof(buf), "%d.%d", JVM_CLASSFILE_MAJOR_VERSION,
185 JVM_CLASSFILE_MINOR_VERSION);
186 PUTPROP(propArray, _java_class_version_NDX, buf);
These are defined at build time.  Can they be moved to 
VersionProps.java.template?

yes, but that is a separate cdata structure change, and
there are other properties that should be moved to desktop or 2d modules.


130 // Get the platform specific values
  131 sprops = GetJavaProperties(env);
   :
  191 PUTPROP(propArray, _os_name_NDX, sprops->os_name);
  192 PUTPROP(propArray, _os_version_NDX, sprops->os_version);
  193 PUTPROP(propArray, _os_arch_NDX, sprops->os_arch);

This obtains the platform-specific configuration and then later
sets the value in the array of a predefined index.

Have you considered other alternatives?  SystemProps.Raw can
define the named prop value instead of index e.g.
private static String _os_arch;

yes, I built a complete prototype using raw fields and having
the native code store to them directly.
I decided that it was more overhead and a more complex native
implementation so was less desirable.  It had no better performance.



these fields are set via JNI.  Or have the native method
to return Object[] with the property name/value pair as
in the VM.

SystemProps.java

   69 putIfAbsent(props, "user.name", 
raw.propDefault(Raw._user_name_NDX));
   70 putIfAbsent(props, "os.name", raw.propDefault(Raw._os_name_NDX));
   71 putIfAbsent(props, "os.arch", raw.propDefault(Raw._os_arch_NDX));
   72 putIfAbsent(props, "os.version", 
raw.propDefault(Raw._os_version_NDX));
   73 putIfAbsent(props, "line.separator", 
raw.propDefault(Raw._line_separator_NDX));
   74 putIfAbsent(props, "file.separator", 
raw.propDefault(Raw._file_separator_NDX));
   75 putIfAbsent(props, "path.separator", 
raw.propDefault(Raw._path_separator_NDX));

jdk.internal.util.StaticProperty calls System.getProperty.
Should we move the above (or more) static properties and
initialize their values directly in StaticProperty class?
This is out of the scope of this issue but if we initialize
the field values directly via JNI.  Something that might
worth exploring.
I left that cleanup for a second pass, if the basic idea was found to be 
sound.

It kept this change simple, modifying fewer files and kept the change set
easier to understand.

My goal besides performance, was to minimize the native surface area and
structure it in a way to reduce maintenance and native <-> java 
dependencies.


Thanks, Roger




thanks
Mandy

Re: RFR: XXXS: JDK-8213913: Redundant HTML in java.se/module-info.java

[Mandy Chung]

+1

Mandy

On 11/14/18 4:20 PM, Jonathan Gibbons wrote:
Please review the remove of an unnecessary  tag from 
java.se/module-info.java that is showing up in "tidy" reports by 
doccheck.


$ hg diff -R open
diff -r 8934429cfb0b src/java.se/share/classes/module-info.java
--- a/src/java.se/share/classes/module-info.java Wed Nov 14 16:11:21 
2018 -0800
+++ b/src/java.se/share/classes/module-info.java Wed Nov 14 16:17:37 
2018 -0800

@@ -25,7 +25,6 @@

 /**
  * Defines the API of the Java SE Platform.
- * 
  *
  * 
  * Optional for the Java SE Platform:


-- Jon

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

Re: Re: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX default charset

[Ichiroh Takiguchi]

Hello Martin.

I know your point, but it's default encoding issue.
User cannot start OpenJDK JDK9/10/11/12 on ja_JP(IBM29626C) and 
zh_TW(IBM964)

locale on AIX.
But IBM964 cannot be used for default encoding in current setting.
This fix is really required on OpenJDK for AIX.

Ichiroh Takiguchi

On 2018-11-15 04:50, Martin Buchholz wrote:

Ichiroh, IBM/AIX people should reach consensus on how to handle IBM
charsets.  I'm going to add some IBM people who might know or care.

(I haven't used AIX in 20 years)

On Wed, Nov 14, 2018 at 10:23 AM, Ichiroh Takiguchi <
taki...@linux.vnet.ibm.com> wrote:


Hello.

Martin Buchholz suggested me via bugs.openjdk.java.net,
I should not touch non AIX side.
So I rewrote another code.
Could you review the fix again ?

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

I don't want to touch non AIX side code, but I need to rename 3 files
to avoid compilation issue.
IBM33722.java -> IBM33722.java.template
IBM964.java -> IBM964.java.template
SimpleEUCEncoder.java -> SimpleEUCEncoder.java.template

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

 Original Message 
Subject: Re: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX
default charset
Date: 2018-11-08 20:13
From: Volker Simonis 
To: Ichiroh Takiguchi 
Cc: Java Core Libs ,
ppc-aix-port-...@openjdk.java.net, "SHEN, XUEMING" <
xueming.s...@oracle.com>,Alan Bateman 



Hi Ichiroh,

sorry, but unfortunately, this change is way beyond my level of 
expertise

:)

You should try to get a review from Sherman or Alan.

Regards,
Volker
On Fri, Oct 26, 2018 at 3:33 PM Ichiroh Takiguchi
 wrote:



Hello.

Could you review the fix ?

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

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


IBM964 charset and IBM29626C charset are required for default charset
on AIX zh_TW and ja_JP locale.
OpenJDK already has IBM964, but it could not be configured for 
default

charset.
IBM29626C is new one.
(IBM33722 extends IBM29626C class)

I knew IBM charsets would need to move to somewhere.
The discussion was started by "Adding new IBM extended charsets". [1]
But it's related default charset issue.
Please put them inside of OpenJDK.

About IBM964,
Bhaktavatsal started the discussion [2].
Sherman said that [3]
   the new model (open/make/data/charetmapping), instead of 
hard-coding

the map
   into the source code.

This fix only has small sized hard-coded mapping,
IBM964/IBM29626C/IBM33722 refer other charsets conversion table
which are using the new model.
And class file is smaller then before.
Still I used SimpleEUCEncoder class because it's stable.
I think we may re-write it by IBM charsets renewal.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-Ju
ly/054248.html
[2]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053050.html
[3]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053096.html

Re: RFR: XXXS: JDK-8213913: Redundant HTML in java.se/module-info.java

[Lance Andersen]

+1
> On Nov 14, 2018, at 7:20 PM, Jonathan Gibbons  
> wrote:
> 
> Please review the remove of an unnecessary  tag from 
> java.se/module-info.java that is showing up in "tidy" reports by doccheck.
> 
> $ hg diff -R open
> diff -r 8934429cfb0b src/java.se/share/classes/module-info.java
> --- a/src/java.se/share/classes/module-info.java Wed Nov 14 16:11:21 2018 
> -0800
> +++ b/src/java.se/share/classes/module-info.java Wed Nov 14 16:17:37 2018 
> -0800
> @@ -25,7 +25,6 @@
> 
>  /**
>   * Defines the API of the Java SE Platform.
> - * 
>   *
>   * 
>   * Optional for the Java SE Platform:
> 
> -- Jon
> 
> https://bugs.openjdk.java.net/browse/JDK-8213913
> 
> 

 
  

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

RFR: XXXS: JDK-8213913: Redundant HTML in java.se/module-info.java

[Jonathan Gibbons]

Please review the remove of an unnecessary  tag from 
java.se/module-info.java that is showing up in "tidy" reports by doccheck.


$ hg diff -R open
diff -r 8934429cfb0b src/java.se/share/classes/module-info.java
--- a/src/java.se/share/classes/module-info.java Wed Nov 14 16:11:21 
2018 -0800
+++ b/src/java.se/share/classes/module-info.java Wed Nov 14 16:17:37 
2018 -0800

@@ -25,7 +25,6 @@

 /**
  * Defines the API of the Java SE Platform.
- * 
  *
  * 
  * Optional for the Java SE Platform:


-- Jon

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

RFR JDK-8213909: jdeps --print-module-deps should report missing dependences

[Mandy Chung]

This patch improves `jdeps --print-module-deps`, `--list-deps` and
`--list-reduced-deps` to report missing dependences and also do transitive
dependence analysis as the default.

Webrev at:
http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8213909/webrev.00/

$ jdeps --class-path libs --print-module-deps app.jar

`--print-module-deps` finds the modules required by the specified 
application.
Its result can be used to create a runtime image for such application to 
run.

The current behavior does not report missing dependences.  In addition,
`--print-module-deps` only reports module dependences required by app.jar.
To include the transitive module dependences required by libs, if 
referenced,

-R option can be used.

If -R option is not specified, app.jar will fail to run on the runtime 
image

created by the output from `jdeps --print-module-deps`.  The patch changes
the default behavior to do transitive analysis.  In addition, it will report
as an error if any dependence is missing and not found.
The --ignore-missing-deps option can be used to ignore missing deps.

This patch also includes a simple fix in JdepsTask.ResourceBundleHelper for:
   JDK-8168869: jdeps: localized messages don't use proper line breaks

I can separate it in its own changeset when I push.

Thanks
Mandy

Re: RFR: XXS: JDK-8213910: Invalid HTML in java.net.http.HttpClient

[Lance Andersen]

*1
> On Nov 14, 2018, at 7:01 PM, Jonathan Gibbons  
> wrote:
> 
> Please review the removal of two extraneous  in HttpClient.java.
> 
> $ hg diff -R open
> diff -r 40098289d580 
> src/java.net.http/share/classes/java/net/http/HttpClient.java
> --- a/src/java.net.http/share/classes/java/net/http/HttpClient.java Wed Nov 
> 14 12:25:15 2018 -0800
> +++ b/src/java.net.http/share/classes/java/net/http/HttpClient.java Wed Nov 
> 14 15:56:04 2018 -0800
> @@ -104,7 +104,7 @@
>   *.thenApply(HttpResponse::body)
>   *.thenAccept(System.out::println); }
>   *
> - *  Security checks
> + *  Security checks
>   *
>   *  If a security manager is present then security checks are performed by
>   * the HTTP Client's sending methods. An appropriate {@link URLPermission} is
> @@ -327,7 +327,7 @@
>   * then newly built clients will use the {@linkplain
>   * ProxySelector#getDefault() default proxy selector}, which is 
> usually
>   * adequate for client applications. The default proxy selector 
> supports
> - * a set of system properties related to
> + * a set of system properties related to
>   *  href="{@docRoot}/java.base/java/net/doc-files/net-properties.html#Proxies">
>   * proxy settings. This default behavior can be disabled by
>   * supplying an explicit proxy selector, such as {@link #NO_PROXY} or
> 
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8213910
> 
> -- Jon
> 

 
  

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

RFR JDK-8211051: jdeps usage of --dot-output doesn't provide valid output for modular jar

[Mandy Chung]

This is a small fix to jdeps --dot-output option that should
name the dot file with the filename of the modular JAR rather
than its module name.

http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8211051/webrev.00/

Thanks
Mandy

Re: RFR: XXS: JDK-8213910: Invalid HTML in java.net.http.HttpClient

[Joseph D. Darcy]

+1

-Joe

On 11/14/2018 4:01 PM, Jonathan Gibbons wrote:

Please review the removal of two extraneous  in HttpClient.java.

$ hg diff -R open
diff -r 40098289d580 
src/java.net.http/share/classes/java/net/http/HttpClient.java
--- a/src/java.net.http/share/classes/java/net/http/HttpClient.java 
Wed Nov 14 12:25:15 2018 -0800
+++ b/src/java.net.http/share/classes/java/net/http/HttpClient.java 
Wed Nov 14 15:56:04 2018 -0800

@@ -104,7 +104,7 @@
  *.thenApply(HttpResponse::body)
  *.thenAccept(System.out::println); }
  *
- *  Security checks
+ *  Security checks
  *
  *  If a security manager is present then security checks are 
performed by
  * the HTTP Client's sending methods. An appropriate {@link 
URLPermission} is

@@ -327,7 +327,7 @@
  * then newly built clients will use the {@linkplain
  * ProxySelector#getDefault() default proxy selector}, which 
is usually
  * adequate for client applications. The default proxy 
selector supports

- * a set of system properties related to
+ * a set of system properties related to
  * href="{@docRoot}/java.base/java/net/doc-files/net-properties.html#Proxies">

  * proxy settings. This default behavior can be disabled by
  * supplying an explicit proxy selector, such as {@link 
#NO_PROXY} or



JBS: https://bugs.openjdk.java.net/browse/JDK-8213910

-- Jon

Re: RFR: XXS: JDK-8213910: Invalid HTML in java.net.http.HttpClient

[Mandy Chung]

Looks fine.

Mandy

On 11/14/18 4:01 PM, Jonathan Gibbons wrote:

Please review the removal of two extraneous  in HttpClient.java.

$ hg diff -R open
diff -r 40098289d580 
src/java.net.http/share/classes/java/net/http/HttpClient.java
--- a/src/java.net.http/share/classes/java/net/http/HttpClient.java 
Wed Nov 14 12:25:15 2018 -0800
+++ b/src/java.net.http/share/classes/java/net/http/HttpClient.java 
Wed Nov 14 15:56:04 2018 -0800

@@ -104,7 +104,7 @@
  *    .thenApply(HttpResponse::body)
  *    .thenAccept(System.out::println); }
  *
- *  Security checks
+ *  Security checks
  *
  *  If a security manager is present then security checks are 
performed by
  * the HTTP Client's sending methods. An appropriate {@link 
URLPermission} is

@@ -327,7 +327,7 @@
  * then newly built clients will use the {@linkplain
  * ProxySelector#getDefault() default proxy selector}, which 
is usually
  * adequate for client applications. The default proxy 
selector supports

- * a set of system properties related to
+ * a set of system properties related to
  * href="{@docRoot}/java.base/java/net/doc-files/net-properties.html#Proxies">

  * proxy settings. This default behavior can be disabled by
  * supplying an explicit proxy selector, such as {@link 
#NO_PROXY} or



JBS: https://bugs.openjdk.java.net/browse/JDK-8213910

-- Jon

RFR: XXS: JDK-8213910: Invalid HTML in java.net.http.HttpClient

[Jonathan Gibbons]

Please review the removal of two extraneous  in HttpClient.java.

$ hg diff -R open
diff -r 40098289d580 
src/java.net.http/share/classes/java/net/http/HttpClient.java
--- a/src/java.net.http/share/classes/java/net/http/HttpClient.java Wed 
Nov 14 12:25:15 2018 -0800
+++ b/src/java.net.http/share/classes/java/net/http/HttpClient.java Wed 
Nov 14 15:56:04 2018 -0800

@@ -104,7 +104,7 @@
  *    .thenApply(HttpResponse::body)
  *    .thenAccept(System.out::println); }
  *
- *  Security checks
+ *  Security checks
  *
  *  If a security manager is present then security checks are 
performed by
  * the HTTP Client's sending methods. An appropriate {@link 
URLPermission} is

@@ -327,7 +327,7 @@
  * then newly built clients will use the {@linkplain
  * ProxySelector#getDefault() default proxy selector}, which 
is usually
  * adequate for client applications. The default proxy 
selector supports

- * a set of system properties related to
+ * a set of system properties related to
  * href="{@docRoot}/java.base/java/net/doc-files/net-properties.html#Proxies">

  * proxy settings. This default behavior can be disabled by
  * supplying an explicit proxy selector, such as {@link 
#NO_PROXY} or



JBS: https://bugs.openjdk.java.net/browse/JDK-8213910

-- Jon

Re: RFR 4947890 : Minimize JNI upcalls in system-properties initialization

[Brent Christian]

Hi, Roger

* I like Mandy's idea of not combining the cli/VM props and the 
well-known props into a single array.  Maybe we could then avoid copying 
between arrays (System.c L166).


* The name "Raw" doesn't really speak to me.  It's OK as an inner class, 
though I wonder if everything could be done in SystemProps directly.


A few other comments:

java.base/share/native/libjava/System.c:

 112  * The first FIXED_LENGTH entries are the platform defined 
property values, no names.

 113  * The remaining array indices are alternating key/value pairs
 114  * supplied by the VM including those defined on the command line
 115  * using -Dkey=value that may override the platform defined value.

Some of this would also be useful information SystemProps.java, maybe in 
the comment for Raw.initProps.  Or refer the reader to 
Java_jdk_internal_util_SystemProps_00024Raw_getRawProperties for a 
description of the layout of the array.  Or may become moot if we use 
two separate arrays.


--

file.encoding used to be set from sprops->encoding on Mac, and 
sprops->sun_jnu_encoding otherwise:


 382 #ifdef MACOSX
 383 /*
 384  * Since sun_jnu_encoding is now hard-coded to UTF-8 on 
Mac, we don't

 385  * want to use it to overwrite file.encoding
 386  */
 387 PUTPROP(props, "file.encoding", sprops->encoding);
 388 #else
 389 PUTPROP(props, "file.encoding", sprops->sun_jnu_encoding);
 390 #endif

There is no longer an ifdef for this.  But I guess this is OK, as
SystemProps.initProperties() will only put a value for "file.encoding" 
if there isn't one, and only uses sun.jnu.encoding if there is no 
file.encoding:


  59 putIfAbsent(props, "file.encoding",
  60 ((raw.propDefault(Raw._file_encoding_NDX) == null)
  61 ? raw.propDefault(Raw._sun_jnu_encoding_NDX)
  62 : raw.propDefault(Raw._file_encoding_NDX)));

--

 313 * Command line overrides with -D are copied above from 
JVM_getProperties.


s/JVM_get/JVM_Get/


java.base/share/classes/jdk/internal/util/SystemProps.java:

 126 /**
 127  * Puts the property if it is non-null
 128  * @param props the Properties
 129  * @param key the key
 130  * @param value the value
 131  */
 132 private static void put(Properties props, String key, String 
value) {


I notice that this method is only called once.

--

 175 cmdProps.put(disp, dispValue);
...
 186 cmdProps.put(fmt, fmtValue);

Aren't L175 & L186 just putting the property that is already there ?

Thanks,
-Brent

On 11/13/18 7:59 AM, Roger Riggs wrote:
Please review a re-implementation of the initialization of System 
properties

moving some functions from native to Java.

The upcalls from native to java for each property are replaced by a 
mechanism

to gather the platform, VM and command line properties and return them
from a single JNI call.  The creation of the Properties instance and 
applying

command line overrides is handled in Java instead of native.

The JVM_initProperties interface in Hotspot is replaced by 
JVM_getProperties.


Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-props-only-raw/

Issue:
   https://bugs.openjdk.java.net/browse/JDK-4947890

Thanks, Roger

Re: FYI: new javadoc tag to document system properties

[Joseph D. Darcy]

Hello,

For future CSR requests involving system properties, please document the 
properties using these javadoc facilities.


Thanks,

-Joe

On 11/14/2018 2:27 PM, Jonathan Gibbons wrote:
This is an FYI to announce some initial, long-overdue support in 
javadoc for documenting system properties (JDK-5076751).


Currently, system properties are just documented using ad-hoc 
narrative text, which is fine if you know where to look for any given 
property.


JDK 12 introduces a new inline javadoc tag, {@systemProperty 
/property-name/} which can be used to "declare" the name of a system 
property. You can use this tag as a drop-in replacement for the 
plain-text property name; it will have no overt effect on the 
narrative text, but it will cause the property name to be put into the 
search index and the A-Z index. Thus, property names will become 
searchable, to allow users to easily find the definition of any such 
system property.


Adding support into javadoc is only part of the story. Now that the 
support is in javadoc, we want to update the API documentation, so 
that the documentation is updated for all Java SE and JDK system 
properties.


Where should the tag be used?  The tag should be used in the text of 
the defining instance of the property.  This is where the 
characteristics of the system property are described, which may 
include information like: "what is the property for", "how and when is 
it set", "can it be modified", and so on. For example, it could be 
used in the docs for System.getProperties [1] or Networking Properties 
[2] In general, it should -not- be used in situations that merely 
refer to the system property by name.  For example, the docs for 
Path.toAbsolutePath [3] make a reference to the system property 
user.dir, but that is not a definition of the property.


Going forward, in future releases, we expect to explore some 
enhancements to this feature. Here are some of the ideas that have 
been suggested:


 * Create a "summary page" that lists all the system properties. This
   would be somewhat similar to the current top-level "Constant Values"
   page.
 * Add information regarding the "scope" of the definition: is it
   defined by the Java SE specification, or JDK, or JavaFX, etc. This
   information could be used to organize the content on the summary page.
 * Update @see and {@link} to be able to refer to system properties.
 * Allow a short description to be included in the {@systemProperty}
   tag. This text could be included in the search index, the A-Z index,
   and the summary page.

-- Jon


[1]: 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/System.html#getProperties()
[2]: 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/doc-files/net-properties.html
[3]: 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/Path.html#toAbsolutePath()

FYI: new javadoc tag to document system properties

[Jonathan Gibbons]

This is an FYI to announce some initial, long-overdue support in javadoc 
for documenting system properties (JDK-5076751).


Currently, system properties are just documented using ad-hoc narrative 
text, which is fine if you know where to look for any given property.


JDK 12 introduces a new inline javadoc tag, {@systemProperty 
/property-name/} which can be used to "declare" the name of a system 
property. You can use this tag as a drop-in replacement for the 
plain-text property name; it will have no overt effect on the narrative 
text, but it will cause the property name to be put into the search 
index and the A-Z index. Thus, property names will become searchable, to 
allow users to easily find the definition of any such system property.


Adding support into javadoc is only part of the story. Now that the 
support is in javadoc, we want to update the API documentation, so that 
the documentation is updated for all Java SE and JDK system properties.


Where should the tag be used?  The tag should be used in the text of the 
defining instance of the property.  This is where the characteristics of 
the system property are described, which may include information like: 
"what is the property for", "how and when is it set", "can it be 
modified", and so on. For example, it could be used in the docs for 
System.getProperties [1] or Networking Properties [2] In general, it 
should -not- be used in situations that merely refer to the system 
property by name.  For example, the docs for Path.toAbsolutePath [3] 
make a reference to the system property user.dir, but that is not a 
definition of the property.


Going forward, in future releases, we expect to explore some 
enhancements to this feature. Here are some of the ideas that have been 
suggested:


 * Create a "summary page" that lists all the system properties. This
   would be somewhat similar to the current top-level "Constant Values"
   page.
 * Add information regarding the "scope" of the definition: is it
   defined by the Java SE specification, or JDK, or JavaFX, etc. This
   information could be used to organize the content on the summary page.
 * Update @see and {@link} to be able to refer to system properties.
 * Allow a short description to be included in the {@systemProperty}
   tag. This text could be included in the search index, the A-Z index,
   and the summary page.

-- Jon


[1]: 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/System.html#getProperties()
[2]: 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/doc-files/net-properties.html
[3]: 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/Path.html#toAbsolutePath()

Re: RFR 4947890 : Minimize JNI upcalls in system-properties initialization

[Mandy Chung]

Hi Roger,

The system property initialization long for a clean up.
Thanks for looking at it.  This is a good start.  I think
it'd be good to make further improvement.

140 cmdProps = JVM_GetProperties(env); Instead of prepending the 
predefined set of properties with cmdProps, I suggest to separate 
getRawProperties into two separate methods 1. get the system properties 
defined by -D 2. the predefined properties


176 PUTPROP(propArray, _java_specification_version_NDX, 
VERSION_SPECIFICATION);
177 PUTPROP(propArray, _java_specification_name_NDX, "Java Platform API 
Specification");
178 PUTPROP(propArray, _java_specification_vendor_NDX, 
JAVA_SPECIFICATION_VENDOR);

179
180 PUTPROP(propArray, _java_vendor_NDX, VENDOR);
181 PUTPROP(propArray, _java_vendor_url_NDX, VENDOR_URL);
182 PUTPROP(propArray, _java_vendor_url_bug_NDX, VENDOR_URL_BUG);
183
184 jio_snprintf(buf, sizeof(buf), "%d.%d", JVM_CLASSFILE_MAJOR_VERSION,
185 JVM_CLASSFILE_MINOR_VERSION);
186 PUTPROP(propArray, _java_class_version_NDX, buf);

These are defined at build time.  Can they be moved to 
VersionProps.java.template?


130 // Get the platform specific values
 131 sprops = GetJavaProperties(env);
  :
 191 PUTPROP(propArray, _os_name_NDX, sprops->os_name);
 192 PUTPROP(propArray, _os_version_NDX, sprops->os_version);
 193 PUTPROP(propArray, _os_arch_NDX, sprops->os_arch);

This obtains the platform-specific configuration and then later
sets the value in the array of a predefined index.

Have you considered other alternatives?  SystemProps.Raw can
define the named prop value instead of index e.g.
   private static String _os_arch;

these fields are set via JNI.  Or have the native method
to return Object[] with the property name/value pair as
in the VM.

SystemProps.java

  69 putIfAbsent(props, "user.name", 
raw.propDefault(Raw._user_name_NDX));
  70 putIfAbsent(props, "os.name", raw.propDefault(Raw._os_name_NDX));
  71 putIfAbsent(props, "os.arch", raw.propDefault(Raw._os_arch_NDX));
  72 putIfAbsent(props, "os.version", 
raw.propDefault(Raw._os_version_NDX));
  73 putIfAbsent(props, "line.separator", 
raw.propDefault(Raw._line_separator_NDX));
  74 putIfAbsent(props, "file.separator", 
raw.propDefault(Raw._file_separator_NDX));
  75 putIfAbsent(props, "path.separator", 
raw.propDefault(Raw._path_separator_NDX));


jdk.internal.util.StaticProperty calls System.getProperty.
Should we move the above (or more) static properties and
initialize their values directly in StaticProperty class?
This is out of the scope of this issue but if we initialize
the field values directly via JNI.  Something that might
worth exploring.

thanks
Mandy

Re: Reflection, TYPE_USE annotation on THROWS on inner class constructor, Java 9+

[Vicente Romero]

Hi Michael,

Thanks for the report. I have created: 
https://bugs.openjdk.java.net/browse/JDK-8213905 to track it,


Vicente

On 11/9/18 10:13 AM, Michael Rasmussen wrote:

Hi

When adding a TYPE_USE annotation with runtime retention to the throws 
exception clause of a constructor of an inner class, these annotations are not 
found via Constructor.getAnnotatedExceptionType().getDeclaredAnnotations() on 
Java 9+, but present when running on Java 8.
For static nested classes, the annotations are correctly found on Java 9+.

See sample code below.

Looking in the .class file for the nested classes (with javap), the runtime 
annotation is present there:
   public app1.MiscTest8$Inner(app1.MiscTest8) throws java.lang.Exception;
 (...)
 RuntimeVisibleTypeAnnotations:
   0: #17(): THROWS, type_index=0
 app1.MiscTest8$MyAnnotation

and
   public app1.MiscTest8$StaticInner() throws java.lang.Exception;
 (...)
 RuntimeVisibleTypeAnnotations:
   0: #14(): THROWS, type_index=0
 app1.MiscTest8$MyAnnotation

When I run it on Java 8, I get the following output:
=== public app1.MiscTest8$Inner(app1.MiscTest8) throws java.lang.Exception ===
[@app1.MiscTest8$MyAnnotation()]
=== public app1.MiscTest8$StaticInner() throws java.lang.Exception ===
[@app1.MiscTest8$MyAnnotation()]
=== public static void app1.MiscTest8.main(java.lang.String[]) throws 
java.lang.Exception ===
[@app1.MiscTest8$MyAnnotation()]

But when I run the same class files on Java 9, 10, 11, (and 12-ea) I get:
=== public app1.MiscTest8$Inner(app1.MiscTest8) throws java.lang.Exception ===
[]
=== public app1.MiscTest8$StaticInner() throws java.lang.Exception ===
[@app1.MiscTest8$MyAnnotation()]
=== public static void app1.MiscTest8.main(java.lang.String[]) throws 
java.lang.Exception ===
[@app1.MiscTest8$MyAnnotation()]


Shouldn't I be able to find this annotation vis getAnnotatedExceptionTypes() on 
Java9+, similar to how it works on Java 8?

Kind regards
Michael Rasmussen.


/* --- snip --- */
package app1;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import java.lang.reflect.AnnotatedType;
import java.lang.reflect.Executable;
import java.util.Arrays;

public class MiscTest8 {

   @Retention(value = RetentionPolicy.RUNTIME)
   @Target(ElementType.TYPE_USE)
   @interface MyAnnotation {
   }

   class Inner {
 public Inner() throws @MyAnnotation Exception {
 }
   }

   static class StaticInner {
 public StaticInner() throws @MyAnnotation Exception {
 }
   }
   public static void main(String[] args) throws @MyAnnotation Exception {
 foo(Inner.class.getDeclaredConstructor(MiscTest8.class));
 foo(StaticInner.class.getDeclaredConstructor());
 foo(MiscTest8.class.getDeclaredMethod("main", String[].class));
   }

   static void foo(Executable c) throws Exception {
 System.out.println("=== " + c + " ===");

 for (AnnotatedType exceptionType : c.getAnnotatedExceptionTypes()) {
   
System.out.println(Arrays.toString(exceptionType.getDeclaredAnnotations()));
 }
   }
}
/* --- snap --- */

Re: RFR 4947890 : Minimize JNI upcalls in system-properties initialization

[Roger Riggs]

Hi Coleen,

yes, the changes to the jvm.h functions should have a CSR.
I created a CSR to track the interface change.

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

Thanks, Roger


On 11/14/2018 11:22 AM, coleen.phillim...@oracle.com wrote:


Hi Roger, the VM changes to this look great to me.

I think you need a CSR to remove JVM_InitProperties though.

Thanks,
Coleen

On 11/13/18 10:59 AM, Roger Riggs wrote:
Please review a re-implementation of the initialization of System 
properties

moving some functions from native to Java.

The upcalls from native to java for each property are replaced by a 
mechanism

to gather the platform, VM and command line properties and return them
from a single JNI call.  The creation of the Properties instance and 
applying

command line overrides is handled in Java instead of native.

The JVM_initProperties interface in Hotspot is replaced by 
JVM_getProperties.


Webrev:
  http://cr.openjdk.java.net/~rriggs/webrev-props-only-raw/

Issue:
  https://bugs.openjdk.java.net/browse/JDK-4947890

Thanks, Roger

Re: RFR: 8148188: Enhance the security libraries to record events of interest

[Seán Coffey]

Thanks for the comments Weijun.

As per other review thread, I'm now recording all properties set via 
Security.setProperty(String, String).


regards,
Sean.


On 14/11/2018 01:11, Weijun Wang wrote:

Confused. Aren't all Security properties security-related? This is not about 
normal system properties.

And the method name in the latest webrev is "isSecurityProperty" without the 
"JDK" word. I assume this means you don't care about the difference between SE properties 
and JDK properties.

--Max

Re: RFR: 8148188: Enhance the security libraries to record events of interest

[Seán Coffey]

Hi Sean,

comments inline..

On 13/11/2018 18:53, Sean Mullan wrote:

Looking good, a couple of comments/questions:

* src/java.base/share/classes/java/security/Security.java

The isJdkSecurityProperty method could return false positives, for 
example there may be a non-JDK property starting with "security.". I 
was thinking it would be better to put all the JDK property names in a 
HashSet which is populated by the static initialize() method, and only 
if event logging is enabled. Then setProperty can just check if the 
property name is in this set.
after further discussion, we've decided to log all properties operated 
on via Security.setProperty(String, String). It think it makes sense. 
The contents of a JFR recording should always be treated as sensitive. 
Keep in mind also that these new JFR Events will be off by default.


* src/java.base/share/classes/sun/security/x509/X509CertImpl.java
Good points here. I've taken on board your suggestion to move this code 
logic to the sun/security/provider/X509Factory.java class as per your 
later email suggestion.



45 l.addExpected("SunJSSE Test Serivce");

Is that a typo? "Serivce"

That's a typo in the test certificate details. We should fix it up via 
another bug record.



* test/jdk/jdk/security/logging/TestX509ValidationLog.java

54: remove blank line

* test/lib/jdk/test/lib/security/SSLSocketTest.java

Why is this file included? It looks like a duplicate of 
SSLSocketTemplate.
Yes - it's almost identical to SSLSocketTemplate except that 
SSLSocketTemplate doesn't belong to a package. I had a hard time 
incorporating its use into the jtreg tests via the @lib syntax. I think 
it's best if we open another JBS issue to migrate other uses of 
SSLSocketTemplate to jdk.test.lib.security.SSLSocketTemplate


I've cleaned up the various typo/syntax issues that you've highlighted also.
http://cr.openjdk.java.net/~coffeys/webrev.8148188.v9/webrev/index.html

regards,
Sean.


The rest of my comments are mostly minor stuff, and nits:

* 
src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java


245 if(xve.shouldCommit() || EventHelper.isLoggingSecurity()) {

add space before "(xve"

* src/java.base/share/classes/sun/security/ssl/Finished.java

1097 }

indent

1098 if(event.shouldCommit()) {

add space before "(event"

* src/java.base/share/classes/sun/security/x509/X509CertImpl.java

update copyright

* src/java.base/share/classes/jdk/internal/event/EventHelper.java

35  * A helper class to have events logged to a JDK Event Logger

Add '.' at end of sentence.

* src/java.base/share/classes/jdk/internal/event/TLSHandshakeEvent.java

38: remove blank line

* src/java.base/share/classes/jdk/internal/event/X509ValidationEvent.java

30  * used in X509 cert path validation

Add '.' at end of sentence.

* src/jdk.jfr/share/classes/jdk/jfr/events/X509ValidationEvent.java

47: remove blank line

* test/jdk/jdk/security/logging/TestTLSHandshakeLog.java


--Sean


On 11/6/18 3:46 AM, Seán Coffey wrote:
With JDK-8203629 now pushed, I've re-based my patch on latest jdk/jdk 
code.


Some modifications also made based on off-thread suggestions :

src/java.base/share/classes/java/security/Security.java

* Only record JDK security properties for now (i.e. those in 
java.security conf file)
   - we can consider a new event to record non-JDK security events if 
demand comes about

   - new event renamed to *Jdk*SecurityPropertyModificationEvent

src/java.base/share/classes/sun/security/x509/X509CertImpl.java

* Use hashCode() equality test for storing certs in List.

Tests updated to capture these changes

src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java 



* Verify that self signed certs exercise the modified code paths

I've added new test functionality to test use of self signed cert.

webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v7/webrev/

Regards,
Sean.

On 17/10/18 11:25, Seán Coffey wrote:
I'd like to re-boot this review. I've been working with Erik off 
thread who's been helping with code and test design.


Some of the main changes worthy of highlighting :

* Separate out the tests for JFR and Logger events
* Rename some events
* Normalize the data view for X509ValidationEvent (old event name : 
CertChainEvent)
* Introduce CertificateSerialNumber type to make use of the 
@Relational JFR annotation.
* Keep calls for JFR event operations local to call site to optimize 
jvm compilation


webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v6/webrev/

This code is dependent on the JDK-8203629 enhancement being integrated.

Regards,
Sean.

On 10/07/18 13:50, Seán Coffey wrote:

Erik,

After some trial edits, I'm not so sure if moving the event & 
logger commit code into the class where it's used works too well 
after all.


In the code you suggested, there's an assumption that calls such as 
EventHelper.certificateChain(..) are low cost. While that might be 

Re: RFR 4947890 : Minimize JNI upcalls in system-properties initialization

[Roger Riggs]

Hi Mandy,

The change does not make a measurable change in startup time.
The number of bytecodes executed in initPhase1 dropped from 60k to 50k
out of 850k.

Thanks, Roger


On 11/14/2018 12:25 PM, Mandy Chung wrote:

Hi Roger,

Does this change improve the startup performance? initProperties
is done in initPhase1 where the Java code is running in interpreted
mode.  Brent did the measurement some time ago that JNI calls
is one cost while executing quite a lot of bytecodes in
interpreted mode is another cost.

Mandy

On 11/13/18 7:59 AM, Roger Riggs wrote:
Please review a re-implementation of the initialization of System 
properties

moving some functions from native to Java.

The upcalls from native to java for each property are replaced by a 
mechanism

to gather the platform, VM and command line properties and return them
from a single JNI call.  The creation of the Properties instance and 
applying

command line overrides is handled in Java instead of native.

The JVM_initProperties interface in Hotspot is replaced by 
JVM_getProperties.


Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-props-only-raw/

Issue:
https://bugs.openjdk.java.net/browse/JDK-4947890

Thanks, Roger

Re: Re: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX default charset

[Martin Buchholz]

Ichiroh, IBM/AIX people should reach consensus on how to handle IBM
charsets.  I'm going to add some IBM people who might know or care.

(I haven't used AIX in 20 years)

On Wed, Nov 14, 2018 at 10:23 AM, Ichiroh Takiguchi <
taki...@linux.vnet.ibm.com> wrote:

> Hello.
>
> Martin Buchholz suggested me via bugs.openjdk.java.net,
> I should not touch non AIX side.
> So I rewrote another code.
> Could you review the fix again ?
>
> Bug:https://bugs.openjdk.java.net/browse/JDK-8212794
> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.01/
>
> I don't want to touch non AIX side code, but I need to rename 3 files
> to avoid compilation issue.
> IBM33722.java -> IBM33722.java.template
> IBM964.java -> IBM964.java.template
> SimpleEUCEncoder.java -> SimpleEUCEncoder.java.template
>
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.
>
>  Original Message 
> Subject: Re: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX
> default charset
> Date: 2018-11-08 20:13
> From: Volker Simonis 
> To: Ichiroh Takiguchi 
> Cc: Java Core Libs ,
> ppc-aix-port-...@openjdk.java.net, "SHEN, XUEMING" <
> xueming.s...@oracle.com>,Alan Bateman 
>
> Hi Ichiroh,
>
> sorry, but unfortunately, this change is way beyond my level of expertise
> :)
>
> You should try to get a review from Sherman or Alan.
>
> Regards,
> Volker
> On Fri, Oct 26, 2018 at 3:33 PM Ichiroh Takiguchi
>  wrote:
>
>>
>> Hello.
>>
>> Could you review the fix ?
>>
>> Bug:https://bugs.openjdk.java.net/browse/JDK-8212794
>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.00/
>>
>> I'd like to obtain a sponsor for this issue.
>>
>>
>> IBM964 charset and IBM29626C charset are required for default charset
>> on AIX zh_TW and ja_JP locale.
>> OpenJDK already has IBM964, but it could not be configured for default
>> charset.
>> IBM29626C is new one.
>> (IBM33722 extends IBM29626C class)
>>
>> I knew IBM charsets would need to move to somewhere.
>> The discussion was started by "Adding new IBM extended charsets". [1]
>> But it's related default charset issue.
>> Please put them inside of OpenJDK.
>>
>> About IBM964,
>> Bhaktavatsal started the discussion [2].
>> Sherman said that [3]
>>the new model (open/make/data/charetmapping), instead of hard-coding
>> the map
>>into the source code.
>>
>> This fix only has small sized hard-coded mapping,
>> IBM964/IBM29626C/IBM33722 refer other charsets conversion table
>> which are using the new model.
>> And class file is smaller then before.
>> Still I used SimpleEUCEncoder class because it's stable.
>> I think we may re-write it by IBM charsets renewal.
>>
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-Ju
>> ly/054248.html
>> [2]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053050.html
>> [3]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053096.html
>>
>>
>

Re: [12] RFR: 8213818: @return has already been specified

[Roger Riggs]

Looks fine!

Thanks, Roger

On 11/14/2018 02:11 PM, naoto.s...@oracle.com wrote:

Hi,

Please review an XS fix to the following issue:

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

The fix is located at:

http://cr.openjdk.java.net/~naoto/8213828/webrev.00/

which is just removing a duplicate @return statement.

Naoto

[12] RFR: 8213818: @return has already been specified

[naoto . sato]

Hi,

Please review an XS fix to the following issue:

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

The fix is located at:

http://cr.openjdk.java.net/~naoto/8213828/webrev.00/

which is just removing a duplicate @return statement.

Naoto

Fwd: Re: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX default charset

[Ichiroh Takiguchi]

Hello.

Martin Buchholz suggested me via bugs.openjdk.java.net,
I should not touch non AIX side.
So I rewrote another code.
Could you review the fix again ?

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

I don't want to touch non AIX side code, but I need to rename 3 files
to avoid compilation issue.
IBM33722.java -> IBM33722.java.template
IBM964.java -> IBM964.java.template
SimpleEUCEncoder.java -> SimpleEUCEncoder.java.template

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

 Original Message 
Subject: Re: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX 
default charset

Date: 2018-11-08 20:13
From: Volker Simonis 
To: Ichiroh Takiguchi 
Cc: Java Core Libs , 
ppc-aix-port-...@openjdk.java.net, "SHEN, XUEMING" 
,Alan Bateman 


Hi Ichiroh,

sorry, but unfortunately, this change is way beyond my level of 
expertise :)


You should try to get a review from Sherman or Alan.

Regards,
Volker
On Fri, Oct 26, 2018 at 3:33 PM Ichiroh Takiguchi
 wrote:


Hello.

Could you review the fix ?

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

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


IBM964 charset and IBM29626C charset are required for default charset
on AIX zh_TW and ja_JP locale.
OpenJDK already has IBM964, but it could not be configured for default
charset.
IBM29626C is new one.
(IBM33722 extends IBM29626C class)

I knew IBM charsets would need to move to somewhere.
The discussion was started by "Adding new IBM extended charsets". [1]
But it's related default charset issue.
Please put them inside of OpenJDK.

About IBM964,
Bhaktavatsal started the discussion [2].
Sherman said that [3]
   the new model (open/make/data/charetmapping), instead of hard-coding
the map
   into the source code.

This fix only has small sized hard-coded mapping,
IBM964/IBM29626C/IBM33722 refer other charsets conversion table
which are using the new model.
And class file is smaller then before.
Still I used SimpleEUCEncoder class because it's stable.
I think we may re-write it by IBM charsets renewal.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054248.html
[2]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053050.html
[3]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053096.html

Re: Problems with AES-GCM native acceleration

[Vladimir Kozlov]

CCing to core-libs and security.

Based on last comment corresponding java code may need to be re-factored. It is 
not simple.

To trigger x64 AES instructions usage early (before JIT compilation kicks in) we may consider call optimized code from 
Interpreter similar to CRC32 code. It is also very big investment.


Regards,
Vladimir

On 11/14/18 4:39 AM, Gidon Gershinsky wrote:

Hi,

We are working on an encryption mechanism at the Apache Parquet - that will enable efficient analytics on encrypted data 
by frameworks such as Apache Spark.

https://github.com/apache/parquet-format/blob/encryption/Encryption.md
https://www.slideshare.net/databricks/efficient-spark-analytics-on-encrypted-data-with-gidon-gershinsky

We came across an AES-related issue in the Java HostSpot engine that looks like a substantial problem for us in both 
Spark and Parquet workloads. The bug report had been accepted a while ago:

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8201633

The fix should hopefully be rather straightforward though. Could you help us with that? I have a couple of small samples 
reproducing the problem.


(If I'm writing to a wrong mailing list - I apologize, please point me in the 
right direction).

Cheers, Gidon.

Re: RFR (JDK 12/java.base) 8213325: (props) Properties.loadFromXML does not fully comply with the spec

[Joe Wang]

Hi Daniel,

You're right. It isn't strictly necessary. It was there only because it 
was in a pair with startDTD as in the original SAX interface. I can 
remove it as it doesn't serve anything here.


Thanks,
Joe

On 11/14/18, 2:32 AM, Daniel Fuchs wrote:

Hi Joe,

I do not see where the new DTDHandler::endDTD methos is called.
Is that an oversight or is there more magic?

best regards,

-- daniel

On 14/11/2018 05:18, Joe Wang wrote:

Hi,

Please review a patch to bring the small footprint parser for 
java.util.Properties compliant with the specification.


JBS: https://bugs.openjdk.java.net/browse/JDK-8213325
webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev/

Thanks,
Joe

Re: RFR 4947890 : Minimize JNI upcalls in system-properties initialization

[Mandy Chung]

Hi Roger,

Does this change improve the startup performance?  initProperties
is done in initPhase1 where the Java code is running in interpreted
mode.  Brent did the measurement some time ago that JNI calls
is one cost while executing quite a lot of bytecodes in
interpreted mode is another cost.

Mandy

On 11/13/18 7:59 AM, Roger Riggs wrote:
Please review a re-implementation of the initialization of System 
properties

moving some functions from native to Java.

The upcalls from native to java for each property are replaced by a 
mechanism

to gather the platform, VM and command line properties and return them
from a single JNI call.  The creation of the Properties instance and 
applying

command line overrides is handled in Java instead of native.

The JVM_initProperties interface in Hotspot is replaced by 
JVM_getProperties.


Webrev:
  http://cr.openjdk.java.net/~rriggs/webrev-props-only-raw/

Issue:
  https://bugs.openjdk.java.net/browse/JDK-4947890

Thanks, Roger

Re: RFR : 8211106: [windows] Update OS detection code to recognize Windows Server 2019

[Bob Vandette]

> On Nov 14, 2018, at 3:50 AM, Baesken, Matthias  
> wrote:
> 
> Hello,  looks like  finally  Windows Server 2019 is  availability  after the 
> release stop .
> 
> David found this info from  November 13, 2018  :
> 
> https://cloudblogs.microsoft.com/windowsserver/2018/11/13/update-on-windows-server-2019-availability/
> 
> 
> " ...  In addition to extensive internal validation, we have taken time to 
> closely monitor feedback and diagnostic data from our Windows Insiders and 
> from millions of devices on the Windows 10 October 2018 Update. 
> There is no further evidence of data loss. Based on this data, today we are 
> beginning the re-release of Windows Server 2019,  ... "
> 
> 
> Alan / Bob - can I you as reviewers ?

I’m ok with this.

Bob.

> 
> 
> Best regards , Matthias
> 
> 
> 
>> -Original Message-
>> From: Alan Bateman 
>> Sent: Samstag, 20. Oktober 2018 10:06
>> To: Baesken, Matthias 
>> Cc: hotspot-dev Source Developers ; core-
>> libs-...@openjdk.java.net; Moldenhauer, Niclas
>> 
>> Subject: Re: RFR : 8211106: [windows] Update OS detection code to
>> recognize Windows Server 2019
>> 
>> On 19/10/2018 13:11, Baesken, Matthias wrote:
>>> Hi Alan,  I agree  it is a pity  that   the minor version (dwMinorVersion) 
>>> was
>> not increased .
>>> Looking at the build number was not my preferred way to handle this .
>>> 
>>> My understanding  (checked with our  internal  SAP-MS porting guys)  is
>> that the  buildNumber  of  Windows server 2016will not get larger than
>>>  the minimum introduced  buildNumber of Windows server 2019 .
>>> 
>> The changes in your webrev look okay to me although I assume we need to
>> be cautious about back porting until it becomes clear if Windows Server
>> 2019 will be re-released or not.  The Windows Server blog [1] suggests
>> that the release is paused while an issue is investigated and maybe a
>> re-release will mean a new build number at least.
>> 
>> -Alan
>> 
>> [1]
>> https://cloudblogs.microsoft.com/windowsserver/2018/10/02/windows-
>> server-2019-now-generally-available

Re[4]: The new optimized version of Dual-Pivot Quicksort

[Vladimir Yaroslavskiy]

Hello, Tagir!

Thank you for interesting news! I will look at RadixSort and let you know my 
result.

It may happen that int will be sorted by numeric-specific sorting algorithm
(like we switched byte, char, short to counting sort).

Regards,
Vladimir

>Среда, 14 ноября 2018, 19:17 +03:00 от Tagir Valeev :
>
>Hello, Laurent, Vladimir!
>
>I created a pull request containing my RadixSort implementation:
>https://github.com/bourgesl/nearly-optimal-mergesort-code/pull/1
>On my machine the results produced by Mergesorts.java are like this:
>
>Runs with individual timing (skips first 10 runs):
>adjusted reps: 110 + inner loop: 1
>avg-ms=102.6177(+/- 7 %), algo=PeekSort+iscutoff=24+onlyIncRuns=false,
>n=100 (55000110) (n=100, µ=102.6177, σ=7.4065714)
>avg-ms=95.62607(+/- 4 %),
>algo=TopDownMergesort+iscutoff=24+checkSorted=true, n=100
>(55000110) (n=100, µ=95.62607, σ=3.5302947)
>avg-ms=118.73089(+/- 4 %),
>algo=BottomUpMergesort+minRunLen=24+checkSorted=true, n=100
>(55000110) (n=100, µ=118.73089, σ=4.464908)
>avg-ms=108.36175(+/- 4 %), algo=MarlinSort, n=100 (55000110)
>(n=100, µ=108.36175, σ=4.5998554)
>avg-ms=99.68292(+/- 4 %), algo=MarlinMergeSort, n=100
>(55000110) (n=100, µ=99.68292, σ=3.9944465)
>avg-ms=75.43999(+/- 3 %), algo=DualPivotQuicksort2018, n=100
>(55000110) (n=100, µ=75.43999, σ=2.6127808)
>avg-ms=83.80406(+/- 6 %), algo=DualPivotQuicksort2018Ext, n=100
> (55000110) (n=100, µ=83.80406, σ=4.734225)
>avg-ms=18.886326(+/- 4 %), algo=RadixSort, n=100 (55000110)
>(n=100, µ=18.886326, σ=0.75667334)
>
>As you can see RadixSort is much faster than anything. Well, probably
>there are some input patterns where it may lose (though it's
>performance is much more predictable and much less depend on input
>data than in DPQS), but I strongly believe that concentrating efforts
>on testing corner cases performance and integrating RadixSort into JDK
>would yield much better performance than DPQS, at least for int[]
>arrays. Also the implementation is much simpler.
>
>With best regards,
>Tagir Valeev.
>On Mon, Nov 12, 2018 at 5:09 PM Laurent Bourgès
>< bourges.laur...@gmail.com > wrote:
>>
>> Hi,
>>
>> Do you know if someone has written a complete JMH benchmark suite dedicated
>> to Arrays.sort() ?
>> with varying array size (trivial) but also testing lots of data
>> distributions: (see Vladimir's tests) and possibly all variants (int, long,
>> double, Object[] )
>>
>> It could be part of the standard OpenJDK JMH test suite...
>>
>> For now, I forked the nearly-optimal-mergesort repository on github:
>>  
>> https://github.com/bourgesl/nearly-optimal-mergesort-code/tree/master/results
>>
>> Cheers,
>> Laurent
>>
>> Le sam. 10 nov. 2018 à 12:49, Laurent Bourgès < bourges.laur...@gmail.com > a
>> écrit :
>>
>> > Dear Vladimir & other Java sort experts,
>> >
>> > I made the port of the DPQS 2018.2 code last night to support a secondary
>> > array to be sorted and use preallocation (aux/run for merge sort):
>> >
>> >  
>> > https://github.com/bourgesl/nearly-optimal-mergesort-code/blob/master/src/wildinter/net/mergesort/DualPivotQuicksort2018Ext.java
>> >
>> > I succeded in using this variant in Marlin renderer (dev) and it is
>> > promising. I figured out a rendering bug in 1 test wigh 65535 random
>> > segments, certainly due to array swaps in mergesort (my side)...
>> >
>> > I will look again at my changes to check if I miss some permutation (a //
>> > b) or made any mistake on their indices... tricky.
>> >
>> > PS: Please share your updated webrev when possible to rebase my changes.
>> >
>> > Regards,
>> > Laurent
>> >
>> > Le ven. 9 nov. 2018 à 10:08, Laurent Bourgès < bourges.laur...@gmail.com >
>> > a écrit :
>> >
>> >> Hi Vladimir,
>> >>
>> >> Thank you for your attention, you are the Sort Master.
>> >>
>> >>
>> >> Le ven. 9 nov. 2018 à 09:02, Vladimir Yaroslavskiy < vlv.spb...@mail.ru >
>> >> a écrit :
>> >>
>> >>> Hi Laurent,
>> >>>
>> >>> The new version is still under review, there were a lot of suggestions
>> >>> and ideas from Doug Lea.
>> >>> I needed time to apply and check them. I'm going to send final version
>> >>> in few days.
>> >>>
>> >>
>> >> Excellent news, so it will ship in jdk12...
>> >>
>> >>>
>> >>> As to new method sort(a[], low, high, indices): do you mean this method
>> >>> in Arrays class?
>> >>> Are you going to extend Arrays API?
>> >>>
>> >>
>> >> I benchmarked my MergeSort and adding extra array implies many more
>> >> moves: thresholds should be adjusted and my sort is sometimes better as it
>> >> makes half moves (a <-> buffer swaps), so this complementary sort should
>> >> have its own tuned implementation (tests & benchmarks).
>> >>
>> >> I coded my sort as such need did not match any Arrays.sort() methods.
>> >> Having it publicly in jdk.base would be great for any other data handling
>> >> algorithm (science, AI ?)
>> >>
>> >> If you agree it is useful, I could try proposing an Arrays/Collection API
>> >> extension like :
>> >> 

Re: Re[2]: The new optimized version of Dual-Pivot Quicksort

[Tagir Valeev]

Hello, Laurent, Vladimir!

I created a pull request containing my RadixSort implementation:
https://github.com/bourgesl/nearly-optimal-mergesort-code/pull/1
On my machine the results produced by Mergesorts.java are like this:

Runs with individual timing (skips first 10 runs):
adjusted reps: 110 + inner loop: 1
avg-ms=102.6177(+/- 7 %), algo=PeekSort+iscutoff=24+onlyIncRuns=false,
n=100 (55000110) (n=100, µ=102.6177, σ=7.4065714)
avg-ms=95.62607(+/- 4 %),
algo=TopDownMergesort+iscutoff=24+checkSorted=true, n=100
(55000110) (n=100, µ=95.62607, σ=3.5302947)
avg-ms=118.73089(+/- 4 %),
algo=BottomUpMergesort+minRunLen=24+checkSorted=true, n=100
(55000110) (n=100, µ=118.73089, σ=4.464908)
avg-ms=108.36175(+/- 4 %), algo=MarlinSort, n=100 (55000110)
(n=100, µ=108.36175, σ=4.5998554)
avg-ms=99.68292(+/- 4 %), algo=MarlinMergeSort, n=100
(55000110) (n=100, µ=99.68292, σ=3.9944465)
avg-ms=75.43999(+/- 3 %), algo=DualPivotQuicksort2018, n=100
(55000110) (n=100, µ=75.43999, σ=2.6127808)
avg-ms=83.80406(+/- 6 %), algo=DualPivotQuicksort2018Ext, n=100
 (55000110) (n=100, µ=83.80406, σ=4.734225)
avg-ms=18.886326(+/- 4 %), algo=RadixSort, n=100 (55000110)
(n=100, µ=18.886326, σ=0.75667334)

As you can see RadixSort is much faster than anything. Well, probably
there are some input patterns where it may lose (though it's
performance is much more predictable and much less depend on input
data than in DPQS), but I strongly believe that concentrating efforts
on testing corner cases performance and integrating RadixSort into JDK
would yield much better performance than DPQS, at least for int[]
arrays. Also the implementation is much simpler.

With best regards,
Tagir Valeev.
On Mon, Nov 12, 2018 at 5:09 PM Laurent Bourgès
 wrote:
>
> Hi,
>
> Do you know if someone has written a complete JMH benchmark suite dedicated
> to Arrays.sort() ?
> with varying array size (trivial) but also testing lots of data
> distributions: (see Vladimir's tests) and possibly all variants (int, long,
> double, Object[] )
>
> It could be part of the standard OpenJDK JMH test suite...
>
> For now, I forked the nearly-optimal-mergesort repository on github:
> https://github.com/bourgesl/nearly-optimal-mergesort-code/tree/master/results
>
> Cheers,
> Laurent
>
> Le sam. 10 nov. 2018 à 12:49, Laurent Bourgès  a
> écrit :
>
> > Dear Vladimir & other Java sort experts,
> >
> > I made the port of the DPQS 2018.2 code last night to support a secondary
> > array to be sorted and use preallocation (aux/run for merge sort):
> >
> > https://github.com/bourgesl/nearly-optimal-mergesort-code/blob/master/src/wildinter/net/mergesort/DualPivotQuicksort2018Ext.java
> >
> > I succeded in using this variant in Marlin renderer (dev) and it is
> > promising. I figured out a rendering bug in 1 test wigh 65535 random
> > segments, certainly due to array swaps in mergesort (my side)...
> >
> > I will look again at my changes to check if I miss some permutation (a //
> > b) or made any mistake on their indices... tricky.
> >
> > PS: Please share your updated webrev when possible to rebase my changes.
> >
> > Regards,
> > Laurent
> >
> > Le ven. 9 nov. 2018 à 10:08, Laurent Bourgès 
> > a écrit :
> >
> >> Hi Vladimir,
> >>
> >> Thank you for your attention, you are the Sort Master.
> >>
> >>
> >> Le ven. 9 nov. 2018 à 09:02, Vladimir Yaroslavskiy 
> >> a écrit :
> >>
> >>> Hi Laurent,
> >>>
> >>> The new version is still under review, there were a lot of suggestions
> >>> and ideas from Doug Lea.
> >>> I needed time to apply and check them. I'm going to send final version
> >>> in few days.
> >>>
> >>
> >> Excellent news, so it will ship in jdk12...
> >>
> >>>
> >>> As to new method sort(a[], low, high, indices): do you mean this method
> >>> in Arrays class?
> >>> Are you going to extend Arrays API?
> >>>
> >>
> >> I benchmarked my MergeSort and adding extra array implies many more
> >> moves: thresholds should be adjusted and my sort is sometimes better as it
> >> makes half moves (a <-> buffer swaps), so this complementary sort should
> >> have its own tuned implementation (tests & benchmarks).
> >>
> >> I coded my sort as such need did not match any Arrays.sort() methods.
> >> Having it publicly in jdk.base would be great for any other data handling
> >> algorithm (science, AI ?)
> >>
> >> If you agree it is useful, I could try proposing an Arrays/Collection API
> >> extension like :
> >> sort([], low, high, int[]indices)
> >>
> >>
> >>> About new parameters workbase[]: method sort(...) in DualPivotQuicksort
> >>> class (version is under review)
> >>> has extra parameter - parallel context (Sorter sorter) which has
> >>> required workbase[].
> >>> If we run sorting sequentially, sorter parameter is null (no any
> >>> objects) and temporary buffer
> >>> will be created inside in tryMerge method if we go ahead with merging.
> >>>
> >>
> >> I will have a look. For Marlin, parallel sort is not possible as
> >> rendering shapes can 

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

[Roger Riggs]

Hi,

On 11/14/2018 09:52 AM, Andy Herrick wrote:


On 11/13/2018 5:50 PM, Philip Race wrote:



On 11/13/18, 12:52 PM, Roger Riggs wrote:

Hi,

There are enough files unique to each platform to put them in 
separate packages
otherwise you get too many (IMHO) files in a single 
package/directory and
its harder to tell which go with which.  There isn't much of a 
problem with

classes being public because they are all in a module and not exported.

I would put them all under 
share/classes/jdk/jpackagers/internal/ and

save a directory level.


That isn't how the rest of the JDK is organised.
Platform specific classes are split where you have "share" in the 
path above.
So whilst the other issues are more arguable I don't think the build 
team

would like platform specific classes under share. There is already an
objection to that for the native files.

To the "too many files in one package/directory" point.
I think that might happen at the directory level if Andy went through 
with

his suggestion but I don't think it will happen with what I proposed and
we probably should get some benefit from being able to make classes + 
methods

package private.


but my proposal only increases the number of files in each directory 
as follows:


share/classes/jdk/jpackager/internal   - from 28 to 31

windows/classes/jdk/jpackager/internal - from 6 to 7

macosx/classes/jdk/jpackager/internal   - from 6 to 7

linux/classes/jdk/jpackager/internal    - from 3 to 4

(adding Main.java, that makes are only 50 source files total)

so I hardly see any any impact of having "too many files in one 
package/directory"


and for Phil's part of the change, although the platform dependent 
source files would be in the same package as the platform independent 
files, they are still in a different source dir, and every platform 
specific source file's name starts with the platform ("Win", "Mac", or 
"Linux")

This should be fine, since there is no need to for cross-platform support,
the reason for the top level platform directory is so the build can be 
selectively

include the right files.

I assume the service loader mechanism deals with all the issues in 
locating platform specific files.



finally a question about resources:

Each source file that references resources has it's own resource file 
(23 resource files in each of 3 languages for a total of 69 properties 
files).


That seems like overkill to me. One result is duplicate resources 
whenever a key is referenced in more than one source file.


Wouldn't it simplify things to combine these into a smaller set of 
resource files ?
agreed, there should be fewer resource files to track and maintain and 
NO duplication.


Roger




/Andy




So I think what I proposed is about right ..

phil


$.02, Roger


On 11/13/2018 03:46 PM, Andy Herrick wrote:

I agree with this and would take it further.

1 file is in ./share/classes/jdk/jpackager/internal/builders - why 
not just ./share/classes/jdk/jpackager/internal


2 files are in ./share/classes/jdk/jpackager/internal/bundlers - 
why not just in ./share/classes/jdk/jpackager/internal


1 file is in ./linux/classes/jdk/jpackager/internal/builders/linux 
- why not just ./linux/classes/jdk/jpackager/internal


1 file is in ./macosx/classes/jdk/jpackager/internal/builders/mac - 
why not just ./macosx/classes/jdk/jpackager/internal


1 file is in 
./windows/classes/jdk/jpackager/internal/builders/windows - why not 
just ./windows/classes/jdk/jpackager/internal


then just move the associated resources -

Basically put everything except Main in same package - everything 
would be easier to find, and we could make almost all methods 
package-private (the only exception would be the few things called 
by Main, and the ToolProvider.



On 11/13/2018 2:54 PM, Phil Race wrote:
Question .. why is "mac", "linux" and "windows" necessary in the 
package name here ?


 src/jdk.jpackager/macosx/classes/jdk/jpackager/internal/mac/MacAppBundler.java 

 src/jdk.jpackager/windows/classes/jdk/jpackager/internal/builders/windows/WindowsAppImageBuilder.java 

src/jdk.jpackager/linux/classes/jdk/jpackager/internal/linux/LinuxRpmBundler.java 



There's not likely to be a clash, so is there some other reason 
not to want these

in the same package as the shared internals like
src/jdk.jpackager/share/classes/jdk/jpackager/internal/Param.java

?

-phil.

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

[Andy Herrick]

On 11/13/2018 5:50 PM, Philip Race wrote:



On 11/13/18, 12:52 PM, Roger Riggs wrote:

Hi,

There are enough files unique to each platform to put them in 
separate packages
otherwise you get too many (IMHO) files in a single package/directory 
and
its harder to tell which go with which.  There isn't much of a 
problem with

classes being public because they are all in a module and not exported.

I would put them all under share/classes/jdk/jpackagers/internal/ 
and

save a directory level.


That isn't how the rest of the JDK is organised.
Platform specific classes are split where you have "share" in the path 
above.

So whilst the other issues are more arguable I don't think the build team
would like platform specific classes under share. There is already an
objection to that for the native files.

To the "too many files in one package/directory" point.
I think that might happen at the directory level if Andy went through 
with

his suggestion but I don't think it will happen with what I proposed and
we probably should get some benefit from being able to make classes + 
methods

package private.


but my proposal only increases the number of files in each directory as 
follows:


share/classes/jdk/jpackager/internal   - from 28 to 31

windows/classes/jdk/jpackager/internal - from 6 to 7

macosx/classes/jdk/jpackager/internal   - from 6 to 7

linux/classes/jdk/jpackager/internal    - from 3 to 4

(adding Main.java, that makes are only 50 source files total)

so I hardly see any any impact of having "too many files in one 
package/directory"


and for Phil's part of the change, although the platform dependent 
source files would be in the same package as the platform independent 
files, they are still in a different source dir, and every platform 
specific source file's name starts with the platform ("Win", "Mac", or 
"Linux")



finally a question about resources:

Each source file that references resources has it's own resource file 
(23 resource files in each of 3 languages for a total of 69 properties 
files).


That seems like overkill to me. One result is duplicate resources 
whenever a key is referenced in more than one source file.


Wouldn't it simplify things to combine these into a smaller set of 
resource files ?



/Andy




So I think what I proposed is about right ..

phil


$.02, Roger


On 11/13/2018 03:46 PM, Andy Herrick wrote:

I agree with this and would take it further.

1 file is in ./share/classes/jdk/jpackager/internal/builders - why 
not just ./share/classes/jdk/jpackager/internal


2 files are in ./share/classes/jdk/jpackager/internal/bundlers - why 
not just in ./share/classes/jdk/jpackager/internal


1 file is in ./linux/classes/jdk/jpackager/internal/builders/linux - 
why not just ./linux/classes/jdk/jpackager/internal


1 file is in ./macosx/classes/jdk/jpackager/internal/builders/mac - 
why not just ./macosx/classes/jdk/jpackager/internal


1 file is in 
./windows/classes/jdk/jpackager/internal/builders/windows - why not 
just ./windows/classes/jdk/jpackager/internal


then just move the associated resources -

Basically put everything except Main in same package - everything 
would be easier to find, and we could make almost all methods 
package-private (the only exception would be the few things called 
by Main, and the ToolProvider.



On 11/13/2018 2:54 PM, Phil Race wrote:
Question .. why is "mac", "linux" and "windows" necessary in the 
package name here ?


 src/jdk.jpackager/macosx/classes/jdk/jpackager/internal/mac/MacAppBundler.java 

 src/jdk.jpackager/windows/classes/jdk/jpackager/internal/builders/windows/WindowsAppImageBuilder.java 

src/jdk.jpackager/linux/classes/jdk/jpackager/internal/linux/LinuxRpmBundler.java 



There's not likely to be a clash, so is there some other reason not 
to want these

in the same package as the shared internals like
src/jdk.jpackager/share/classes/jdk/jpackager/internal/Param.java

?

-phil.

Re: RFR 4947890 : Minimize JNI upcalls in system-properties initialization

[Roger Riggs]

Hi Thomas,

I was aiming for a fairly straightforward, easy to maintain technique,
not too far removed from the current implementation.

The strings need to be created sometime and the JNI function to create a 
string

doesn't suffer from much overhead (compared to java) so I don't think it
would make much of a difference to delay their creation.

The fixed indices have no lookup overhead and with @Native and the
generated .h file there is no code to get out of sync. It might look nicer
in the source code if Java enums supported @Native, but that's a 
different topic.


Thanks for the suggestion, but I think I'll keep the current approach.

Regards, Roger


On 11/13/2018 04:21 PM, Thomas Stüfe wrote:

Hi Roger,

I somehow wonder whether that coding could be further simplified and
maybe made faster by just returning a big byte array or String from
the hotspot containing a concatenation of key-value pairs, each
separated by \0, e.g. like this:

"os.name\0linux\0os.arch\0i386\0java.io.tmpdir\0/tmp\0..."

instead of a string array, that is.

That string could be parsed in java, chopped into single string
key-value pairs, which one could feed it into the Properties.

For speedups, one could even return an integer array in addition to
the big string, containing the start indices of the key/value strings.

That way, one would also not have to maintain named indices in java.

Just a thought. I may not seeing the whole picture though.

Best Regards, Thomas
On Tue, Nov 13, 2018 at 5:03 PM Roger Riggs  wrote:

Please review a re-implementation of the initialization of System properties
moving some functions from native to Java.

The upcalls from native to java for each property are replaced by a
mechanism
to gather the platform, VM and command line properties and return them
from a single JNI call.  The creation of the Properties instance and
applying
command line overrides is handled in Java instead of native.

The JVM_initProperties interface in Hotspot is replaced by
JVM_getProperties.

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-props-only-raw/

Issue:
https://bugs.openjdk.java.net/browse/JDK-4947890

Thanks, Roger

Re: RFR - JDK-8203442 String::transform (Code Review)

[Stephen Colebourne]

On Tue, 13 Nov 2018 at 15:44, Brian Goetz  wrote:
> Yes, we know :)  But we don’t have any current plans to do that, nor use-site 
> extension methods, nor does it seem likely to come to the top of the language 
> priority list very soon.  So its not a choice between |> and .transform(); 
> it’s a choice between transform() and nothing.  Picking transform() seems 
> pretty good here.
>
> Stephen raised the issue of a “broader context”; indeed, the intention of 
> adding a transform() method here was that it would be feasible to add to 
> other types for which it was suitable.  String is an obvious candidate for 
> “do it first”, but this is within a broader context.

I'd be more comforted if there was a commitment to add the method to
Stream and Optional in Java 12 or 13.

I also agree with Remi that `transform()` is a poor name for Stream,
and thus it is a poor name for String. I doubt there is a perfect
name, process() or apply() seem like good candidates.

Stephen

JDK12 talks ASM7 now!

[Vicente Romero]

Hi guys,

Thanks everyone for the feedback. I pushed the patch yesterday,

Vicente

RE: RFR - JDK-8203442 String::transform (Code Review)

[Anthony Vanelverdinghe]

Hi Remi, Brian,



What about ‘asInputTo’ or some variant thereof (e.g. using Argument or the 
abbreviated Arg instead of Input; or dropping/replacing either of the 
prefix/suffix)?



This would give, for example:

`raw html`.asInputTo(HtmlDocument::new)

source.stream().asInputTo(this::maybeAddFilter)



To me, this name clearly relates the object with its argument: the object 
serves ‘as input to’ the argument (plus it hints at the fact that the argument 
is a Function). And since it’s just using general terminology, it’s applicable 
in a broad context, yet is unlikely to clash or look awkward anywhere.



Kind regards,

Anthony






From: core-libs-dev  on behalf of Remi 
Forax 
Sent: Wednesday, November 14, 2018 12:36:16 PM
To: Brian Goetz
Cc: core-libs-dev
Subject: Re: RFR - JDK-8203442 String::transform (Code Review)

Hi Brian,

- Mail original -
> De: "Brian Goetz" 
> À: "Peter Levart" 
> Cc: "core-libs-dev" 
> Envoyé: Mardi 13 Novembre 2018 15:37:31
> Objet: Re: RFR - JDK-8203442 String::transform (Code Review)

>> An argument against re-using the name map() for this String method is that
>> Stream.map() and Optional.map() act on the element(s) of the "container" the
>> method is invoked upon, and return the same raw part of type with type
>> parameter adjusted, while String.map() would be passing the target object
>> itself to the function and returning an arbitrary type.
>
> This is exactly why we did not choose the name map() when this feature was
> proposed.  (Such is life when a platform is accrete-only; you have to live 
> with
> your past decisions, good and bad.)
>
> (I didn’t see the proposal to rename transform() to map() fly by; I would have
> made the same comments as Peter.)

as i said earlier, we have https://bugs.openjdk.java.net/browse/JDK-8140283 
that asks for the same kind of method on Stream,
i think it's a good idea to have some kind or coordination here.
While 'transform' is a ok name for String, it's a bad name for Stream. All 
intermediary ops are transformations, but 'transform' doesn't subsume them. A 
method named transform will act as a magnet for Stream newbies that want to do 
transformation on a stream.

Perhaps 'chain' as proposed in JDK-8140283 is a better name ?

>
>> Other languages have introduced an operator to solve that issue (function 
>> call
>> syntax is not fluent) like by example the operator '|>' as in "foo" |>
>> Utils.capitalizeFirstLetter.
>
> Yes, we know :)  But we don’t have any current plans to do that, nor use-site
> extension methods, nor does it seem likely to come to the top of the language
> priority list very soon.  So its not a choice between |> and .transform(); 
> it’s
> a choice between transform() and nothing.  Picking transform() seems pretty
> good here.
>
> Stephen raised the issue of a “broader context”; indeed, the intention of 
> adding
> a transform() method here was that it would be feasible to add to other types
> for which it was suitable.  String is an obvious candidate for “do it first”,
> but this is within a broader context.

ok about the rationale, we just need to find a good name.

Rémi

Re: RFR: 8148188: Enhance the security libraries to record events of interest

[Sean Mullan]

On 11/13/18 1:53 PM, Sean Mullan wrote:

* src/java.base/share/classes/sun/security/x509/X509CertImpl.java

  158 // Event recording cache list
  159 private List recordedCerts;

Shouldn't this be static? Otherwise each certificate would have it's own 
instance and duplicates would not be detected.


Thinking more about this, this List has the potential to contain a lot 
of entries if there are many certificates and there is no way to control 
the size. It might be better to leverage the existing in-memory 
certificate cache in sun/security/provider/X509Factory.java:


private static final Cache certCache
= Cache.newSoftMemoryCache(750);

Could you look into moving the code from X509CertImpl to X509Factory 
instead? In engineGenerateCertificate, you could do the commit only if 
it is added to the cache:


try {
byte[] encoding = readOneBlock(is);
if (encoding != null) {
X509CertImpl cert = getFromCache(certCache, encoding);
if (cert != null) {
return cert;
}
cert = new X509CertImpl(encoding);
addToCache(certCache, cert.getEncodedInternal(), cert);
commitEvent();
return cert;

This way you could leverage the same cache. Duplicates could get 
recorded but only if the constraints on the cache are exceeded. This 
seems like a fair tradeoff.


--Sean

Re: RFR: 8148188: Enhance the security libraries to record events of interest

[Sean Mullan]

On 11/13/18 8:11 PM, Weijun Wang wrote:

Confused. Aren't all Security properties security-related? This is not about 
normal system properties.


Although probably not that common, an application could create their own 
security properties, ex: Security.setProperty("security.myPassword", 
"abc123");


We want to avoid logging those. We just want to record changes to the 
JDK security properties.



And the method name in the latest webrev is "isSecurityProperty" without the 
"JDK" word. I assume this means you don't care about the difference between SE properties 
and JDK properties.


Hmm, I was reviewing v7, and the name was changed in v8. I think 
isJdkSecurityProperty method is a better name.


--Sean



--Max


On Nov 14, 2018, at 2:53 AM, Sean Mullan  wrote:

* src/java.base/share/classes/java/security/Security.java

The isJdkSecurityProperty method could return false positives, for example there may be a 
non-JDK property starting with "security.". I was thinking it would be better 
to put all the JDK property names in a HashSet which is populated by the static 
initialize() method, and only if event logging is enabled. Then setProperty can just 
check if the property name is in this set.

Re: RFR - JDK-8203442 String::transform (Code Review)

[Remi Forax]

Hi Brian,

- Mail original -
> De: "Brian Goetz" 
> À: "Peter Levart" 
> Cc: "core-libs-dev" 
> Envoyé: Mardi 13 Novembre 2018 15:37:31
> Objet: Re: RFR - JDK-8203442 String::transform (Code Review)

>> An argument against re-using the name map() for this String method is that
>> Stream.map() and Optional.map() act on the element(s) of the "container" the
>> method is invoked upon, and return the same raw part of type with type
>> parameter adjusted, while String.map() would be passing the target object
>> itself to the function and returning an arbitrary type.
> 
> This is exactly why we did not choose the name map() when this feature was
> proposed.  (Such is life when a platform is accrete-only; you have to live 
> with
> your past decisions, good and bad.)
> 
> (I didn’t see the proposal to rename transform() to map() fly by; I would have
> made the same comments as Peter.)

as i said earlier, we have https://bugs.openjdk.java.net/browse/JDK-8140283 
that asks for the same kind of method on Stream,
i think it's a good idea to have some kind or coordination here.
While 'transform' is a ok name for String, it's a bad name for Stream. All 
intermediary ops are transformations, but 'transform' doesn't subsume them. A 
method named transform will act as a magnet for Stream newbies that want to do 
transformation on a stream.

Perhaps 'chain' as proposed in JDK-8140283 is a better name ?

> 
>> Other languages have introduced an operator to solve that issue (function 
>> call
>> syntax is not fluent) like by example the operator '|>' as in "foo" |>
>> Utils.capitalizeFirstLetter.
> 
> Yes, we know :)  But we don’t have any current plans to do that, nor use-site
> extension methods, nor does it seem likely to come to the top of the language
> priority list very soon.  So its not a choice between |> and .transform(); 
> it’s
> a choice between transform() and nothing.  Picking transform() seems pretty
> good here.
> 
> Stephen raised the issue of a “broader context”; indeed, the intention of 
> adding
> a transform() method here was that it would be feasible to add to other types
> for which it was suitable.  String is an obvious candidate for “do it first”,
> but this is within a broader context.

ok about the rationale, we just need to find a good name. 

Rémi

Re: RFR (JDK 12/java.base) 8213325: (props) Properties.loadFromXML does not fully comply with the spec

[Daniel Fuchs]

Hi Joe,

I do not see where the new DTDHandler::endDTD methos is called.
Is that an oversight or is there more magic?

best regards,

-- daniel

On 14/11/2018 05:18, Joe Wang wrote:

Hi,

Please review a patch to bring the small footprint parser for 
java.util.Properties compliant with the specification.


JBS: https://bugs.openjdk.java.net/browse/JDK-8213325
webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev/

Thanks,
Joe

RE: RFR : 8211106: [windows] Update OS detection code to recognize Windows Server 2019

[Baesken, Matthias]

Hello,  looks like  finally  Windows Server 2019 is  availability  after the 
release stop .

David found this info from  November 13, 2018  :

https://cloudblogs.microsoft.com/windowsserver/2018/11/13/update-on-windows-server-2019-availability/


" ...  In addition to extensive internal validation, we have taken time to 
closely monitor feedback and diagnostic data from our Windows Insiders and from 
millions of devices on the Windows 10 October 2018 Update. 
There is no further evidence of data loss. Based on this data, today we are 
beginning the re-release of Windows Server 2019,  ... "


Alan / Bob - can I you as reviewers ?


Best regards , Matthias



> -Original Message-
> From: Alan Bateman 
> Sent: Samstag, 20. Oktober 2018 10:06
> To: Baesken, Matthias 
> Cc: hotspot-dev Source Developers ; core-
> libs-...@openjdk.java.net; Moldenhauer, Niclas
> 
> Subject: Re: RFR : 8211106: [windows] Update OS detection code to
> recognize Windows Server 2019
> 
> On 19/10/2018 13:11, Baesken, Matthias wrote:
> > Hi Alan,  I agree  it is a pity  that   the minor version (dwMinorVersion) 
> > was
> not increased .
> > Looking at the build number was not my preferred way to handle this .
> >
> > My understanding  (checked with our  internal  SAP-MS porting guys)  is
> that the  buildNumber  of  Windows server 2016will not get larger than
> >   the minimum introduced  buildNumber of Windows server 2019 .
> >
> The changes in your webrev look okay to me although I assume we need to
> be cautious about back porting until it becomes clear if Windows Server
> 2019 will be re-released or not.  The Windows Server blog [1] suggests
> that the release is paused while an issue is investigated and maybe a
> re-release will mean a new build number at least.
> 
> -Alan
> 
> [1]
> https://cloudblogs.microsoft.com/windowsserver/2018/10/02/windows-
> server-2019-now-generally-available

Extending Java Arrays/Collection Sort API

[Laurent Bourgès]

Hi,

I am a scientist and the author of the Marlin renderer, integrated in
OpenJDK.

In this renderer, I needed a fast sort algorithm on small almost sorted
arrays, but more important, to deal with 2 arrays: x values and their
corresponding edge indices (pointer like). I derived my MergeSort class to
perform 2 swaps (x & edge ptr) as Arrays.sort() or TimSort() did not
provide such API.

1. I started discussing about extending the Java Sort API with Vladimir
Yaroslavskiy, the author of the famous Java DualPivotQuickSort, as he is
currently improving it.

His coming DPQS 2018 class provides lot of sort algorithms, I propose to
make them public API through a facade method in Arrays class:
insertionSort(), heapSort(), mergeSort(), quickSort()... Of course, his
current code is dedicated to DPQS, but his algorithm implementation could
be generalized to propose the Best implementations as a public Java API
(stable & unstable sorts)

For example in Marlin, I need trivial insertionSort() in the Helpers class,
my MergeSort could be replaced by another best implementation.
Let's not reinvent the wheel...

2. New Sort API to deal with indices...

For now, there is no mean to obtain the indices sorted on another value,
see my introduction: edge indices sorted by their x positions.
In data science, this is very useful and general.

What about an Arrays API extension:
- Arrays.sort(int[] a, int[] b, low, high) or
Indices int[] Arrays.sortIndices(int[] a, low high), a[] left untouched
- same with preallocated buffers & runs arrays
- alternatively, it could be expressed as Comparator
Arrays.sort(int[] a, low, high, Comparator cmp) that sorts array
a using the given comparator. For example, a[] could be edge indices sorted
according to their edge x position...
This comparator is specific as it compares anything (external storage) at
given indices i,j.

Finally Marlin renderer would benefit from Value types (array of structs),
as edge data are currently packed in int[] arrays, but this new Sort API
seems to me general & needed enough to be discussed here.

Best regards,
Laurent