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

Alan, Rémi, If you're still interested in providing transform-like behavior for CharSequence, there's a fairly neat (I hope) way to do that. The idea is to use the following helper functional interface for forwarding to the already added String.transform: @FunctionalInterface interface

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

Hi everyone, I came up with the following patch: http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ It specifically addresses the problem in JDK-8214122 where on 32 bit Windows jdwpTransport_OnLoad can exported with its plain and __stdcall-mangled name. I used conditional compilation so

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

Alan Bateman wrote on 11/12/2018 15:32:31: > From: Alan Bateman > To: Adam Farley8 , core-libs-dev d...@openjdk.java.net> > Date: 11/12/2018 15:33 > Subject: Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words > > On 11/12/2018 15:03, Adam Farley8 wrote: > > Hey All, > > > > I've

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

Ho Vincent, On 12/11/2018 11:34 AM, Vincent Ryan wrote: Responses in-line. Its really nice/necessary that examples can be copy/pasted and compile.  - dumpAsStream(ByteBuffer, from, to, chunk, Formatter) may be confusing because it    is using the relative methods of ByteBuffer, but the

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

Hotspot has had support for decorated and non-decorated names for the JNI_OnLoad functions. Perhaps you should just follow the same procedure for the debug library. #define JNI_ONLOAD_SYMBOLS {"_JNI_OnLoad@8", "JNI_OnLoad"} #define JNI_ONUNLOAD_SYMBOLS {"_JNI_OnUnload@8", "JNI_OnUnload"}

RE: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue

> File paths are, in general, always something that demands extra scrutiny > as it can be the source of security issues (privacy leaks, traversal > attacks, etc). It's not just me that thinks that way, you can do a > search on the Internet and find lots of references. ... > > It might be

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

On 11/12/2018 15:03, Adam Farley8 wrote: Hey All, I've spotted 12 instances of swear words in OpenJDK source comments, and it seems appropriate to remove them. Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 I've created a webrev and attached to the bug. Also, I've mentioned in the bug

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

Hi Adam, in order to prevent me from using swear words, could you please upload your webrev to cr.openjdk.java.net :) As you may have realized webrevs are a collection of HTML files and it makes no big sense to provide them as a zip file. Thank you and best regards, Volker On Tue, Dec 11, 2018

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

Hi, And the patch by itself is sufficient, inline or attached to the issue or the email. No need to carry around the whole webrev. And it is very handy to have an quick link to cr.openjdk.java.net $.02, Roger On 12/11/2018 10:46 AM, Volker Simonis wrote: Hi Adam, in order to prevent me

Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace

Hi Martin, On 12/11/2018 01:30 PM, Doerr, Martin wrote: thanks for updating. I think it can get shipped when Gustavo is fine with it and jdk/submit tests have passed. Yep, I'm working on that right now. I'll update soon. So I have to push to jdk/submit, wait the test results and if it's fine

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

! // these icons are pretty crappy to use in Mac OS X since // they really are interactive but we have to return a static // icon for now. -> ! // these icons are difficult to use in Mac OS X since // they really are interactive

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

Sure thing: http://cr.openjdk.java.net/~afarley/8215217/webrev/ Best Regards Adam Farley IBM Runtimes Volker Simonis wrote on 11/12/2018 15:46:44: > From: Volker Simonis > To: adam.far...@uk.ibm.com > Cc: Java Core Libs > Date: 11/12/2018 15:47 > Subject: Re: RFR: JDK-8215217: OpenJDK

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

Hi Stuart, The APIs for streams of characters bifurcated a bit between PrintStream and Writers. Many common use cases would like to direct the output to System.out/err which are PrintStreams.  Hence, I lean toward PrintStream that can be used directly. $.02, Roger On 12/10/2018 09:11 PM,

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

Hi Simon, Thank you for your comments. The updated webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ Indeed, it looks much cleaner. Regards, Alexey On 11/12/2018 16:43, Simon Tooke wrote: On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: Hi everyone, I came up with the following

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

