It's not very fun, actually.
I've been using Mirah (a simple Ruby-esque language with basic type inference that compiles to Java bytecode without a runtime dependency), so at least I don't have to write Java, but the Kindle framework itself feels very beta.
My two apps have been bouncing back and forth with QA for several months---Amazon QA does an amazing and through job (including user testing + feedback), but it is frustrating to work around the framework so often in my application code.
For instance, it takes on the order of seconds to load and display an image (not the e-ink display, but actually reading the image into memory).
The framework requires that an app starts up in roughly 5 seconds, so I've spent a lot of time spinning up threads to load images in the background.
But then you need to make sure these threads are stopped when the app exits (or goes into screensaver), and the framework sometimes calls stop() before start(), &c. &c.
Oh, and you can only test this on the hardware itself, because the simulator doesn't emulate the Kindle CPU (it just runs using your system's Java)
To get more of a feel of what you're in for, check out this forum post + Java sample code:
A limited version of Java 1.4, the UI set is custom build, Writing a kindlet bit similar to writing an old fashioned applet.
Limited memory/processing power though, but you can do fun some stuff, but the eInk slow refresh rates is the largest limitation.
There is no functional app store, right? There is an app I'd make on Kindle if the distribution channel works. Now I'll make it for iPad and maybe Android tablets.
