Tales from the jar side: Game 7s, Lazy Suppliers, Good Tweets, and Yet even more Bangles content
How many mystery writers does it take to screw in a lightbulb? Two. One to screw it in most of the way, and the other to give it a surprise twist at the end
Welcome, fellow jarheads, to Tales from the jar side, the Kousen IT newsletter, for the week of May 8 - May 15, 2022. This week I taught the Introduction to the Gradle Build Tool course for Gradle, Inc, and gave lots of talks at the NFJS event in Des Moines, Iowa.
Regular readers of this newsletter are affectionately known as jarheads, and are far more intelligent, sophisticated, and attractive than the average newsletter reader. If you wish to become a jarhead, please subscribe using this button:
As a reminder, this message is truncated in email, click on the title at the top to open it in a browser tab formatted properly for both the web and mobile.
NBA Update
The last two weeks I started each newsletter with a comment about how Steph Curry, the Greatest Free Throw Shooter in NBA History, did in his most recent playoff game. I didn’t plan for that to become a regular feature of this newsletter, but here we are. For the record, on Wednesday, the Golden State Warriors got crushed by the Memphis Grizzlies by about 40 points, after being behind by as much as 55 (!). Since the game was a complete disaster, Steph was pulled from the game early, and only finished 3 of 4 from the free throw line.
On Friday, the Warriors finally remembered how to play basketball again. They closed out the series with a win, sending them to the Western Conference Finals that start this week. Ironically, Steph once again went 3 for 4 on his free throws. This tendency to miss at least one free throw a game is troubling, but I’ll live with it as long as they keep winning.
I don’t know who the Warriors will be playing next, because today (Sunday) there are two Game 7s: Milwaukee vs Boston in the East (update/spoiler: Boston), and Dallas vs Phoenix in the West. The media likes to call “Game 7” the greatest two words in sports, but unfortunately it brings up a problematic memory for me.
Back when I was at MIT in the early 1980s and dinosaurs roamed the Earth, I was a Philadelphia 76ers fan, mostly because of Julius Erving. Their biggest rival at the time was the Boston Celtics. One year the two teams were incredibly evenly matched. They were getting ready to play Game 7 of the Eastern Conference finals, and we had a crowd of guys surrounding our small TV in the lounge in my dorm, when another student (call him Steve, because that was his name) who knew nothing about sports walked in. He asked what was going on.
We explained how the two teams had fought a brutal series, and that not only had all six of the previous games been decided by 5 points or less, but that each team had scored almost the same number of total points across the series. There followed this conversation:
Steve: If that’s true, why are you bothering to watch?
Us: What are you talking about?
Steve: There’s no statistically significant difference between these two teams. The winner will be decided purely by chance. It’s completely random.
I’m forced to admit that:
He was right, and
We let him live, but it as a near thing.
So enjoy your Game 7s today, which will obviously be won by the team that “wants it more,” or “rises to the occasion,” or “knows how to win,” or “plays well in the clutch,” or by any reason other than some lucky bounce along the way. Grr.
Lazy Suppliers
I spent Friday and Saturday giving 10 talks (!) at the NFJS event in Des Moines, IA, as well as the keynote. All but two of those talks were technical. (The others were my Help Your Boss Help You talk, about managing your manager, and my Mental Bookmarks and the Fractal Nature of Success talk). I feel, therefore, that I ought to say at least something about the technical content, so here are a few words about the java.util.function.Supplier
interface in Java and how it is often used for lazy evaluation of expensive objects.
As usual, if you’re not into that sort of thing, feel free to skip this section.
The Javadocs define the Supplier<T> interface as a supplier of results, which is true but a nearly useless description. Supplier
is a functional interface, which means it contains a single abstract method:
T get()
The method takes no arguments and returns a reference to an object. To see one place suppliers are used, consider the assertTrue
method in JUnit 5. Here are the available overloads:
The first one checks the boolean and returns the default error message if it’s false. The other two are the ones I care about here. The second one takes an additional argument of type String
, and returns that message if the boolean argument is false. The last one takes a Supplier<String>
, and, as the docs say, “If necessary, the failure message will be retrieved lazily from the supplied messageSupplier
.”
What does that mean? Here are two tests, one for each of the two-argument versions:
When you run the first test, the getErrorMessage
method is invoked even though the test passes. That’s normal Java. Whenever you call a method, all of its arguments are evaluated, so of course it calls getErrorMessage
.
In the second one, however, the argument is a Supplier<String>
, implemented using a lambda expression. The lambda is compatible with the Supplier
interface because it takes no arguments and returns a String
, like the get
method in the interface. To use the Supplier
version, all I had to do was to add parentheses and an arrow in front of the method call.
That difference, however, is everything. Now the second argument is an object, rather than just a method call. If you drill into the JUnit code for assertTrue, you’ll (eventually) find:
if (!condition) {
fail(buildPrefix(nullSafeGet(messageSupplier)) +
EXPECTED_TRUE, true, false);
}
In other words, if the boolean is true, just return. Only if the boolean is false does the code call nullSafeGet
on the supplier.
When you run them, the first test calls the getErrorMessage
method, and the second does not. That’s lazy loading, and is one of the primary usages of suppliers in Java. You’ll find them in several places in the API, like:
The logging methods in
java.util.logging.Logger
, where you’ll find methods likeinfo(String)
andinfo(Supplier<String>)
. The latter only creates the log message if the log level means it will be seen, andIn
java.util.Optional
, where you’ll findorElse(T)
andorElseGet(Supplier<T>)
. The second one only creates the default if theOptional
is empty.
Suppliers are quite useful for this sort of deferred execution.
Our Software Symposium
On an unrelated note, relevant to a bit I included a couple newsletters ago, at lunch one day at the conference we had the following conversation:
Raju: What’s the actual name of this conference? It’s not NFJS Des Moines. Is it Central Iowa Software Conference?
Jay Zimmerman (organizer): Central Iowa Software Symposium.
Me: Right, because the word conference isn’t nearly pretentious enough.
Jay: (Launches into a long explanation of why the NFJS events are called software symposia, which I tuned out after about 15 seconds because it didn’t change anything for me at all. I’d include it here, but, as I said, I stopped paying attention. Sorry.)
Just thought you might like to know.
Miscellaneous
That Day Again
This from Susanna Hoffs (see below for yet even more Bangles content):
The Abyss
Another great cartoon from Tom Gault:
Machine Learning, AI, and All That
That hits uncomfortably close to home.
Posted Without Comment
Gender Reveal
I have to admit I don’t quite get this, but it cracked up my wife:
Um, yeah?
Yet Even More Bangles
Another running item that I never intended to become a thing here is that in the last two newsletters, I’ve included a video from The Bangles. Two weeks ago, it was Manic Monday. These days, when listening to the lyrics, I have a different reaction to them than when I was younger.
Specifically, there’s this section:
He tells me in his bedroom voice
C'mon honey, let's go make some noise
Maybe I’m getting old, but I wonder if all they did was run the vacuum cleaner to freak out the dog. I mean, come on, it’s Monday, and as she admitted on Twitter, Saturday is actually her fun day. Monday is also not Wednesday, which as we established a few newsletters ago, is Business Time.
(Note: last time I included a link to the live version of Business Time. To my considerable astonishment, there’s actually an official video, which I’d never seen:
I’m not sure whether or not I like it better. Let me know what you think.)
Last newsletter I included the Bangles video for Eternal Flame, which was (and is) awesome. But as a wise man once said, some people want to fill the world with silly love songs. What’s wrong with that? I’d like to know. Cause here I go again:
That’s not actually a love song, and it’s also a cover, but I still like it. I have to admit, though, after checking out the lyrics, I still have no idea what this song is about. Nice harmonies, though.
As a reminder, you can see all my upcoming training courses on the O’Reilly Learning Platform here and all the upcoming NFJS Virtual Workshops here.
Last week:
Introduction to the Gradle Build Tool, online for Gradle, Inc
Central Iowa Software Symposium, the NFJS event in Des Moines, IA.
This week:
Next Generation Java Testing with JUnit 5, on the O’Reilly Learning Platform
Reactive Spring and Spring Boot, also same