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

[Lukas Eder]

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;
  local.add(local.remove(0));
}

It would seem cleaner for such a method not to have a generic type variable
on the signature level, if it is used only in its internals...

2018-05-09 2:30 GMT+02:00 Paul Sandoz :

> Hi Lukas,
>
> See this thread:
>
>   http://mail.openjdk.java.net/pipermail/lambda-dev/2013-June/010115.html
>
> Paul.
>
> On May 7, 2018, at 2:00 AM, Lukas Eder  wrote:
>
> Hello,
>
> I'm currently designing API that I'd like to keep somewhat consistent with
> the Stream API and I've stumbled upon Stream.collect(), whose signature is:
>
>   R collect(Collector collector);
>
> For most common usages, I would imagine that this signature would have
> worked just as well:
>
>   R collect(Collector collector);
>
> In fact, it seems to be a nicer signature for the caller in edge cases
> where a type witness for  is needed, because in the current API, a
> witness for  has to be supplied as well, which seems unnecessary, if not
> for even rare edge cases.
>
> I understand that the ReferencePipeline's implementation is happy about
> being able to name the accumulator type rather than capturing it in a
> private auxiliary method or resorting to raw types, but I doubt that this
> is really an implementation detail having leaked into the API, given that
> much of the Collectors API also exposes the accumulator type as a type
> variable.
>
> What's the reason for  being in the public API?
>
> Thanks,
> Lukas
>
>
>

Re: JEP 306

[coleen . phillimore]

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
https://bugs.openjdk.java.net/browse/JDK-8175916

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

[Kevin Rushforth]

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:

https://bugs.openjdk.java.net/browse/JDK-8202553
http://cr.openjdk.java.net/~kcr/8202553/webrev.00/


 FXLauncherTest.java:

57 private static final String TEST_SRC = System.getProperty("test.src");
Since this test extends TestHelper, it already inits a global constant 
TEST_SOURCE_DIR

http://hg.openjdk.java.net/jdk/jdk/file/06d5b1f66553/test/jdk/tools/launcher/TestHelper.java#l120

209 // javac -d mods/javafx.graphics mockfx/src/javafx.graphics/**
is not quite accurate does not mention the --source-path


Prefer to avoid array copies in favor of List/ArrayList
228 System.arraycopy(compilerArgs, 0, fxCompilerArgs, 2, 
compilerArgs.length); - 237 System.arraycopy(cmds, 1, fxCmds, 3, 
cmds.length - 1); ditto. -

