Re: RFR: 8214078: Jtreg test java/nio/file/DirectoryStream/SecureDS.java fails on ARM32

[Alan Bateman]

On 20/11/2018 05:38, Nick Gasson wrote:

Hi,

Could someone please review this small patch?

Bug: https://bugs.openjdk.java.net/browse/JDK-8214078
Webrev: http://cr.openjdk.java.net/~njian/8214078/webrev.0/

This fixes a failure of the java/nio/file/DirectoryStream/SecureDS.java
Jtreg test on ARM32.

Glibc by design does not expose symbols for the `stat' family of
functions, this means we cannot get the address of fstatat64 via
dlsym. For other Linux platforms we have wrappers that directly
call the system call as a workaround, but this wasn't enabled for
ARM32. Also removed the comment about this being temporary,
because this seems to be a permanent feature of glibc (see
comment in sys/stat.h).

Ran Jtreg tests with no new regressions.

This looks okay.

(I've moved the bug to the right place, also changed the bug synopsis to 
make it clear what this issue is about).


-Alan

Re: Extending Java Arrays/Collection Sort API

[Laurent Bourgès]

Hi,
Any feedback on improving Java Sort API ?

PS: I improved a lot the Array benchmark accuracy (confidence interval ~
5%). Here are EA results:
https://github.com/bourgesl/nearly-optimal-mergesort-code/blob/master/results/basher-results-partial.out

Does anybody want to help me on this topic ?
Do you have a JMH test suite dedicated to array sorting ?

Cheers,
Laurent

Le mer. 14 nov. 2018 à 09:01, Laurent Bourgès  a
écrit :

> 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
>

Re: RFR of JDK-8211974,move test/jdk/lib/testlibrary/java/util/jar/*.java to top-level library or a local library

[Hamlin Li]

Hi Igor,

I have updated the bugs to avoid review confusion, patch is not changed.

Thank you

-Hamlin

On 2018/11/15 9:36 AM, Igor Ignatyev wrote:

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

RFR: 8214078: Jtreg test java/nio/file/DirectoryStream/SecureDS.java fails on ARM32

[Nick Gasson]

Hi,

Could someone please review this small patch?

Bug: https://bugs.openjdk.java.net/browse/JDK-8214078
Webrev: http://cr.openjdk.java.net/~njian/8214078/webrev.0/

This fixes a failure of the java/nio/file/DirectoryStream/SecureDS.java
Jtreg test on ARM32.

Glibc by design does not expose symbols for the `stat' family of
functions, this means we cannot get the address of fstatat64 via
dlsym. For other Linux platforms we have wrappers that directly
call the system call as a workaround, but this wasn't enabled for
ARM32. Also removed the comment about this being temporary,
because this seems to be a permanent feature of glibc (see
comment in sys/stat.h).

Ran Jtreg tests with no new regressions.

Thanks!
Nick

Re: Should HashMap::computeIfAbsent be considered a "structural modification" for an existing key?

[Michael Rasmussen]

From: Andrew Dinn 
> I have to ask the obvious: Why does the question matter?

I'm trying to figure out if something is a bug in HashMap in the JDK, or in 
Weld :D

The case in question is basically, a HashMap is created, and then the keys are 
iterated over concurrently.
The issue here though is that the HashMap is used as the backing of a MultiMap, 
and the multimap.get is basically hashmap.computeIfAbsent(key, k -> new 
HashSet()).
Meaning you have a HashMap, which you've fully initialized, and you're 
iterating over all the known keys in the map... but surprisingly the call to 
.get actually changes the structure of the map, leading to bad consequences.

/Michael

Re: RFR 4947890 : Minimize JNI upcalls in system property initialization

[Roger Riggs]

Hi,

Webrev updated in place:

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

On 11/16/2018 06:36 PM, Mandy Chung wrote:

Hi Roger,

Looking good.  I have a few small comments:

I assume VM.saveAndRemoveProperties will be a separate cleanup.
SystemProps::cmdProperties adds the system properties that can
skip adding these internal properties to the Properties object.
In fact, these internal properties are the interface between VM
and libraries that can be replaced with a different mechanism
other than system properties.

fine as a future change


Suggest to move the call to VersionProps.init(props) in
SystemProps.initProperties

That's harder that it might seems, the method can't be made public
and moving it to jdk.internal.util with SystemProps is more difficult
since there is Hotspot code that reads those fields directly. (thread.cpp)
That goes back quiet a number of years.

Another future cleanup/decoupling.


The `VENDOR*` build time variables can always have a default
like the other constants in VersionProps.  Then no need to
handle if not set.

Moved defaults to configure,
easy to override with --with-vendor-url, --with-vendor-bug-url, and 
--with-vendor-name.


SystemProps.staticInitOnly_* are a bit odd.  They are temporarily
set with the values and then reset to null.  Perhaps leave
StaticProperty as is for now and re-visit it in the future.
Then I think SystemProps::putDefault can be removed.

ok, reverted the code so the static values are read via System.getProperty.


Raw::xxx_NDX are initialized to 1 + previous_NDX.  It's a general
good approach to increment the index but I find it error-prone and
hard to catch mistake since the (adjacent) variable names look
so alike. Perhaps some form of verification or assertion to ensure
the indices are correctly initialized.

Added a test that uses reflection to verify the uniqueness and sequence.

