Back in the late 90s when absolutely everybody knew that Java was going to become the one programming language to rule them all, the Java Ring was handed out to folks at Java developer conferences as an example of how it was going to revolutionize smart wearable devices. Recently [Daisuke Yamazaki] got his mittens on one of these collector’s items to see about reviving it.
We talked about these rings and associated iButton devices before, with their intended use being primarily to act as authentication keys. For the Java Ring, this use was mostly just used as a kind of gag, whereby visitors to these conferences could specify their coffee preferences at a terminal, having this programmed into the ring so that they could get their desired cup of literal java at various bean juice dispensers around the conference site.
Talking to one of these iButton devices requires a so-called Blue Dot adapter, which [Yamazaki-san] purchased along with the ring. Although the device happily responded on the 1-wire bus, figuring out how to interact with the original Java-based firmware and answering the question of how much of the original information of someone’s coffee preferences in ’98 were retained would require more sleuthing.

After recovering an installer for the Dallas Semiconductor’s IB-DE IDE from the Wayback Machine, this posed the next problem. As it was a 32-bit Java binary, which didn’t play nice with the modern Java 25 runtime and belying the ‘write once, run anywhere’ marketing phrase of back then. Downgrading to 32-bit Java 1.8 with since removed communication APIs helped here.
With the IDE in place, the traffic between the Java Ring and the PC-based software could be analyzed to figure out what was going on. This revealed CRC errors that pointed to the built-in lithium backup battery having expired. Unfortunately the stainless steel case is meant to be sealed and thus turn into e-waste the moment said battery calls it quits. Here fortunately a Japanese TV program picked up on these efforts and featured his efforts on national TV.
This led to the happy ending, with some help with others in replacing this battery. This also answered the question of which parts of the firmware and data were in the battery-backed RAM and which in ROM. Although full details of the findings here are a bit scarce, it seems that the original data was lost along with the dead back-up battery, but the ROM retained the JVM and allowed for a new program to be eventually written to the device and retained across reader sessions.
Although these days the various NFC standards have made bulky devices like iButtons rather obsolete, they’re still a fun look at an era when it was thought that lugging a tiny computer as a (key) ring around for authentication was the future. Of course these days we mostly lug an entire 6″ smartphone for that purpose, so maybe the joke is on us after all.
Thanks to [Wood] for the tip.

IIRC, these run JavaCard applets, which are still used extensively in smart cards, SIM cards, SEs, and even some NFC implants!
I was thinking the same. I’ve briefly worked with Javacard, and it is one of my favorite examples of demonstrating how much more complex the (tech) world is than most people realize. As in, most people don’t expect their bank cards to run a Javacard virtual machine.
JVM is quite clever, and the attack surface is minimal. However, you have to be extremely precise in programming them. For example, Java defaults to 32bit, but the VM is just 16bit. This means you are constantly casting data back to 16bit. E.g. “short c = (short)((short)a + (short)b);”
lol “Run anywhere!” …but nowadays in the server world, nobody in their sane mind would deploy Java without bundling the runtime. Docker largely solved that problem, though.
Compile once run anywhere was a lie on the first day and its a lie now. I won’t deny though that Java had its uses and its cross device compatibility was better than anything at the time.
But can we please discuss ARM Jezelle? Who thought it was a good idea? Feels like a grand total of 15 people across the world actually used it. I mean it kinda sounds good on paper but I don’t see why cross compiling the runtime for the specific architecture wasn’t considered the obvious route than bolting on a third instruction set (for an interpreted language! of all things)
Wasn’t Jazelle a failure because it was proprietary and required some kind of an NDA?
I still have one, It was a nice ring something. I could wear in my 30s.
These don’t fit a elegant small hand.
Bring back Oak!
Oh now I want to 3d print this with a RFID tag in 😂 where can I find the STL?! 😂