Re: RFR: 8202583: Remove experimental ClassForNamePlugin

+1 > On May 7, 2018, at 10:23 AM, Claes Redestad wrote: > > Hi, > > the --class-for-name jlink plugin was added as an experiment to test and > evolve the jlink plugin infrastructure. The actual effect of enabling this > plugin on standard images is very limited

RFR: JDK-8200436 - String::isBlank

New string instance method that returns true if the string is empty or contains only white space, where white space is defined as any codepoint returns true when passed to Character::isWhitespace. webrev: http://cr.openjdk.java.net/~jlaskey/8200436/webrev/index.html jbs:

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

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

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

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

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

\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

Re: RFR: JDK-8200380 String::lines

10:44 AM, Jim Laskey <james.las...@oracle.com> wrote: > > String::lines instance method that returns a Stream with elements > composed of substrings from the original string delimited by any recognized > new line character sequence. > > webrev: http://cr.openjdk.java.net/~

RFR: CSR JDK-8203630 Add instance method equivalents for String::format

csr: https://bugs.openjdk.java.net/browse/JDK-8203630

Re: RFR: JDK-8200380 String::lines

ll into > the Latin1 encoding. > The rest looks fine. > > Roger > > On 5/18/18 10:31 AM, Sundararajan Athijegannathan wrote: >> +1 >> >> I think LinesSpliterator classes in StringLatin1 and StringUTF8 could be >> "private" and "final&quo

RFR: CSR - JDK-8203428 Predicate::not

Introduce a new static method Predicate::not which will allow developers to negate predicate lambdas trivially. csr: https://bugs.openjdk.java.net/browse/JDK-8203428

RFR: JDK-8200380 String::lines

String::lines instance method that returns a Stream with elements composed of substrings from the original string delimited by any recognized new line character sequence. webrev: http://cr.openjdk.java.net/~jlaskey/8200380/webrev/index.html

Re: RFR: JDK-8200380 String::lines

it's > tempting to provide an abstract implementation with two concrete > implementation each providing their version of a getChar. Possibly not worth > it. > > Paul. > > >> On May 18, 2018, at 6:44 AM, Jim Laskey <james.las...@oracle.com> wrote: >>

Re: RFR: JDK-8200436 - String::isBlank

>>> Rémi >>>>> >>>>> - Mail original - >>>>>> De: "Louis Wasserman" <lowas...@google.com> >>>>>> À: "Xueming Shen" <xueming.s...@oracle.com> >>>>>> Cc: "cor

Re: RFR: CSR - JDK-8203428 Predicate::not

rian.go...@oracle.com> >> À: "Paul Sandoz" <paul.san...@oracle.com>, "Jim Laskey" >> <james.las...@oracle.com> >> Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net> >> Envoyé: Vendredi 18 Mai 2018 20:08:42 >> Objet:

Re: RFR: JDK-8200380 String::lines

le.com> wrote: > > On 5/18/18, 6:44 AM, Jim Laskey wrote: >> >> String::lines instance method that returns a Stream with elements >> composed of substrings from the original string delimited by any recognized >> new line character sequence. >> >> webrev:

Re: RFR: 8196990 :Resolve disabled warnings for libjli

traditionally there is a space after // simplify comment to something like (rest is redundant) // initialize to avoid -Werror=maybe-uninitialized issues from gcc 7.3 onwards. > On Jun 7, 2018, at 11:01 AM, Srinivas Dama wrote: > > Hi, > > Please review

Re: RFR JDK-8204229: Formatter and String.format ignore the width with the percent modifier (%5%)

+1 > On Jun 7, 2018, at 11:33 PM, Xueming Shen wrote: > > Hi, > > Please help review the change for JDK-8204229. It appears to be a overlook > in the implementation. We do have a method print(String, Locale) that adjust > the "padding spaces" > > issue:

Re: RFR: 8196990 :Resolve disabled warnings for libjli

+1 > On Jun 7, 2018, at 12:14 PM, Srinivas Dama wrote: > > Ok. Thank you Jim. > Please find revised webrev at > http://cr.openjdk.java.net/~sdama/8196990/webrev.01/. > > Regards, > Srinivas > > - Original Message - > From: james.las...@oracle.com > To: srinivas.d...@oracle.com,