Thanks, Roger


Mandy

On 11/16/18 10:49 AM, Roger Riggs wrote:

Updates to include the suggestions made by Mandy and Brent:

 - Move the build-time properties from native code to the 
VersionProps.java.template
   including java.vendor.* and java.specification.* properties, plus 
the java.class.version (major.minor)
   This included two changes to the build that generates source of 
VersionProps.java.


 - Updated the StaticProperty initialization to be explicitly invoked 
by initProperties.


 - Makes separate calls to native to retrieve the platform properties 
and VM/command line properties


 - (The hotspot function for JVM_GetProperties are unchanged)

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

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

Thanks, Roger

RE: RFR(S)JDK-8214074: Ghash optimization using AVX instructions

[Kamath, Smita]

Hi Florian,

The performance gain that I reported was over the earlier implementation of 
GHASH using clmul instructions (generate_ghash_process_blocks).
 
Regards,
Smita

-Original Message-
From: Florian Weimer [mailto:fwei...@redhat.com] 
Sent: Monday, November 19, 2018 1:55 PM
To: Kamath, Smita 
Cc: 'Vladimir Kozlov' ; Anthony Scarpino 
; core-libs-dev@openjdk.java.net; hotspot compiler 

Subject: Re: RFR(S)JDK-8214074: Ghash optimization using AVX instructions

* Smita Kamath:

> I'd like to contribute an optimization for GHASH Algorithm using AVX 
> Instructions. I have tested this optimization on SKX x86_64 platform 
> and it shows ~20-30% performance improvement for larger message sizes 
> (for example 8k).

Performance improvement against what?  The pure Java implementation?  I find 
this a bit surprising.  I would have expected a much larger performance 
improvement from the use of CLMUL instructions.

Thanks,
Florian

Re: RFR(S)JDK-8214074: Ghash optimization using AVX instructions

[Eric Caspole]

Hi everybody,
There are already JMH crypto micros in the open corpus (a maven project):

http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/javax/crypto

that should be able to measure the benefit of this webrev against the 
existing intrinsics.

Regards,
Eric


On 11/19/18 16:54, Florian Weimer wrote:

* Smita Kamath:


I'd like to contribute an optimization for GHASH Algorithm using AVX
Instructions. I have tested this optimization on SKX x86_64 platform
and it shows ~20-30% performance improvement for larger message sizes
(for example 8k).


Performance improvement against what?  The pure Java implementation?  I
find this a bit surprising.  I would have expected a much larger
performance improvement from the use of CLMUL instructions.

Thanks,
Florian

Re: RFR(S)JDK-8214074: Ghash optimization using AVX instructions

[Bernd Eckenfels]

Hello,

What is the purpose of setting some of them to 0 twice? (It’s a new array which 
should be all-0 anyway.)

+  for (int i = 1; i < 9 ; i++) {
+subkeyHtbl[2*i] = 0;
+subkeyHtbl[2*i+1] = 0;
+}

