Re: RFR: 8329948: Remove string template feature [v5]

2024-04-11 Thread Jim Laskey
On Thu, 11 Apr 2024 10:15:54 GMT, Maurizio Cimadamore wrote: >> This PR removes support for the string template feature from the Java >> compiler and the Java SE API, as discussed here: >> >> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html > > Maurizio Cimadamore

Re: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using wrong test [v4]

2024-03-09 Thread Jim Laskey
The class is used in java.lang.invoke.MethodType but add is not used.  > On Mar 9, 2024, at 11:42 AM, Chen Liang wrote: > > On Tue, 5 Mar 2024 20:23:56 GMT, Jim Laskey wrote: > >>> Currently, add is returning intern(e) == null which will always be false. >>>

Integrated: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using wrong test

2024-03-06 Thread Jim Laskey
On Tue, 6 Feb 2024 12:52:15 GMT, Jim Laskey wrote: > Currently, add is returning intern(e) == null which will always be false. The > correct test is intern(e) == e , that is, true when element is newly added. This pull request has now been integrated. Changeset: a7461de2 Author: Jim

Re: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using wrong test [v3]

2024-03-05 Thread Jim Laskey
On Sun, 11 Feb 2024 17:41:14 GMT, ExE Boss wrote: >> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update ReferencedKeyTest.java > > src/java.base/share/classes/jdk/internal/util/ReferencedK

Re: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using wrong test [v4]

2024-03-05 Thread Jim Laskey
> Currently, add is returning intern(e) == null which will always be false. The > correct test is intern(e) == e , that is, true when element is newly added. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Fix ReferencedKeySe

Re: RFR: 8310351: Typo in ImmutableCollections

2024-02-25 Thread Jim Laskey
On Sun, 25 Feb 2024 08:13:08 GMT, Korov wrote: > Fix the @param name Marked as reviewed by jlaskey (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/17996#pullrequestreview-1899627681

Re: RFR: 8325730: StringBuilder.toString allocation for the empty String

2024-02-20 Thread Jim Laskey
On Tue, 20 Feb 2024 16:32:54 GMT, Claes Redestad wrote: > JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured > StringBuilder/StringBuffer::toString returns `""` when the builders are empty. > > > Name Cnt Base Error Test Error

Re: CFV: New Core Libraries Group Member: Raffaello Giulietti

2024-02-13 Thread Jim Laskey
Vote: yes  > On Feb 13, 2024, at 4:25 PM, Brian Burkhalter > wrote: > > I hereby nominate Raffaello Giulietti to Membership in the Core Libraries > Group. > > Raffaello has been working in the Core Library team at Oracle since April, > 2022. He has authored more than 50 contributions to

Re: RFR: 8325679: Optimize ArrayList subList sort

2024-02-12 Thread Jim Laskey
On Mon, 12 Feb 2024 22:52:51 GMT, Attila Szegedi wrote: > Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will > thus fall back to slower default method of `List.sort()` instead of sorting a > range of the array in-place in its backing root `ArrayList`. > > This

Re: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using wrong test [v2]

2024-02-06 Thread Jim Laskey
On Tue, 6 Feb 2024 18:29:17 GMT, Chen Liang wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains two addi

Re: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using wrong test [v3]

2024-02-06 Thread Jim Laskey
> Currently, add is returning intern(e) == null which will always be false. The > correct test is intern(e) == e , that is, true when element is newly added. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

Re: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using wrong test [v2]

2024-02-06 Thread Jim Laskey
> Currently, add is returning intern(e) == null which will always be false. The > correct test is intern(e) == e , that is, true when element is newly added. Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unr

RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using wrong test

2024-02-06 Thread Jim Laskey
Currently, add is returning intern(e) == null which will always be false. The correct test is intern(e) == e , that is, true when element is newly added. - Commit messages: - Correct test Changes: https://git.openjdk.org/jdk/pull/17732/files Webrev:

Re: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may be shared [v10]

2024-02-05 Thread Jim Laskey
On Mon, 5 Feb 2024 16:38:59 GMT, Roger Riggs wrote: >> Good catch. Your solution might be correct but I think `!contains(e)` is >> redundant since that is how intern starts out. >> >> >>static T intern(ReferencedKeyMap> setMap, T key, >> UnaryOperator interner) { >> T value =

Re: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may be shared [v10]

2024-02-05 Thread Jim Laskey
On Sat, 3 Feb 2024 07:20:14 GMT, ExE Boss wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 17 commits: >> >> - Merge branch 'master' into 8310913 >> - Update implNote for int

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v14]

2024-01-29 Thread Jim Laskey
> Currently String::translateEscapes does not support unicode escapes, reported > as a IllegalArgumentException("Invalid escape sequence: ..."). > String::translateEscapes should translate unicode escape sequences to provide > full coverage, Jim Laskey has up

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v13]

