On Mon, 23 Jun 2025 20:14:36 GMT, Naoto Sato wrote:
> Fixing the side-effect caused by calling `StringTokenizer.nextToken(null)`,
> where the delimiter is set to `null` even if the method throws an NPE.
Thanks for the reviews!
-
PR Comment: https://git.openjdk.org/jdk/pull/25942#i
On Mon, 23 Jun 2025 21:21:44 GMT, ExE Boss wrote:
> Note that as mentioned in the bug discussion, the same also occurs when doing
> `new StringTokenizer("some string", (String) null)`.
Right, and it's super weird, but seems to have been specified since JDK 5 to
defer the NPE to later. I don't
On Mon, 23 Jun 2025 20:14:36 GMT, Naoto Sato wrote:
> Fixing the side-effect caused by calling `StringTokenizer.nextToken(null)`,
> where the delimiter is set to `null` even if the method throws an NPE.
Marked as reviewed by alanb (Reviewer).
-
PR Review: https://git.openjdk.org/j
On Mon, 23 Jun 2025 20:14:36 GMT, Naoto Sato wrote:
> Fixing the side-effect caused by calling `StringTokenizer.nextToken(null)`,
> where the delimiter is set to `null` even if the method throws an NPE.
Note that as mentioned in the bug discussion, the same also occurs when doing
`new StringTo
On Mon, 23 Jun 2025 20:14:36 GMT, Naoto Sato wrote:
> Fixing the side-effect caused by calling `StringTokenizer.nextToken(null)`,
> where the delimiter is set to `null` even if the method throws an NPE.
Indeed, looking at the spec, we would anticipate an exception means no change
has been comm
Fixing the side-effect caused by calling `StringTokenizer.nextToken(null)`,
where the delimiter is set to `null` even if the method throws an NPE.
-
Commit messages:
- initial commit
Changes: https://git.openjdk.org/jdk/pull/25942/files
Webrev: https://webrevs.openjdk.org/?repo=j
