Re: RFR: 8201274: Launch Single-File Source-Code Programs

On 5/4/18 2:59 PM, Jonathan Gibbons wrote: Here's an update to the previously proposed patch for JEP 330: Launch Single-File Source-Code Programs. It includes all review feedback so far. The changes are mostly minor, but with the addition of more test cases. The webrev includes a

Re: RFR JDK-8200372 - String::trim JavaDoc should clarify meaning of space

Will do. Sent from my iPhone > On May 9, 2018, at 10:38 PM, Stuart Marks wrote: > > A typical way to refer to a particular Unicode character by code point hex > value is U+ (with more x's if necessary). For example, > > 2602 * Returns a string whose value

Re: Should Java have a unit type?

When we complete the (long) arc of Valhalla, making void a real type will be highly desirable (for example, Consumer becomes a refinement of Function).  But that's a ways off. On 5/9/2018 9:40 PM, James Roper wrote: Hi all, I'm interested in opinions on whether Java should have a

Should Java have a unit type?

Hi all, I'm interested in opinions on whether Java should have a unit type. I apologise if this has already been discussed on this list before, I did search for it but didn't find anything. By unit type, I'm referring to a type that represents no value. When a Java method returns no value, void

Re: RFR JDK-8200372 - String::trim JavaDoc should clarify meaning of space

A typical way to refer to a particular Unicode character by code point hex value is U+ (with more x's if necessary). For example, 2602 * Returns a string whose value is this string, with all leading 2603 * and trailing space removed, where space is defined 2604 * as any

JEP 306 Question

Does anyone know what is going to be decided around full target status of JEP 306? I have been recommended to this list for the sake of this question. ? http://openjdk.java.net/jeps/306 https://bugs.openjdk.java.net/browse/JDK-8175916

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

> On May 10, 2018, at 6:49 AM, Vincent Ryan wrote: > >> >> - As Max observes, being able to supply the delimiters might be a good >> addition. (I'm thinking IP addresses too). > > Sure. Add another toHexString method that takes a delimiter character? Good idea.

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

Thanks for your comments Max. > On 9 May 2018, at 03:34, Weijun Wang wrote: > > Nice tool. > > However, I am not sure how toFormattedHexString() and toPrintableString() are > useful, seems only for providing a customizable dump format which is, > actually, not very

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

Thanks Roger for your comments. The main motivator for this class is to provide a basic hex. encoder/decoder for smaller amounts of binary data and to provide a hexdump encoder for larger amounts of binary data, while recognising the need to cater for custom formats too. The class does not

RFR: jsr166 jdk integration 2018-05

Time to do this, since Claes is also touching ArrayList. http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html 8202685: Improve ArrayList replaceAll http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/replaceAll/index.html

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

Hi Vinnie, On the API and spec, a few comments:  - Expanding the printable string from ASCII to ISO-8859-1 would make it a bit more useful in more cases.    That might suggest using the Charset converter to do the work (less optimized but more functional). - There is no API support for

Re: RFR of JDK-8202756,move FilterUSRTest.java to openJDK

Hi Hamlin, Looks good, Thanks, Roger On 5/7/2018 10:17 PM, Hamlin Li wrote: Would you please review the following patch? bug: https://bugs.openjdk.java.net/browse/JDK-8202756 webrev: http://cr.openjdk.java.net/~mli/8202756/webrev.00/ Thank you -Hamlin

Re: [11] RFR for JDK-8202544: Hide unused exports in libzip

Any volunteers from core-libs and/or hotspot? Thank you, Alexey On 02/05/2018 13:02, Magnus Ihse Bursie wrote: Looks good to me, FWIW. /Magnus 2 maj 2018 kl. 13:52 skrev Alexey Ivanov : Hi, Could you please review the following fix for jdk11? bug:

RFR: JDK-8200377 String::strip, String::stripLeading, String::stripTrailing

This feature introduces three String instance methods for removal of white space from the beginning and end of a string. Unlike String::trim, these methods use the Unicode definition of white space. Specifically, these methods use Character.isWhitespace(int codePoint) to detect space

Re: [11] RFR: 8202553: Update FXLauncherTest as part of removing JavaFX from JDK

I'll work up a new version of the webrev that addresses your feedback, and strip down the mockfx classes to the minimum needed to support the test cases. -- Kevin On 5/8/2018 3:52 PM, Kumar Srinivasan wrote: Hi Kevin, Please review the following test fix:

Re: JEP 306

This seems like better mailing list for this inquiry. Coleen On 5/9/18 6:43 AM, A Z wrote: Does anyone know what is going to be decided around full target status of JEP 306? I have been recommended to this list for the sake of this question. ? http://openjdk.java.net/jeps/306

Re: Rationale behind having type variables for Collector's accumulator types in public APIs

Thanks a lot for digging this up. Interesting, so the implementation "leaked" into the API after all. Sometimes I wish that it would be possible for an implementation to "capture" a wildcard in a local type variable, as such: void foo(List list) { List local = list;