If Sun were to dictate an extremely rigid JME no phone designer would include Java capabilities in their devices. They'd effectively be locking themselves into a very strictly defined set of capabilities and user interface options for the device, which would end all innovation and remove any chance of standing out with an improved user interface or functionality the JME spec writers didn't consider.

On MIDP devices the java language and some of the basic libraries like Collections work perfectly. When it comes to user interface the spec fails to provide what it suggests. In reality developers are forced to "Canvas programming", meaning that faulty and fragmented UI-component implementations of e.g. text fields lead developers to draw their own text fields etc. on the screen using Canvas-class or Custom Items. Given that the UI is the hardest part of the fragmentation problem, the MIDP spec offers surprisingly little support for the developer. It seems that this hard problem is almost totally dismissed and developers are offered a thin library of components with extremely uncontrolled and fragmented implementations. The UI aspect of the MIDP spec is in My opinon on experimental level, not ready for use in enterprise application clients. The spec should really assert more control over how the UI components and commands are implemented on the devices. Without such control the only usable MIDP UI class would be the Canvas. LWUIT and JavaFx might address some of these concerns but the MIDP spec is still faulty and would need some quality engineering effort and collaboration between device manufacturers.