Responses in-line. > On 10 Dec 2018, at 21:38, Roger Riggs wrote: > > Hi Vincent, > > On 12/10/2018 03:59 PM, Vincent Ryan wrote: >> Comments in-line. >> Thanks. >> >>> On 10 Dec 2018, at 16:59, Roger Riggs >> > wrote: >>> >>> Hi, >>> >>> Looks good, though

Re: RFR: 8215159: Improve initial setup of system Properties

On 12/10/18 1:17 PM, Claes Redestad wrote: Hi, by inverting the order in which the internal property maps are created, we avoid some classloading and get a slightly more efficient code execution profile in System.initPhase1. Webrev: http://cr.openjdk.java.net/~redestad/8215159/jdk.00/ Bug:

Re: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT

On Tue, Dec 11, 2018 at 3:35 PM Magnus Ihse Bursie wrote: > > > > On 2018-12-11 00:23, David Holmes wrote: > > Hi Magnus, > > > > On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: > >> I propose that we introduce a new define, available to all JDK native > >> files (Hotspot included), called

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

On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: > Hi everyone, > > I came up with the following patch: > http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ > > It specifically addresses the problem in JDK-8214122 where on 32 bit > Windows jdwpTransport_OnLoad can exported with its plain and >

Re: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect

Hi Naoto, Thanks for fixing this. Your fix looks good to me. Thanks, Rachna On 12/11/18 8:21 PM, Naoto Sato wrote: Hi, Please review the fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8215194 The proposed fix is located at:

