Tales from the jar side: Groovy 4, Gradle, and Spock, A Grails Foundation honor, A CAP design pattern disaster, Some corrections, and Attempts to take the moral high ground
What's the difference between a literalist and a kleptomaniac? A literalist takes things literally. A kleptomaniac takes things, literally.
Welcome, fellow jarheads, to Tales from the jar side, the Kousen IT newsletter, for the week of January 23 - 30, 2022. This week I taught my Deep Dive into Spring course and my Spring MVC course, both as No Fluff Just Stuff virtual workshops.
If you wish to become a jarhead, subscribe using this button:
Whenever my newsletter becomes too long for email (like this week), you can see the full version online. If you miss an issue, the entire archive is there as well, and everything is free.
Groovy 4 Released
Here’s the tweet from Paul King announcing the release of Groovy 4:
My regular practice when there is a new version of Groovy is to update my IntroGroovy GitHub repository. This time I also took that opportunity to switch from using the groovy-all jar file to only the modules I need, which is something I’ve been planning to do for some time. While I was at it, I decided to take advantage of Gradle’s ability to work with a Maven BOM (bill of materials), so I could specify the version number only once.
Here’s that part of my Gradle build file:
Note the switch in the coordinates for Groovy from org.codehaus.groovy (which went away a while ago) to the new Apache-based ones, org.apache.groovy. That’s a good thing, but is going to be quite a transition over the next couple of years. Still, it didn’t cause me any problems. You can also see from the file that I’m following a recommendation from the excellent Marcin Zajączkowski (more about him in a moment) to exclude that group from the Spock dependency.
I had to fix some imports (mostly replacing the imports of groovy.util.XmlSlurper with groovy.xml.XmlSlurper and similar package changes), but it all compiled eventually. I haven’t tried the new features yet, which are documented in the release notes for Groovy 4.
My build compiled, but, as often happens, the Spock testing framework caused another problem. Unlike frameworks like Gradle, which bundle in a version of Groovy to power them, Spock is built using each specific version of Groovy and has releases for each one. There’s no distribution yet for Groovy 4. I could just wait for that, I guess, but I was hoping for a work-around. When I commented on that, Paul King himself replied:
Seriously, that’s the name of the flag. :) It’s actually called spock.iKnowWhatImDoing.disableGroovyVersionCheck. The problem was how to set that flag in the build file. Tim Yates, who is my first reference for anything coding-related, suggested this:
That’s definitely the right way to set a system property in Gradle, but it didn’t fix my problem, because apparently the version check occurs before the Groovy compilation stage. It turns out that the aforementioned Marcin dealt with that problem before and wrote about it in this article.
His suggestion was to add this to the Gradle build:
Fortunately, that works. Unfortunately, my project also includes tests that execute some included Groovy scripts, and they use a GroovyShell to do it. The scripts themselves contain assert statements, so simply by executing them, I know if they’re right or not. The tests are like this:
That has nothing to do with Spock, but for some reason those tests trigger the same incompatible versions error. I have no idea why, though I suspect it’s because they’re spawning a separate JVM and the flag isn’t being carried through to it. Those tests are therefore failing at the moment. I’ll probably have to contact Marcin directly to see how I can fix that, too.
An Unexpected Honor
This tweet came out on Friday:
Here’s a link to the Grails Foundation website. The Grails Foundation is a non-profit organization “that exists to support and collectively lead the open source Grails project.” Regarding the Technology Advisory Board:
The Grails Foundation is supported by a Technology Advisory Board that ensures the Framework continues to reflect and serve its diverse and growing user community. The Board meets quarterly to discuss and make recommendations regarding the Grails framework's roadmap and technical direction.
I really am honored to be a new member, and am looking forward to seeing exactly what that involves and how I can help Grails be more successful in the future.
Since everything has a story behind it, let me say this much. Jeff Scott Brown is a long-time friend, a former NFJS speaker, and one of the founders of the Grails framework, as well as a partner at Object Computing, Inc., which supports both Groovy and Grails financially. Jeff contacted me a couple weeks ago and said he wanted to talk.
Of all the developers associated with Grails, Jeff is probably the most involved in the business aspects of the ecosystem. He’s a great guy, but my experience with him is that whenever he “wants to talk,” it usually means:
He’s going to ask me to do something.
It’s going to be really interesting and I’m going to want to do it.
I’m probably going to wind up committing to yet another project I don’t have time for.
I therefore accepted his meeting invite with a bit of trepidation. As it turned out, he just wanted to invite me to be a member of the TAC of the Grails Foundation, which he promised (he promised — you heard it here first) would not be too much of a time sink.
As usual, what he asked me to do is interesting and I really do want to do it. I’ll see how much time and energy it ultimately takes. But seriously, this is a great honor and I’m flattered to be asked at all.
A Couple of Minor Corrections
My subscriber list has grown to the point where when I make mistakes in the newsletter, somebody tells me about it. So far all the replies have been very kind, which is in keeping with the well-established fact that jarheads are simply smarter, more sophisticated, and all-around better people than your average newsletter reader. No doubt better looking, too, but that probably goes without saying.
One of the errors I made was very simple. I referred to a blog post called My first impressions of web3 by Moxie Marlinspike, and managed to get the author’s name wrong even though I was looking right at it when I added a link to his Twitter account. Oops. In the wildly unlikely event he actually reads this newsletter, sorry about that.
The next one is a tiny typo: I expanded NFT as Non-Functional Token rather than Non-Fungible Token. I blame the fact that I also discussed my Functional Programming in Java, Groovy, and Kotlin talk in the same issue and I must have had functional on the brain. Oops again. I trust that didn’t throw anybody off.
I know there’s a joke in there somewhere about getting together an Ocean’s 11 type of crew and saying, “you know all those Non-Fungible Tokens? Well, boys, we’re going to funge them!” I just haven’t found the right wording yet.
Finally, I made a much more subtle error. Here’s the tweet that identified it:
Hadi Hariri is a developer advocate for JetBrains, so he cares about issues like that. The confusing part is that Google includes Compose as part of their Jetpack Components library, while JetBrains simply refers to Compose for Desktop (which I got right from the linked web page) as part of Compose Multiplatform. Heck, the subtitle on that page is “Fast reactive desktop UIs for Kotlin, based on Google's modern toolkit and brought to you by JetBrains,” with the link to Google’s Jetpack Compose docs and everything.
Yeah, okay, I get the motivation to keep the branding separate and that there are no doubt copyright and trademark issues involved, but honestly, good luck with that. I’ll do my best to keep them straight when I talk about them, but that’s definitely an uphill battle.
CAP Design Pattern Failure
One of the most successful software development books of all time came out in 1995. It’s called Design Patterns: Elements of Reusable Object-Oriented Software, by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
A few quick notes about that book:
The developer community quickly tired of listing all the names, so the authors were dubbed the Gang of Four, and the book was known as the GoF book and the included patterns as the GoF patterns. If you know some history, you realize this decision was in pretty poor taste. The original Gang of Four was a ruthless dictatorship that ruled China after Mao died. They triggered the so-called Cultural Revolution that killed millions of people, especially intellectuals. I was amazed the name caught on for the four authors, just because there happened to be four of them, but the name stuck.
The examples in the book were written in two of the major object-oriented languages at the time: C++ and SmallTalk. Java was released about a year later, with interfaces and single inheritance, both of which were going to affect the implementations of the patterns. We waited for over four years (!) before a design patterns book was released specifically for Java. Finally one came out in 2000, which I bought immediately, and that book has the distinction of being one of only two books that were so badly written and so filled with errors that I physically threw them across the room. It’s also the only book I ever returned to Borders bookstore (remember them?) for a refund. The irony is that if the GoF authors had published a second edition, in 1997 or 1998, with examples in Java, much of the rest of their careers could have consisted of wandering out to the mailbox, saying “Hello, check! Gotta catch up on some Flintstones now,” and doing whatever else they wanted. They apparently were sufficiently dismayed by how many of the patterns were used in practice that they never wrote that second edition. A staggering missed opportunity.
Now, of course, there are many good books on design patterns in Java. Probably the best known these days is Head First Design Patterns.
I haven’t been able to confirm this, but rumor has it that Vlissides did a huge fraction of the work, yet his name appeared (alphabetically) last, making it easy to forget about him. Let that be a lesson, kids: if you write a book with a collaborator, GET YOUR NAME FIRST.
Why bring this up? I have a gag I use in class a lot, and I know that if you have to explain a gag it’s not funny, but if you’ve stuck with me this far here is your reward, such as it is.
When I’m coding in front of students I often ask if they’ve ever heard of the CAP design pattern. When they look at me blankly, I explain that stands for Copy-And-Paste, and its purpose it to take errors from one part of your code and distribute them throughout the entire system, or at least it works that way for me. (Pause for laughter.)
This week I spent some time digging into the Jenetics library for genetic algorithms, which is implemented in Java and will be the basis of one of my upcoming NFJS talks this year. Unfortunately, much of the documentation is included in a PDF document. The doc contained a program I wanted to try, so I did something I know I should never do but did it anyway: I copied the code out of the PDF and pasted it into my IntelliJ IDEA code editor.
After cleaning up the code, removing lots of internal spaces and typos (which should have been a clue, but go with it for the moment), the program ran but didn’t do what it was supposed to do. After spending way too much time debugging, I can now tell you that this one line is the issue:
Can you see the difference between commented-out version and the real one? I can assure you, you cannot. The problem is that the correct line declares the chars variable to a sequence of all the capital letters from A to Z, plus a single space. The line that is commented out, however, uses a dash THAT ISN’T A DASH. It’s some weird Unicode character that has no meaning in this context. In other words, the commented line says to the algorithm: use only the letters A, Z, space, and whatever the heck that strange dash-like symbol is, and certainly not the range of capital letters from A to Z that was intended. That’s why that output of my program looked like:
11485: [ AA−ZZ− ZZ AZ ZAZZ A −ZAAAZ] -> 7
11486: [ AA−ZZ− ZZ AZ ZAZZ A −ZAAAZ] -> 7
11487: [ AA−ZZA AZ AZ ZAZZ A −ZAAAZ] -> 7
11488: [ AA−ZZA AZ AZ ZAZZ A −ZAAAZ] -> 7
before I killed it. I found the driver program I needed in the Jenetics source code, and I went through it line-by-line until I suddenly realized the problem with the help of the Unix diff utility, which kept telling me those lines were different.
Ugh. The CAP design pattern got me. Never, ever, ever, EVER copy and paste from a PDF. Next time I’ll type the stupid thing myself, by hand, as I should have done in the first place.
Miscellaneous
This newsletter is already long, so just a few items this week.
Neil Young (and Joni Mitchell) and Spotify
You probably heard about Neil Young removing all his music from Spotify because they fund Joe Rogan and his merry band of vaccine misinformation spreaders. I saw a great post about that somewhere but can’t find it, so I’ll just quote it here:
Age 30 and below: Who is Neil Young?
Age 31 - 60: Neil Young is still alive?
Age 60+: What is Spotify?
The best snarky comment I saw was:
Good one.
Substack: Seizers of the Moral High Ground
On a related note of tech companies doing whatever makes them more money, good old Substack (where I host this humble newsletter) sent an elaborate email defending free speech entitled “Society has a trust problem. More censorship will only make it worse.” Here is a link to the online version.
My immediate reaction was, oh no, somebody did something awful and they’re not going to do anything about it, right?
Fortunately, one of my favorite sites, Defector.com, published an article about it with the clever title, I Am Begging The Substack Bosses To Can It Already. As it turns out, the email was in response to an article on The Guardian that mentioned how many anti-vaxxers are making millions from their Substack newsletters. Substack felt obligated to respond.
I am sure you are shocked - SHOCKED - to find that the owners of a tech site are very much in favor of whatever lets them keep making money, and are desperate to somehow cast themselves as being justified, and even noble, in doing so.
I have two reactions:
Yeah, right. Pardon me while I try to stop rolling my eyes. I’m not there yet.
When evil people like anti-vaxxers or 911 “truthers” or racist, misogynistic jerks publish their newsletters and charge for them, it becomes very easy for me to exclude them from my own little bubble. Let them preach to their own choirs and leave me out of it. I’m sure they exploit their own followers for all they’re worth, but I don’t have to deal with that. I’d much rather they do that than publish in major newspapers or on television. It’s like inviting them all into a room where they can shout all they want, and closing the door behind them.
As you might expect, that post on Substack has several hundred comments, and I didn’t write (or even read) any of them. Wake me when they take an ethical position that actually costs them money and maybe I’ll be interested, but I doubt it.
Not All Models
I’m a big fan of the George Box quote, All models are wrong, but some are useful. I used it in my Help Your Boss Help You book in the introduction to the chapter on personality typing systems like Myers-Briggs Type Indicator. As you might imagine, I loved this tweet:
Some are useless, by George Unbox. I’m still chuckling.
Word Counts At Last
One of the features that Substack never had has now been remedied:
This post just broke 3000 words, so I should probably wind it up, so here you go:
I still believe that Dolly Parton sang it better than Whitney Houston, but either way, the feeling is mutual. :)
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:
Deep Dive Into Spring, an NFJS Virtual Workshop
Spring MVC, an NFJS Virtual Workshop
This week:
Managing Your Manager, on the O’Reilly Learning Platform
Basic Android Development, on the O’Reilly Learning Platform
Groovy Podcast this week, hopefully :)
I'm pretty sure that your "CAP Design Pattern" should probably be the "CAP Design Anti-Pattern".