Also, is the subkeyH no longer be needed (or can be redesigned to use 
subkeyHtbl[0] and 1?

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


Von: core-libs-dev  im Auftrag von 
Kamath, Smita 
Gesendet: Montag, November 19, 2018 10:52 PM
An: 'Vladimir Kozlov'
Cc: Anthony Scarpino; core-libs-dev@openjdk.java.net; hotspot compiler
Betreff: RFR(S)JDK-8214074: Ghash optimization using AVX instructions

Hi Vladimir,

I'd like to contribute an optimization for GHASH Algorithm using AVX 
Instructions. I have tested this optimization on SKX x86_64 platform and it 
shows ~20-30% performance improvement for larger message sizes (for example 8k).

I, smita.kam...@intel.com , Shay Gueuron, 
(shay.gue...@intel.com) and Regev Shemy 
(regev.sh...@intel.com) are contributors to this 
code.

Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8214074

Link to webrev: http://cr.openjdk.java.net/~svkamath/ghash/webrev/

For testing the implementation, I have executed TestAESMain.java. I have 
executed Jtreg tests and tested this code on 64 bit Windows and Linux platforms.

Please review and let me know if you have any comments.

Thanks and Regards,
Smita

Re: RFR (JDK 12/java.xml) 8210722: JAXP Tests: CatalogSupport2 and CatalogSupport3 generate incorrect messages upon failure

[Lance Andersen]

Seems OK joe

> On Nov 19, 2018, at 4:04 PM, Joe Wang  wrote:
> 
> Hi,
> 
> Please review a test patch below. The main change is removing the references 
> to openjdk.java.net. Since the Catalog feature sits above the default 
> resolution of external resources, there is no need for the tests to depend on 
> a real/live domain to test the feature that enables/disables Catalog. The 
> accessExternalDTD property is handy for verifying the situation when Catalog 
> feature is disabled (test CatalogSupport2 and 3) since when Catalog is 
> enabled, all access will be local (file).
> 
> Once this change is resolved, I'll close JDK-8210720 as there's no more 
> dependency on openjdk.java.net.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8210722
> webrev: http://cr.openjdk.java.net/~joehw/jdk12/8210722/webrev/
> 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8210720
> 
> Thanks,
> Joe
> 

 
  

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

Re: RFR(S)JDK-8214074: Ghash optimization using AVX instructions

[Florian Weimer]

* Smita Kamath:

> I'd like to contribute an optimization for GHASH Algorithm using AVX
> Instructions. I have tested this optimization on SKX x86_64 platform
> and it shows ~20-30% performance improvement for larger message sizes
> (for example 8k).

Performance improvement against what?  The pure Java implementation?  I
find this a bit surprising.  I would have expected a much larger
performance improvement from the use of CLMUL instructions.

Thanks,
Florian

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

[David Holmes]

On 20/11/2018 6:39 am, Kim Barrett wrote:

On Nov 19, 2018, at 7:56 AM, David Holmes  wrote:

On 19/11/2018 5:04 pm, Kim Barrett wrote:

On Nov 19, 2018, at 1:31 AM, David Holmes  wrote:

Hi Kim,

On 16/11/2018 12:31 pm, Kim Barrett wrote:

This doesn't strike me as a JEP that actually integrates anything. It wants to establish 
a process by which future C++ features are accepted for use with hotspot. That's just 
documentation on the OpenJDK wiki as far as I can see. The actual set of features and any 
"vote" on them can happen any time after the JEP is approved. Any actual use of 
those features can follow any time after that.

There is the integration of the build changes needed to enable the use of C++14.
Presently we explicitly specify C++98 (actually, gnu++98) for gcc.
We also presently permit the use of older versions of compilers that don’t 
support C++14
(or even C++11) at all, or only partially.  Those need to be dropped.


Even so those changes don't need to be put in place until we actually need to 
start using a new feature. So I would still think we can finalize the JEP 
independently of the subsequent code changes.


I don't see any benefit to making the first C++ code change that uses
a new feature also incorporate the needed build system changes.
Indeed, how does one develop that feature usage unless one has the
build system changes already in hand?


Just trying to distinguish the JEP from the build changes that will 
enable what is agreed upon by the JEP versus the first use of such changes.


If you want it all tied together that's fine - you're right it likely 
won't make 12.


Cheers,
David
-



It seems to me that if the documentation says one can use some new
language feature but the build system hasn't been updated to actually
support doing so, then the documentation is wrong. And recall that
this JEP includes making some new features available immediately.
(That initial list might be modified as part of this JEP discussion.)

RFR (JDK 12/java.xml) 8210722: JAXP Tests: CatalogSupport2 and CatalogSupport3 generate incorrect messages upon failure

[Joe Wang]

Hi,

Please review a test patch below. The main change is removing the 
references to openjdk.java.net. Since the Catalog feature sits above the 
default resolution of external resources, there is no need for the tests 
to depend on a real/live domain to test the feature that 
enables/disables Catalog. The accessExternalDTD property is handy for 
verifying the situation when Catalog feature is disabled (test 
CatalogSupport2 and 3) since when Catalog is enabled, all access will be 
local (file).


Once this change is resolved, I'll close JDK-8210720 as there's no more 
dependency on openjdk.java.net.


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


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

Thanks,
Joe

RFR(S)JDK-8214074: Ghash optimization using AVX instructions

[Kamath, Smita]

Hi Vladimir,

I'd like to contribute an optimization for GHASH Algorithm using AVX 
Instructions. I have tested this optimization on SKX x86_64 platform and it 
shows ~20-30% performance improvement for larger message sizes (for example 8k).

I, smita.kam...@intel.com , Shay Gueuron, 
(shay.gue...@intel.com) and Regev Shemy 
(regev.sh...@intel.com) are contributors to this 
code.

Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8214074

Link to webrev: http://cr.openjdk.java.net/~svkamath/ghash/webrev/

For testing the implementation, I have executed TestAESMain.java. I have 
executed Jtreg tests and tested this code on 64 bit Windows and Linux platforms.

Please review and let me know if you have any comments.

Thanks and Regards,
Smita

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

[Kim Barrett]

> On Nov 19, 2018, at 7:56 AM, David Holmes  wrote:
> 
> On 19/11/2018 5:04 pm, Kim Barrett wrote:
>>> On Nov 19, 2018, at 1:31 AM, David Holmes  wrote:
>>> 
>>> Hi Kim,
>>> 
>>> On 16/11/2018 12:31 pm, Kim Barrett wrote:
>>> 
>>> This doesn't strike me as a JEP that actually integrates anything. It wants 
>>> to establish a process by which future C++ features are accepted for use 
>>> with hotspot. That's just documentation on the OpenJDK wiki as far as I can 
>>> see. The actual set of features and any "vote" on them can happen any time 
>>> after the JEP is approved. Any actual use of those features can follow any 
>>> time after that.
>> There is the integration of the build changes needed to enable the use of 
>> C++14.
>> Presently we explicitly specify C++98 (actually, gnu++98) for gcc.
>> We also presently permit the use of older versions of compilers that don’t 
>> support C++14
>> (or even C++11) at all, or only partially.  Those need to be dropped.
> 
> Even so those changes don't need to be put in place until we actually need to 
> start using a new feature. So I would still think we can finalize the JEP 
> independently of the subsequent code changes.

I don't see any benefit to making the first C++ code change that uses
a new feature also incorporate the needed build system changes.
Indeed, how does one develop that feature usage unless one has the
build system changes already in hand?

It seems to me that if the documentation says one can use some new
language feature but the build system hasn't been updated to actually
support doing so, then the documentation is wrong. And recall that
this JEP includes making some new features available immediately.
(That initial list might be modified as part of this JEP discussion.)

Re: RFR 8177552: Compact Number Formatting support

[naoto . sato]

Hi Nishit,

On 11/18/18 10:29 PM, Nishit Jain wrote:

Hi Naoto,

Please check my comments inline.

On 17-11-2018 04:52, naoto.s...@oracle.com wrote:

Hi Nishit,

Here are my comments:

- CLDRConverter: As the compact pattern no more employs List, 
can we eliminate stringListEntry/Element, and use Array equivalent 
instead?
Since the CNF design does not put any limit on the size of compact 
pattern, so at the time of parsing the CLDR xmls using SAX parser, it 
becomes difficult to identify the size of array when the parent element 
of compact pattern is encountered, so I think it is better to keep the 
List while extracting the resources.


OK. However I'd not keep the List format on generating the 
resource bundle, as there is no reason to introduce yet another bundle 
format other than the existing array of String.




- CompactNumberFormat.java

Multiple locations: Use StringBuilder instead of StringBuffer.

OK


line 268: The link points to NumberFormat.getNumberInstance(Locale) 
instead of DecimalFormat

OK. Changed it at line 165 also.


line 855: no need to do toString(). length() can detect whether it's 
empty or not.


line 884: "Overloaded method" reads odd here. I'd prefer specializing 
in the "given number" into either long or biginteger.

OK


line 1500: subparseNumber() pretty much shares the same code with 
DecimalFormat.subparse(). can they be merged?
The existing CNF.subParseNumber differs in the way parseIntegerOnly is 
handled, DecimalFormat.parse()/subparse() behaviour is unpredictable 
with parseIntegeronly = true when multipliers are involved (Please see 
JDK-8199223).


Also, I had thought that the CNF.parse()/subparseNumber() should *not 
*parse the exponential notation e.g. while parsing "1.05E4K" the parsing 
should break at 'E' and returns 1.05, because 'E' should be considered 
as unparseable character for general number format pattern or compact 
number pattern, but this is not the case with DecimalFormat.parse(). The 
below DecimalFormat general number format instance


NumberFormat nf =  NumberFormat.getNumberInstance();
nf.parse("1.05E4")

Successfully parse the string and returns 10500. The same behaviour is 
there with other DecimalFormat instances also e.g. currency instance.


Do you think this is an issue with DecimalFormat.parse() and CNF should 
avoid parsing exponential numbers? Or, should CNF.parse() be modified to 
be consistent with DecimalFormat.parse() in this aspect?


No, I understand there are differences. But I see a lot of duplicated 
piece of code which I would like to eliminate.






line 1913-1923, 1950-1960, 1987-1997, 2024-2034: It simply calls 
super. No need to override them.
Since setters are overridden, I think that it is better to override 
getters also (even if they are just calling super and have same javadoc) 
to keep them at same level. But, if you see no point in keeping them in 
CNF, I will remove them. Does that need CSR change?


I don't see any point for override. I don't think there needs a CSR, but 
better ask Joe about it.




line 2231: You need to test the type before cast. Otherwise 
ClassCastException may be thrown.
The type is checked in the superclass equals method getClass() != 
obj.getClass(), so I think there is no need to check the type here.


OK.

Naoto



Regards,
Nishit Jain


Naoto

On 11/16/18 9:54 AM, Nishit Jain wrote:

Hi,

Please review this non trivial feature addition to NumberFormat API.

The existing NumberFormat API provides locale based support for 
formatting and parsing numbers which includes formatting decimal, 
percent, currency etc, but the support for formatting a number into a 
human readable or compact form is missing. This RFE adds that feature 
to format a decimal number in a compact format (e.g. 1000 -> 1K, 
100 -> 1M in en_US locale) , which is useful for the environment 
where display space is limited, so that the formatted string can be 
displayed in that limited space. It is defined by LDML's 
specification for Compact Number Formats.


http://unicode.org/reports/tr35/tr35-numbers.html#Compact_Number_Formats


RFE: https://bugs.openjdk.java.net/browse/JDK-8177552
Webrev: http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.00/
CSR: https://bugs.openjdk.java.net/browse/JDK-8188147

Request to please help review the the change.

Regards,
Nishit Jain

Re: RFR: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 compiler

[Thomas Stüfe]

Hi Adam,

could you please include link to the JBS issue and either link to the
patch/webrev or link to the webrev, or at the very least the patch
verbatim?

As for the issue itself: could you please elaborate why this fails with xlc13?

Also, a real patch would be helpful instead here of yet another link
to some J9 issue. We are really strapped for manpower and the AIX port
eats up enough time as it is.

Thanks, Thomas

On Mon, Nov 19, 2018 at 6:28 PM Adam Farley8  wrote:
>
> Hi All
>
> Both the problem and the solution appear straight-forward enough.
>
> Details included in the bug description.
>
> Thoughts and opinions welcome.
>
> Best Regards
>
> Adam Farley
> IBM Runtimes
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: RFR: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 compiler

[Roger Riggs]

Hi Adam,

As a convenience to the numerous developers in OpenJDK please include
a link to the issue and the changes when sending a request for review.
It makes things go much smoother. An in-line patch may be more 
convenient in this case.


Also note that *only* changes using the OpenJDK aliases
and infrastructure can be accepted.

Sorry, github is not part of the JDK infrastructure. Please re-send.

Regards, Roger

On 11/19/2018 12:26 PM, Adam Farley8 wrote:

Hi All

Both the problem and the solution appear straight-forward enough.

Details included in the bug description.

Thoughts and opinions welcome.

Best Regards

Adam Farley
IBM Runtimes

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

RFR: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 compiler

[Adam Farley8]

Hi All

Both the problem and the solution appear straight-forward enough.

Details included in the bug description.

Thoughts and opinions welcome.

Best Regards

Adam Farley 
IBM Runtimes

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

[Mandy Chung]

Thanks Sundar.  Here is the CSR:
   https://bugs.openjdk.java.net/browse/JDK-8213915

Mandy

On 11/19/18 6:48 AM, Sundararajan Athijegannathan wrote:

Looks good to me.

-Sundar

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

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:Java 8 - Lambdas, Streams, Default Methods | Baeldung

[Peter Hawthorne]

Hi there,
 
I just read Java 8 - Lambdas, Streams, Default Methods | Baeldung, I've shown 
it to some colleagues and we think a collaboration between us could work well. 
 

I represent a digital marketing agency currently working with a leading 
technology company who operates in the same marketplace as Android. We would 
like to feature a unique piece of content on your site on behalf of our client. 
For the privilege, we'd be happy to pay you somewhere in the region of $75. 
Would you also be willing to accept link placements on pre-existing content on 
your site?
 

Let me know your thoughts.
 

Best wishes,

Peter

 
Don't want emails from us anymore? Reply to this email with the word 
"UNSUBSCRIBE" in the subject line.

Re: Should HashMap::computeIfAbsent be considered a "structural modification" for an existing key?

[Andrew Dinn]

On 19/11/2018 16:01, Michael Rasmussen wrote:
> As the topic asks, should calling computeIfAbsent on a HashMap with
> an existing key be a structural modification?

I have to ask the obvious: Why does the question matter?

Are you just dipping a toe into the cold and briny realm of language
lawyers (of his bones are quarrels made) or is there a reason why being
a 'structural modification' needs to be precisely determined in this
case (perhaps, in all cases).

regards,


Andrew Dinn
---

Should HashMap::computeIfAbsent be considered a "structural modification" for an existing key?

[Michael Rasmussen]

Hi

As the topic asks, should calling computeIfAbsent on a HashMap with an existing 
key be a structural modification?

The documentation for HashMap has the following note regarding concurrency:
A structural modification is any operation that adds or deletes one or more 
mappings; merely changing the value associated with a key that an instance 
already contains is not a structural modification.

Especially the last part there makes me argue that computeIfAbsent with an 
existing key should NOT be a structural modification -- especially considering 
the equivalent call to HashMap::put is not.

Yet, it currently can be, as computeIfAbsent might resize the underlying table 
_before_ checking if the key is present.
(computeIfAbsent has if (size > threshold) resize() in the beginning, vs putVal 
having it at the end, after the key has been added).

So if HashMap::computeIfAbsent with an existing key should not be a structural 
modification, the current implementation is bugged.

Kind regards
Michael Rasmussen

Re: speed of class loading via a modulepath

[Richard Hillegas]

Thanks, Rémi and Alan.

On 11/19/18 12:53 AM, Alan Bateman wrote:

On 18/11/2018 20:00, Richard Hillegas wrote:
I am updating Apache Derby documentation to reflect the recent 
modularization of the codeline. While doing this, I have stumbled 
across an old piece of advice from the Derby Tuning Guide:


"The structure of your classpath can affect Derby startup time and 
the time required to load a particular class.


The classpath is searched linearly, so locate Derby's libraries at 
the beginning of the classpath so that they are found first. If the 
classpath first points to a directory that contains multiple files, 
booting Derby can be very slow."


That may be an old, Java 1.2 concern, which no longer affects modern 
JVMs. I have a couple questions:


1) Is this still good advice when booting a large application like 
Derby via a classpath?


