http://www.developer.com/java/data/article.php/3085111/JCP-Watch-J2ME-Location-API-Java-OLAP-and-XML-Streaming.htm
The Location API for J2ME which provides an interface to positioning systems like GPS was approved in it's final ballot making it an endorsed Java standard. Further, proposed final draft specifications for XML Streaming API‘s, Java OLAP and Portlets were released. New JSR's relating to data synchronization and mobile payments were also proposed. Two new JSR's were proposed for the J2ME platform. The purpose of this JSR is to define the following: Both will allow 3rd party developers to build applications with control of features and services that are chargeable. The JSR API may include methods for The provisioning data definitions take care that service providers and payment service providers can select a suitable set of payment instruments provisioned for applications during the application deployment time. Primarily payment instruments addressed will be This JSR will provide a solution to allow J2ME application developers to gain revenue at a finer grained basis controlled directly from within J2ME applications, i.e. pay per level, and pay per feature etc. rather than pay per application or pay per download. This JSR differs from JSR–182 (Payment API for the Java platform) in the following way: while JSR 229 will define an API between a mobile application and a payment facility, JSR-182 concentrates on handling of payment interactions with web-based services. Therefore, JSR-182 could be used to implement one of the payment methods as supported by this proposal (i.e. JSR–182 is one possible payment instrument). This JSR will be under public review until 6th October 2003. To contribute, send an email to jsr-229-comments at jcp.org. This JSR will be a J2ME optional package to enable mobile applications to synchronize their application specific data stored in the terminal with corresponding data stored on a server (or any other target) replicating any changes made to either instance of the data. It intends to provide a generic interface to the data synchronization device implementation, to enable data synchronization via underlying implementations of data synchronization protocols. One example of the data synchronization protocols to be accessed from Java applications will be SyncML / OMA Data Synchronization. This JSR will be under public review until 6th October 2003. To contribute, send an email to jsr-230-comments at jcp.org. One JSR‘s was approved for further development under the guidelines of the JCP. This JSR's were approved via ballot voting by the Executive Committee members. (http://jcp.org/en/participation/committee) This JSR will define a J2ME profile targeting embedded networked devices that wish to support a Java runtime environment similar to the Mobile Information Device Profile (MIDP) version 2.0, but that do not provide the graphical display capabilities required by MIDP 2.0. The Information Module Profile – Next Generation (IMP-NG) will be a strict subset of MIDP 2.0, where at least the APIs relating to GUI functionality (the LCDUI) are removed. Functionality not already present in MIDP 2.0 is not anticipated or desired. The primary focus of this "IMP–NG" specification scope will address: The following JSR‘s were released for public review. Java Database Connectivity (JDBC) specifies a Rowset interface which allows programmatic access to manipulate and view tabular data stored within a database. However, JDBC does not specify any proposed implementations which is what this JSR intends to provide, a guideline for implementations of the Rowset interface. The public review of this specification ends on September 27th 2003. To contribute, send email to jsr–114–comments at jcp.org. The review and reference implementation are available at http://jcp.org/aboutJava/communityprocess/review/jsr114/index2.html. The JAIN (Java Advanced Intelligent Network) API's are a set of libraries that enable the rapid development of Next Generation telecom products and services on the Java platform. The JAIN APIs bring service portability, convergence, and secure network access to telephony and data networks. Java Coordination and Transaction (JCAT) includes (but is not limited to) the facilities required for applications to be invoked and return results before, during or after calls; to process call parameters or subscriber-supplied information; and to engage in further call processing and control. The JCAT JSR will extend another JAIN API called Java Call Control (JCC) which provides the facilities required for observing, initiating, answering, processing and manipulating calls, where a call is understood to include (but is not necessarily limited to) a multimedia, multiparty session over the underlying integrated (PSTN, packet and/or wireless) network. JCAT will extend JCC with concepts to model and control terminal capabilities. This enriches JCC's state transitions models by giving more control over its processing. The public review of this specification ends on September 26th 2003. To contribute, send email to Jbakker at telcordia.com. The review and reference implementation are available at http://jcp.org/aboutJava/communityprocess/review/jsr122/index.html. The Community Draft Specification is the specification developed in collaboration by members of the expert group for the JSR. The following community draft specifications were approved via ballot voting by the Executive Committee members. (http://jcp.org/en/participation/committee) This JSR will define a dense download format for Java classfiles. It is expected that this format can achieve considerable size savings over compressed JAR files. Currently the Java platform uses Java Archive (JAR) encapsulation of these applications and their classes. The Java archive format can compress these classes at the byte level only, leading to a meager reduction factor of about two. There is a need to compress the classes much more efficiently, thus making network transfers faster and therefore more reliable. As a starting point, the Sun developed PACK format, which has been successfully tested to achieve reduction factors of 7–9 will be used. Metadata are annotations that mark particular fields, methods, and classes as having attributes that should be processed in special ways by development tools, deployment tools, or run–time libraries. For example, the JavaBeans architecture introduced various stylistic naming patterns (such as getFoo/setFoo method names) that could be used to indicate that particular methods were used for accessing properties, for registering event handlers, and so forth. Similarly the Enterprise JavaBeans architecture introduced various stylistic patterns that allow methods to be marked as remote methods, home methods, and the like. The EJB architecture defines significant extra information in its deployment descriptors that is used to provide information on things like the persistence relationships of fields, the transactional properties of methods, and so forth. Source code defining web services components has similar needs. Custom tools may use metdata to generate auxillary source files to be used in conjunction with the source file containing the annotation. For example, a stub generator could generate remote procedure call stubs based on annotations indicating that certain methods are designed for remote use. This JSR intends to add to the Java programming language a means of associating arbitrary attribute information with particular classes/interfaces/methods/fields. This mechanism is referred to as the Java programming language metadata facility. This facility is meant to replace the various ad hoc metadata facilities in use today. This JSR will For a detailed explanation of the features this JSR implements, please refer my previous article describing the features of the Java 1.5 platform release (http://www.developer.com/java/other/article.php/2213791) This JSR will modify and extend the Java Class File format to support updates to the Java platform and language specifications. The JSR will add support for quicker and more efficient byte code verification, class literal support directly from the class file format and will increase certain implicit size limits within the class file. This JSR proposes four new JavaTM programming language features: enumerations, autoboxing, enhanced for loops and static import. For a detailed explanation of the features this JSR implements, please refer my previous article describing the features of the Java 1.5 platform release (http://www.developer.com/java/other/article.php/2213791). This JSR aims to define a new version of the Java Community Process to address some of the day-to-day issues of Spec Leads and Expert Groups through relatively minor, easy to implement changes to the process. None of the changes require modification to the participation agreements (the JSPA or IEPA). This JSR will not consider any issues that are difficult to implement or that require changes to the JSPA. In particular this JSR will address the following issues: The Specification Lead, Aaron Williams of Sun Microsystems sent out a call to all those involved in the JCP process. Since this is a community effort, I would like to reproduce the contents of the email sent he sent out and encourage readers of this column to participate “This update (to the JCP) is designed to encourage JSRs to be more transparent to the community and public, and to make it easier for people to get more meaningfully involved in the work of the community. JSR 215 entered Community Review last Friday, and the expert group is working now to ensure we get as much feedback as we can during this review period. To this end, we have decided to open our community review to the public. We would really appreciate you taking the time to download and review the materials, and provide comment and feedback. Those materials can be found here: http://jcp.org/aboutJava/communityprocess/review/jsr215/index.html” Please help make the JCP an ideal model for developing community endorsed standards by downloading, reviewing and providing feedback! This JSR is an update to JAXP 1.2 (JSR-63 Java API for XML Processing 1.2) to support the current evolving XML processing standards. The revised XML standards incorporate changes based on several years of growing implementation experience. In particular this update will address the following revisions of core XML standards such as DOM Level 3 Specifications, XML 1.1 and related Namespaces specifications and SAX 2.0.1. This update will also focus on improving performance of XML processing, allowing better client control over the characteristics of the XML processor, XInclude support and support for future revisions to XPath and XSLT. The Java Language and VM specifications specify the semantics of threads and locks, as well as related features such as volatile variables. Unfortunately, the current specification has been found to be hard to understand and has subtle, often unintended, implications. Certain synchronization idioms sometimes recommended in books and articles are invalid according to the existing specification. Subtle, unintended implications of the existing specification prohibit common compiler optimizations done by many existing Java virtual machine implementations. Enforcing these aspects of the specification would be prohibitively expensive on many existing processor architectures. It is doubtful that enforcement of these implications would be useful to programmers, regardless of the cost of enforcing them. Several important issues, such as the interaction between synchronization and final fields, simply aren't discussed in the existing specification. The proposed specification describes the semantics of threads, locks, volatile variables and data races. The specification is expected to revise substantially Chapter 17 of “The Java Language Specification” and Chapter 8 of “The Java Virtual Machine Specification”. It is not expected to result in changes to existing APIs, but might clarify the semantics of some existing methods in java.lang.Thread and java.lang.Object (java.lang.Object defines the wait and join methods). This will enable Java programmers to write reliable multithreaded software and understand which thread communication idioms are legal. It will also allow Java virtual machine (JVM) implementors to implement specification compliant and high-performance JVMs. Low-level threading primitives, such as synchronized blocks, Object.wait and Object.notify, are insufficient for many programming tasks. As a result, application programmers are often forced to implement their own higher level concurrency facilities. This results in enormous duplication of effort. Further, such facilities are notoriously hard to get right and even more difficult to optimize. The concurrency facilities written by application programmers are often incorrect or inefficient. Offering a standard set of concurrency utilities will ease the task of writing a wide variety of multithreaded applications and generally improve the quality of the applications that use them. This JSR has aims analogous to those of the JDK1.2 Collections package: The implementation will consist of interfaces and classes that tend to be useful across diverse programming styles and applications. These classes include: Session Initiation Protocol (SIP) is an upcoming standard for establishing sessions over an IP networks. SIP is a signaling protocol similar to tone based dialing on telephone networks. SIP specifies how to establish, maintain and terminate a simple two-way telephone call or a collaborative multi-media conference session over an IP network. The goal of this JSR is to provide an API that allows SIP protocol handling for the Java Microedition enabling SIP support for small devices. The specification is available at http://jcp.org/aboutJava/communityprocess/first/jsr180/index.html. To contribute, send email to jsr-180-comments at jcp.org. Portlets are web components much like Servlets specifically designed to be aggregated in the context of a composite page. Usually, many Portlets are invoked to in the single request of a Portal page. Each Portlet produces a fragment of a page that it s combined with the fragments of other Portlets, composed within the Portal page. The Portlet specification will define the different components for Portal Computing, their interaction, lifecycle and semantics. These components will comprise -but they will not be restricted to-: Portlets, Deployment descriptor, Portlet APIs. In addition, APIs for vendor extensions, APIs for security, user customization and layout management will be considered. The Portlet specification will be based on the Servlet specification. It is envisioned that the developer API will be similar to the Servlet API. The specification and reference implementation are available at http://jcp.org/aboutJava/communityprocess/first/jsr168/index2.html. To contribute, send email to jsr-168-comments at jcp.org. The goal of this specification is to develop APIs and conventions that support processing XML as a stream of XML (as opposed to using a document metaphor for processing). The specification will address three main areas: The specification and reference implementation are available at http://jcp.org/aboutJava/communityprocess/first/jsr173/index.html. To contribute, send email to jsr-173-comments at jcp.org. The Java community needs a standard way to create, store, access and maintain data and metadata in OLAP systems serving J2EE–compliant application servers. Currently, there is no widely-agreed upon, standard API for doing this. By using JOLAP, implementors of OLAP systems can expose a single, standard API that will be understood by a wide variety of client applications and components running on the J2EE Platform. Similarly, OLAP clients can be coded against a single API that is independent of the underlying data resource (e.g., native multidimensional database versus relational star-schema). The ultimate goal of JOLAP is to provide for OLAP systems what JDBC did for relational databases. The JOLAP specification will address the need for a pure Java API that supports the creation, storage, access and maintenance of data and metadata in OLAP servers and multidimensional databases. The specification is available at http://jcp.org/aboutJava/communityprocess/first/jsr69/index.html. To contribute, send email to jsr–69–comments at jcp.org. At this stage the final specification, Technology Compatibility Kit (TCK) and reference implementations are available for developers to use. This specification will define a generic interface for positioning. As such, this API shall work with most positioning methods, such as GPS or E–OTD, but the core API will not expose features that pertain to one technology only (however it may allow extensions for specific purposes). You may download the final specification from http://jcp.org/aboutJava/communityprocess/final/jsr179/index.html. What do you think of the JCP? What do you think of the current JSR's? Do you have any suggestions for this column? Feel free to write to me at apu at jcpwatch.org.
JCP Watch: J2ME Location API, Java OLAP and XML Streaming
September 29, 2003
New JSR's
JSR–229 Payment API
JSR–230 Data Sync API
Approved JSR‘s
JSR–228 Information Module Profile – Next Generation (IMP–NG)
Public Review Specifications
JSR–114 JDBC Rowset Implementations
JSR–122 JAIN JCAT
Community Draft Approvals
JSR–200 Network Transfer Format for Java Archives
JSR–175 A Metadata Facility for the Java Programming Language
JSR–202 Java Class File Specification Update
JSR–201 Extending the Java Programming Language with Enumerations, Autoboxing, Enhanced for loops and Static Import
JSR–215 Java Community Process version 2.6
JSR–206 Java API for XML Processing (JAXP) 1.3
JSR–133 Java Memory Model and Thread Specification Revision
JSR–166 Concurrency Utilities
Proposed Final Draft Specifications
JSR–180 SIP API for J2ME
JSR–168 Portlet Specification
JSR–173 Streaming API for XML
JSR–69 Java OLAP Interface (JOLAP)
JSR Final Release
JSR–179 Location API for J2ME
Resources:
