The following is a reply I recently sent to Terrence Barr at Sun.com. We've been corresponding on the state of J2ME development. He sent me a PDF describing the new Java Verified program as unveiled at Java One and asked me my opinion of it.. Upon reflection and re-reading I realized that my reply incorporated a number of new arguments in support of the theme that is the focus of this site. So I've included it here as another page on the subject. Here is my reply to him:

==========

I looked over the PDF. Here's my thoughts on Java Verified.

I fundamentally disagree with the apriori assumption that application verification should be bundled with application signing. I believe the two are fundamentally different. It is in the interests of both the carriers and the proponents of the Java Verified initiative to blur this distinction.

The purpose of application SIGNING is two fold. First and foremost it ensures the user that the signed application hasn't been altered by patching or other binary tweaking. This is probably the most important aspect of signing in general. Note that an application could be SELF SIGNED by the developer and still have this benefit given a developer provided key. MD5 signatures are analogous.

The second purpose of SIGNING is to provide some assurance that the author that signed the code actually is a real identifiable person/entity. This benefit may be harder for the end user to actually realize but the idea is that if they want to exercise some recourse or inquiry regarding an application, they have some evidence that there is a real person/entity to address. In other words, they can tell their lawyer who to sue.

Now NONE of that has anything to do whatever with the QUALITY of the application in question or any particular suitability for purpose. QUALITY and/or SUITABILITY is a completely different question. I believe that Java Verified is at the very least self serving and at the worst a defacto accessory before the fact to the carrier hegemony by participating in the propagation of the fiction that SIGNING and SUITABILITY are conjoined twins. They are not.

I don't have a problem with requiring application signing to gain unprompted access to some API's (those that incur network charges for example.) I have a harder time seeing it for things like Bluetooth which are benign in terms of connectivity charges. Yes, I'm aware of pranksters using BT for "bluejacking" and the like but it's worth noting that they typically use messaging apps already built into the firmware and not 3rd party J2ME apps to do this. So why make the J2ME developer pay for what isn't even fundamentally a J2ME "sin."

But requiring that the developer also pass very expensive (typically running into the thousands of dollars per version) application testing in order to SIGN his app (and thereby gain access to the API's) is where I leave the party. That kind of arbitrary linkage puts practical development out of the reach of all but the most well heeled developers. It's nothing more than a shallowly disguised revenue pump for those that control the process. Imagine the revenues for Microsoft if they could somehow insist that every piece of software written for Windows had to be "Windows Verified." Don't get me wrong. I have no beef with the Java Verified folks providing a service and trying to convince developers of the advantages marketing and otherwise to be had by availing themselves of it. But in the PC world, I can choose to install a Java program and run it at my own risk under my own recognizance as a consumer without it being "Java Verified." Imagine the uproar that would occur if Microsoft elected to put code into Windows that would refuse to run any .exe without nags unless it was "Windows Verified." Imagine how many very useful shareware programs that would take out of the market and which would never have (as has happened in many cases) made it to eventual commercial success on their OWN MERITS. I'm sorry, but Java Verified is just that kind of thing because they've linked API access to mandatory and very pricey testing. By acting in collusion with the vendors/carriers to promote this kind of restriction, they are just as guilty and open to the same and worse condemnation that the open developer community has heaped on Microsoft for not being "open" with Windows API's (by way of documentation rather than certification perhaps but the means of restriction is beside the point.)

The bottom line is that any developer should only have to pay a reasonable fee for the certificate authority to do an acceptable verification of identity and to cover the costs of generating the certificate and maintaining the certificate record. That certificate should suffice to sign any and all versions of the developer's product. While I'm on that thought, think about the built in IMPEDIMENT to quality that linking certification to validation imposes. The sheer cost of retesting will surely discourage a small to medium sized business from making IMPROVEMENTS (let alone bug fixes) in their software because it must be retested (at significant cost) every time a byte changes. That is simply ridiculous.

Unequivocally, code signing should be completely distinct from code validation. If I want to install some piece of shareware on my phone that I got from sourceforge or Tucows I should be able to do so and it should run unfettered with appropriate warnings if it is unsigned. If I want to be sure the code is as the author intended and that I have a shot at recourse to the author if needed then I can CHOOSE to run only signed apps on my mobile device. If it is signed then the warnings can be reduced or eliminated. If I want as a consumer to only run applications that have been thoroughly tested and certified by some third party testing house then I should be willing to pay the extra cost that the vendor will have to charge in order to be able to pay the thousands and thousands of dollars he'll have to pay to maintain that certification over the life of the product.

I don't know about you but over the years some of the most USEFUL software I've run on my PC has been some piece of shareware that solved a particular problem/need. Most of it cost $30 or less to register (and a good bit is actual "freeware.") That kind of software would never have seen the light of day if the developer had had to pay Microsoft thousands of dollars to "test" his app before Windows would let me run it on my PC. Somehow ATT et al has been able to inflict restraint of trade practices that Bill Gates could only dream of and so far they've gotten away with it.

Frankly, all things being equal, I don't want to see the carriers "get in bed" with the Java Verified program. I think efforts to do so are just a thinly disguised attempt to accomplish the same oligopolistic restrictions by merely adding another player to the oligopoly (Java Verified is just a new partner with the carriers.) If Java Verified wants to sell their testing services that's fine. If they want to sell their logo to those that are interested, that's fine. But when they cross the line in becoming a "gateway" to the useful J2ME API's on devices, they've become a worse "villain" in the eyes of the developer world than Micro$oft could ever be short of making Vista only run "Windows Verified" apps. Come to think of it, with what I'm hearing about the new security hoops in Vista (not to mention about a half dozen versions) they may be making a run at the software equivalent of the Darwin awards. My next PC is very likely going to be a MAC when I can no longer get XP.

So the bottom line for me is that the fatal flaw in the Java Verified program is the failure to distinguish code signing from quality assurance. The two just aren't the same thing. But I'm quite sure that is a deliberate confusion. Face it, the ONLY reason for me to jump through their testing would be to obtain the certificate to obtain unfettered execution on the target device. It wouldn't be quality. Every developer knows that the ultimate test of quality for a program is real world experience by real users. No testing lab on earth can match the brutality of the real world. The open market is the ultimate testing lab. The Java Verified folks know that if quality assurance was the only incentive (that is, take away the arbitrary restrictions on program execution) then they'd not have nearly the market. What that means is that no matter how much they trumpet their testing services (read where they really make their money) what they are really selling is something else. They are merely forcing developers to buy one thing to get another. If they want to sell quality through testing, fine. Sell that. If they can con carriers into deals whereby the carriers agree to distribute only Java Verified apps via their channels, fine. But when they both collude to limit the meaningful creation, distribution and dissemination of mobile applications via OTHER channels (the internet, shareware, etc.) by arbitrary and self serving locks/limitations in the mobile device firmware then they've become equally villains in the eyes of the developer community.

Java Verified as it is currently incarnated is just as guilty of holding the meaningful and useful J2ME API's "ransom" to arbitrary and expensive barriers in the guise of "quality" as the carriers. All the attached PDF really tells me is that some of the carriers have suborned Java Verified over to the "dark side." How far do you think J2SE would get if something like the file I/O or network connection API's were off limits to developers without expensive certs obtained from Sun? That's what is going on here. That's why it will spell the death of J2ME for both Sun, Java Verified and even the carriers if it's not fixed.

The promise of J2ME will never be realized if this sorry state of affairs is not fixed. Take it to the bank.

-dB