[12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect

Hi, Please review the fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8215194 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8215194/webrev.00/ This one line fix is for the correctness of the initial map size of Character.UnicodeBlock. Naoto

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

Sweet! Learning English with the OpenJDK community. You sir, probably, have a degree in public relations and/or marketing. This was *the best* way to draw attention to those swear words. Had these words stayed unexposed, no one would have been bothered by them. I guess... On a serious note, I

Re: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect

Hi Naoto, Since the value changes from time to time, it would give it some visibility if it were defined using a private final int  (or float) private final int MAP_CAPACITY = 667; Though I suppose the test can't use the value without using reflection. But it would lower the maintenance in

Re: RFR: 8215159: Improve initial setup of system Properties

HashMap sizing was a terrible design mistake, but too much software depends on it, e.g. https://google.github.io/guava/releases/23.0/api/docs/com/google/common/collect/Maps.html#newHashMapWithExpectedSize-int- On Tue, Dec 11, 2018 at 1:26 AM Claes Redestad wrote: > Hi Peter, > > On 2018-12-11

RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

Hey All, I've spotted 12 instances of swear words in OpenJDK source comments, and it seems appropriate to remove them. Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 I've created a webrev and attached to the bug. Also, I've mentioned in the bug that there are additional swears in more

Re: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect

Hi Claes, I don't see any particular reason for that. In fact, I was wondering the same thing, but just left it as it was. Since I've already pushed the changeset, I will fix it on the next occasion. Naoto On 12/11/18 2:31 PM, Claes Redestad wrote: Hi Naoto, while the here fix looks good,

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

On 12/11/2018 1:52 PM, mark.reinh...@oracle.com wrote: 2018/12/11 7:03:57 -0800, adam.far...@uk.ibm.com: I've spotted 12 instances of swear words in OpenJDK source comments, and it seems appropriate to remove them. Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 (webrev:

Review Request JDK-8215238: (jdeps) update jdk8_internals.txt per the removal of javafx, corba, EE modules

Several modules including Java EE and CORBA modules [1] and JavaFX and a few other modules have been removed from JDK. jdeps maintains a list of JDK 8 internal API packages that `jdeps -jdkinternals` can properly flag that a reference to JDK 8 internal API that was renamed or removed while the

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

On 12/11/18 1:52 PM, mark.reinh...@oracle.com wrote: 2018/12/11 7:03:57 -0800, adam.far...@uk.ibm.com: I've spotted 12 instances of swear words in OpenJDK source comments, and it seems appropriate to remove them. Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 (webrev:

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

2018/12/11 7:03:57 -0800, adam.far...@uk.ibm.com: > I've spotted 12 instances of swear words in OpenJDK source comments, and > it seems appropriate to remove them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 (webrev: http://cr.openjdk.java.net/~afarley/8215217/webrev/) > I've

Re: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect

Hi Naoto, while the here fix looks good, I can't help wondering why the map isn't final? /Claes On 2018-12-11 19:59, Naoto Sato wrote: Hi Ivan, Thank you for the review. On 12/11/18 10:49 AM, Ivan Gerasimov wrote: OptimalCapacity.ofHashMap uses the initialCapacity to verify that a HashMap

Re: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect

Hi Roger, Thanks. I updated it as suggested (incl. test using reflection): http://cr.openjdk.java.net/~naoto/8215194/webrev.01/ Naoto On 12/11/18 7:57 AM, Roger Riggs wrote: Hi Naoto, Since the value changes from time to time, it would give it some visibility if it were defined using a

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

Hi Vincent, I have no new inclinations about relative vs absolute, maybe someone else has use cases that will tip the balance. HexFormat.java:  - line 264: I think you can safely just append the (char) (byte[i] & 0xff). (to avoid sign extension).    Creating a string for each char seems

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

On 12/11/18 10:44 PM, David Holmes wrote: > No issue with fixing F-bomb (though one comes from upstream sources I think) > and the Pitch typo, > but seriously "damn" is not a swear word. Exactly my comment as well. Thanks, -Aleksey

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

On 12/11/2018 01:52 PM, mark.reinh...@oracle.com wrote: 2018/12/11 7:03:57 -0800, adam.far...@uk.ibm.com: I've spotted 12 instances of swear words in OpenJDK source comments, and it seems appropriate to remove them. Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 (webrev:

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

On 12/12/2018 7:52 am, mark.reinh...@oracle.com wrote: 2018/12/11 7:03:57 -0800, adam.far...@uk.ibm.com: I've spotted 12 instances of swear words in OpenJDK source comments, and it seems appropriate to remove them. Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 (webrev:

Re: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT

On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: On 2018-12-11 00:23, David Holmes wrote: Hi Magnus, On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: I propose that we introduce a new define, available to all JDK native files (Hotspot included), called JDK_EXPORT. The behavior of this

Re: Review Request JDK-8215238: (jdeps) update jdk8_internals.txt per the removal of javafx, corba, EE modules

+1 > On Dec 11, 2018, at 6:57 PM, Mandy Chung wrote: > > Several modules including Java EE and CORBA modules [1] and > JavaFX and a few other modules have been removed from JDK. > > jdeps maintains a list of JDK 8 internal API packages that > `jdeps -jdkinternals` can properly flag that a

Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace

Hi Michi and Martin, On 12/11/2018 01:30 PM, Doerr, Martin wrote: thanks for updating. I think it can get shipped when Gustavo is fine with it and jdk/submit tests have passed. webrev.06 removed has_darn from match_rule_supported and the JVM now crashes with SIGILL (cmprb) on CPUs <= POWER8.

Re: RFR: 8215159: Improve initial setup of system Properties

On 12/11/18 10:08 AM, Roger Riggs wrote: VM.java:  - line 180:  The savedProps doesn't need to be (and was not previously) unmodifiable.    Seems safer this way though since the map at the bottom is not ConcurrentHashMap.    Its not entirely clear who calls getSavedProperties().    Would

Re: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect

Looks fine. Thanks, Roger On 12/11/2018 01:33 PM, Naoto Sato wrote: Hi Roger, On 12/11/18 10:12 AM, Roger Riggs wrote: Hi Naoto, Looks ok, I intended only the number of elements to be defined as a constant. The other factors can be hard coded. OK, I revised it again:

JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

Hi, I've been looking into this bug in HashMap where resize() is called multiple times when putting whole map into another. I come up with following patch: http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8210280/webrev.00/ I've tried to do it as little invasive as possible. New resize(int)

Re: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode()

Hi Zheka and Tagir, @Override public void forEach(final Consumer action) { Objects.requireNonNull(action); for (int i = 0; i < this.n; i++) { action.accept(this.element); } } I think here we should extract this.element and this.n into a local vars, as Consumer may have interaction

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

What is this, the thought police? Cheers Stefan BotCompany.de On Tue, 11 Dec 2018 at 20:47, Phil Race wrote: > 1) Thanks for uploading the webrev. much better for one person to do > this than make > everyone who wants to look at it go through a tedious and off-putting > set of steps. > > 2)

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

