Tales from the jar side: 97 Things, Groovy, Spring, and the Challenges of Changing Versions
My life would probably easier if I didn't update software right before a training class, but what fun would that be?
Welcome to Tales from the jar side, the Kousen IT newsletter, for the week of May 17 - 24, 2020. This week I taught a JUnit 5 testing class for O’Reilly, and both a Spring Deep Dive and a Groovy for Java Developers course as NFJS Virtual Workshops.
97 Things
Also this week, the electronic version of the O’Reilly Media book 97 Things Every Java Developer Should Know was released.
That’s me in the upper left corner. Prime placement, as it were, even though the one “thing” I submitted of the 97 included was called Make Your Java Groovier. As I mentioned last year when I sent in my article, my goal was a subversive attempt to get an article about Groovy accepted into a book about Java.
At least I intended it to be subversive. Sadly, it wasn’t nearly as radical as I thought.
That tweet prompted these replied from the editors:
So much for my walk on the wild side. Clearly, I am such a crazy person, somebody needs to hold me back. For an encore, maybe I’ll upgrade my software right before a training class …
… which I did twice last week.
Spring Training
How did you like that segue? It’s transitions like that that make me a professional writer, despite the fact I still can’t quite say that (professional writer) with a straight face.
On Wednesday I ran an all-day training class on the Spring framework. The underlying Spring Boot library updated the day before my class from 2.2.7 to 2.3.0. I didn’t have much choice, to be honest, because the so-called Spring Initializr (the website where you go to create a new app) defaults to the latest release version.
Everything in the class worked well, except for two items. In a Spring Boot app, if you:
Use the H2 database
Add in the web dependency
Add in the Spring devtools dependency
then you get access to something called the H2 web console. You start your app, navigate to the “/h2-console” link, and you get this nice little GUI:
You see that weird entry in the “JDBC URL” column? The value you’re supposed to use is “jdbc:h2:mem:testdb”. I have that in my slides, and you can find it in various tutorials around the web.
Sadly, testdb ain’t there no more. I need the bizarre string you see entered in the form, which is different every time. Of course, I didn’t know that. After class I finally found that if you want Spring to show you the right connection string, you add the line:
logging.level.org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration=INFOto your application.properties file, and when you start the app, you’ll see an entry like:
H2 console available at '/h2-console'. Database available at 'jdbc:h2:mem:ce361edb-a330-4b10-a56d-14dc60d1d65e'in the console log. In other words, log the automatic configuration settings of the datasource at INFO level, and it will show you the required connection string.
I haven’t seen anybody report on that yet, but I didn’t spend a lot of time looking, either. Now that I know how to resolve the problem, I can live with this approach until the next time I need to do that demo. I suppose I should search the Spring Boot gitter group and see what they say.
(Okay, writing that sentence made me feel guilty, so I searched the group — nothing — and then entered my own question about it. If somebody responds, I’ll mention it next week.)
Wait, you know who probably knows about this stuff? My friend Greg Turnquist, whose self-published book Hacking with Spring Boot 2.3 was also released this week.
![Hacking with Spring Boot 2.3: Reactive Edition by [Greg L. Turnquist]](https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F38ebb5e4-400a-485b-93f0-359edc5fbe6d_333x500.jpeg "Hacking with Spring Boot 2.3: Reactive Edition by [Greg L. Turnquist]")
On the other hand, that’s such an obscure issue, he might not know about it yet. But I know he reads this newsletter, so he will now. :)
The other bit of weirdness I encountered was at the very end of the course, when I tried to demonstrate the so-called Spring Data REST HAL Explorer. I previously used the HAL Browser, which looks like this:
It’s a nice graphical way to access the REST interface provided when you use Spring Data JPA and Spring Data REST, and makes for a cool demo at the end of the course. Last time I did it, I encountered this message in the console log:
o.s.d.rest.webmvc.halbrowser.HalBrowser : Spring Data REST HAL Browser is deprecated! Prefer the HAL Explorer (artifactId: spring-data-rest-hal-explorer)!
which means they don’t want me to do that any more. Fine, before this week’s class I changed to the HAL Explorer, and guess what? It didn’t work, and I didn’t have time to go back.
Great. I just tried it again, and this time it came up.
Sigh. The joys of open source. The class went well anyway.
(Btw, the title of this section of my newsletter is Spring Training. Probably more readers of this newsletter know that’s a term from baseball, rather than the Spring framework. I’m always amused by doing a Spring training course during spring training. This year, of course, there is no baseball, so never mind.)
Gettin’ Groovy With It
Speaking of Groovy, I was really happy to do a Groovy training course again. The biggest problem there was that I have about three days of materials that I can usually condense down to about a day and a half, but unfortunately all I had was 3 1/2 hours. Such is the nature of online training these days — nobody wants more than a day, and even that is discouraged.
This was my first time using Groovy 3, and of course Groovy 3 changed versions the day before my class. It went from 3.0.3 to 3.0.4, so I didn’t expect any issues at all.
Unfortunately, I hit a mild problem there, too. Here’s my original Gradle build file for the Groovy project we created for examples, labs, and so on:
See that line that says “jcenter”? If you change that to “mavenCentral” (which is what IntelliJ started with), then the first time you run a test you get:
Wait, what? I didn’t do anything with TestNG, but apparently my “groovy-all” dependency asked for it, and Gradle couldn’t find it at Maven Central. Serves me right for using groovy-all, I guess. During the class I switched back to Groovy 3.0.3 and it worked, and afterwards I found that if I used “jcenter” with Groovy 3.0.4, that worked, too.
Again, I should probably tell somebody about that, but I haven’t yet. Hey, maybe Paul King (the man, the myth, the legend, the de facto head of the Apache Groovy project) reads my newsletter. Wouldn’t that be awesome?
(Mild note for any Groovy person reading that build file: you still need “test { useJUnitPlatform() }” as well. I just forgot to include that in the screen shot.
One last Groovy note. Here’s a Groovy script that shows how many astronauts are in space right now:
That demo was part of my article in the 97 Things book, too. You can find all my Groovy examples in my IntroGroovy project on GitHub. The code for the astro example in in a package called, naturally enough, astro, under src/main/groovy.
JUnit 5
You may find this hard to believe, but the release version of JUnit 5 also changed right before my training class this week …
… but everything worked. No issues whatsoever. Yay!
My only problem during that class was that since the Eclipse IDE changed versions, I’ve been unable to open it on my machine. It crashes every time. I don’t use it much, but a lot of my students do, so I needed it to at least run. I knew the problem was related to using Java 11, but I couldn’t figure out why, and even when I changed to Java 8, it refused to budge.
Eventually I tracked down the problem. I’ve been using the awesome SDKMAN! package manager to handle my Java installations, along with Groovy, Gradle, and more. For some reason, even though SDKMAN does set the JAVA_HOME variable correctly, Eclipse still executes /usr/libexec/java_home to find out what Java you have. That program only reports on Java installations inside /Library/Java/JavaVirtualMachines, which is not where SDKMAN stores Java.
My fix was to uninstall all the versions I had in that location (which are official ones from Oracle) and install the official one with version 11.0.7. At long last, that worked. I can still use a different Java version on an individual project, but I needed this or I couldn’t get Eclipse (or it’s descendent program, Spring Tool Suite) to start at all. Best of all is when Eclipse tells you to install the legacy Java 6 distribution, which really isn’t worth dignifying with a response.
Managing Your Manager
Thanks to Laurie Penny’s Writing Spring Quarantine Club, I’ve been cranking away on my Managing Your Manager book. This week I added a “Miscellaneous” chapter, which talks about special cases that are important but may not warrant an entire chapter.
This week I added material about:
The Flat Organization
Working for a Micro-Manager
Working Remotely
All three were interesting and fun to write about. I’d say more here, but this newsletter has already gotten out of hand, so I’ll wait until I have a chance to blog about them when my book is closer to publication.
Speaking of blogging, I forgot to mention that last week that I added another post to my blog the week before, entitled, Are you positive you tested positive? The idea is a simple statistical demo that when you are looking for a very weak signal, even a highly accurate test gives false positives that overwhelm the true positives.
It’s an old demo I used to do as part of my NFJS presentation called Bayes Rule Predicts You’ll Come To This Talk. The math is simple, so you might find the post interesting if you get a chance to take a look. The basic idea is that if you are looking for a disease that occurs in only a tenth of a percent of the population and you have a test that is 95% accurate, if you receive a positive test you still only have the actual disease less than 2% of the time. On the other hand, if 40% of the population has the disease, the same positive test implies a 93% likelihood you have it.
It’s not about the accuracy of the test — it’s about the strength or weakness of the signal you’re trying to detect. If you’re thinking about our current pandemic, so many people have been exposed by now, including asymptomatic carriers, that the tests are probably a good indication of whether you have it or not.
Speaking of the pandemic, have you seen this one yet?
Sadly, in this country, you’re probably more likely to see somebody without any protective equipment than anybody like this. Although that could be anecdotal, I guess. I haven’t seen anyone without a mask, but I don’t get out much, either.
Finally, here’s a decent joke I saw on Twitter that’s unrelated to anything:
I’ve seen a couple versions of that joke, so I don’t know who actually wrote it, but it’s funny anyway.
Finally, happy 25th birthday to Java. I’ve spent pretty much my whole career in I.T. either directly in Java or in languages that compile down to the Java Virtual Machine, like Groovy or Kotlin. My first Java version was 1.0.6, way back in 1996, so I’ve been there almost from the beginning. Here’s hoping for another 25 years!
(Actually, five more years would probably do it. But that’s a whole different discussion.)
Last week:
Java Testing with JUnit 5, on the O’Reilly Learning Platform
Deep Dive Into Spring, NFJS Virtual Workshop
Groovy for Java Developers, NFJS Virtual Workshop
Lots of writing on my Managing Your Manager book
Blog post the previous week I finally remembered to mention in this week’s newsletter
This week:
What’s New In Java?, on the O’Reilly Learning Platform
Functional Modern Java, NFJS Virtual Workshop
More writing on Managing Your Manager. Getting closer to a full draft. :)