2024-01-29 Thread Jim Laskey
On Fri, 26 Jan 2024 17:36:52 GMT, Jim Laskey wrote: >> Currently String::translateEscapes does not support unicode escapes, >> reported as a IllegalArgumentException("Invalid escape sequence: ..."). >> String::translateEscapes should translate unicode escape s

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v12]

2024-01-26 Thread Jim Laskey
On Fri, 26 Jan 2024 16:54:14 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains 12 addi

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v13]

2024-01-26 Thread Jim Laskey
> Currently String::translateEscapes does not support unicode escapes, reported > as a IllegalArgumentException("Invalid escape sequence: ..."). > String::translateEscapes should translate unicode escape sequences to provide > full coverage, Jim Laskey has up

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v12]

2024-01-26 Thread Jim Laskey
> Currently String::translateEscapes does not support unicode escapes, reported > as a IllegalArgumentException("Invalid escape sequence: ..."). > String::translateEscapes should translate unicode escape sequences to provide > full coverage, Jim Laskey has updated the p

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v11]

2024-01-26 Thread Jim Laskey
> Currently String::translateEscapes does not support unicode escapes, reported > as a IllegalArgumentException("Invalid escape sequence: ..."). > String::translateEscapes should translate unicode escape sequences to provide > full coverage, Jim Laskey has up

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v10]

2024-01-26 Thread Jim Laskey
> Currently String::translateEscapes does not support unicode escapes, reported > as a IllegalArgumentException("Invalid escape sequence: ..."). > String::translateEscapes should translate unicode escape sequences to provide > full coverage, Jim Laskey has up

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v7]

2024-01-26 Thread Jim Laskey
On Fri, 19 Jan 2024 18:28:22 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update Copyright > > test/jdk/java/lang/String/TranslateEscapes.java line 113: &g

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v8]

2024-01-26 Thread Jim Laskey
On Tue, 23 Jan 2024 21:41:54 GMT, Naoto Sato wrote: >> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Requested changes > > src/java.base/share/classes/java/lang/String.java line 4229: > &

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v9]

2024-01-26 Thread Jim Laskey
On Fri, 26 Jan 2024 08:38:32 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update String.java > > src/java.base/share/classes/java/lang/String.java line 4238: >

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v7]

2024-01-26 Thread Jim Laskey
On Fri, 19 Jan 2024 18:27:24 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update Copyright > > test/jdk/java/lang/String/TranslateEscapes.java line 1

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v6]

2024-01-26 Thread Jim Laskey
On Fri, 19 Jan 2024 17:39:57 GMT, Raffaello Giulietti wrote: >> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update copyright year of test > > test/jdk/java/lang/String/TranslateEscapes

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v9]

2024-01-24 Thread Jim Laskey
> Currently String::translateEscapes does not support unicode escapes, reported > as a IllegalArgumentException("Invalid escape sequence: ..."). > String::translateEscapes should translate unicode escape sequences to provide > full coverage, Jim Laskey has up

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v8]