2) What about the modulepath? Can classes be faulted in faster by 
re-arranging the order of jar files on the modulepath?
The position of the directory or module on the module path won't 
impact class/resources loading as modules are accessed directly (as 
Remi notes) so no linear scan/searching after startup. Ordering is of 
course important when you end up with a multiple versions of the same 
module on the path, in that case the first version of a module wins.


One other thing to be aware of is that the initial scanning of the 
module path can be slow when it contains lots of automatic modules or 
modules that have been packaged with the jar tool from JDK 8 or older. 
Explicit modules that are packaged with the JDK 9 (or newer) jar tool 
are indexed at packaging time to avoid scanning the contents at startup.


-Alan

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

[Sundararajan Athijegannathan]

Looks good to me.

-Sundar

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

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: 8213920 : Use {@systemProperty} tag for properties listed in System.getProperties

[Alan Bateman]

On 16/11/2018 07:00, Priya Lakshmi Muthuswamy wrote:

Hi,

Kindly review the fix for 
https://bugs.openjdk.java.net/browse/JDK-8213920

webrev: http://cr.openjdk.java.net/~pmuthuswamy/8213920/webrev.00/
This looks good, and I assume the first of many changes to make use of 
@systemProperty.


-Alan

Re: RFR 8177552: Compact Number Formatting support

