Abstract

The balkanization of the Java ME platform is undoubtedly its weakest point. As you’ve seen in the chapters throughout this part, a number of optional APIs enable you to create compelling applications for the platform. Unfortunately, it’s often difficult to determine which devices support which of these APIs, and if you use more than a few optional APIs in your application, you’ll need to manage the combinatorial explosion that results from the number of different optional APIs that may or may not be on target devices in the market. This fragmentation is an undesirable side effect of the JCP; as vendors attempt to extend Java ME to support their device’s features, they propose new extensions to the Java ME platform. The JCP works reasonably well in ensuring that when different vendors differentiate products, the new features are available via a common API. However, it suffers from the presence of too many optional APIs from which to choose. Many organizations active in the JCP recognize this problem and have proposed several JSRs to address this problem.KeywordsSession Initiation ProtocolCommon PlatformOptional APIsRecord StoreCompliant DeviceThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call