Thanks for your review Alan. I believe I’ve addressed your concerns in this latest webrev/javadoc: http://cr.openjdk.java.net/~vinnie/8170769/webrev.08/

Re: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect

Hi Naoto, Looks ok, I intended only the number of elements to be defined as a constant. The other factors can be hard coded. In the test, you will still have to edit the test when the number changes. I meant to avoid that edit.  Though then may be there is not need for the test at all.

Re: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect

Hi Roger, On 12/11/18 10:12 AM, Roger Riggs wrote: Hi Naoto, Looks ok, I intended only the number of elements to be defined as a constant. The other factors can be hard coded. OK, I revised it again: http://cr.openjdk.java.net/~naoto/8215194/webrev.02/ In the test, you will still have

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

Thanks Roger. I believe that all but one of your concerns are addressed in this latest webrev/javadoc: http://cr.openjdk.java.net/~vinnie/8170769/webrev.08/

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

Thanks for your review Stuart. My preference is for PrintStream rather than Writer, for the same reason as Roger: it’s more convenient for handling System.out. Does that address your concern? I cannot simply cast 8859-1 characters into UTF-8 because UTF-8 is multi-byte charset so some 0x8X

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

No issue with fixing F-bomb (though one comes from upstream sources I think) and the Pitch typo, but seriously "damn" is not a swear word. I have to suspect you ran a corporate word checker over the sources. David - damn /dam/ verb past participle: damned 1. (in Christian belief)

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

1) Thanks for uploading the webrev. much better for one person to do this than make everyone who wants to look at it go through a tedious and off-putting set of steps. 2) I've added some client lists since you are touching UI client files, not just core-libs.    To me the client ones look OK,

Re: RFR: 8215159: Improve initial setup of system Properties

On 2018-12-11 18:41, Mandy Chung wrote: On 12/10/18 1:17 PM, Claes Redestad wrote: Hi, by inverting the order in which the internal property maps are created, we avoid some classloading and get a slightly more efficient code execution profile in System.initPhase1. Webrev:

Re: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect

Hi Naoto! The fix looks good, thank you! I wonder if the test can be updated to also verify the optimal capacity of HashMap aliases; On 12/11/18 10:33 AM, Naoto Sato wrote: Hi Roger, On 12/11/18 10:12 AM, Roger Riggs wrote: Hi Naoto, Looks ok, I intended only the number of elements to

Re: RFR: 8215159: Improve initial setup of system Properties

Hi Claes, SystemProps.java:   - the import of Collections isn't used. VM.java:  - line 180:  The savedProps doesn't need to be (and was not previously) unmodifiable.    Seems safer this way though since the map at the bottom is not ConcurrentHashMap.    Its not entirely clear who calls

Re: [12] RFR: 8215194: Initial size of UnicodeBlock map is incorrect

Hi Ivan, Thank you for the review. On 12/11/18 10:49 AM, Ivan Gerasimov wrote: OptimalCapacity.ofHashMap uses the initialCapacity to verify that a HashMap created with that initialCapacity will not reallocate its internal array after inserting the factual number of elements. So, if one day

Re: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue

On 12/11/18 10:38 AM, Baesken, Matthias wrote: File paths are, in general, always something that demands extra scrutiny as it can be the source of security issues (privacy leaks, traversal attacks, etc). It's not just me that thinks that way, you can do a search on the Internet and find lots of

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