[Stephen Colebourne]

I'm not a big fan of having a class named `Style` as it is commonly used in
business logic. (Yes, its an inner class, but I still think the potential
for annoyance is high). java.time.* has `TextStyle`, but I don't think it
can be reused here. Maybe the class should be honest and called
NumberFormatStyle (as a top level class).

More generally, the API does not allow the caller to take control of the
text, for example to use "mil" as a suffix for million. eg Think of this
method in java.time.* -
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/format/DateTimeFormatterBuilder.html#appendText(java.time.temporal.TemporalField,java.util.Map)


Stephen


On Fri, 16 Nov 2018 at 17:56, Nishit Jain  wrote:

> Hi,
>
> Please review this non trivial feature addition to NumberFormat API.
>
> The existing NumberFormat API provides locale based support for
> formatting and parsing numbers which includes formatting decimal,
> percent, currency etc, but the support for formatting a number into a
> human readable or compact form is missing. This RFE adds that feature to
> format a decimal number in a compact format (e.g. 1000 -> 1K, 100 ->
> 1M in en_US locale) , which is useful for the environment where display
> space is limited, so that the formatted string can be displayed in that
> limited space. It is defined by LDML's specification for Compact Number
> Formats.
>
> http://unicode.org/reports/tr35/tr35-numbers.html#Compact_Number_Formats
>
>
> RFE: https://bugs.openjdk.java.net/browse/JDK-8177552
> Webrev: http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.00/
> CSR: https://bugs.openjdk.java.net/browse/JDK-8188147
>
> Request to please help review the the change.
>
> Regards,
> Nishit Jain
>
>
>
>
>

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

