I have been working with embedded systems for 20+ years, starting at an IBM research lab with assembly code and hardware design of a multi-68000 CPU. This was the original 68000 running at a mind-boggling 4 MHz (about 4X faster than other controllers of the day), and packaged in a huge 68-lead DIP which we called the "Hershey bar package". I hated programming until I discovered C in the mid-1980s. I'm a degreed Electrical Engineer with a math minor and some graduate course work. I've been an adjunct assistant professor at the University of Utah School of Computing where I taught the CS/CE 4710 class for three years. Most of my microcontroller hardware design experience is on 8051s, including the high speed Dallas cores 80C320/520/530/550/390/400, Intel/AMD 80188, and some bit slice and other odd bits here and there. Many of these systems were "soft" realtime and some were "hard" realtime with possible loss of life (mine, in at least one case!) if the system failed unsafely. A lot of these systems were mixed analog and digital (like the estuaries where fresh- and salt- water meet, that is usually where the interesting stuff happens). I've designed successful systems which included laser diodes, high precision optics, photodetectors, hydraulic pumps, servovalves, stepper and DC motors, LVDTs, satellite communications links, high speed graphics coprocessors, video interfacing, etc. I have designed ASICs, boards and multi-board systems. Systems were programmed in realtime embedded BASIC, assembly code and C. I've also worked on some systems which were technical and/or marketing flops.

I wrote and self-published a book documenting the Intel 8052 BASIC interpreter, and it has sold over 10,000 copies worldwide. At the time, BASIC was the best choice for an easy to use embedded system. In case you are wondering, this predated the BASIC Stamp. In fact, I met with Chip Gracey of Parallax when he was still working out of his apartment. We discussed the future of embedded systems and how we might collaborate on it. I pitched BASIC as the language of choice, and left him a copy of my book. He was dubious about BASIC at first but the rest -as they say - is history. This meeting planted the seed of what Chip grew into the very successful BASIC Stamp. Later I headed a design team which wrote the first (and maybe still the only) realtime BASIC compiler for the 8051 family. It received an EDN 100 Hot Products of the year award in 1994.

So I come from the perspective of someone who has designed embedded control hardware and sofware using the "status quo" microcontrollers programmed in C, assembly and BASIC.

Java is not the perfect tool for every job. Nothing is. A skilled craftsman doesn't try to use tools indiscriminately, but picks the best tool for a specific task. Java may not be the right choice for:

1. small, fixed purpose, simple, high-volume, price-sensitive systems. The world's largest use of 4-bit micros, at least a few years ago, was in rice cookers. We own two, and they cost under $50. I can't imagine any benefit to using anything other than assembly code, on a single-chip micro, in an application like this. This might change in the future if someone develops a practical "micro-Java", and such work is underway, for example James Caska's muvium (see the Related Sites links).
2. Systems which will never be maintained and updated. This generally means simple fixed purpose systems. I've never upgraded the firmware in any of my car stereos, microwave oven, dishwasher, etc, have you? In such systems the overhead of Java may not be worth the benefit. There's a threshhold here at which the system complexity is large enough that Java would accrue benefits.
3. Legacy apps which work fine. For example, the PalmOS and its development environment is mature and stable. Why re-write it all in Java?
Don't use any tool just to use it.
4. DSP hardware. I don't know of any available Java for DSP processors, although there are some projects underway to port Java to DSP.
5. Extremely high speed control systems. If you are using a fast bit slice or RISC chip with hand coding (by experienced people) and barely meeting your speed requirements, the last thing you need is any high level language to get in your way.
6. On a complex and already late project written in C and/or assembly. This is not the time to be learning a new tool. Java is not a "silver bullet".
7. Don't use a code converter and try to convert C to Java. Such tools exist but the anecdotal evidence is that the Java code they create is not well-written. How could it be? Object-oriented code needs to be well-engineered as such from the beginning. Conversion tools are a long way from being smart enough to do that for you.
8. But wait a minute - isn't the underlying JVM that provides all these benefits written in C? Yes, in general, it is. So your Java code *is* only as robust as the underlying JVM. But a huge amount of resources have gone into JVM development to achieve just that goal. So it makes sense to leverage that (relatively small) amount of highly reliable, extensively tested code. It's similar to why the original Macintosh and Palm devices were so popular with programmers - all the critical runtime library support was contained in system ROM and could be recycled endlessly by legions of coders.

Android is stirring up a lot of interest and controversy. If it walks like a duck and quacks like a duck, is it a duck?

Google maneuvered around the Sun Java licensing requirements by not using the Sun Java Virtual Machine. The JVM is what has to be licensed, not the use of Java Syntax or Java development tools. So Google purchase Android and developed the Dalvik virtual machine which does not create Java byte codes. This is a mixed blessing - Android apps cannot benefit from existing Java accelerators (e.g. Jazelle) or optimizers (e.g. HotSpot).

But the good news is that as far as the source code is concerned, Android is really Java.

Dalvik is, IMO, nothing like PhoneME. In my (admittedly limited) experience this is a good thing.