Re: RFR: 8204967: Resolve disabled warnings for libunpack

Does -Wimplicit-fallthrough=3 work for gnu c and clang? unpack.cpp redundant comment 3713 // else fall through: +1 — Jim > On Jun 13, 2018, at 1:57 PM, Srinivas Dama wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8204967/webrev.00/ > for

RFR: JDK-8204172 Predicate::not should explicitly mention "NullPointerException - if target is null"

CSR: https://bugs.openjdk.java.net/browse/JDK-8204959 webrev: http://cr.openjdk.java.net/~jlaskey/8204172/webrev/index.html Thank you, — Jim

Re: RFR: 8204967: Resolve disabled warnings for libunpack

+1 > On Jun 15, 2018, at 1:45 AM, Srinivas Dama wrote: > > Hi Magnus/Jim, > > Thank you for the comments. > Here is the latest webrev with suggested changes: > webrev: http://cr.openjdk.java.net/~sdama/8204967/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8204967 > > Jim, > gnu

RFR: JDK-8050818 Predicate::not - provide an easier way to negate a predicate

Introduce a new static method Predicate::not which will allow developers to negate predicate lambdas trivially. webrev: http://cr.openjdk.java.net/~jlaskey/8050818/webrev/index.html bug: https://bugs.openjdk.java.net/browse/JDK-8050818 csr: https://bugs.openjdk.java.net/browse/JDK-8203428

Re: RFR JDK-8200530: '\r' is not supported as "newline" in java.util.jar.Manifest.

