Sometimes we write something for the book, only to realize it shouldn’t be in the book. This post is an example. Do you think this legal?
public sealed interface MySealedClass permits MyRecord, MyEnum {
}
record MyRecord() implements MySealedClass {}
enum MyEnum implements MySealedClass { VALUE }
It is! A sealed interface can be implemented by any Java type. Which means records and enums are included.
Jeanne and I over the moon to announce the release of our new OCP Java 17 Developer Complete Study Guide! This book is the culmination of years of knowledge that we’ve accumulated writing study guides for Java. It is for anyone who wants to expand their knowledge of Java, or who wants to pass Oracle’s new Java SE 17 Developer 1Z0-829 exam and become a Java 17 Oracle Certified Professional.
Lambdas and streams? Covered! Concurrency, JDBC, and NIO.2? Covered! New Java 17 switch expressions, records, sealed classes, pattern matching? Definitely covered! Modules? Ok, we don’t use them much either, but they are covered for the exam! It’s great for those who are familiar with Java, but want to acquire a deeper understanding of the language. Learn features of the language that will help you write better code!
Our Java 17 book is a streamlined version of our previous books, including all of the new material and changes that you need to know for the exam. Previously, we wrote one book for each of the two exams. Starting with Java 17, there’s only one exam, allowing us to cover the material in a much more concise and straight-forward manner. Put simply, it weighs less than our previous Complete Study Guide!
Want to win a free copy? Our home away from home, CodeRanch, will be running a book promotion next week starting on May 10th!
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,
Style.SHORT);
var longCNF = NumberFormat.getCompactNumberInstance(Locale.US,
Style.LONG);
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,
Style.SHORT);
var longCNF = NumberFormat.getCompactNumberInstance(Locale.US,
Style.LONG);
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:
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!)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!