[David Holmes]

On 19/11/2018 5:04 pm, Kim Barrett wrote:

On Nov 19, 2018, at 1:31 AM, David Holmes  wrote:

Hi Kim,

On 16/11/2018 12:31 pm, Kim Barrett wrote:

On Oct 3, 2018, at 3:13 PM, Kim Barrett  wrote:

I've submitted a JEP for

(1) enabling the use of C++14 Language Features when building the JDK,

(2) define a process for deciding and documenting which new features
can be used or are forbidden in HotSpot code,

(3) provide an initial list of permitted and forbidden new features.

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

While there has been some discussion of this JEP here, so far only Mikael has 
officially
reviewed or endorsed it.


I added myself as a Reviewer.


Thanks.


Regarding the timing of this JEP, integration in time for JDK 12 seems unlikely.


This doesn't strike me as a JEP that actually integrates anything. It wants to establish 
a process by which future C++ features are accepted for use with hotspot. That's just 
documentation on the OpenJDK wiki as far as I can see. The actual set of features and any 
"vote" on them can happen any time after the JEP is approved. Any actual use of 
those features can follow any time after that.


There is the integration of the build changes needed to enable the use of C++14.
Presently we explicitly specify C++98 (actually, gnu++98) for gcc.
We also presently permit the use of older versions of compilers that don’t 
support C++14
(or even C++11) at all, or only partially.  Those need to be dropped.


Even so those changes don't need to be put in place until we actually 
need to start using a new feature. So I would still think we can 
finalize the JEP independently of the subsequent code changes.



I think it is important that all the port owners buy into this.


At least one port (aix_ppc) presently seems to have no way to support this 
change, because
the compiler being used is seriously deficient and appears to be languishing.  
(It doesn’t even
support C++11, let alone C++14.)  I think the community could (and in my 
opinion, should)
chose to move ahead despite that.  


Okay I've seen the mail on this - thanks.

Cheers,
David


If a new and adequate compiler is expected “soon” then
the community might choose to wait, or might proceed and let that port languish 
until the new
compiler is available.  I think that’s all part of the discussion that should 
happen around the
targeting of this JEP.  I hope this inadequate compiler on a relatively niche 
platform won’t be
an indefinite blocker in this area.

Re: RFR 4947890 : Minimize JNI upcalls in system property initialization

[Magnus Ihse Bursie]

On 2018-11-16 21:36, Erik Joelsson wrote:

Thanks, looks good to me now.

And to me.

Looks like a nice cleanup in general!

/Magnus



/Erik

On 2018-11-16 12:02, Roger Riggs wrote:

Hi Erik,

Yes, that is removed.
Webrev updated in place.

Thanks, Roger

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

On 11/16/2018 02:37 PM, Erik Joelsson wrote:
Does this mean we can remove $(VERSION_CFLAGS) from System.c in 
make/lib/CoreLibraries.gmk?


Otherwise this looks good from a build point of view.

/Erik

On 2018-11-16 10:49, Roger Riggs wrote:

Updates to include the suggestions made by Mandy and Brent:

 - Move the build-time properties from native code to the 
VersionProps.java.template
   including java.vendor.* and java.specification.* properties, 
plus the java.class.version (major.minor)
   This included two changes to the build that generates source of 
VersionProps.java.


 - Updated the StaticProperty initialization to be explicitly 
invoked by initProperties.


 - Makes separate calls to native to retrieve the platform 
properties and VM/command line properties


 - (The hotspot function for JVM_GetProperties are unchanged)

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

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

Thanks, Roger

Re: [PATCH] Windows 32-bit DLL name decoration

[Alexey Ivanov]

Hi Ali,