Hi, fyi, jmh tests appropriate for JDK apis are located in the test/micro/... directories. The benchmarks are built with:   % make build-microbenchmark The results are in the build//images/test/micro/benchmarks.jar $.02, Roger On 12/11/2018 A 9:55 PM, Martin Buchholz wrote: Hi Michal,

Re: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode()

> > In performance critical code, we don't trust hotspot to not reload final > fields. Other forEach methods do this, e.g. final Object[] es = queue; for (int i = 0, n = size; i < n; i++) action.accept((E) es[i]);

Re: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode()

I used to believe that, but apparently I was wrong. https://openjdk.markmail.org/thread/rfqfultw35i2az45 On Tue, Dec 11, 2018 at 8:14 PM Zheka Kozlov wrote: > Would be better to add @Stable to the fields instead? (`n` and `element` > are final, so @Stable is OK here) > > ср, 12 дек. 2018 г. в

Re: JDK 13 RFR of core libs portions of JDK-8205626: Start of release updates for JDK 13

Hi Andrew, Way back when JSR 269 which added the javax.lang.model API was running, we did consider having a "LATEST" enum constant that would be an alias for the most current release. In the end, we decided against this approach and use a pair of "latest" methods on the SourceVersion enum to

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

Hi Michal, pleased to meet you. I'll be your sponsor. The test will need a legal header, presumably similar to others authored by redhatters. It is now possible to check in jmh microbenchmarks (but I've never done so myself). The current coding style is non-standard, but deliberate; avoid

Re: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode()