Mock JavaFX:
test/jdk/tools/launcher/mockfx/src/javafx.graphics/com/sun/javafx/application/* 
I have a general concern with the above classes, it seems to be overly 
complicated for a simple launcher test(s) to prevent regressions. I 
think this should be simply testing the logic in 
LauncherHelper.FXHelper, specifically this table: 
https://java.se.oracle.com/source/xref/jdk-jdk/open/src/java.base/share/classes/sun/launcher/LauncherHelper.java#852 
Alan, Mandy, what is your take on Mock JavaFX ?

Thanks
Kumar


This modifies the existing FXLauncherTest as follows:

1. Reverse the check for the presence of the 
javafx.application.Application class and fail the test if present


2. Create a "mock" javafx.graphics module with a mocked up version of 
the few classes needed to validate the FX launcher functionality


3. Remove the "intermittent" and "headful" keywords, since neither 
apply any more


4. Remove the test from the problem list

Thanks.

-- Kevin

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

[Jim Laskey]

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

webrev: http://cr.openjdk.java.net/~jlaskey/8200377/webrev/index.html
jbs: https://bugs.openjdk.java.net/browse/JDK-8200377
csr: https://bugs.openjdk.java.net/browse/JDK-8200378

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

[Alexey Ivanov]

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: https://bugs.openjdk.java.net/browse/JDK-8202544
webrev: http://cr.openjdk.java.net/~aivanov/8202544/jdk11/webrev.0/

The following exported functions in libzip are not used:
ZIP_GetEntry, ZIP_FreeEntry, ZIP_Lock, ZIP_Unlock, ZIP_Read

I removed JNIEXPORT modifiers from these functions. With the fix, they're not 
exported on Windows; on Linux they're listed as Local rather than Global.

I ran tests, no failures.


Thank you in advance.

Regards,
Alexey

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

[Roger Riggs]

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: 8170769 Provide a simple hexdump facility for binary data

[Roger Riggs]

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 ByteBuffers, another common source of 
bytes, that would make a good addition
   for completeness.  John Rose suggested a ByteSequence interface in 
the context of file processing but

   that hasn't settled down.

- The class name "Hex" might be a bit more evocative as HexDump or 
HexConverter.


- Method names;  the "Hex" in method names might be 
unnecessary/redundant since, as static methods,
  they would frequently appear in code as "Hex.fromHexString" and a 
simple "Hex.fromString" would be fine.

  Ditto,  toHexString(bytes) -> toString(bytes)...

- There are not many forms that allow the formatter to be supplied, for 
example, dump(in, out) might be

  a case where a formatter would be desired.

- Hex.Formatter interface could have a default method that provides the 
default formatting or as

  a static method so it can be used with a method reference.

- On the example in the class javadoc, I would use the implementation of 
the default formatter with both hex and ascii

  to show how that works.

 - As Max observes, being able to supply the delimiters might be a good 
addition.  (I'm thinking IP addresses too).


It looks quite good and very useful.

Thanks, Roger

On 5/8/2018 10:34 PM, 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 customizable.

For me, toHexString and fromHexString are of course the most useful methods. As 
for dump, I can only think of

1. The existing sun.security.HexDumpEncoder format, when I want to dump a lot 
of bytes as a block
2. "00:11:22:33:AA:BB:CC" which fits in one line and also easy to read, when I 
want inline debugging output

If the customizable dump method is both powerful and simple enough to create 2) above, I'll be 
happy. Otherwise, I can live with toHexString().replaceAll("(..)(?=.)", "$1:").

Thanks
Max


On May 4, 2018, at 4:22 AM, Vincent Ryan  wrote:

Hello,

Please review this proposal for a new API to conveniently generate and display 
binary data using hex string representation.
It supports both bulk and stream operations and it can also generate the 
well-known hexdump format [1].

Thanks


Bug: https://bugs.openjdk.java.net/browse/JDK-8170769
API: 
http://cr.openjdk.java.net/~vinnie/8170769/javadoc.05/api/java.base/java/util/Hex.html
Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.05/


[1] https://docs.oracle.com/cd/E86824_01/html/E54763/hexdump-1.html

RFR: jsr166 jdk integration 2018-05

[Martin Buchholz]

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
https://bugs.openjdk.java.net/browse/JDK-8202685

8201386: Miscellaneous changes imported from jsr166 CVS 2018-05
http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html
https://bugs.openjdk.java.net/browse/JDK-8201386

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

[Vincent Ryan]

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

These provide implementations only to generate the human-readable hexdump 
format. 
They are not designed to be customizable. Custom formats should be supplied via 
Hex.Formatter.


> 
> For me, toHexString and fromHexString are of course the most useful methods. 
> As for dump, I can only think of
> 
> 1. The existing sun.security.HexDumpEncoder format, when I want to dump a lot 
> of bytes as a block
> 2. "00:11:22:33:AA:BB:CC" which fits in one line and also easy to read, when 
> I want inline debugging output
> 
> If the customizable dump method is both powerful and simple enough to create 
> 2) above, I'll be happy. Otherwise, I can live with 
> toHexString().replaceAll("(..)(?=.)", "$1:”).

How about adding another toHexString method that takes a delimiter character?

> 
> Thanks
> Max
> 
>> On May 4, 2018, at 4:22 AM, Vincent Ryan  wrote:
>> 
>> Hello,
>> 
>> Please review this proposal for a new API to conveniently generate and 
>> display binary data using hex string representation.
>> It supports both bulk and stream operations and it can also generate the 
>> well-known hexdump format [1].
>> 
>> Thanks
>> 
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170769
>> API: 
>> http://cr.openjdk.java.net/~vinnie/8170769/javadoc.05/api/java.base/java/util/Hex.html
>> Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.05/
>> 
>> 
>> [1] https://docs.oracle.com/cd/E86824_01/html/E54763/hexdump-1.html
> 

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

[Vincent Ryan]

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 attempt to satisfy every custom format. Instead it provides 
some basic formatting methods
and functions from which a wide variety of custom formats can be constructed. 
Developers can also write their
own formatting functions to use with this class.

More comments in-line below.


> On 9 May 2018, at 16:20, Roger Riggs  wrote:
> 
> 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).

Yes adding support for additional charsets could be useful but it is a tradeoff 
against cluttering the API.
I think ASCII is sufficient for the common case.


> 
> - There is no API support for ByteBuffers, another common source of bytes, 
> that would make a good addition
>for completeness.  John Rose suggested a ByteSequence interface in the 
> context of file processing but
>that hasn't settled down.

Support for byte buffers was requested before and I suggested wrapping in an 
I/O stream.
Is that acceptable?


> 
> - The class name "Hex" might be a bit more evocative as HexDump or 
> HexConverter.

I tried to keep the class name short as many of its method names are long.


> 
> - Method names;  the "Hex" in method names might be unnecessary/redundant 
> since, as static methods,
>   they would frequently appear in code as "Hex.fromHexString" and a simple 
> "Hex.fromString" would be fine.
>   Ditto,  toHexString(bytes) -> toString(bytes)…

I agree the repetition is ugly. Shortening to fromString() and toString() is 
appealing except for the possible
confusion with Object.toString


> 
> - There are not many forms that allow the formatter to be supplied, for 
> example, dump(in, out) might be
>   a case where a formatter would be desired.

The 3 dump methods are just convenience functions around the stream generators. 
The dumpAsStream
methods are the expected entry points for customizers.


> 
> - Hex.Formatter interface could have a default method that provides the 
> default formatting or as
>   a static method so it can be used with a method reference.

Sure. What do you suggest?


> 
> - On the example in the class javadoc, I would use the implementation of the 
> default formatter with both hex and ascii
>   to show how that works.

Can you give me an example?


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


> 
> It looks quite good and very useful.
> 
> Thanks, Roger
> 
> On 5/8/2018 10:34 PM, 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 customizable.
>> 
>> For me, toHexString and fromHexString are of course the most useful methods. 
>> As for dump, I can only think of
>> 
>> 1. The existing sun.security.HexDumpEncoder format, when I want to dump a 
>> lot of bytes as a block
>> 2. "00:11:22:33:AA:BB:CC" which fits in one line and also easy to read, when 
>> I want inline debugging output
>> 
>> If the customizable dump method is both powerful and simple enough to create 
>> 2) above, I'll be happy. Otherwise, I can live with 
>> toHexString().replaceAll("(..)(?=.)", "$1:”).
>> 
>> Thanks
>> Max
>> 
>>> On May 4, 2018, at 4:22 AM, Vincent Ryan  wrote:
>>> 
>>> Hello,
>>> 
>>> Please review this proposal for a new API to conveniently generate and 
>>> display binary data using hex string representation.
>>> It supports both bulk and stream operations and it can also generate the 
>>> well-known hexdump format [1].
>>> 
>>> Thanks
>>> 
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170769
>>> API: 
>>> http://cr.openjdk.java.net/~vinnie/8170769/javadoc.05/api/java.base/java/util/Hex.html
>>> Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.05/
>>> 
>>> 
>>> [1] https://docs.oracle.com/cd/E86824_01/html/E54763/hexdump-1.html
> 

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

[Weijun Wang]

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

Still, I am not sure about all those methods taking InputStream as an input. 
Most likely I would use this class for debugging purpose, so any side effect 
(advancing inside an InputStream or ByteBuffer) might not be desirable. 

Another question, I just noticed that sun.security.HexDumpEncoder emits 
uppercase letters (ABCDEF) and your code emits lowercase letters. Do we need to 
provide user a choice here?

Thanks
Max

JEP 306 Question

[A Z]

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: RFR JDK-8200372 - String::trim JavaDoc should clarify meaning of space

[Stuart Marks]

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 character whose codepoint is less than or equal to
2605  * U+0020 (the space character).

It doesn't even need to be the code font.

Oh well, you pushed already. Maybe fix this up in your next change to 
String.java.

s'marks



On 5/8/18 6:43 AM, Roger Riggs wrote:

Hi Jim,

I would agree about code points in methods that refer to code points and need a 
more
precise notation.  However, trim() is not one of them and the alternative 0x 
format is quite acceptable.
Would the syntax for raw string literals (not there yet) make the source more 
readable?


Roger


On 5/8/2018 9:36 AM, Jim Laskey wrote:

Roger,

You withdrew the comment from the CSR so I assumed that you had changed your 
mind.


Stuart, Sherman and Joe have be pushing the use of codepoints versus char (or 
ASCII) in new character related comments hence the choice of ‘\u' 
notation. Unfortunately, unicode preprocessing vs backslash processing vs 
Javadoc does not allow the '\\u0020' in comments (it ends up being '\\u0020’ 
in the Javadoc) and '\u0020’ just ends up being ‘ ‘.


Cheers,

— Jim





On May 8, 2018, at 10:04 AM, Roger Riggs  wrote:

Hi Jim,

The use of \u005c in the source makes the source code unreadable.
The more conventional use of the 0x prefix (i.e. 0x0130) is preferred.
Though \u is necessary in some cases, it should be avoided where a more 
readable alternative is available.


Thanks, Roger


On 5/8/2018 8:19 AM, Jim Laskey wrote:

Comment change approved in CSR

webrev: http://cr.openjdk.java.net/~jlaskey/8200372/webrev/index.html
JBS: https://bugs.openjdk.java.net/browse/JDK-8200372
CSR: https://bugs.openjdk.java.net/browse/JDK-8196005

Should Java have a unit type?

[James Roper]

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 is used, however, void is not a type.

java.lang.Void exists as a placeholder class for use in reflection, but it
doesn't seem that it's meant to be used directly as a type.

In spite of this, java.lang.Void is used in some places in the JDK as a
type, for example, it's used by CompletionStage in methods such as
thenAccept to represent an operation that can complete or fail in future
but has no value:

https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html#thenAccept-java.util.function.Consumer-

Working with it in this way is a little clunky and counter intuitive, Void
is uninstantiable, so how can a CompletionStage ever be redeemed? The
answer is, it gets redeemed with null. Are null and void the same thing?
Apparently, according to this API, but they aren't really, null represents
the absence of a value that could exist, and is treated as such in APIs
like java.util.Optional, which is a different thing from no value.

Now perhaps the use of Void in this way by CompletionStage means the horse
has already bolted, and that now Void is a unit type with a singleton
instance represented by null, by default.

But in my opinion, it really isn't ideal. One issue is that it means any
API that uses Void types won't play well with other APIs that don't accept
nulls - a consequence of void and null being different things. A big one in
this case is Reactive Streams, onNext does not accept null, so if you
asynchronously map a reactive stream, and the asynchronous operation you do
returns CompletionStage (this is actually a common thing to do, eg,
if you're doing a sequence of operations, and the last one is a commit, it
is becoming common practice for asynchronous commit methods to return
CompletionStage), then you need to thenApply that CompletionStage to
some other non null unit type before you can emit it to the stream.

So it's my opinion that Java should have a unit type. This could be done by
promoting Void to a unit type, not just a placeholder type, and giving it a
singleton instance. That approach would mean existing uses of Void as a
unit type would be source compatible, and can migrate to using the instance
instead of null.

Another approach would be to introduce a new type, perhaps java.lang.Unit.
Both Scala and Kotlin have their own unit types, scala.Unit and kotlin.Unit
respectively. Akka did something a little more interesting, it has two unit
types, used to indicate two different intents, the first is NotUsed, which
is used to indicate that a type parameter has no significant meaning, and
the second is Done, which is used to indicate that a type parameter of this
type indicates that whatever it represents has been completed successfully
- this type is typically used in combination with CompletionStage, while
NotUsed might be used in place of Void in PrivelegedAction, as described
here:

https://docs.oracle.com/javase/8/docs/technotes/guides/security/doprivileged.html

Regards,

James

-- 
*James Roper*
*Senior Octonaut*

Lightbend  – Build reactive apps!
Twitter: @jroper 

Re: Should Java have a unit type?

[Brian Goetz]

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 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 is used, however, void is not a type.

java.lang.Void exists as a placeholder class for use in reflection, but it
doesn't seem that it's meant to be used directly as a type.

In spite of this, java.lang.Void is used in some places in the JDK as a
type, for example, it's used by CompletionStage in methods such as
thenAccept to represent an operation that can complete or fail in future
but has no value:

https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html#thenAccept-java.util.function.Consumer-

Working with it in this way is a little clunky and counter intuitive, Void
is uninstantiable, so how can a CompletionStage ever be redeemed? The
answer is, it gets redeemed with null. Are null and void the same thing?
Apparently, according to this API, but they aren't really, null represents
the absence of a value that could exist, and is treated as such in APIs
like java.util.Optional, which is a different thing from no value.

Now perhaps the use of Void in this way by CompletionStage means the horse
has already bolted, and that now Void is a unit type with a singleton
instance represented by null, by default.

But in my opinion, it really isn't ideal. One issue is that it means any
API that uses Void types won't play well with other APIs that don't accept
nulls - a consequence of void and null being different things. A big one in
this case is Reactive Streams, onNext does not accept null, so if you
asynchronously map a reactive stream, and the asynchronous operation you do
returns CompletionStage (this is actually a common thing to do, eg,
if you're doing a sequence of operations, and the last one is a commit, it
is becoming common practice for asynchronous commit methods to return
CompletionStage), then you need to thenApply that CompletionStage to
some other non null unit type before you can emit it to the stream.

So it's my opinion that Java should have a unit type. This could be done by
promoting Void to a unit type, not just a placeholder type, and giving it a
singleton instance. That approach would mean existing uses of Void as a
unit type would be source compatible, and can migrate to using the instance
instead of null.

Another approach would be to introduce a new type, perhaps java.lang.Unit.
Both Scala and Kotlin have their own unit types, scala.Unit and kotlin.Unit
respectively. Akka did something a little more interesting, it has two unit
types, used to indicate two different intents, the first is NotUsed, which
is used to indicate that a type parameter has no significant meaning, and
the second is Done, which is used to indicate that a type parameter of this
type indicates that whatever it represents has been completed successfully
- this type is typically used in combination with CompletionStage, while
NotUsed might be used in place of Void in PrivelegedAction, as described
here:

https://docs.oracle.com/javase/8/docs/technotes/guides/security/doprivileged.html

Regards,

James

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

[James Laskey]

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 is this string, with all leading
> 2603  * and trailing space removed, where space is defined
> 2604  * as any character whose codepoint is less than or equal to
> 2605  * U+0020 (the space character).
> 
> It doesn't even need to be the code font.
> 
> Oh well, you pushed already. Maybe fix this up in your next change to 
> String.java.
> 
> s'marks
> 
> 
> 
>> On 5/8/18 6:43 AM, Roger Riggs wrote:
>> Hi Jim,
>> I would agree about code points in methods that refer to code points and 
>> need a more
>> precise notation.  However, trim() is not one of them and the alternative 0x 
>> format is quite acceptable.
>> Would the syntax for raw string literals (not there yet) make the source 
>> more readable?
>> Roger
>>> On 5/8/2018 9:36 AM, Jim Laskey wrote:
>>> Roger,
>>> 
>>> You withdrew the comment from the CSR so I assumed that you had changed 
>>> your mind.
>>> 
>>> Stuart, Sherman and Joe have be pushing the use of codepoints versus char 
>>> (or ASCII) in new character related comments hence the choice of ‘\u' 
>>> notation. Unfortunately, unicode preprocessing vs backslash processing vs 
>>> Javadoc does not allow the '\\u0020' in comments (it ends up being 
>>> '\\u0020’ in the Javadoc) and '\u0020’ just ends up being ‘ ‘.
>>> 
>>> Cheers,
>>> 
>>> — Jim
>>> 
>>> 
>>> 
>>> 
 On May 8, 2018, at 10:04 AM, Roger Riggs  wrote:
 
 Hi Jim,
 
 The use of \u005c in the source makes the source code unreadable.
 The more conventional use of the 0x prefix (i.e. 0x0130) is preferred.
 Though \u is necessary in some cases, it should be avoided where a more 
 readable alternative is available.
 
 Thanks, Roger
 
 
> On 5/8/2018 8:19 AM, Jim Laskey wrote:
> Comment change approved in CSR
> 
> webrev: http://cr.openjdk.java.net/~jlaskey/8200372/webrev/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8200372
> CSR: https://bugs.openjdk.java.net/browse/JDK-8196005

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

[mandy chung]

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 delta-webrev for those that just want to see 
what has changed since last time.


Full webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/index.html

    Original webrev: 
http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v1/index.html
    Delta webrev: 
http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v2/index.html




I looked through the change and it looks fine to me.

Mandy