2024-01-23 Thread Jim Laskey
> Currently String::translateEscapes does not support unicode escapes, reported > as a IllegalArgumentException("Invalid escape sequence: ..."). > String::translateEscapes should translate unicode escape sequences to provide > full coverage, Jim Laskey has up

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v7]

2024-01-19 Thread Jim Laskey
> Currently String::translateEscapes does not support unicode escapes, reported > as a IllegalArgumentException("Invalid escape sequence: ..."). > String::translateEscapes should translate unicode escape sequences to provide > full coverage, Jim Laskey has up

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v6]

2024-01-19 Thread Jim Laskey
> Currently String::translateEscapes does not support unicode escapes, reported > as a IllegalArgumentException("Invalid escape sequence: ..."). > String::translateEscapes should translate unicode escape sequences to provide > full coverage, Jim Laskey has up

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v5]

2024-01-19 Thread Jim Laskey
> Currently String::translateEscapes does not support unicode escapes, reported > as a IllegalArgumentException("Invalid escape sequence: ..."). > String::translateEscapes should translate unicode escape sequences to provide > full coverage, Jim Laskey has up

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v4]

2024-01-19 Thread Jim Laskey
> Currently String::translateEscapes does not support unicode escapes, reported > as a IllegalArgumentException("Invalid escape sequence: ..."). > String::translateEscapes should translate unicode escape sequences to provide > full coverage, Jim Laskey has up

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v3]

2024-01-19 Thread Jim Laskey
> Currently String::translateEscapes does not support unicode escapes, reported > as a IllegalArgumentException("Invalid escape sequence: ..."). > String::translateEscapes should translate unicode escape sequences to provide > full coverage, Jim Laskey has up

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v2]

2024-01-18 Thread Jim Laskey
> Currently String::translateEscapes does not support unicode escapes, reported > as a IllegalArgumentException("Invalid escape sequence: ..."). > String::translateEscapes should translate unicode escape sequences to provide > full coverage, Jim Laskey has up

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes

2024-01-18 Thread Jim Laskey
On Thu, 18 Jan 2024 19:25:28 GMT, Raffaello Giulietti wrote: >> Currently String::translateEscapes does not support unicode escapes, >> reported as a IllegalArgumentException("Invalid escape sequence: ..."). >> String::translateEscapes should translate unicode escape sequences to >> provide

RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes

2024-01-18 Thread Jim Laskey
Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage, - Commit messages: - Unicode escape sequences

Re: RFR: 8159927: Add a test to verify JMOD files created in the images do not have debug symbols

2024-01-18 Thread Jim Laskey
On Wed, 17 Jan 2024 20:51:23 GMT, Mandy Chung wrote: > The build excludes the native debug symbols in JMOD files created for JDK > modules (see make/CreateJmods.gmk). This PR adds a test to verify that > native debug symbols are excluded as expected. LGTM - Marked as reviewed

[jdk22] Integrated: 8322512: StringBuffer.repeat does not work correctly after toString() was called

2024-01-17 Thread Jim Laskey
On Wed, 17 Jan 2024 14:21:22 GMT, Jim Laskey wrote: > The new repeat methods were not clearing the toStringCache. This pull request has now been integrated. Changeset: 60c68a13 Author: Jim Laskey URL: https://git.openjdk.org/jdk22/commit/60c68a13639fe79cc2510d551b8c1c7d7e1a0

Re: [jdk22] RFR: 8322512: StringBuffer.repeat does not work correctly after toString() was called [v2]

2024-01-17 Thread Jim Laskey
> The new repeat methods were not clearing the toStringCache. Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits si

[jdk22] RFR: 8322512: StringBuffer.repeat does not work correctly after toString() was called

2024-01-17 Thread Jim Laskey
The new repeat methods were not clearing the toStringCache. - Commit messages: - Backport df22fb322e6c4c9931a770bd0abf4c43b83c4e4a Changes: https://git.openjdk.org/jdk22/pull/87/files Webrev: https://webrevs.openjdk.org/?repo=jdk22=87=00 Issue:

Re: RFR: 8323794: Remove unused jimage compressor plugin configuration [v2]

2024-01-16 Thread Jim Laskey
On Tue, 16 Jan 2024 18:03:34 GMT, Claes Redestad wrote: >> There's an unused concept of a pluginConfig that is passed into the jlink >> compress plugins, however we always pass null here and the code seems broken >> (the pluginConfig wouldn't have been stored properly). This seem to be a >>

Re: RFR: 8323794: Remove unused jimage compressor plugin configuration

2024-01-16 Thread Jim Laskey
On Tue, 16 Jan 2024 10:55:07 GMT, Claes Redestad wrote: > There's an unused concept of a pluginConfig that is passed into the jlink > compress plugins, however we always pass null here and the code seems broken > (the pluginConfig wouldn't have been stored properly). This seem to be a >

Re: [jdk22] RFR: 8310995: missing @since tags in 36 jdk.dynalink classes

2024-01-10 Thread Jim Laskey
On Wed, 10 Jan 2024 06:32:54 GMT, Athijegannathan Sundararajan wrote: > backported from jdk mainline "as is" without any modifications. Marked as reviewed by jlaskey (Reviewer). - PR Review: https://git.openjdk.org/jdk22/pull/49#pullrequestreview-1812872031

Re: RFR: 8310995: missing @since tags in 36 jdk.dynalink classes

2024-01-08 Thread Jim Laskey
On Mon, 8 Jan 2024 13:24:55 GMT, Athijegannathan Sundararajan wrote: > Adding missing "@ since 9" in javadoc comment of the public classes, > interfaces and packages of the jdk.dynalink module. LGTM - Marked as reviewed by jlaskey (Reviewer). PR Review:

Integrated: JDK-8322512 StringBuffer.repeat does not work correctly after toString() was called

2024-01-04 Thread Jim Laskey
On Wed, 20 Dec 2023 20:25:07 GMT, Jim Laskey wrote: > The new repeat methods were not clearing the toStringCache. This pull request has now been integrated. Changeset: df22fb32 Author: Jim Laskey URL: https://git.openjdk.org/jdk/commit/df22fb322e6c4c9931a770bd0abf4c43b83c4e4a St

Re: RFR: JDK-8322512 StringBuffer.repeat does not work correctly after toString() was called [v2]

2024-01-04 Thread Jim Laskey
On Thu, 21 Dec 2023 07:55:50 GMT, Jaikiran Pai wrote: >> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Clear sooner > > test/jdk/java/lang/StringBuilder/StringBufferRepeat.java line 138: >

Re: RFR: JDK-8322512 StringBuffer.repeat does not work correctly after toString() was called [v4]

2024-01-04 Thread Jim Laskey
> The new repeat methods were not clearing the toStringCache. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Nit in test - Changes: - all: https://git.openjdk.org/jdk/pull/17172/files - new: https://git.openjdk.

Re: RFR: JDK-8322512 StringBuffer.repeat does not work correctly after toString() was called [v3]

2024-01-04 Thread Jim Laskey
> The new repeat methods were not clearing the toStringCache. Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits si

Re: RFR: JDK-8322512 StringBuffer.repeat does not work correctly after toString() was called [v2]

2023-12-20 Thread Jim Laskey
On Wed, 20 Dec 2023 21:52:40 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Clear sooner > > src/java.base/share/classes/java/lang/StringBuffer.java line 719: >

Re: RFR: JDK-8322512 StringBuffer.repeat does not work correctly after toString() was called [v2]

2023-12-20 Thread Jim Laskey
> The new repeat methods were not clearing the toStringCache. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Clear sooner - Changes: - all: https://git.openjdk.org/jdk/pull/17172/files - new: https://git.openjdk.

RFR: JDK-8322512 StringBuffer.repeat does not work correctly after toString() was called

