[devnexus 2022] pattern matching for Java

Speaker: Neha Sardana

Twitter: @nehasardana09

Link to table of contents



<missed this part; I was late>

Sealed class

  • Want to control children
  • More declarative than access modifiers
  • Can make widely accessible interface without widely extensible
  • Sets stage for pattern matching.

Pattern Matching

  • Pattern matching created in 1960s
  • Helps with clean code, avoiding repetition/bugs


  • matches target object to type pattern
  • sets binding variable – special case of local variables, can be assigned, can shadow field declarations
  • flow scoping – places in program where variable definitely assigned

Switch expressions

  • Limitations on switch/case are accidents of history.
  • Java 17 preview allows pattern matching in case
  • Java 19 – write ”when” instead of && in case
  • Can assign result if all cases covered. (enums and sealed classes can be listed exhaustively


  • Record patterns (deconstrution patterns). ex if (r instanceof Rectangle (Point ul, Point lr))
  • Can also deconstruct arrays

My take

I thought this topic woud be fully review, but I still learned something (“when”). It was great to see Neha’s first public in person presentation! Good job!

[devnexus 2022] the new excitement about the good old java

Speaker: Venkat Subramanium

Twitter: @venkat_s

Link to table of contents



  • Java is a passport to the world – spoke at 50 user groups in hoor of turnig 50
  • Celebrated Paris JUG’s anniversary in Eifflel Tower
  • Ukrainian flag slide


  • good to say that, now talk about what do
  • Hates word – Scrum-master – Agile Manifesto does’t say SM
  • Love ceremony and rituals
  • Easy to hide from what really do
  • Also hates word velocity – sustainable and producing results is what matter
  • TDD – ticket driven development
  • Agile is really feedack driven development
  • Cost of failure low if train leaves every 30 minutes vs plannig a flight


  • Java now evololving faster
  • Java 8 was game changer because of streams
  • “Java late to party but came with amazing desserts”
  • Releases used to be slow because targeted features to releases. Not agile. Want to adapt plan to reality
  • ”When will project loom be ready?” ”When it is ready”
  • Java is not being developed on a 6 month release cycle. It is being released on a 6 month cycle
  • People ask questions about feature while still remember writing it
  • Can learn and adopt technologies as they come out vs all at once
  • Less ceremony/redundancy

Live coding

  • pattern matching with if – smart casting
  • switch expression
  • pattern matching with switch including conditions
  • multi-line string with smart indentation (incidental whitespace
  • sealed interface – use but don’t implement

My take

I don’t think I learned anything new, but Venkat is an entertaining and engaging speaker, so that’s fine! Good coverage of the new Java features in live coding

Java CompactNumberFormat Bug or Feature?

Java 12 introduced a new CompactNumberFormat class, which anyone studying for the new Java 17 1Z0-829 OCP certification should know. It’s really cool utility feature, helping to shorten lengthy number values into shorter forms for common usage. It supports a Style setting, SHORT (1M) vs LONG (1 million), as well as rounding, and many other features. Generally speaking, it rounds the value to the first human-readable 3-digit tuple, formats it, and then adds a label depending on style/locale.

Let’s take a look at an example:

var shortCNF = NumberFormat.getCompactNumberInstance(Locale.US,
var longCNF = NumberFormat.getCompactNumberInstance(Locale.US,
System.out.print(shortCNF.format(15_300));          // 15K
System.out.print(longCNF.format(15_300));           // 15 thousand
System.out.print(shortCNF.format(124_000_200));     // 124M
System.out.print(longCNF.format(124_000_200));      // 124 million
System.out.print(shortCNF.format(4_834_000_000.0)); // 5B
System.out.print(longCNF.format(4_834_000_000.0));  // 5 billion

Useful stuff, right? Notice the last two examples rounded the value up to 5 bllion? Rounding (which can be disabled) is enabled by default. Well, while writing some really tricky practice exam questions for our upcoming Java OCP 17 Practice Test Book, I discovered something rather odd:

var shortCNF = NumberFormat.getCompactNumberInstance(Locale.US,
var longCNF = NumberFormat.getCompactNumberInstance(Locale.US,
System.out.print(shortCNF.format(999_999));   // 1000K (this is weird)
System.out.print(longCNF.format(999_999));    // 1000 thousand (this is weird)
System.out.print(shortCNF.format(1_000_000)); // 1M
System.out.print(longCNF.format(1_000_000));  // 1 million
System.out.print(shortCNF.format(1_999_999)); // 2M
System.out.print(longCNF.format(1_999_999));  // 2 million

Notice the issue? If the CompactNumberFormat rounds up and enters a new range (thousand to million, million to billion, etc), it doesn’t adjust the labels or values. The first two sets of values should print 1M and 1 million, but the rounded value prints 1000K and 1000 thousand instead. While I used Locale.US for reproducibility, this isn’t required. It appears when you use other locales, and other ranges. For instance, 999_999_999 formats as 1000M, instead of 1B. I validated on Oracle’s latest release of Java 17.0.2.

So.. is this a bug or a feature? It partially depends how you read the unicode spec the Java feature was based on. The spec covers formatting rules and order of operation, but it doesn’t provide as much insight on how rounding is supposed to be handled in this particular situation.

I believe this is a bug because:

  • No one would ever expect (or want) to see one million written as 1000 thousand or 1000K. If you saw that on a website or mobile app, you’d likely report it as a bug. (If you’re a developer using this feature, you would probably then be told to stop using this library altogether!)
  • If it is working as designed, then the spec has a problem. The only work-around for someone who wants to use CompactNumberFormat without encountering this issue is to either disable rounding, or round the value ahead of time. In either situation, the utility of using the CompactNumberFormat feature drops precipitously.

To me, it’s a bug…. or a feature that renders CompactNumberFormat not suitable for practical use. With that in mind, I opened a bug ticket JDK-8281317 with Oracle to address the issue. I will update this page when I get a response!

Side note: On February 6, I created a Twitter poll and interestingly enough the correct answer of 1000K was the least selected option! Certainly, not an intuitive implementation!