Sun has posted the proposed final draft of JSR-270 JavaTM SE 6 Release Contents to the Java Community Process (JCP). I don't think there are any surprises here, but it's worth reading over. Component JSRs include:
Other possible additions include:
java.util.concurrent updatesSun has also posted Maintenance Review 2 for the JavaTM Platform, Standard Edition, Version 6. "This document provides descriptions of specification changes being made in version 6 of the Java™ Platform, Standard Edition (Java™ SE 6). Version 6 includes a set of new Java Specification Requests (JSRs) that introduce major new functionality. This Maintenance Review does not cover new APIs defined through those JSRs; it documents only smaller changes made under the JCP Maintenance Review process. Moreover, this Maintenance Review does not cover updates to specifications that are contained in Java SE 6 but that are also available stand-alone. Separate Maintenance Reviews will be held for any changes to such specifications. The descriptions in this document correspond to platform changes made since the release of Java SE 6 Beta. The specification change descriptions are provided for purposes of Java Community Process public maintenance review." There are lots of small but significant changes throughout the API. For instance, it's now possible to set the buffer size for pipe streams. Comments are due by November 13.
Sun has posted the sixth maintenance review change log for JSR 154: Java Servlet API 2.5 . Changes appear quite minor. Comments are due by November 6.
Sun has also posted a maintenance review change log for JSR 245: Java Server Pages 1.1 . "The purpose for the proposed changes to JSR-245, JavaServerTM Pages 2.1 Specification (JSP 2.1) is to take the expression language (EL) out of JSP 2.1 and make it a self-contained specification. The next version of the JSP specification will remove the description of the expression language and will instead reference and depend on the EL specification." Comments are due by November 6.
Motorola and Nokia have posted the finished draft of JSR-232 Mobile Operational Management to the Java Community Process (JCP). According to the document:
The Mobile Operational Management API specification defines an optional package1 for the Java 2 Platform, Micro Edition (J2METM). The specification has been produced in response to Java Specification Request 232 (JSR-232), and specifies the a component management framework that will allow mobile devices based on the J2ME TM Connected Device Configuration to evolve and adapt their capabilities by installing new components on demand. These components can be a combination of active elements with no user interaction (services), active elements with user interfaces (applications), and shared libraries (both native and Java). The framework will also provide for multiple applications to coordinate the use of sharable services. In order to ensure a safe environment, these components will be controlled via a mandatory security model based on the JavaTM 2 Platform security model.
Sun has posted Maintenance Review 2 for Java Data Objects 2. The changes look quite significant, and include better use of java 5 features, as well as documentation clarifications and assorted new methods. Comments are due by November 20.
Oracle has posted the public draft review of JSR-247 Data Mining 2.0 to the JCP. According to the draft,
The Java Data Mining (JDM) specification addresses the need for a pure Java API to facilitate development of data mining-enabled applications. Whereas the term “data mining” can be interpreted in different ways, we distinguish it from the querying of large databases or online analytical processing (OLAP), which are largely deductive technologies. Querying and OLAP rely on users to formulate queries and design constructs which can then be manipulated and interrogated. Data mining, and the more fashionable term predictive analytics, involves inductive technologies, that is, those that extract previously unknown knowledge from a potentially large volume of data.
Existing data mining APIs are proprietary. Using JDM, implementers of data mining applications can benefit from a single, standard API that will be understood by a wide variety of developers writing applications and components running on the Java™ 2 Platform. Similarly, data mining applications can be coded against a single API that is independent of the underlying data mining system. JDM targets for the JavaTM 2 Platform, Enterprise Edition (J2EETM) and Standard Edition (J2SETM).
In JDM 2.0, data mining [Mitchell1997, BL1997] includes the functional areas of classification, regression, attribute importance, clustering, association, feature extraction, time series, and anomaly detection. These are supported by a variety of learning algorithms as decision trees, neural networks, Naive Bayes, Support Vector Machine, K-Means, Apriori, Non-negative Matrix Factorization, and ARIMA.
JDM supports common data mining operations such as model build, test, and apply (score). JDM also supports the creation, persistence, access, and maintenance of metadata supporting mining activities. Also in JDM 2.0, the standard includes extensions for basic text mining, statistics, and transformations integrated with the mining process. A particular implementation of this specification may not necessarily support all interfaces and services defined by JDM. However, JDM provides a mechanism for discovery of supported interfaces and capabilities.
In JDM 1.0, we leveraged data mining standards such the Object Management Group’s Common Warehouse Metadata (CWM) [CWM, CWM-DM], ISO’s SQL/MM for Data Mining [SQL/MM-DM], and the Data Mining Group’s Predictive Model Markup Lan- guage (PMML) [PMML]. We continue reviewing these standards for JDM 2.0 to help ensure greater consistency across standards where possible. Implementation details of JDM are delegated to each vendor. A vendor may decide to implement JDM as a native API of its data mining product. Others may opt to develop a driver/adapter that mediates between a core JDM layer and multiple vendor products. The JDM specification does not prescribe a particular implementation strategy, nor does it prescribe performance or accuracy of a given capability or algorithm.
Comments are due by December 4.
Nokia has released the finished version of JSR 257, Contactless Communication API. This is basically an API for tracking RFID devices attached to products, pets, people, and anything else a corporation or government cares to know about.
Nokia and Vodafone have posted the proposed final draft of Java Specification Request 258, Mobile User Interface Customization API, to the Java Community Process. According to the draft,
This specification defines Mobile User Interface Customization API ( JSR 258), a Java Micro Edition optional package that allows software developers to query and manipulate the appearance of a mobile device user interface, and introduces a common exchange format for appearance data, to be used by content developers and distributors.
Personal mobile devices are typically equipped with a graphical user interface. It provides a rich user experience, and in many devices it can also be customized. Users are able to change background images, color schemes, ringing tones and alert tones, and other features to their liking. Proprietary methods of grouping collections of customization settings and related content as "themes" have been established by device manufacturers, to enable end users to more easily change them in one operation.
The kind of user interface customization related to appearance described above has become increasingly popular as the graphics and sound capabilities of mobile devices have been greatly enhanced. Different user interface themes are used not only by individual users to personalize their devices, but also by telecommunications operators/carriers and device manufacturers to establish their brand and make the user experience more appealing, more seamless and more predictable in terms of appearance.
In addition to systemwide user interface customizations, also individual applications can often be customized to have a distinct look, using both application-specific user interface elements created by the application and customized appearances for system user interface elements.
Motorola has posted the public review draft of JSR-263 Fault Management API to the Java Community Process (JCP). Quoting the executive summary,
Currently, the OSS fault management functionality supported by an OSS through JavaTM API is contained within the OSS Quality of Service API (JSR90). A software vendor that wishes to only implement fault management functionality is faced with the dilemma of being “partially compliant” to the OSS Quality of Service API”; and partially compliant is simply a statement that software vendors would prefer not to make.
This API, The OSS Fault Management API (JSR 263) was initiated to separate the two APIs, fault management and performance management from each other to enable software vendors to implement those portions that they would like to implement, and to be able to make the statement that their product is compliant to one or both of the aforementioned APIs.
The OSS Fault Management API focuses creating an interoperable fault management API that is compatible with the 3GPP Release 6 Alarm IRP. In accordance with the OSS through JavaTM Design Guidelines, the API defines JVT, XML/JMS and Web Service implementation profiles.
The design of the API leverages the design patterns defined within the aforementioned OSS through JavaTM Design Guidelines to ensure that the look, feel and usage of the OSS Fault Management API is familiar to anyone that has studied, implemented or used another of the OSS through
Comments are due by November 6.