2023-12-20 Thread Jim Laskey
The new repeat methods were not clearing the toStringCache. - Commit messages: - Clear toStringCache when calling StringBuffer::repeat Changes: https://git.openjdk.org/jdk/pull/17172/files Webrev: https://webrevs.openjdk.org/?repo=jdk=17172=00 Issue:

Integrated: JDK-8320570 NegativeArraySizeException decoding >1G UTF8 bytes with non-ascii characters

2023-12-06 Thread Jim Laskey
On Tue, 5 Dec 2023 14:57:09 GMT, Jim Laskey wrote: > A regression is found in Java9+ creating String instance from UTF8 bytes, a > side effect of string compactation https://openjdk.org/jeps/254 that changed > the decoding logic. Specifically, when constructing a string f

Re: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8 bytes with non-ascii characters [v5]

2023-12-06 Thread Jim Laskey
it succeeded when jvm heap size is set to be sufficient. Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the l

Re: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8 bytes with non-ascii characters [v4]

2023-12-06 Thread Jim Laskey
it succeeded when jvm heap size is set to be sufficient. Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: - Alternate 64 bit test - Exclude 32 bit - Changes: - all: https://git.openjdk.org/jdk/pull/16974/files - new:

Re: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8 bytes with non-ascii characters [v2]

2023-12-06 Thread Jim Laskey
On Tue, 5 Dec 2023 20:44:54 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Bump up memory >> - Cotrrect NegativeSize.java > > test/jdk/java/lang/String/Com

Re: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8 bytes with non-ascii characters [v3]

2023-12-06 Thread Jim Laskey
it succeeded when jvm heap size is set to be sufficient. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Requested changes - Changes: - all: https://git.openjdk.org/jdk/pull/16974/files - new: https://git.openjdk.org/

Re: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8 bytes with non-ascii characters [v2]

2023-12-05 Thread Jim Laskey
On Tue, 5 Dec 2023 19:42:43 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Bump up memory >> - Cotrrect NegativeSize.java > > test/jdk/java/lang/String/Com

Re: RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8 bytes with non-ascii characters [v2]

2023-12-05 Thread Jim Laskey
it succeeded when jvm heap size is set to be sufficient. Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: - Bump up memory - Cotrrect NegativeSize.java - Changes: - all: https://git.openjdk.org/jdk/pull/16974/files - new:

RFR: JDK-8320570 NegativeArraySizeException decoding >1G UTF8 bytes with non-ascii characters

2023-12-05 Thread Jim Laskey
A regression is found in Java9+ creating String instance from UTF8 bytes, a side effect of string compactation https://openjdk.org/jeps/254 that changed the decoding logic. Specifically, when constructing a string from bytes: ``` String str = new String(largeBytes, StandardCharsets.UTF_8);

Re: RFR: 8321114: Rename "Unnamed Classes" to "Implicitly Declared Classes" better [v2]

2023-12-01 Thread Jim Laskey
On Fri, 1 Dec 2023 11:22:33 GMT, Pavel Rappo wrote: >> Please review this PR to correctly rename "Unnamed Class" to "Implicitly >> Declared Class", not "Implicit Class". >> >> Renaming is fixed where it affects documentation or the end-user. Renaming >> is not fixed where it only affects

Re: RFR: 8321114: Rename "Unnamed Classes" to "Implicitly Declared Classes" better

2023-11-30 Thread Jim Laskey
On Thu, 30 Nov 2023 15:00:00 GMT, Pavel Rappo wrote: > Please review this PR to correctly rename "Unnamed Class" to "Implicitly > Declared Class", not "Implicit Class". > > Renaming is fixed where it affects documentation or the end-user. Renaming is > not fixed where it only affects code:

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v44]

2023-11-30 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Integrated: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview)

2023-11-30 Thread Jim Laskey
On Wed, 1 Nov 2023 18:56:13 GMT, Jim Laskey wrote: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed cla

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v43]

2023-11-30 Thread Jim Laskey
On Wed, 29 Nov 2023 20:07:50 GMT, Joe Darcy wrote: >> Jim Laskey has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Update test/jdk/tools/launcher/InstanceMainTest.java >> >>Co-au

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v43]

