Java, the Coffee Cult

<rant>
The Wictionary defines “cult” as “1. A group or doctrine with religious or philosophical identity viewed as a sect, often existent on the margins of society.”

I have had occasion in the past month to learn Java by the full-immersion method. While there are many ideas and practices embodied in the language and its tools that I admire, I have skeptical of the more extreme claims made for the language. After a month, I am convinced that the Java user community is, in effect, a cult.

Who am I to have an opinion?

I have been working professionally in embedded systems design and implementation for over twenty years. For much of that time, I have found that C remains my language of choice when faced with manipulating bits in the registers of actual hardware devices. Naturally, you can’t escape from the native assembly language of the system’s CPU for some aspects of device drivers, interrupt handlers, and thread scheduling; but for just about everything else, C serves well. When building tools for general use, I have generally reached for C as well, but C++ and Perl are gaining ground.

The customer, however, wants this project to include a substantial chunk of user interface built in Java, with a thin layer (device drivers and low-level routines at most) built in C.

Recent versions of Java are showing signs of becoming a usable language. Version 5 of the Java API introduces a limited kind of template and a first-class enumeration type. But since version 1.0 more than a decade ago we have been hearing claims about Java revolutionizing the world. What happened?

It’s a cult.

One hallmark of a cult is the sweeping claim of a new order and revolutionary changes. Another is isolation of its members from their pasts. The Java Way teaches that Java is the only way. “Write once, run everywhere” they loudly trumpet. But many core technologies sacrifice compatibility with any particular platform on the altar of broad portability. Many of the tutorials at java.sun.com are proud of the fact that Java is not particularly good at playing with others.

If they really wanted to reach a world-changing number of programmers they could open up the JVM to the point where compilers targeting Java bytecode could be written for other languages. Perhaps a few tweaks or minor new features would make it easier to write C++ code that runs in the same JVM and interacts with Java classes. Perhaps someone would even release compilers for FORTRAN, COBOL and BASIC, not to mention Ada, APL, Eiffle, Forth, Haskell, Lisp, Logo, Modula 2, Pascal, Prolog, Scheme, and Smalltalk…

Oh wait, Microsoft actually did just that already. Their oddly named .NET platform is based on a just-in-time compiled virtual machine that has open source implementations available in addition to the “official” release from MS. The open-source implementations run on a variety of platforms (at minimum on Linux and other Unix-like places). MS is responsible for a slew of languages built on it, and I counted a dozen or more research groups using the platform for niche research language projects, while the commercial language vendors are happily eking new life out of APL, COBOL, and FORTRAN on the platform.

But Sun didn’t want to play along, and packed their sandbox up and took it home.

Both platforms weigh in at a hefty 150MB or more for just the platform installation. Both can be installed free for the download time and bandwidth. The Java compilers and development tools are largely also free, and many are open source, while the .NET tools (at least the “official” ones) are all commercial products.

Up to now, I have avoided building utilities and tools in either platform. If I wanted to release a tool internally, it has seemed more productive to require the modest impact of a recent Perl installation which actually is quite portable even back to Windows 9x versions. For products delivered to end users (who in my companies experience are usually running on Windows) rather than among a development team I have generally preferred to build true Windows applications out of C++ and MFC.

To be fair (why, I’m ranting here… oh never mind) a lot of work in Java Swing was devoted to efforts to make its user interface components work well on lots of platforms while making it possible to mimic the look and feel of many of them. That was the result of a lot of hard work by some enormously clever people, and on the two platforms I have personal experience with, it works reasonably well.

Garbage collection has been a feature of Java since before version 1 was released, and it certainly does have benefits by allowing the programmer to stop worrying about memory allocation. But memory is not the only resource that needs an allocation strategy, and because I have yet to fully grok the Java way of handling non-memory resources I won’t try to use my lack of knowledge of a best practice as evidence that there is or isn’t one.

However, users I have talked to over the years rarely, if ever, change platforms. To an end user the idea that the same program (no, the very same binary file) can be executed on more than one platform simply has no value. If that user perceives that performance or usability has been sacrificed, then he may seek another product entirely.

Java is a Coffee Cult.
</rant>

Just Butt Out

<rant>
The media has spent the weekend talking about Terri Schiavo, and I am sick and tired of it. It seems that everyone is suddenly an expert on a “persistent vegetative state” and everyone has an opinion.

My bottom line: Everyone should just get the @#$%* out of this situation.

While it is true that Congress has the Constitutional power to establish the jurisdiction of the Federal courts, they should stop pandering to their own sense of self-importance. We all need to remember: Just because you have the right to do something does not make it the right thing to do.

Apparently this situation got out of hand because Mrs. Schiavo did not draw up an actual living will that would have spelled out in writing before witnesses what her preferences would be in a situation like she is in today. She did, however, confide her wishes to her husband. That should have ended the matter there. However, a dispute arose between her husband and her parents, and the courts got involved. Once lawyers are involved, the only winners are the lawyers.

Finally, we all owe our heartfelt condolences to the long suffering Mr. Schiavo on the loss of his beloved wife.
</rant>

A Candle and a Crayon

Los Angeles held an election, and it seems like no one noticed.

<rant>
There has been a lot of talk about “reforming” the process of local elections. For years, it has been safely all talk with little actual action. However, the ballot counting fiasco in Florida in 2000 caused attention to be focused strongly on the apparent ills in parts of the election process. Unfortunately, when government gets urged to “do something” it is not the government that gets left holding the hanging chad.

Voting is too important to be concealed behind too much technology. It should be trivial for any voter to directly verify that their ballot is marked correctly. It should be easy to verify that the polling place handled the ballots with due care and security. It should be possible for an interested citizen to follow the ballots from precincts to the counting facility. And it should be possible for an observer to verify that the system is honest and the end results match the votes as cast.

