The Tale of Jini & the Missing Objects
It's too much information for me
Perfecting Equilibrium Volume Three, Issue 33
It's pumpin' down the cable
Like never so before
A cola manufacturer
Is sponsoring the war
Here comes the news
With love from me to you
Destroyed by ABC
I hate to bite the hand that feeds me
So much information
The pressure's on the screen
To sell you things that you don't need
It's too much information for me
The Sunday Reader, March 2, 2025
Could it be that the old tech god did not know that data isn’t dead?
I’d read the massive tome twice, gone through the index looking up every possible keyword and synonym. No joy.
Could it be I knew something Bill Joy didn’t?
It hardly seemed likely. Bill Joy was one of the godliest of all the tech gods, father of multiple flavors of UNIX, and the ex and v editors nerds used to write code. And he godfathered a team working on a set-top-box language called Oak, changing the name to Java and leading it to the dominant programing language it has been for the past two decades.
So why have you never heard of him? Because there is a divide between pop culture tech gods and the deities worshipped by nerds.
If we play pop culture tech god association, the winning answers would be Steve Jobs for Apple; Bill Gates for Microsoft; and Scott McNealy for Sun.
Back when Sun was a thing.
But play nerd culture tech god association, and you get Steve Wozniak for Apple, and Paul Allen for Microsoft.
And Bill Joy for Sun.
During the 90s Dot Com boom Sun was one of the Powers That Be. Everyone bought their servers to support web sites. Sun was making so many so fast that McNealy went around Silicon Valley telling anyone who would listen that Sun was the Dot in Dot Com.
Joy, meanwhile, had left. He’d convinced McNealy that he needed to open up a Sun satellite office in Aspen, Colorado. No big deal in 2025, but in the early 90s it required a back hoe to install a mighty T-1 line that offered 1.5 megabits of throughput.
The T-1 I had installed in Waterbury, Connecticut, at about the same time for the first ISP in the area cost us $1,500 a month.
The smartphone in your pocket has more bandwidth.
High in the Rockies Joy fathered something so brilliant that almost no one understood it: the JINI self-negotiating object environment for Java code. To understand JINI, you first have to understand objects, and why everyone at the time was moving to object-orientation.
The Spaghetti Code Incident
Most people know that early computing was dominated by mainframes – one central computer supporting dumb terminals.
Few know most mainframes were single purpose – a single custom software package running on a processor. It wasn’t until a few decades had passed and IBM introduced the Personal Computer that computers running an operating system supporting multiple software packages became widespread.
That meant early coders never had to worry about interference, because there was no other software to interfere. Whatever you wrote was the only thing running; if you could code without tying your virtual shoes together you were good to go.
And that was fine when things were simple. Imagine writing a program that checked a folder every five minutes for files that haven’t been backed up, and backed them up. It’s the classic IF; THEN; ELSE:
IF there is a file in C:\ImportantData\ with no ARCHIVE BIT
o THEN copy to D:\ImportantDataBackups\ and set the ARCHIVE BIT
ELSE GoToSleep for five minutes
Simple! But as computers got more powerful, coders got more clever:
You could do all sorts of fun things if you started chaining these things together! US: IF there is a file in C:\ImportantData\ named US*.* then RENAME US*.* to USMonthDayYear*.*. ELSE go to EUR: IF there is a file in C:\ImportantData\ named EUR*.* then RENAME EUR*.* to EURDayMonthYear*.*.
So coders happily coded away. And coders being coders pretty much none of it was documented. As computers got more powerful and ran more and more software, the Spaghetti Code Incident got more and more untenable.
It was called Spaghetti Code because unravelling it and figuring out which lines did what was like trying to unravel a plate of spaghetti.
Something better was needed. Something clean. And organized.
Enter objects.
Objects were designed from the ground up to run smoothly in complex computing environments. There are three principles for well formed objects:
Objects must be encapsulated; that is, they must know everything about themselves and what they do, and be able to operate completely independently
Objects must be polymorphic; that is, objects must respond to a standard set of requests, such as to store or retrieve a file. This is how modern Operating Systems work. If you are saving a file in Adobe Photoshop, Photoshop does not need to know or care what hardware you are running or how to talk to it. Instead Photoshop sends a SAVE command to the File Handling object of the OS, whether its Windows or macos, Android or iOS. And the file handling object handles things from there.
Objects must exhibit heredity; that is, child objects can be formed that contain everything in the original object
Object orientation was such an improvement that it took the coding world by storm. Java exploded and soon became one of the most popular programming languages in the world largely because it made it easy to write object-oriented code.
Bill Joy, meanwhile, had moved on
Object orientation was all well and good. Encapsulation, polymorphism, heredity…
What if the objects could talk to each other directly?
Meet Jini.
Jini is a self-negotiating object environment. Everything is an object, and objects talk directly to each other. For example, LOOKUP objects are objects of objects: they are directories of what objects are available in the environment, what functions they provide, and how to talk to them to use those functions.
Joy’s brilliant creation had objects for every function imaginable. Jini even has objects that do nothing but facilitate communications and work between other objects.
Objects for everything!
Except data.
The chance that I knew something technical Bill Joy didn’t know was effectively zero.
The chance that I knew something about data Bill Joy didn’t know was quite a bit better.
Because it turned out most coders thought about data the way a line chef thinks about steaks: when you need one you grab it from the walk-in and throw it on the grill. How it got there – from calving to cattle drives to butchering – is almost never part of the discussion.
I, on the other hand, had spent decades thinking about content. How to create it. How to manage it. How to get creators to actually deliver before you were reduced to publishing blank pages.
How data is a living process, and how any content object – a book, a movie, an article, a song, a poem – was actually a snapshot frozen in time of one piece of that process.
Just ask Davis Grubb.
The Night of the Data Hunter
Ever seen the words LOVE and HATE tattooed across someone’s knuckles in a movie or TV show? That’s the influence of Grubb’s novel The Night of the Hunter, made into a movie by Charles Laughton – the only movie ever directed by the great actor – which is now in the United States National Film Registry; the French film magazine Cahiers du Cinéma selected The Night of the Hunter as the second-best film of all time, behind Citizen Kane.
By Christmas of 1977 Grubb had the sort of career as a novelist that generally only happens in the movies: a string of best sellers that garnered critical acclaim and made him a National Book Award finalist. Many were made into movies.
The Center for Appalachian Literature was new that holiday season. We were kicking off the new Center by reprinting famous Appalachian works, starting with Grubb’s A Tree Full of Stars. Grubb’s story of a West Virginia family driven out of town for keeping their Christmas lights up year-round had been a best-seller a decade earlier and been made into a television movie. Each reveler had a red leather-bound copy of the new special edition. As Grubb read his copy to those gathered at the holiday kickoff party for the Center, there was just one teeny tiny problem:
The words Grubb was reading did not match the words in the book. Grubb was holding the book in his left hand. He had a carpenter’s pencil in the thick fingers of his right hand. And he was rewriting the book as he read.
This is surprising to everyone except creators. Every creator will tell you: Content – data – is a process, not a fixed thing.
Most of us have forgotten this because mass production from Guttenberg on produced identical copies of a single version.
Illustrated bibles were made by hand; no two were alike. Homer must have put a little new flare into each telling of the Iliad and the Odyssey.
The great photographer Ansel Adams taught that the film negative was the equivalent of written music, and the print was the performance. No two Adams prints are the same.
Music is the one place we still see this. Artists with any longevity put out live album after live album that show how their songs change and grow over the years.
Here’s Warren Zevon singing “Got a 38 special, up on the shelf/If I start acting stupid gonna shoot myself.”
And here he is doing the same song live years later, singing “Got a 44 magnum, up on the shelf/And I don’t intend to use it on myself.”
And everyone knows David Bowie’s wistful Changes about growing older. Except…that’s not what he wrote. Here’s the original sneering version featuring Bowie as Ziggy Stardust. Ziggy came to tell earthlings everyone on the planet would be dead in five years; NOBODY was going to get older.
If content is a process, how does that fit into IT data architectures?
It doesn’t. But in some ways that doesn’t matter; existing centralized IT data architectures were already overwhelmed by the tsunami of edge data.
I had lunch with a Fortune 100 Chief Data Officer a few years ago. He said that it was not possible to even design a datamart that would work for his organization. They could no longer even track how many data sources they had, never mind the data produced by those sources.
This missive from Tomasz Tunguz, Venture Capitalist at Redpoint, is a good illustration of the problem. Tunguz shows a diagram of a typical Web2 app. The data is divided up into separate data stores for transactions, metadata, and the core data.
Which is the problem. The data has to be ETL’d from sources (Extract, Transform, Load), then correlated, coordinated synchronized with the sources for updates. Processing the data is a Sisyphean task; just one such process, Master Data Management, consumes $11 billion annually.
New technologies are always used first to build better versions of the older technology’s architecture. So, beyond doing away with the old mainframe-derived centralized design, what’s the Sony Walkman “clean sheet” design architecture for Web3? How’s this going to work? Fortunately, there’s already a well-proven method we can use:
Object orientation. Data objects on blockchain will be the backbone of Web3.
There are three primary rules for well-formed data objects:
Data objects must be encapsulated; that is, all the data – core, transactional, metadata – must be stored together
Data objects must be polymorphic; that is all data objects must respond to a standard set of requests, such as to store or retrieve a value
Data objects must exhibit heredity; that is, child objects can be formed that contain everything in the original object
Building up from data objects allows entirely new features. For example, all metadata is on the blockchain as part of the object and can be used to secure the data. Modern processors can return a serial number; that serial number can be used to ensure the data is only accessed on approved devices.
Because data objects contain 100 percent of the raw data, it is possible to generate metadata mathematically and use the metadata to predict change. For example, a temperature probe records ambient temperature hourly: 1000 hours: 36; 1100 hours 37; 1200 hours 38; 1300 hours 38. As the data grows, the mean, average and standard deviation can be calculated and used. So the system can be set to baseline all the data it collects and then alert you when anything is up or down more than a standard deviation.
And it’s not just temperature probes. Any information on your device can be used like this: Date, time, location, weather, network, nearby users…the uses are literally endless. Sell a book for a day, a week, a month or a year. Record sad songs that only play when it rains. Film scary movies that can only be watched at midnight. Create love songs that only play when you and your significant other listen together.
Or, more mundanely, the data can be limited to access at specific geographic locations and networks.
This is the basis of Distributed Data Management Systems such as PrivacyChain. I have five patents on DDMS’s now: four on the VelocIT system we built at Belo Interactive that used a Jini-style self-negotiating object environment for storage; and one with Geoffrey Hayden on PrivacyChain, which uses blockchain without cryptocurrency tokens for data storage.
More on all that soon.