Java News from Tuesday, December 27, 2005

Oracle has posted the early draft review of JSR-227 Data Mining 2.0 to the JCP. According to the draft,

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 such supervised and unsupervised 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.

Comments are due by January 9.


Sun has posted the proposed final draft of Java Specification Request (JSR) 220, Enterprise JavaBeans 3.0 in the Java Community Process (JCP).

The EJB 3.0 release is focused on a simplification of the Enterprise JavaBeans architecture from the developer’s point of view. This simplification has several main aspects:


Sun has posted the public review draft of JSR-221 JDBC 4.0 to the Java Community Process (JCP). New features in 4.0 include:

Comments are due by January 23.


Sun has posted the early draft review of JSR-231 Java Bindings for OpenGL to the JCP. This describes the Java bindings to a native OpenGL 3D graphics library. Comments are due by January 23.


Sun has also posted the public review draft of JSR-239 Java Bindings for OpenGL ES to the Java Community Process (JCP). According to the draft:

JSR 239 defines an optional package that may be run on a number of Java Micro Edition (Java ME) platforms including CLDC 1.1/MIDP 2.0, CDC 1.0/Personal Basis Profile, and CDC 1.0/Personal Profile, as well as backwards-compatible versions of those platforms.

The OpenGL ES and EGL APIs are defined by the Khronos Group (www.khronos.org). OpenGL ES defines two profiles: the Common profile and the Common-Lite profile. The Common-Lite profile is a 32-bit fixed-point profile, while the Common profile supports floating point. The Common profile is a superset of the Common-Lite profile. This specification provides bindings to the Common profile (including all fixed-point functions). No separate specification addresses only Common-Lite.

JSR 239 requires an underlying native engine that has been certified by Khronos to be conformant with the OpenGL ES and EGL APIs. This engine must support version 1.0 of the OpenGL ES and EGL and all core extensions associated with those APIs. It may optionally support version 1.1 or the OpenGL ES and EGL APIs; if not, certain methods of the bindings will throw a java.lang.UnsupportedOperationException. Bindings are also provided for all currently defined optional profile extensions, including the extensions in the OpenGL ES 1.1 Extension Pack.

Comments on this are due by January 9.


Nokia has submitted JSR-287, Scalable 2D Vector Graphics API 2.0 for J2ME to the Java Community Process (JCP). According to the JSR,

This specification will define an optional package for rendering enhanced 2D vector graphics and rich media content based on select features from SVG Mobile 1.2 for Java ME platform, with primary emphasis on MIDP. This API will be designed as an extension to JSR 226, and therefore must remain to be fully backwards compatible with JSR 226 applications and Scalable Vector Graphics (SVG) rendering model. The primary use cases for this API are interactive maps with rich graphics, scalable user interfaces, rich media services, games, entertainment, and other compelling graphics applications aimed at mobile devices.

The API is targeted at mass market devices that typically have limited processing power and memory. The API shall be defined such that implementations on these target devices are feasible and allow utilization of underlying native SVG implementations of the device.

The scope of the API should include the following:

  1. Extend Features in JSR 226
    1. Add the ability to create and modify animations. Not having the ability to create or modify animations makes application development using 226 a bit of a challenge.
    2. DOM serialization to allow compelling use cases. Note: this should be designed to avoid large performance overhead, and avoid any security issues.
  2. Support for select SVG Mobile 1.2 features

    SVG Mobile 1.2 is the next-generation profile for scalable vector graphics. It brings a substantial set of compelling features such as support for opacity, gradients, advanced text rendering, and embedded multimedia (audio, video). The features to be included from the SVG Mobile 1.2 specification must be carefully chosen not to compromise the important requirements for this JSR such as high performance and low implementation footprint, especially for the low-end mass market devices.

  3. Support for additional uDOM APIs from SVG Mobile 1.2

    Currently JSR 226 supports only a subset of uDOM as defined in SVG Mobile 1.2 specification. The proposed JSR will expand the support of uDOM subset to support new interfaces that are only relevant to the use cases envisaged in this document. It is important to note that during this process of subsetting, any changes or issues that may affect the SVG Mobile 1.2 specification will be coordinated with W3C SVG working group to ensure compatibility between JCP and W3C specifications. For the generic XML DOM API part, the work will be closely coordinated with JSR 280 in order to have a common solution for the XML DOM API.

  4. Support of Rich Media content Streaming

    Rich media content update and streaming is gaining high importance in the mobile domain, especially with new work-items in both OMA and 3GPP standards. Such technology is also important for Java ME platform to allow or offer rich media solutions based on SVG Mobile 1.2 which already specifies mechanisms to embed and display rich media data such as graphics, video, audio and text. At the minimum, this JSR intends to define a scene update syntax and APIs to allow rich media services or applications to dynamically update the content on the client terminal with minimum processing overhead.

  5. Advanced immediate-mode rendering APIs (compatible with OpenVG)

    OpenVG defines a standard 2D graphics for hardware acceleration, particularly for vector graphics content such as SVG, Flash, and GUI. We would like to investigate possibilities of defining such an immediate-mode API that can take advantage of this standard.This work however, needs to be coordinated with other Java ME JSR expert groups to minimize overlaps.


Sun has also posted the maintenance review change log for JSR 185: Java Technology for the Wireless Industry specification. There are only two changes, both focusing on increasing the flexibility of security policies. One is to "Allow the JTWI Security Policy (defined in JTWI Specification, Chapter 7) to be revised and/or superseded in new JCP platform JSRs such as JSR 248." The second is to allow "operators and device manufacturers to override and redefine certain aspects of the JTWI security policy." Comments are due by January 16.