This is not a process that requires expensive, finicky, and power-hungry equipment widely deployed. The voter should be able to vote their ballots given shelter from the weather (National elections are the first Tuesday of November, hardly a red letter day for fine weather in most of the U.S.) and enough light to read by. The ballots should be tangible objects and the marks visible to the naked eye and clearly correspond to the ballot instructions.

Electronic voting is a bad idea from the outset. First, it requires that the voting booth be outfitted with the machine itself, and the machine requires power. In my precinct, the polling place has often been located in a donated living room in a small house whose wiring was state-of-the-art in 1940. Spare power outlets are a scarce commodity in the homes owned by the kind folk who allow strangers to traipse through their living rooms and garages.

Second, it requires that the voter trust the machine. Adding a voter-verified paper trail is just adding another point of failure between the paper running out, ribbons running dry, paper jams, etc. The old lever-actuated tabulators had the same problem. You flip the marked switches (click the buttons on the touch screen) and pull the handle and hope that the labels on the back (in the software) have some relationship to the switches you flipped (buttons you clicked).

Third, even if the source of the machine and its software appears trustworthy, can anyone verify that the system deployed actually functions? Can it be adequately defended against a virus or worm that might modify only a few percent of the vote, and then only during some times of the day on Election Day itself? Certainly there are those who would argue that only fully inspected, audited systems would be deployed. But notice that the states buying the currently available systems have been largely unable to get the right to conduct their own audits of the source code, and there have been issues with version control that, in California at least, caused one manufacturer to loose state certification.

Finally, it isn’t transparent in its operation. The voter clicks a spot on a touch screen. The machine claims it registered a vote. Perhaps it even prints a few lines of text on a roll locked behind glass. At some point memory cards and presumably the spent rolls are gathered for tabulation. But by that point the votes themselves are concealed in memory devices that are much easier to loose than entire ballot boxes, and those ballot boxes get lost occasionally today.

Don’t even mention internet voting.

As the title says, “A Candle and a Crayon” is all the voter should need beyond a dry place to sit or stand.

It is reasonable to improve the technologies in use for counting the ballots at the central site. It is, of course, important that any counting and tabulating equipment be audited, inspected, and verified. But since there will be only a few central tabulation points per county (perhaps only one) it is reasonable to use more automation.

Having now used the ink-a-vote cards in a couple of local elections, I find that they largely meet my criteria. They are sturdy cards marked with ink pens. The voting booth contains only a frame that holds up the ballot pages and allows the card to be slid behind where it can be marked as pages are turned. Its principle shortcomings relate to the pens drying up when left uncapped by prior voters, and by a need for good eyesight to verify that the dots actually landed on the right spots.
</rant>

A bad use for RFID

Ok, so it really begins...

<rant>
I am coming to a conclusion that makes me sound like a paranoid freak, or a Luddite. I don't like RFID. Perhaps it has narrow applications where its use is essentially harmless. However, it is being foisted upon all of us like a magic bullet solution to all problems. It ain't. It's really just a fancy barcode that can be read without the holder's knowledge, and at a distance.

Crypto helps, but is not enough. A recent RISKS has a link to a research group that has worked out a way to completely reverse engineer the entire secret key from a particular TI encrypted tag that is widely deployed (a big-three automaker's "smart" ignition key, and Mobil SpeedPass among other applications) from fewer than 10 queries requiring no more than 2 seconds to gather the data. From the collected data, they can duplicate the tag in only a few hours using less than $5000 worth of off-the-shelf hardware.

Worse is the idea that tags could become ubiquitously buried in consumer goods. Walmart is the major driving force here. They have this pipe dream of doing whole-cart checkout by just letting *known* customers just push the cart past a reader. The problem is all the extra inventory data that will just sit their sewn into seams in clothing, cast in soles of shoes, and so forth. Some of that could be used to track people. Some could be used simply to violate privacy. (Hey, like those red panties you're wearing, Mr....) And then there's the easy opportunity for "extra charges" the second time you go shopping carrying or wearing one... (There may be a reader out there that remembers the trouble that we caused a classmate once by sticking a Ralphs anti-theft tag inside his Caltech ID?)

But the worst is the fact that thanks to some damn fools in some part of the US government, all Passports are supposted to use RFID to enable them to be read and validated. Not just US passports, all countries are supposed to be joining in. The tags will hold the country or origin, identifiers like the passport number itself, as well as lots of identity details of the bearer. When it was suggested that this would enable identity theft at a distance, the concern was laughed down as paranoid as well as because the tag reader is designed to work close up. But it wasn't designed to not work at a distance. And close up is enough of a threat. It wouldn't be at all difficult to leave a package in a taxi that will act on the next American (or...) to get in the cab.

The US will start issuing Passports with RFID in late 2005, so renew now to avoid the pesky things for 10 more years in hopes that they come to their senses.

For most of these applications, optical codes of one sort or another are a much better solution. For passports, especially, a 2D code could be used on an inside page, allowing many KB of data to be carried, robustly read, and avoid any possibility of accidental information leakage.

I do carry a SpeedPass, but the mechanical design of a gas station makes it highly unlikely that I could possibly pay for someone else's gas. Besides, we do check the monthly statements, and the total risk exposure is negligible since it really is fundamentally a credit card and those risks are managed by the issuer. I don't happen to own a vehicle with RFID in the ignition key, but I have heard horror stories about the cost of replacing a lost key, while (at least in the LA basin) the thief is likely to make more by chopping the car up for parts and so really doesn't care if he has keys.

All in all, it often seems like there is just plain an urge to use the highest possible tech to solve problems, even when there really isn't a problem there that needs solving.
</rant>