Java ecosystem

The folks at ecosyste.ms have analyzed the structure of the open-source software community, grouping packages/projects into ecosystems, for funding purposes. Their "Java" ecosystem is the one I'm most familiar with: https://funds.ecosyste.ms/funds/java

From their list of 200+ "most critical packages", I extracted the ones I care most about: kotlin, junit4, slf4j, gson, guava, logging-log4j2, groovy, jna, jmh, jcommander, and findbugs. While hardly a representative sample, I'm concerned that several of these (junit4, jmh, and findbugs) appear to be unmaintained. I don't understand how sending money to Ecosystems Funds is going to improve these packages.

Jcommander, which I thought was unmaintained, proves on closer inspection to have a 2.0 release (from August) that I missed because it hasn't been uploaded to Maven Central.

Unmaintained dependencies

A recent online discussion made me think about all the open-source software (OSS) I use regularly and in particular how much of it might be no longer maintained.

My curiosity was piqued. I decided to list my software dependencies with the dates their last-known releases. Here are the ones that are more than a year old:

2010-05-20 jmf v2.1.1e 2012-01-11 imgscalr-lib v4.2 2013-01-25 org.apache.commons.io v2.4 2021-02-13 junit4 v4.13.2 2022-01-11 jcommander v1.82 2022-04-05 lemur v1.16.0 2022-04-05 lemur-props v1.2.0 2022-04-05 lemur-proto v1.13.0 2022-04-24 Bullet v3.2.5 2023-01-26 sim-math v1.6.0 2023-11-02 jmh v0.7.2 2024-01-01 commons-exec v1.4.0 2024-01-28 jinput v2.0.10 2024-02-29 de.undercouch.download v5.6.0 2024-04-08 actions-gh-pages v4.0.0

While there are many reasons a project might not publish a release for 12 months, it seems to me a valid cause for concern.

Pain and boredom

During the past couple weeks, I've dealt with painful injuries to my left hip and left hand. I've pondered the benefits of pain: how it informs (and reminds) us of damage to our bodies, motivating us to slow down and care for ourselves physically. When taking pain medication, I worry I'll forget my injury and carelessly aggravate it.

I'm rarely bored, but it seems to me boredom has similar benefits: it tells us when we're in a rut and motivates us to change our routine, seek out new experiences, and expand our skills. Boredom was what led me to study Vulkan and Kotlin, for instance. Boredom seems to me healthier than other motivators such as money, snobbishness, or desire for approval. Boredom, properly addressed, might well be the key to self-improvement!

Similarly, anger reflects awareness that the world around us isn't as it should be and energizes us to make it better. Hunger motivates us to acquire and consume sustenance. And so on.

Hooray for pain, boredom, anger, and hunger!

Technical writing

Writing clear, precise technical documentation in English is difficult. I'd forgotten just how difficult, but then I decided to spend the month of April writing tutorials. After four days, avoidance is starting to set in. I'm eager to do anything but write tutorials.

Growing my (code)base

The open-source coding challenge I started back in June is approaching its first API freeze, in other words, version 1.0 ! On Monday night I released v0.9.8 with the following line counts:

+ 66K lines of code (excluding blanks and comments)

+ of which 40K are Java and 22K are C++

Compare with v0.9.0 (from October), which contained 42K lines of code, of which 23K were Java and 15K were C++.

Vulkan versus OpenGL, by the numbers

Game-engine developers often worry about the relative complexity of Vulkan graphics versus OpenGL. Luckily, I have some relevant data points:

The coding styles are very similar. I’d estimate V-Sport is providing about 90% of the functionality provided by Sport. So for equal functionality, V-Sport might require about 2x as many LoCs.

Bottom line: Vulkan is more complex, but not hideously so.

Software Proverb

March testing and April documentation bring forth May publicity.

Bisection

I've encountered several otherwise-capable software developers who apparently don't know how to use bisection to locate regressions (=bugs that were introduced recently into a software project).

The basic idea is, you identify a (recent) commit A that exhibits the bug and another (older) commit B where the bug is not present. Then you pick a commit C about halfway between A and B and determine whether the bug is present there. If it is, you pick D between C and B and repeat the process. If not, you pick D between A and C.

In this way, by running a dozen or so tests, you can often identify a single commit from among thousands. It's an example of a "divide and conquer" strategy.

I spent a pleasant half hour today using bisection to locate a 3 year-old performance regression in one of my projects. Said project has 1427 commits. Back in 2022 I added code to check for OpenGL errors. For one particular workload, those changes cut the graphics frame rate by a factor of 4.

All I need now is a simple mechanism to bypass OpenGL error checking, one that won't cause me to forget that those checks are available!

Managing

I recently gave the following advice to a friend who's managing a difficult software release: "It’s nearly impossible to please everyone, and anyway that’s not what managing is about. I’ve told you this before, but it bears repeating: you should do what you think is best for the project (not what will please the most people)."

Year 3

It's been 2 years since I launched this devblog, so it's retrospection time!

Tumblr works fine as a public journal, but I don't know many people here. I'm not a person who makes online friends easily. For connecting with people I've met IRL, I tend to use Facebook or BlueSky.

I have 57 followers (thank you for tuning in!) and am following 65 blogs.

During the past 2 years I've made 290 posts and given 5,237 likes.

Fewer features, please

Today I learned that a "snow" release (in the context of Apple, at least) means a software release that removes more features than it adds. I don't know much about Apple software, but in general this sounds like a potentially valuable strategy, particularly for mature projects suffering from bloat.

100/100

I've reached a round-number milestone at GitHub: following 100 accounts, with 100 accounts following mine.

Being wrong

About fixing software defects, Steve McConnell says: "Before you make a change, be confident that it will work. Being wrong about a change should leave you astonished. It should cause self-doubt, personal reevaluation, and deep soul-searching." (Code Complete 2nd ed., p. 553)