Java record pattern matching in JDK 19

Re:Java record pattern matching in JDK 19 by papercrane on Saturday May 14, 2022 @01:05PM (#31379974)

The Typescript way would only work for local variables in Java. Since another thread might update a field between the instanceof check and the use of the field.

[ Parent | on HN ]

Re:Java record pattern matching in JDK 19 by peterkelly on Saturday May 14, 2022 @07:48PM (#31383842)

This is an issue in TypeScript even with single-threaded code; it (always/sometimes?) assumes function calls won't affect the results of type narrowing tests: https://github.com/microsoft/TypeScript/issues/9998

[ Parent | on HN ]

Re:Java record pattern matching in JDK 19 by zarzavat on Saturday May 14, 2022 @02:38PM (#31380943)

You’re definitely holding it wrong if you have polymorphic fields in your lock-free shared memory. Or at least holding it weirdly.

[ Parent | on HN ]

Re:Java record pattern matching in JDK 19 by gizmo686 on Saturday May 14, 2022 @02:43PM (#31380993)

Thats the problem with language design. If the language allows something, it needs to correctly support it; even if actually doing it is a bad idea.

[ Parent | on HN ]

Re:Java record pattern matching in JDK 19 by SemanticStrengh on Saturday May 14, 2022 @01:29PM (#31380262)

those cases are rare. Defensive copying should be optin, not the default. Java really deep copy objects for even the most basic instanceof checks??

[ Parent | on HN ]

Re:Java record pattern matching in JDK 19 by kaba0 on Saturday May 14, 2022 @02:48PM (#31381055)

You can’t change the object’s type in Java, so if you hold on to the same reference it will be safe to use after the instanceof check.

[ Parent | on HN ]