2023-11-29 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v42]

2023-11-29 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v41]

2023-11-28 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v36]

2023-11-28 Thread Jim Laskey
On Tue, 28 Nov 2023 15:51:37 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 40 commits: >> >> - Merge remote-tracking branch 'upstream/master' into 8315458

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v36]

2023-11-28 Thread Jim Laskey
On Tue, 28 Nov 2023 14:43:36 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 40 commits: >> >> - Merge remote-tracking branch 'upstream/master' into 8315458

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v40]

2023-11-28 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v39]

2023-11-28 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v35]

2023-11-28 Thread Jim Laskey
On Mon, 27 Nov 2023 23:46:00 GMT, Joe Darcy wrote: >> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Requested changes > > test/langtools/tools/javac/ImplicitClass/TestImplicitClass.

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v38]

2023-11-28 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v37]

2023-11-28 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v36]

2023-11-28 Thread Jim Laskey
On Tue, 28 Nov 2023 14:15:48 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 40 commits: >> >> - Merge remote-tracking branch 'upstream/master' into 8315458

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v36]

2023-11-28 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v35]

2023-11-24 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v34]

2023-11-24 Thread Jim Laskey
On Fri, 24 Nov 2023 11:00:18 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove Test > > src/java.base/share/classes/java/lang/Class.java line 4797: > >>

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v34]

2023-11-23 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v33]

2023-11-23 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v32]

2023-11-22 Thread Jim Laskey
On Wed, 22 Nov 2023 15:29:08 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annota

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v32]

2023-11-22 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v31]

2023-11-21 Thread Jim Laskey
On Tue, 21 Nov 2023 19:16:06 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update Class.java > > src/java.base/share/classes/java/lang/Class.java line 4823:

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v31]

2023-11-21 Thread Jim Laskey
On Tue, 21 Nov 2023 17:52:49 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annota

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v31]

2023-11-21 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v19]

2023-11-21 Thread Jim Laskey
On Tue, 21 Nov 2023 10:38:36 GMT, Pavel Rappo wrote: >> Look at the spec https://bugs.openjdk.org/browse/JDK-8319252 under 7.3 >> Compilation Units. >> >> - It is not abstract (8.1.1.1 ⇗). >> - It is final (8.1.1.2 ⇗). >> - It is a member of an unnamed package (7.4.2 ⇗) and **has package

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v30]

2023-11-20 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v26]

2023-11-20 Thread Jim Laskey
On Mon, 20 Nov 2023 13:56:13 GMT, Christian Stein wrote: >> src/java.base/share/classes/java/lang/Class.java line 4839: >> >>> 4837: @PreviewFeature(feature=PreviewFeature.Feature.IMPLICIT_CLASSES) >>> 4838: @CallerSensitive >>> 4839: public Method getMainMethod() { >> >> This is a

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v29]

2023-11-20 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v21]

2023-11-20 Thread Jim Laskey
On Mon, 20 Nov 2023 11:55:57 GMT, Maurizio Cimadamore wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 464: >> >>> 462: } >>> 463: for (Symbol sym = s.owner; sym != null; sym = sym.owner) { >>> 464: if (sym.kind == TYP && sym.name ==

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v28]

2023-11-20 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v27]

2023-11-20 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v26]

2023-11-19 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v25]

2023-11-19 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v24]

2023-11-18 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v23]

2023-11-18 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v22]

2023-11-18 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Re: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v21]

2023-11-17 Thread Jim Laskey
> Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim

Integrated: JDK-8315457 Implement JEP 459: String Templates (Second Preview)

2023-11-17 Thread Jim Laskey
On Mon, 16 Oct 2023 13:41:55 GMT, Jim Laskey wrote: > Update String Templates for a second preview. With the addition of > > - Expression type and throws are determined from the `process` method of the > processor type and not the processor type. > > - Qualified `STR` and

  1   2   3   4   5   6   >