Pattern Matching in Java - Past, Present, Future

[@prdoyle]

The first half hour covers a lot of material we already knew. A few points of interest that are perhaps less well-known: 12:08 - If the condition is negated, the scope of the pattern variable is the "else" block. 25:38 - Synthesized default case that throws MatchException. The future arrives starting at 32:45 38:35 - Primitive pattern matching safeguards based on value ranges 42:06 - Potential future features 46:15 - Deconstruction of classes 49:20 - Reconstruction of records 50:15 - Reconstruction of classes 51:25 - New serialization

[@haroldpepete]

great talk sr, it really greafull see how java has been improving in a solid manner, thanks again, you did a great job

[@ZeroUm_]

Hopefully we will get a for(var k, v : map) someday.

[@julianjupiter5890]

And for (var (id, name) : users), where User is a record.

[@Ewig_Luftenglanz]

But isn't it just syntax sugar for for(var entry: map.entryset)? I supposed se it would be a nice to have tho, we already can do map.stream().forEach( (k, v) -> ...);

[@freebusdoctor]

LETS GO

[@claudemartin5907]

will they ever change that nightmarish background image?

[@nisonatic]

They'd better not, I've developed a whole industrial process that depends on it to horrify the one guy who does all the work in case he's slacking.

[@ianbrown8408]

Am I the only one who expected “Pattern Matching in Java” to at least mention Pattern() or Matcher()? Co-opting the well established use of the words pattern and matcher to mean something completely different in one language is crazy. This is going to make Java more confusing from now to the end of Java’s days. If they want to call it shape matching, or data matching fine. Just don’t call it pattern matching - that is already taken and these new features have nothing to do with it. Searching on the terms -java pattern match- is going to be a mess giving results for completely different ideas.

[@greatso9018]

Verbosity is something Java is already mocked for, so adding the concept of deconstructor is odd to me. Wasn't it possible to have a syntax like : case MyClass {fieldName, fieldNameThatIsAnArray[index], fieldNameThatIsARecord(type,type) } -> ....

[@VuLinhAssassin]

Yes, I like the concept of with object { field } more

[@sjzara]

One thing Java is praised for is readability. That’s far more important than conciseness.

[@prdoyle]

Records are already quite concise in this way. It's harder for general classes. Once they get the semantics worked out (with deconstructors) they could follow up with improved syntax.

[@adambickford8720]

@@sjzara This is a false dichotomy

[@Ewig_Luftenglanz]

IMHO deconstruction is going to be easier and mostly be used with records. Records have many features (thanks to it's more restrictive nature and more specification rules) that make Deconstruction not only more convenient there but also easier to implement. For starters records only have one constructor so there is only one "deconstructor" and this deconstructors is implicitly given "for free" (just as hashCode, to string, equals and so on) that's why we have records deconstruction in pattern matching (what they call record patterns) Another festure records' have is that records' field names are part of the record specification, so things like nominal parameters (with defaults) and even nominal destructuring (very like what JavaScript/typescript already do) is far easier to implement and use in records than anywhere else in the language. I wouldn't be surprised is most of these festires arrive to records first and then to classes (if ever) developing festires about records it's almost like coding only thinking in the happy case, because most of wrong cases and variants tha would make hard the development are straight up ilegal in records