Hi Sergey. `n` and `element` are final fields. Extracting it into local vars will not make any difference. ср, 12 дек. 2018 г. в 02:25, Сергей Цыпанов : > Hi Zheka and Tagir, > > @Override > public void forEach(final Consumer action) { > Objects.requireNonNull(action); > for (int i = 0; i <

Re: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace

Hi Michi, On 12/11/2018 11:12 PM, Michihiro Horie wrote: Thank you for finding the issue on Power8. You do not need a check with has_darn in the ppc.ad. It is better to add a check in vm_versoin_ppc. I agree. I uploaded webrev.08 based on your webrev.07. (Thanks for the enhancement of

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

On 12/11/18 1:21 PM, Vincent Ryan wrote: My preference is for PrintStream rather than Writer, for the same reason as Roger: it’s more convenient for handling System.out. Does that address your concern? PrintStream is fine with me. I cannot simply cast 8859-1 characters into UTF-8 because

Re: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode()

Would be better to add @Stable to the fields instead? (`n` and `element` are final, so @Stable is OK here) ср, 12 дек. 2018 г. в 11:02, Martin Buchholz : > In performance critical code, we don't trust hotspot to not reload final >> fields. Other forEach methods do this, e.g. > > > final

Re: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT

On Tue, Dec 11, 2018 at 11:47 PM David Holmes wrote: > > On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: > > > > > > On 2018-12-11 00:23, David Holmes wrote: > >> Hi Magnus, > >> > >> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: > >>> I propose that we introduce a new define, available to

Re: Review Request JDK-8215238: (jdeps) update jdk8_internals.txt per the removal of javafx, corba, EE modules

On 11/12/2018 23:57, Mandy Chung wrote: Several modules including Java EE and CORBA modules [1] and JavaFX and a few other modules have been removed from JDK. jdeps maintains a list of JDK 8 internal API packages that `jdeps -jdkinternals` can properly flag that a reference to JDK 8 internal

RE: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace

Hi Gustavo, thanks for your improvements. You can also remove the trailing \t from the opto assembly. Note that there's no need to re-push newer version to jdk/submit when only PPC files were changed. jdk/submit doesn't look at them. Best regards, Martin -Original Message- From:

Re: RFR: 8215159: Improve initial setup of system Properties

Hi Peter, On 2018-12-11 10:02, Peter Levart wrote: Hi Claes, Haven't checked all changes yet, although it looks like a straightforward swap of Properties for HashMap for intermediary result, but I noticed the following in SystemProps:  265 var cmdProps = new

Re: RFR: 8215159: Improve initial setup of system Properties

Hi Claes, Haven't checked all changes yet, although it looks like a straightforward swap of Properties for HashMap for intermediary result, but I noticed the following in SystemProps:  265 var cmdProps = new HashMapString>((vmProps.length / 2) + Raw.FIXED_LENGTH); The

Re: RFR: 8215159: Improve initial setup of system Properties

Hi, On 2018-12-11 19:08, Roger Riggs wrote: Hi Claes, SystemProps.java:   - the import of Collections isn't used. will fix before push. VM.java:  - line 180:  The savedProps doesn't need to be (and was not previously) unmodifiable.    Seems safer this way though since the map at the

Re: RFR(XS): 8215009: GCC 8 compilation eror in libjli

On 12/11/18 4:03 AM, David Holmes wrote: Hi Dmitry, On 11/12/2018 12:16 am, Dmitry Chuyko wrote: Hello, Please review a small fix in java_md_solinux.c: continuation is not truly compatible with pthread_create start_routine's signature but we control what actually happens. So it makes sense

RE: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace

Hi Michihiro, the shared code looks good to me, now. Looks like the PPC64 is not consistent any more. Where do you enable UseCharacterCompareIntrinsics on PPC64? Why aren't you using it for match_rule_supported in the ad file? I think has_darn could be used to enable it in vm_version_ppc. Best

Re: Add convenience collect methods to the Stream interface

Although I do understand the reasoning (non-repeatability of streams), Stream not implementing Iterable is a minor but frequent annoyance for this precise reason. Using forEach() instead isn't always an option. Maybe Iterable can have a superinterface IterableOnce with the methods moved up to

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

On 08/12/2018 01:18, Vincent Ryan wrote: Here’s the latest version that addresses all the current open issues: webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.07/ javadoc:

Re: Add convenience collect methods to the Stream interface

Hi Rob, On 12/10/18 11:11 PM, Rob Griffin (rgriffin) wrote: Hi Remi, There are certainly places where we could do this when we are simply iterating over the results but that is not always the case. However I was disappointed to find that the enhanced for loop can't iterate over a stream so

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

The help output of jpackager should mention how to set the classpath for the various bundle resource files. I have not found a working solution how to set the classpath. jpackager -classpath build/deploy/ jpackager -cp build/deploy/ DEB Using default package resource [menu icon] (add

Re: Add convenience collect methods to the Stream interface

You say it jokingly, but we've explored this.  (The exact way you phrase it (the supertype specified to throw if called more than once) means that Iterable can't extend IterableOnce, because then Iterable does not conform to the superclass contract, but there are other ways to stack it.)  It's

Re: Add convenience collect methods to the Stream interface

Hi Rob, Hi Petter, we (the lambda EG) have decided against implementing Iterable (see the answer of Brian), so for consistency we have also not enable the right hand side of a enhanced for loop to be a poly-expression (that enables the lambda conversion), hence the mandatory cast. Rémi -

Re: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work.

Yes please, with the Solaris update. Thanks, Roger On 12/11/2018 02:52 AM, Volker Simonis wrote: Hi Roger, just to clarify - do you want us to push the last version [1] which adds "|| forceNullOutputStream)" to the Solaris version as well? Thank you and best regards, Volker [1]

Re: Add convenience collect methods to the Stream interface

And i've forgotten to add that currently calling stream.iterator() is slw, i don't know if it's just because the implementation of this method did not get some love or it's a more fundamental issue because a spliterator is push while an iterator is pull so the implementation needs an

Re: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT

On 2018-12-11 00:23, David Holmes wrote: Hi Magnus, On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: I propose that we introduce a new define, available to all JDK native files (Hotspot included), called JDK_EXPORT. The behavior of this symbol will be very similar (as of now, in fact