Attributes.java:380 nit - assign c at decl - only test len if decremented >> byte c; if ((c = lbuf[--len]) != '\n' && c != '\r') { throw new IOException("line too long"); } if (len > 0 && lbuf[len-1] == '\r') {

Re: RFR: 8197594 - String and character repeat

We’re going with the one instance method (Louis clinched it.) with recommended enhancements and not touching CharSequence. Working it up now. — Jim > On Feb 16, 2018, at 7:46 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 15/02/2018 17:20, Jim Laskey wrote: >> T

Re: RFR: 8196959: NullPointerException in discovery003.java

+1 > On Feb 14, 2018, at 1:24 AM, Srinivas Dama wrote: > > Jim, > > May I have second review for this thread in core-libs-dev group. > > Regards, > Srinivas > > - Forwarded Message - > From: sundararajan.athijegannat...@oracle.com > To:

RFR: 8197594 - String and character repeat

This is a pre-CSR code review [1] for String repeat methods (Enhancement). The proposal is to introduce four new methods; 1. public String repeat(final int count) 2. public static String repeat(final char ch, final int count) 3. public static String repeat(final int codepoint, final int count)

Re: RFR: 8197594 - String and character repeat

el > >> On Feb 15, 2018, at 9:20 AM, Jim Laskey <james.las...@oracle.com> wrote: >> >> This is a pre-CSR code review [1] for String repeat methods (Enhancement). >> >> The proposal is to introduce four new methods; >> >> 1. public String repeat(

Re: RFR: 8197594 - String and character repeat

Thank you Remi. Re final: Attila got into my head. > On Feb 15, 2018, at 4:24 PM, Remi Forax <fo...@univ-mlv.fr> wrote: > > - Mail original - >> De: "Ivan Gerasimov" <ivan.gerasi...@oracle.com> >> À: "Jim Laskey" <jame

Re: RFR: 8197594 - String and character repeat

; > if (Integer.MAX_VALUE / count < len) { > throw new IllegalArgumentException( > "Resulting string exceeds maximum string length: " + > ((long)len * (long)count)); > } > final int limit = count * len; Good. Tha

Re: RFR: 8197594 - String and character repeat

its use (methods expecting strings.) — Jim > > Rémi > > - Mail original - >> De: "Jim Laskey" <james.las...@oracle.com> >> À: "Brian Goetz" <brian.go...@oracle.com> >> Cc: "core-libs-dev" <core-libs-dev@openj

Re: RFR: 8197594 - String and character repeat

bs team. He can speak up if he wants. > > Don't make statements about count == Integer.MAX_VALUE / 2. > There is no point, unless it should throw IAE. > > On 2/15/2018 3:16 PM, Jim Laskey wrote: >>> On Feb 15, 2018, at 4:04 PM, Remi Forax <fo...@univ-mlv.fr

Re: RFR 8202922 Method reference identity is broken by serialization

+1 > On Jun 14, 2018, at 2:41 PM, Paul Sandoz wrote: > > Hi, > > Please review an update to the specifications of LambdaMetafactory and > SerializedLambda to clarify that the identity of function objects is > unpredictable. A similar (informational) clarification was made to the > language

RFR - CSR JDK-8200435 - String::align, String::indent (after revisions)

After further discussion, the API specs for these methods have been extensively reworked and the CSR moved back to Proposal stage. Please review https://bugs.openjdk.java.net/browse/JDK-8200435 Cheers, — Jim

RFR - JDK-8200434 - String::align, String::indent (code review)

Please review the code for String::align and String::indent at the link below. Notes: Includes a private version of String::isMultiline() which may be made into a public method at some future date Includes minor correctness clean up of StringLatin1.java, StringUTF16.java

Re: RFR - JDK-8200434 - String::align, String::indent (code review)

ent(0) depends on whether the string is > single-line or multi-line: In the former case it is unchanged, while in the > later case it gets a newline appended. > Moreover, if a multi-line string already ends with a new line, then a new > new-line is not appended, which seems inconsisten

Re: RFR JDK-8210394: (zipfs) jdk/nio/zipfs/ZFSTests.java rootdir.zip: The process cannot access the file because it is being used by another process

+1 > On Sep 5, 2018, at 12:38 PM, Xueming Shen wrote: > > Hi > > Please help review the change for JDK-8210394. > > issue: https://bugs.openjdk.java.net/browse/JDK-8210394 > webrev: http://cr.openjdk.java.net/~sherman/8210394/webrev > > It appears the "zipfile" for testing is opened with

Re: RFR - JDK-8200434 - String::align, String::indent (code review)

for for structure doesn't follow the style guide. Fixed, see updated webrev. > > > Thanks, Roger > > (Sorry for the duplicates, I missed core-libs the first time) > > On 8/29/18 10:00 AM, Jim Laskey wrote: >> Please review the code for String::align and String::i

Re: [11]RFR: 8198819: tools/jimage/JImageExtractTest.java, fails intermittently at testExtract (macos)

+1 > On Jul 4, 2018, at 8:25 AM, Srinivas Dama wrote: > > Hi, > > Please review > webrev: http://cr.openjdk.java.net/~sdama/8198819/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8198819 > > Modified test to work only on modules extracted using jimage instead of > considering

Re: [11] RFR: 8198405: JImageExtractTest.java & JImageListTest.java failed in Windows.

+1 > On Jul 5, 2018, at 2:42 PM, Srinivas Dama wrote: > > Hi, > > Please review > Webrev: http://cr.openjdk.java.net/~sdama/8198405/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8198405 > > Regards, > Srinivas

Re: RFR: CSR - JDK-8200435 String::align, String::indent (Preview)

llectively they are replaced by a single > space. > > Perhaps replace "All" with "Each". > > Regards, Roger > > On 7/6/2018 1:16 PM, Jim Laskey wrote: >> csr: https://bugs.openjdk.java.net/browse/JDK-8200435 >

RFR: CSR - JDK-8200435 String::align, String::indent (Preview)

csr: https://bugs.openjdk.java.net/browse/JDK-8200435

Re: Useless null check in HashMap.merge()

Just as a note, it is reasonable to make value “final” so that value can not be nulled out between the test and its use. Cheers, — Jim > On Jul 4, 2018, at 10:22 AM, Zheka Kozlov wrote: > > Oh yes, you are right. Then this is not dead code, just a useless null > check. > > 2018-07-04 19:55

Re: RFR: JDK-8197594: String#repeat

wer of 2 copying. >> >> >> 2978 * @throws IllegalArgumentException if the {@code count} is >> 2979 * negative. >> 2980 */ >> 2981 public String repeat(int count) { >> >> Missing @since11 on the method. >> >> >> Like

Re: RFR: JDK-8197594: String#repeat

Peter, Very reasonable and worth considering. The main reason the power of 2 copy works well is that the source is (almost) always cached. I thought about this a bit at the beginning and wondered about introducing Arrays.fill(T[] dst, T[] src) where dst is filled repeatedly from src. This can

Re: JDK-8197594: String#repeat

ters > where: > > +if (Integer.MAX_VALUE / count < len) { > +throw new OutOfMemoryError(); > +} > > „Repeating „ + len + „ bytes „ + count + „ times would produce a String > exceeding maximum size.“ > > Gruss > Bernd

Raw String Literal Library Support

With the announcement of JEP 326 Raw String Literals, we would like to open up a discussion with regards to RSL library support. Below are several implemented String methods that are believed to be appropriate. Please comment on those mentioned below including recommending alternate names or

Please review CSR : JDK-8200378 String#strip, String#stripLeading, String#stripTrailing

Please review and mark as reviewed https://bugs.openjdk.java.net/browse/JDK-8200378

Please review CSR : JDK-8200373 String#trim JavaDoc should clarify meaning of space

Please review and mark as reviewed https://bugs.openjdk.java.net/browse/JDK-8200373

Please review CSR : JDK-8200437 String#isBlank

Please review and mark as reviewed https://bugs.openjdk.java.net/browse/JDK-8200437

Please review CSR : JDK-8200425 String#lines

Please review and mark as reviewed https://bugs.openjdk.java.net/browse/JDK-8200425

Re: Raw String Literal Library Support

asy enough to create custom trim margin lambdas. D. Escape management. - Good Cheers, — Jim > On Mar 13, 2018, at 10:47 AM, Jim Laskey <james.las...@oracle.com> wrote: > > With the announcement of JEP 326 Raw String Literals, we would like to open > up a discussion with re

Re: Raw String Literal Library Support

One more change set. trimIndent -> stripIndent trimMarkers -> stripMarkers > On Mar 20, 2018, at 10:35 AM, Jim Laskey <james.las...@oracle.com> wrote: > > Summary. > > A. Line support. > > - Supporting a mix of line terminators `\n|\r\n|\r` is alre

Re: RFR: JDK-8197594: String#repeat

; limit - copied; copied <<= 1) { > System.arraycopy(multiple, 0, multiple, copied, copied); > } > > (didn't actually run it to check for correctness.) > > With kind regards, > Ivan > > > On 2/28/18 8:31 AM, Jim Laskey wrote: >> Introduction of a

RFR: JDK-8197594: String#repeat

Introduction of a new instance method String::repeat to allow an efficient and concise approach for generating repeated character sequences as strings. Performance information in JBS. Thank you. Cheers, — Jim JBS: https://bugs.openjdk.java.net/browse/JDK-8197594

RFR: JDK-8198955 - String#repeat loop optimization

Verified to work on edge cases. JBS: https://bugs.openjdk.java.net/browse/JDK-8198955 Webrev: http://cr.openjdk.java.net/~jlaskey/8198955/webrev/index.html

Please review CSR: JDK-8200435 String::stripIndent, String::stripMarkers

Please review and mark as reviewed https://bugs.openjdk.java.net/browse/JDK-8200435

Re: RFR: 8212726: Replace some use of drop- and foldArguments with filtering argument combinator in StringConcatFactory

Thank you for doing this. The MethodHandle changes will simplify many a use case. Cheers, — Jim > On Oct 22, 2018, at 6:58 AM, Claes Redestad wrote: > > Hi, > > StringConcatFactory uses a customized internal foldArguments > implementation which takes positional arguments to avoid

RFR: JDK-8212694 - Using Raw String Literals with align() and Integer.MIN_VALUE causes out of memory error

This fix proper clips large negative values for n. webrev: http://cr.openjdk.java.net/~jlaskey/8212694/webrev-00/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8212694

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

updated webrev: http://cr.openjdk.java.net/~jlaskey/8203442/webrev-02/index.html <http://cr.openjdk.java.net/~jlaskey/8203442/webrev-02/index.html> > On Sep 21, 2018, at 7:42 AM, Remi Forax wrote: > > - Mail original - >> De: "Alan Bateman" >

Re: RFR - JDK-8203703 String::transform (CSR Review)

parse); Not a strong argument. Along with Remi’s request for primitive variants, I might be lead back to just supporting String. Cheers, — Jim > On Sep 19, 2018, at 10:25 AM, Stephen Colebourne wrote: > > On Tue, 18 Sep 2018 at 18:57, Jim Laskey wrote: >> >> Please

Re: RFR - JDK-8202442 - String::unescape (Code Review)

gt; Not sure if that's an intent or not. > > Jan > > On 18.9.2018 20:55, Jim Laskey wrote: >> The intent, of course, is to offset the raw string literals non-translation >> of Unicode escapes and escape sequences. That is, have the multi-line cake >>

Re: RFR - JDK-8210718 String::detab, String::entab (CSR Review)

gt; In the exceptions, a typo: "less that equals” Updated. > > In entab(), the "replaces some space characters... spacing aligns" seems a > bit vague. > (I don't want to read the code to have a precise understanding.) Will reword and post an update. > > Thanks,

Re: RFR - JDK-8202442 - String::unescape (Code Review)

Will do. > On Sep 19, 2018, at 11:42 AM, Jonathan Gibbons > wrote: > > If you're making the change, then you might add a test case based on Jan's > suggestion, testing > > "\u005ct".equals(`\u005ct`.unescape()) > > -- Jon > > > On 9/19/1

Re: RFR - JDK-8210717 String::detab, String::entab (Code Review)

webrev updated http://cr.openjdk.java.net/~jlaskey/8210717/webrev-01/index.html <http://cr.openjdk.java.net/~jlaskey/8210717/webrev-01/index.html> > On Sep 19, 2018, at 9:35 AM, Jim Laskey wrote: > > Thank you. Updated. > >> On Sep 19, 2018, at 4:20 AM, An

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

updated webrev: http://cr.openjdk.java.net/~jlaskey/8203442/webrev-01/index.html <http://cr.openjdk.java.net/~jlaskey/8203442/webrev-01/index.html> > On Sep 19, 2018, at 10:35 AM, Jim Laskey wrote: > >> On Sep 19, 2018, at 9:58 AM, Remi Forax wrote: >> >

Re: RFR - JDK-8202442 - String::unescape (Code Review)

"during decoding (or unescaping)" sounds better to me. > > Naoto > > On 9/18/18 10:51 AM, Jim Laskey wrote: >> Please review the code for String::unescape. Used to translate escape >> sequences in a string, typically in a raw string literal, into characters >&

Re: RFR - JDK-8210717 String::detab, String::entab (Code Review)

> > 3029 * @throws IllegalArgumentException if n is less that equals to zero. > > I would write it as: if n is less than or equals to zero. > > Best regards, > Andrej Golovnin > On Tue, Sep 18, 2018 at 7:53 PM Jim Laskey wrote: >> >> Please review the code for String::

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

ethod(…) which applies static R method(T fakeThis, …), but that will take years of debate. String::transform was intended to facilitate custom manipulation (alignment) of raw string literals, in the most string generalized way. I’ll discuss the other variants but please provide better use cases. Che

Re: RFR - JDK-8202442 - String::unescape (Code Review)

> On Sep 19, 2018, at 7:21 PM, Stuart Marks wrote: > > > > On 9/18/18 10:51 AM, Jim Laskey wrote: >> Please review the code for String::unescape. Used to translate escape >> sequences in a string, typically in a raw string literal, into characters >

Re: RFR - JDK-8210717 String::detab, String::entab (Code Review)

Caught that. Thx. > On Sep 19, 2018, at 5:12 PM, Jonathan Gibbons > wrote: > > It should really be "if n is less than or equal to zero" (equal, not equals) > > -- Jon > > > On 09/19/2018 05:35 AM, Jim Laskey wrote: >> Thank you. Updated. >>

Re: RFR - JDK-8202442 - String::unescape (Code Review)

Modified as per Stuart's suggestion. > On Sep 20, 2018, at 7:45 AM, Chris Hegarty wrote: > > >> On 19 Sep 2018, at 23:21, Stuart Marks wrote: >> >> ... >> >> 2979 * Each unicode escape in the form \u is translated to the >> 2980 * unicode character whose code point is {@code

Re: RFR - JDK-8202442 - String::unescape (Code Review)

revised webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev-02/index.html > On Sep 19, 2018, at 11:57 AM, Jim Laskey wrote: > > Will do. > > >> On Sep 19, 2018, at 11:42 AM, Jonathan Gibbons >> wrote: >> >> If you're making the change, then y

RFR - JDK-8215682 - Remove compiler support for Raw String Literals from JDK 12

Looking for reviewers to make sure this CSR passes muster. CSR: https://bugs.openjdk.java.net/browse/JDK-8215682 Thank you. Cheers, — Jim

RFR - CSR JDK-8215499 - String::indent inconsistency with blank lines

Please review CSR: https://bugs.openjdk.java.net/browse/JDK-8215499 Thank you. — Jim

RFR - CSR JDK-8215490 Remove String::align

CSR: https://bugs.openjdk.java.net/browse/JDK-8215490 Thank you. Cheers, — Jim JBS: https://bugs.openjdk.java.net/browse/JDK-8215489 webrev:

Re: RFR 8171426 : java/lang/ProcessBuilder/Basic.java failed with Stream closed

+1 > On Dec 3, 2018, at 5:45 PM, Roger Riggs wrote: > > Ping? > > On 11/27/2018 02:04 PM, Roger Riggs wrote: >> Please review a test update to address an intermittent test failure. >> The test is modified to accept the current implementation behavior of the >> input streams >> from processes

Re: RFR 8214971 : Replace use of string.equals("") with isEmpty()

I assume you automated this change, might be worthwhile to automate a verification (compare the -+ pairs.) Eyeballing the patch it seems complete, one comment changed as well. Question: Is it probably that vm optimizes .equals(“”) to .isEmpty() and there is no net win, ie., more of an esthetic

RFR - JDK-8215489 Remove String::align

Please review the removal of String::align from JDK12. Thank you. — Jim webrev: http://cr.openjdk.java.net/~jlaskey/8215489/webrev/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8215489

Re: RFR - JDK-8202442 - String::unescape (Code Review)

Revised to break up long exception statements; webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev-01/index.html > On Sep 18, 2018, at 3:03 PM, Jim Laskey wrote: > > Do you mean the throws specifically? If so, of course. > > > >> On Sep 18, 2018, at 2:

Re: RFR - JDK-8202442 - String::unescape (Code Review)

te string escape sequences in terms of Unicode escapes. > > I'm not suggesting you should do the same here, but you should be aware of > the difference, compared to javac behavior. > > -- Jon > > > On 9/18/18 10:51 AM, Jim Laskey wrote: >> Please review the code for S

RFR - JDK-8202442 - String::unescape (Code Review)

Please review the code for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes. webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html jbs:

RFR - JDK-8210717 String::detab, String::entab (Code Review)

Please review the code for String::detab and String::entab. Used to expand tabs into spaces, and spaces back to tabs. webrev: http://cr.openjdk.java.net/~jlaskey/8210717/webrev/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8210717 csr: https://bugs.openjdk.java.net/browse/JDK-8210718

RFR - JDK-8210718 String::detab, String::entab (CSR Review)

Please review the API for String::detab and String::entab. Used to expand tabs into spaces, and spaces back to tabs. csr: https://bugs.openjdk.java.net/browse/JDK-8210718 jbs: https://bugs.openjdk.java.net/browse/JDK-8210717 Cheers, — Jim

Re: RFR - JDK-8202442 - String::unescape (Code Review)

Do you mean the throws specifically? If so, of course. > On Sep 18, 2018, at 2:51 PM, Jim Laskey wrote: > > Please review the code for String::unescape. Used to translate escape > sequences in a string, typically in a raw string literal, into characters > represented b

RFR - JDK-8203703 String::transform (CSR Review)

Please review the API for String::transform. The goal is to provide a String instance method to allow function application of custom transformations applied to an instance of String. csr: https://bugs.openjdk.java.net/browse/JDK-8203703 jbs: https://bugs.openjdk.java.net/browse/JDK-8203442

RFR - JDK-8202443 - String::unescape (CSR Review)

Please review the API for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes. We decided to simplify the interface to the basics, i.e., translate all escape sequences. No reciprocating method since

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

Please review the code for String::transform. The goal is to provide a String instance method to allow function application of custom transformations applied to an instance of String. webrev: http://cr.openjdk.java.net/~jlaskey/8203442/webrev/index.html jbs:

RFR - JDK-8215493 String::indent inconsistency with blank lines

Please review these changes for jdk 12. webrev: http://cr.openjdk.java.net/~jlaskey/8215493/webrev/index.html There is inconsistency with regards to blank lines and indentation. Adding indent space ignores blank lines, where

RFR - 8212975 - ClassDesc should have a full name method

Please review the webrev below. Though generally useful for debugging ClassDesc (or using Class::forName), ClassDesc::fullDisplayName allows compiler devs to use a ClassDesc directly to optimally add classes to the symbol table. Past: ClassDesc cd = ... String className =

Re: RFR: 8222484: Specialize generation of simple String concatenation expressions

The StringConcatHelper::valueOf really should be StringConcatHelper::stringOf to clarify the result. Use here is unlike String::valueOf context where the result is logically String. StringConcatHelper::mix comments really should describe the encoding. If does a lot of handwaving re checking

Re: JDK 13 RFR of JDK-8224783: Javadoc of String strip methods uses link where linkplain would be better

+1 > On May 24, 2019, at 10:15 PM, Joe Darcy wrote: > > Hello, > > Please review the patch below to address: > > JDK-8224783: Javadoc of String strip methods uses link where linkplain > would be better > > Thanks, > > -Joe > > diff -r 4947a097db60

Re: RFR (CSR) - JDK-8223776 String::stripIndent (Preview)

miter should influence the indentation of the > content as a whole -- a "significant trailing line" policy.)" > > I think the corresponding portion of the JavaDoc is good. > > Thanks, > -Brent > > On 5/24/19 5:17 AM, Jim Laskey wrote: >> Please do a

Re: RFR 8216553: JrtFIleSystemProvider getPath(URI) omits /modules element from file path

+1 > On May 27, 2019, at 6:18 AM, Sundararajan Athijegannathan > wrote: > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216553 > Webrev: https://cr.openjdk.java.net/~sundar/8216553/webrev.00/ > > Thanks, > -Sundar > >

RFR: Revert: 8216553: JrtFileSystemProvider getPath(URI) omits /modules element from file path

Please review. Need to revert a change Sundar did earlier today that is causing 33 tier2 failures. Cheers, -- Jim Reverse webrev: http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html JBS:

Re: RFR: Revert: 8216553: JrtFileSystemProvider getPath(URI) omits /modules element from file path

Thank you. > On May 28, 2019, at 4:44 PM, Joe Darcy wrote: > > If this is a straight backport of the previous change, I approve the revision. > > Cheers, > > -Joe > > On 5/28/2019 12:39 PM, Jim Laskey wrote: >> Please review. Need to revert

Re: RFR: Revert: 8216553: JrtFileSystemProvider getPath(URI) omits /modules element from file path

Thank you. > On May 28, 2019, at 4:46 PM, Kim Barrett wrote: > > On May 28, 2019, at 3:39 PM, Jim Laskey wrote: >> >> Please review. Need to revert a change Sundar did earlier today that is >> causing 33 tier2 failures. >> >> Cheers, >&g

Re: RFR: 8224986: (str) optimize StringBuilder.append(CharSequence, int, int) for String arguments

+1 > On May 29, 2019, at 12:36 PM, Claes Redestad > wrote: > > Hi, > > it's been pointed out[1] that append(string.substring(start, end)) can > outperform append(string, start, end) in some circumstances. In part due > the former being intrinsified, but also I think due it tickling some >

Re: RFR 8216553: JrtFIleSystemProvider getPath(URI) omits /modules element from file path

+1 > On May 28, 2019, at 6:48 AM, Sundararajan Athijegannathan > wrote: > > Updated for java test failures: > > https://cr.openjdk.java.net/~sundar/8216553/webrev.01/ > > PS. Test framework used wrong jrt: URI pattern. Fixed it. > > -Sundar > > On 27/05/19, 5:37 PM, Alan Bateman wrote: >>

Re: RFR - JDK-8223780 String::translateEscapes (Preview)

tps://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/util/regex/Pattern.html#sum > > <https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/util/regex/Pattern.html#sum> > With kind regards, > > Ivan > > > On 5/21/19 12:24 PM, Jim Laskey

RFR: JDK-8225448 String::translateEscapes javadoc has accessibility issues

Please review these changes. A table in the javadoc for String::translateEscapes was missing some tags. Thank you. Cheers, -- Jim webrev: http://cr.openjdk.java.net/~jlaskey/8225448/webrev-01/index.html jbs:

  1   2   3   4   5   6   >