That One Poor Sod
As a software engineer, there are times when you look at something and think, “There has to be only one poor sod out there who needs this.”
Once upon a time, Sun Microsystems provided a serial communications library in their distribution of Java for a few platforms (notably Solaris on SPARC, Windows on x86, and later on Linux on x86). It was a reference implementation of the JavaComm API. It doesn’t seem like too many people cared about it, though: they withdrew support for Windows in 2005, sometime during the Java 5 era.
This probably didn’t matter to too many people, but I know it mattered to at least one person. I know this because in 2006, she decided to use the in-JVM implementation of JavaComm on Windows for x86 in an effort to integrate industrial equipment with an industrial ERP system. She knew what kind of beast she was making: client-server communications between serial devices and an ERP system is kind of a niche thing, and she knew that this would be mission critical for her client.
Of course, she didn’t know that Java 5 had deprecated this library: she was deep in the realm of Java 2 Enterprise Edition version 4 and its near complete reliance on Servlets. Java 5 wasn’t on her horizon.
She moved on and up and onto other things and passed it on to her successor, a woman we’ll call Alice. Alice got a luxurious tour of the facilities, ready access to it, and could even trivially plug her laptop into a console in the factory and operate parts of it in the debugger. And then, Alice was on her own.
Alice noticed that it was difficult to fake the feed from the ERP system. So she developed herself a side tool. It could fake the SOAP request that her system would get from the ERP system. She even provided a series of files to fake each kind of request the system could get.
But eventually, Alice too needed to move on. It was someone else’s job to be That Poor Sod.
And so it fell to Bob. Bob was from out-of-state, but he lived near two other sites where the software was deployed. Bob didn’t quite get the full tour, and in fact never spent a lot of time on site. But Bob did a few things.
When Bob took over, he started by dragging the application into the era of Java 6 because Java 4 was ending its long and venerable life. This wasn’t too hard, but for one thing: those serial libraries went away in Java 5. So what did Bob do?
The stupid tactical move was to try using the JARs from Java 4. This worked for a while, but wasn’t cool. It didn’t solve his problems. He still couldn’t debug this mess.
So he replaced it with as close of a drop-in replacement as he could that didn’t require too much in the way of native libraries. He also had to fix a UI problem that stopped the application from running natively on x64. But eventually he got there. He made notes on his options and why he chose what he did (it wasn’t RTRX). But he could debug the app.
This led to perhaps the only production implementation of the open source library he used that’s currently in use today. That open source library still exists on GitHub. It doesn’t seem like too many people use it for things outside hobbyist robotics.
But finally, he could debug his app. The itch was scratched. And the app actually worked on 64 bit Windows 7, unbeknownst to anyone, because nobody cared until they did, and they were surprised to find that it Just Worked.
But eventually Bob moved on — but not before a parting gift: an emulator for the factory equipment, as he knew his successor couldn’t get to a factory too easily: Charlie.
Charlie was another good steward of the application. However, he did one better: Bob had left him a compendium of notes that were scattershot, but included complete debates with himself about technical solutions, contact information for downstream vendors up to and including personal phone numbers of the CTOs at those manufacturers, the personal phone numbers of a few Java engineers at Oracle, a complete documentation of the serial interfaces, and even enterprise property IDs and people responsible for them, as well as an occasional rant about the Java Messaging System. He turned all of those notes into a full, searchable index of everything that could go wrong with this app and what might happen.
Eventually, Charlie lost his contract for reasons that had nothing to do with him and everything to do with his company, and those documents — which still contained Bob’s rants and Alice’s initial design commentary — were passed along to the next person, Debbie.
Debbie took over the codebase in a time of great renewal for the Java Programming Language. Java 9 was right around the corner, as was JavaEE , and her company snapped to the new protocols. It’s still running on Java 9 today, as it’s still fundamentally a JavaEE app, and that’s what JavaEE 9 expects. Debbie also rewrote it to use more of JavaEE: it had relied on Spring’s dependency injection framework since the beginning, and that wasn’t necessary anymore. Finally, she made sure the app work on Windows 10 workstations.
Today, Evan is that one poor sod who has to use these technologies cobbled together through the years. He’s never seen the factory — he doesn’t have to. He has what he needs to tackle the move to Jakarta.
I don’t know why I feel compelled to tell this story. Maybe it’s the whiskey.
