Tales from the jar side: No one makes the first jump, Java LTS versions, The temptations of curmudgeon mode, a new Mockito video, and Tweets and Toots
When I get to work I immediately hide, because good employees are hard to find. (rimshot)
Don’t feel like reading this newsletter? That’s fine — I’ll read it to you on the Tales from the jar side YouTube channel. Today’s newsletter is tomorrow’s video.
Welcome, fellow jarheads, to Tales from the jar side, the Kousen IT newsletter, for the week of February 4 - 12, 2023. This week I taught my Managing Your Manager course and Week 2 of my Android Development Bootcamp on the O’Reilly Learning Platform, and a New Features In Java course as an NFJS Virtual Workshop.
Regular readers of (and listeners to, and now video viewers of) this newsletter are affectionately known as jarheads, and are far more intelligent, sophisticated, and attractive than the average newsletter reader (or listener, or viewer). If you wish to become a jarhead, please subscribe using this button:
As a reminder, when this message is truncated in email, click on the title to open it in a browser tab formatted properly for both the web and mobile.
If No One Ever Made the First Jump…
I imagine that nearly everyone reading this newsletter is familiar with this scene from The Matrix:
Let me summarize some of the dialog:
Morpheus: Tank, load the jump program.
…
Mouse: What if he makes it?
Tank: No one’s ever made the first jump.
Mouse: I know. But what if he does?
Apoc: He won’t.
Sure enough, he doesn’t.
The jump program is supposed to illustrate how far Neo still has to go to “free his mind” and let go of reality when he’s inside the Matrix. As an instructor, however, I have a different interpretation. In my view, if everybody falls the first time…
… you’re teaching it wrong.
Seriously, what’s the point of an exercise that everyone fails? To show them they don’t know everything? They already know that. To publicly humiliate them? How does that help them learn?
There is certainly value in showing a student how far you can go once you reach your potential. There’s nothing wrong with Morpheus jumping to the next building. But the implication is that Neo is supposed to do it as well, when Morpheus knows — he absolutely knows — Neo will fail. After he falls, Neo will have a lingering doubt in the back of his mind in every subsequent test, worrying that he’s being set up to fail, painfully.
I’m sorry, but I can’t teach that way. Learning is hard enough without making students worry that you’re going to humiliate them in front of the class. To me, the result of that test is to make the instructor feel powerful, and that’s awful.
I thought of this entire situation this week, when a question came up on the Java Champions email list.
Long Term Support versions of Java
(Note: I’m removing all the names here. I’m not trying to call out anyone. I just want to discuss my reactions and differences in philosophy.)
Someone noted that the upcoming Java 21 version, to be released in September, is expected to be an LTS (Long Term Support) version. This is a change, because starting with Java 10, Java versions come out every six months, and every three years Oracle designates a version as an LTS version. Java 8 was retroactively designated an LTS version, and Java 11 was the first one after the change. The one after that was Java 17, because that’s three years of two-versions-a-year. The unintended result, however, was that most companies completely ignore non-LTS versions, choosing only to upgrade to LTS versions, and not even all of those. The most recent market share numbers I’ve seen suggest Java 17 has about 20% of the Java market, with Java 8 (still) and Java 11 splitting the rest, and no non-LTS version making it out of single digits.
This apparently frustrated the core Java team at Oracle enough that they stated about a year ago that they’re moving the LTS period to two years instead of three. That’s fine, and for most languages, that declaration would be enough. But Java is provided by a wide range of vendors, and the questioner wanted to know if this change was “official” or not, since only Oracle seems to be saying it. What about the other vendors?
A couple of responders agreed that this was exclusive to Oracle. Each vendor has their own schedule for support, though everyone follows the official specifications for their releases.
This is when one of the leaders in the field (again, name withheld), responded (emphasis added):
People seem to have a surprisingly hard time with this, but in actuality it is quite simple. (I guess some people just really, really want it to be different.) And it is truly bizarre that this *still* has to be explained at this point, five years after adopting this model -- especially to Java Champions.
Java specifications are not divided into "LTS" and "non-LTS"; every Java release is a full feature release, with all the usual artifacts -- specification, implementation, TCK. The Java 17 specifications do not say "This version of Java is an LTS", and the OpenJDK processes (under which the specification and implementation are developed) do not distinguish between kinds of releases. Java release are releases.
LTS is a support phenomenon. LTS is a statement _by a particular entity_ that they will make particular support (such as updates) available under a particular license for a particular time frame. Oracle's JDK offering ("Oracle JDK") were previously on a three year LTS cadence, and have moved to a two year LTS cadence, with 21 as the next LTS.
Other organizations can decide to offer LTS on other JDK releases, or offer support on other terms than the LTS terms offered by Oracle. Someone could decide they are going to offer 13 year support on Java 13. This is entirely up to them, and there is no "coordination" process between vendors to decide which versions will be deemed LTS.
It does great damage to the Java ecosystem for people to hear the non-LTS release being described by Java Champions as "betas" or "not real" or "not serious" by Java Champions. This was an acceptable misunderstanding for about ten minutes five years ago, but we should be past that by now.
I dearly wanted to reply to this. My message would have consisted of something like:
If everyone is still asking this question — including Java Champions — and you believe they should know better because it was all resolved five years ago, then you’re teaching it wrong.
My problem with the original answer is with the attitude expressed. The responder is implying that Java Champions are misunderstanding this fundamental concept because either they’re not paying attention, or they’re stupid, or they don’t care. If we assume for the sake of argument that Java Champions aren’t stupid, then what’s the problem here? Why isn’t this message getting across?
The title “Java Champion” is a bit misleading. It seems to imply an exceptional level of technical knowledge, and that’s not necessarily true. That is only one way you can be elected to the group. Others include doing a lot of meeting organizing or community events, or advocating for the language in public forums, or publishing information that tries to expand the user base. Sure you need to know the basics, but you don’t have to be an expert to be a worthy Java Champion. It’s an indication of advocacy and effort as much as technical excellence.
That means Java Champions are trying to help. They believe in the language and want to convince people to use it, and they work hard to help get it accepted in the marketplace, both among developers and companies.
So if, after five years, some fundamental concept is still being misunderstood, why is that happening? What’s the actual problem? It can’t be the students (Java Champions), or at minimum it can’t be only the fault of the students. At some point, the teacher (Oracle) has to take some responsibility, and the quoted response doesn’t do that at all.
As I said, however, I didn’t respond. I didn’t say anything. One reason is my basic preference to avoid confrontation. Another is I didn’t want to challenge a leader in our field publicly, one for whom I have enormous respect. I was tempted, though, to say something to reassure the other readers who did misunderstand the issue that it’s not (entirely) their fault. Partly I also held back because I didn’t want to deal with any resulting drama.
I also have an opinion about why the original response sounded like it did. I feel like this person, whom as I said I greatly respect and admire, has over time become more and more of a curmudgeon. A senior person will adopt the attitude of “seen it all, done it all, not impressed,” and expresses that attitude in a way that drags down everyone around them. They’re difficult and depressing people to deal with, because they are all too willing to express their barely-concealed contempt for questions (and, by implication, questioners) they don’t like.
Let me now, therefore, address my struggle to avoid becoming a curmudgeon.
The Curmudgeon Trap
I understand why the original answerer (the leader in the field) acts like that. He’s been an acknowledged top technical expert for literally decades, and people with those skills attract difficult questioners who enjoy asking difficult questions. He’s had to deal with hostile and obnoxious developers for years, some of which condemn Java for reasons that are simply wrong, or at least misguided. Some people argue with him in bad faith. I would hate that role.
I find that this leader acts like a curmudgeon too often, and his answer was the latest example. My feeling is that a curmudgeonly attitude, like the one expressed in that answer, actually does more harm to the the community than any misunderstanding the concept of an LTS version.
Maybe I’m reading too much into this, and, as I say, I was not willing to respond this way on the Java Champions mailing list. I needed time to think about it, too, in order to understand why it bothered me so much. But this is my newsletter, and while I have a nice subscriber base, I think I can rely on the people here to at least give me the benefit of the doubt and listen to what I have to say. If that leader hears about this and is offended in some way, I’ll deal with that, but the most likely consequences will be none at all. Still, this is a risk for me.
But it’s a sensitive issue, because as I’ve gotten older, I worry about turning into a curmudgeon myself. Most concepts seem easy once you understand them, and sometimes it’s hard to empathize with learners who struggle. I too get tired of answering the same questions over and over again. But whose fault is that? Sure, sometimes students don’t put in the work and are looking for shortcuts, but don’t we all do that? Who wouldn’t want concepts to be easy?
A lot of conference speakers turn into curmudgeons, because it’s popular with audiences. Curmudgeon speakers make fun of companies and their stupid sounding rules, and use terms like cargo cult programming that drip with contempt for how foolishly things are done. Attendees love that. Who doesn’t want to hear an expert tell you that your issues aren’t your fault and that it’s stupid programmers and companies that are to blame?
I always sit and squirm in those talks. Sure, dumb things are done by companies every day, but just because you can’t see why things are being done a certain way doesn’t mean there wasn’t a decent reason at the time. It’s the general hostility and contempt for others that bothers me, combined with what feels like a complete lack of empathy.
Like most hostile attitudes, being a curmudgeon can get you a short-term boost at the cost of long-term problems. Being angry and miserable all the time is a hard way to live. The world is tough enough without looking for problems and misery, and searching for someone to blame avoids dealing with the actual issues at hand.
Learning is not the fun process that teachers sometimes think it is. It’s hard and scary and can make you feel uncertain and foolish. There’s no reason for a teacher to make it harder. If you know that nobody ever makes the first jump, maybe don’t require them to do it without a bit more preparation.
At least tell them no one ever made it the first time.
Why Use Mockito?
I published a video this week, along with another Medium post. The video is called Why Use Mockito At All? and illustrates where Mockito fits into the testing story:
This is the first purely technical video to be published on the Tales from the jar side YouTube channel, and it’s done pretty well. I plan for it to be the first in a series.
Incidentally, I tried again to publish an unboxing video at Amazon, with the prices masked out and no references beyond the table of contents, and again my video was rejected for “not complying with our community guidelines.” Oh well. So much for that. I officially give up on them.
Tweets and Toots
Elon Again
First, Twitter had an outage that looked to be for a really funny reason. Everyone trying to post kept getting an error about exceeding some posting limit, which was absurd. Rumor had it that this was because when they cut off the public API to all third-party clients, they didn’t realize their own internal systems used the same API. That would have been a riot, but turned out not to be the case. According to Casey Newton in her Platformer newsletter, what actually happened was:
It turns out that an employee had inadvertently deleted data for an internal service that sets rate limits for using Twitter. The team that worked on that service left the company in November.
Oops. In the same newsletter, Newton also reported that Musk is the reason that tweets now have “viewer counts” on them, and he was upset that his own personal viewer counts had been dropping recently. Here’s the recounting of what happened next:
One of the company’s two remaining principal engineers offered a possible explanation for Musk’s declining reach: just under a year after the Tesla CEO made his surprise offer to buy Twitter for $44 billion, public interest in his antics is waning.
Employees showed Musk internal data regarding engagement with his account, along with a Google Trends chart. Last April, they told him, Musk was at “peak” popularity in search rankings, indicated by a score of “100.” Today, he’s at a score of nine. Engineers had previously investigated whether Musk’s reach had somehow been artificially restricted, but found no evidence that the algorithm was biased against him.
Musk did not take the news well.
“You’re fired, you’re fired,” Musk told the engineer.
What an oversensitive man-baby. Also, can you believe it’s been a year since Elon made the original offer?
All this and more led to the following meme:
On the left is Zephram Cochrane, inventor of the warp drive, from Star Trek: First Contact. In the center is Quark, from Deep Space 9, the ultimate capitalist exploiter. On the right is one of the Pakleds, from Next Generation, who are basically idiots who collect things, or, more to the point, stupid con artists in way over their heads.
Best Venn Diagram Ever
This is an old joke, but I’ve always enjoyed it, and it emerged this week again:
On the left we have a beaver with a guitar. On the right is a duck with a keyboard. In the overlap, there is a platypus with a keytar. Brilliant. :)
Great AI Commentary
Yup. For all their abilities, tools like ChatGPT are trained parrots. Don’t expect more than that, at least for a while.
(Aside: I’m working on a couple of proposals for upcoming video courses, and I hate doing that. I tried to use ChatGPT to write the parts I didn’t want to do, but couldn’t get it to come up with what I needed. “Prompt crafting” of questions to AI tools is going to be significant skill in the future.)
Sampling Bias Defined
That’s the best illustration of sampling bias ever. I have to find somewhere to use that.
Have a great week, everybody. Enjoy the Super Bowl today. It’s much easier to watch when you don’t have a favorite, and I don’t have a strong preference for either team, though I firmly believe that “Tomahawk Chop” is both racist and contemptible. I just choose not to blame the players for that.
The video version of this newsletter should be uploaded onto the Tales from the jar side YouTube channel tomorrow.
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:
Managing Your Manager, on the O’Reilly Learning Platform (APAC time zone)
Latest Features in Java, an NFJS Virtual Workshop
Android Development Bootcamp, week 2 of 3, on the O’Reilly Learning Platform.
This week:
Android Development Bootcamp, week 3 of 3, on the O’Reilly Learning Platform.
I thought the part about LTS releases and Java Champions and curmudgeons was too long and not terribly interesting, but a BLOG is the expression of ones own opinions and that certainly is yours and I respect your right to express it.