The fix looks good to me provided it resolves your problem.
I am not a reviewer so you'll have to get OK from reviewers, likely from 
build-dev and from core-libs.


Have you submitted the issue in JBS?

You have to sign OCA to be able to contribute to OpenJDK:
https://openjdk.java.net/contribute/
and also
https://openjdk.java.net/sponsor/

Regards,
Alexey

On 18/11/2018 12:07, Ali İnce wrote:

Hi Alexey,

Below is a new patch content that removes JNICALL modifiers from the exported 
functions of interest. This results in exported functions not to be name 
decorated and use __cdecl calling convention.

Do you have any more suggestions, or would you please guide me on next steps?

Thanks,

Ali

# HG changeset patch
# User Ali Ince 
# Date 1542542415 0
#  Sun Nov 18 12:00:15 2018 +
# Node ID a41df44e13e1b761f4b3f05a17ed18953067ae39
# Parent  16d5ec7dbbb49ef3f969e34be870e3f917ea89ff
Remove JNICALL modifiers to prevent name decoration on 32-bit windows builds

diff -r 16d5ec7dbbb4 -r a41df44e13e1 
src/jdk.jdi/share/native/libdt_shmem/shmemBack.c
--- a/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c  Tue Aug 14 14:28:23 
2018 +0200
+++ b/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c  Sun Nov 18 12:00:15 
2018 +
@@ -339,7 +339,7 @@
  return JDWPTRANSPORT_ERROR_NONE;
  }
  
-JNIEXPORT jint JNICALL

+JNIEXPORT jint
  jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr,
   jint version, jdwpTransportEnv** result)
  {
diff -r 16d5ec7dbbb4 -r a41df44e13e1 
src/jdk.jdwp.agent/share/native/include/jdwpTransport.h
--- a/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h   Tue Aug 14 
14:28:23 2018 +0200
+++ b/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h   Sun Nov 18 
12:00:15 2018 +
@@ -140,7 +140,7 @@
  void (*free)(void *buffer);  /* Call this for all deallocations */
  } jdwpTransportCallback;
  
-typedef jint (JNICALL *jdwpTransport_OnLoad_t)(JavaVM *jvm,

+typedef jint (*jdwpTransport_OnLoad_t)(JavaVM *jvm,
 jdwpTransportCallback 
*callback,
 jint version,
 jdwpTransportEnv** env);
diff -r 16d5ec7dbbb4 -r a41df44e13e1 
src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
--- a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.cTue Aug 
14 14:28:23 2018 +0200
+++ b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.cSun Nov 
18 12:00:15 2018 +
@@ -1019,7 +1019,7 @@
  return JDWPTRANSPORT_ERROR_NONE;
  }
  
-JNIEXPORT jint JNICALL

+JNIEXPORT jint
  jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr,
   jint version, jdwpTransportEnv** env)
  {




On 16 Nov 2018, at 23:03, Alexey Ivanov  wrote:

Hi Ali,

It's exactly what I referred to.

Yes, it does change the calling convention.
Yet it's not a (big) problem because both parties will use the same calling 
convention.

Using a DLL from another build will not be possible. But it's not a good idea 
to do so anyway.


Mapfiles and export options have been removed by 
https://bugs.openjdk.java.net/browse/JDK-8200178 to simplify managing exported 
functions. So that to add or remove an exported function, you don't have modify 
makefiles and/or mapfiles. You just edit the source files.

Regards,
Alexey

On 16/11/2018 22:42, Ali İnce wrote:

Hi Alexey,

Thanks for your reply.

I will definitely give it a try though I’m not sure if that’ll be a breaking 
change. This is because JNICALL modifier is defined to be __stdcall on windows 
which is both specified on jdwpTransport_OnLoad exported functions both for 
dt_socket.dll and dt_shmem.dll.

The __stdcall is ignored on x64 platforms and also name decoration is not 
applied 
(https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017).
 I believe that’s why we don’t experience any problems on x64 builds.

Removing JNICALL (thus __stdcall) modifier (apparently only applies to x86 
builds) will result in the calling convention to be changed, and thus will 
change how parameters are ordered and also the stack cleanup rules. I think 
this may result in problems in programs that are designed to load shared 
libraries and its exported functions at runtime (not bound by link time which 
probably won’t cause any issues - assuming that they use the shared function 
signature) - as in 
https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99.

Any thoughts?

Regards,

Ali


On 15 Nov 2018, at 22:14, Alexey Ivanov  wrote:

Hi Ali,

Can the issue be resolved by using different call modifiers on the affected 
functions?

Some build / link issues were resolved by adding / removing JNICALL modifier, 
see
https://bugs.openjdk.java.net/browse/JDK-8201226

Re: speed of class loading via a modulepath

[Alan Bateman]

On 18/11/2018 20:00, Richard Hillegas wrote:
I am updating Apache Derby documentation to reflect the recent 
modularization of the codeline. While doing this, I have stumbled 
across an old piece of advice from the Derby Tuning Guide:


"The structure of your classpath can affect Derby startup time and the 
time required to load a particular class.


The classpath is searched linearly, so locate Derby's libraries at the 
beginning of the classpath so that they are found first. If the 
classpath first points to a directory that contains multiple files, 
booting Derby can be very slow."


That may be an old, Java 1.2 concern, which no longer affects modern 
JVMs. I have a couple questions:


1) Is this still good advice when booting a large application like 
Derby via a classpath?


