They say they will sign midlets with normal root certificate and cheap anough

I wanted to write some gadgets for my own mobile and got super frustrated by this signing problem. Now I don’t know enough about certificates, but I bought a HTC and found a neat solution on http://www.xs2us.eu
Lately I got a Nokia from a friend, but this doesn’t work with the same trick. So I presume there even is a difference between the way different manufacturers apply Java security ? It sucks !

$20 for 2.2 billion signing attempts for BlackBerry only, or upwards of $200-500/year for any phone.. I think I made the right choice

It is a port of a java application I made a year ago, the whole point is to be able to keep track of your gasoline purchases and be able to send the flat-file database from your phone to your computer and vice versa so that whether you’re on the go or at home you can view it.

The problem is, it always asks for users permission to access the file-system to save the database. (it only asks once for GPS on my BlackBerry). No end-user wants to have to do this.

Signing the code is so expensive, the only way I would be able to afford VeriSign(since VeriSign certificates are on MOST phones) would be to charge the end-user $20-50/year, because VeriSign costs $499/year to keep your certificate from expiring.

No one, and I mean NO ONE will pay me such an outrageous amount for such a simple midlet.

The projected number of end-users is so small and the projected number of those end-users who donate to my cause is even smaller that I’ve come to the conclusion that signing the midlet is pointless.

I paid $20(USD) to Research In Motion, Ltd. for limited-use signing keys that supposedly never expire. This was, from my perspective the best option. BlackBerry end-users will be able to use my midlet without having to be hassled. I’m creating a work-around for other end-users to be able to easily(but not as easily as having a file to transfer) where the midlet prints the database in its flat-file format to the screen so they can copy/paste it to a form on my website where it then stores the information so they can update their PC copy.

It’s a dirty hack, and javax.microedition.rms.RecordStore isn’t the best way to store the database. If I ever update the midlet the end-user would have to transfer the database to the website, then re-enter EVERY entry manually, because the RecordStore doesn’t always stick around after some midlet updates.

VeriSign and other major CA’s should offer the same cheap limited-use never-expires signing for independent developers like us that Research In Motion, Ltd does. I don’t need to sign my midlet a million times a year, I don’t plan on making too many updates, I just want it to work without hassling the end-user every 5 seconds while at the same time be platform independent.

That’s why Java was created, right? Someone needs to have a long chat with James Gosling and Sun’s board of directors, things are getting out of hand, especially with the insane cost for Java Verified.

In 14 years Java has gone from “Write Once, Run Anywhere”(WORA) to “Write Once, Run Anywhere If You Can Afford Our Steep Rates”(WORAIYCAOSR – pronounced “Whore, I Caesar!” or “Whore, I Kaiser!”)

http://blogs.s60.com/2008/10/enhancing-the-security-prompting-for-java-apps#comment-10515

However Sean Sealey’s comment is also very valuable. It seems that the misconception that the midlets _have to_ be javaverified for each device is quite widespead. I believed it for the first sight too. The reality is better fortunately. Not if paying 240 EUR, that is $360 for one version would be such a great option. It’s only viable for ‘write and forget’ types of applications, like games, etc.

Basically, there is no seek function so you can’t go seek randomly in the file. You can however close the InputStream and open a new one. This gets you back to the beginning of the file. You have to keep the FileConnection open otherwise it asks for your permission to read the file again.

I’ll post the code somewhere if people are interested…