2) What about the modulepath? Can classes be faulted in faster by 
re-arranging the order of jar files on the modulepath?
The position of the directory or module on the module path won't impact 
class/resources loading as modules are accessed directly (as Remi notes) 
so no linear scan/searching after startup. Ordering is of course 
important when you end up with a multiple versions of the same module on 
the path, in that case the first version of a module wins.


One other thing to be aware of is that the initial scanning of the 
module path can be slow when it contains lots of automatic modules or 
modules that have been packaged with the jar tool from JDK 8 or older. 
Explicit modules that are packaged with the JDK 9 (or newer) jar tool 
are indexed at packaging time to avoid scanning the contents at startup.


-Alan

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

[Volker Simonis]

On Mon, Nov 19, 2018 at 9:00 AM Kim Barrett  wrote:
>
> > On Nov 19, 2018, at 2:04 AM, Kim Barrett  wrote:
> >
> >> On Nov 19, 2018, at 1:31 AM, David Holmes  wrote:
> >> I think it is important that all the port owners buy into this.
> >
> > At least one port (aix_ppc) presently seems to have no way to support this 
> > change, because
> > the compiler being used is seriously deficient and appears to be 
> > languishing.  (It doesn’t even
> > support C++11, let alone C++14.)  I think the community could (and in my 
> > opinion, should)
> > chose to move ahead despite that.  If a new and adequate compiler is 
> > expected “soon” then
> > the community might choose to wait, or might proceed and let that port 
> > languish until the new
> > compiler is available.  I think that’s all part of the discussion that 
> > should happen around the
> > targeting of this JEP.  I hope this inadequate compiler on a relatively 
> > niche platform won’t be
> > an indefinite blocker in this area.
>
> Here’s what Volker said on the build-dev list, 2017-07-19, subject 
> “C++11/C++14 support in XLC ?”
>
> 
> - SAP is currently maintaining the AIX port in the OpenJDK and we're
> willing to do that in the future. But we're not IBM and we can not
> decide about the XLC feature list. If Oracle and the OpenJDK community
> finally decide to use C++11/14 features which are not available in XLC
> we have to live with that. We can either escalate the XLC deficiencies
> to IBM and suspend the port until the compiler gets fixed. Or we can
> switch the port to use the GCC tool chain with all the pros (bigger
> compatibility with Linux platforms) and cons (porting effort, testing,
> compatibility with other AIX software compiled with XLC, compiler
> support). While the GCC alternative sounds very appealing at a first
> glance it really isn't that perfect in reality, especially not for our
> commercial SAP JVM version of OpenJDK. One problem is the fact that
> there's no official support for GCC on AIX, the other is
> compatibility. Just think you had to replace Solaris Studio by GCC on
> Solaris :)
> 
>
> He had more to say on the general topic at the time.  I don’t know if anything
> has changed in the intervening nearly 1 1/2 years.
>

Not really. IBM is working on a new compiler which is in Beta now. But
neither have I tested it nor do I know exactly if it will have full
C++11/14 support.

As I wrote before, this is a chicken/egg problem which I can not solve
and I agree that it shouldn't be a blocker for OpenJDK. Therefore,
please go ahead and use whichever feature the OpenJDK community agrees
upon.

Regards,
Volker

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

[Kim Barrett]

> On Nov 19, 2018, at 2:04 AM, Kim Barrett  wrote:
> 
>> On Nov 19, 2018, at 1:31 AM, David Holmes  wrote:
>> I think it is important that all the port owners buy into this.
> 
> At least one port (aix_ppc) presently seems to have no way to support this 
> change, because
> the compiler being used is seriously deficient and appears to be languishing. 
>  (It doesn’t even
> support C++11, let alone C++14.)  I think the community could (and in my 
> opinion, should)
> chose to move ahead despite that.  If a new and adequate compiler is expected 
> “soon” then
> the community might choose to wait, or might proceed and let that port 
> languish until the new
> compiler is available.  I think that’s all part of the discussion that should 
> happen around the
> targeting of this JEP.  I hope this inadequate compiler on a relatively niche 
> platform won’t be
> an indefinite blocker in this area.

Here’s what Volker said on the build-dev list, 2017-07-19, subject “C++11/C++14 
support in XLC ?”


- SAP is currently maintaining the AIX port in the OpenJDK and we're
willing to do that in the future. But we're not IBM and we can not
decide about the XLC feature list. If Oracle and the OpenJDK community
finally decide to use C++11/14 features which are not available in XLC
we have to live with that. We can either escalate the XLC deficiencies
to IBM and suspend the port until the compiler gets fixed. Or we can
switch the port to use the GCC tool chain with all the pros (bigger
compatibility with Linux platforms) and cons (porting effort, testing,
compatibility with other AIX software compiled with XLC, compiler
support). While the GCC alternative sounds very appealing at a first
glance it really isn't that perfect in reality, especially not for our
commercial SAP JVM version of OpenJDK. One problem is the fact that
there's no official support for GCC on AIX, the other is
compatibility. Just think you had to replace Solaris Studio by GCC on
Solaris :)


He had more to say on the general topic at the time.  I don’t know if anything
has changed in the intervening nearly 1 1/2 years.