JavaJCP Watch: Getting closer to Tiger

JCP Watch: Getting closer to Tiger


This past month, the Tiger (Java 5.0 platform) JSR and several
dependent JSRs made it past the final approval ballot. Several early access
specifications were made public under the new JCP 2.6 guidelines. Further, the
Java Wireless Messaging API was published in its final form.


Approved JSRs

One JSR was approved for further development under the
guidelines of the JCP. This JSR was approved via ballot voting by the Executive
Committee members. (


JSR-247 Data Mining 2.0

This JSR intends to extend the earlier version of the Java
Data Mining API, JDM 1.0 JSR-73 (
JDM is an API that supports data mining operations and activities. The goal of
JDM is to provide for data mining systems what JDBC did for relational
databases. Java Data Mining 2.0 will address requested features deferred from
JDM 1.0. JDM 2.0 extends JDM with requested functionality for new mining
functions, mining algorithms, and corresponding web services specification.
Features that should be considered in JDM 2.0 include, but are not limited to,
the following:


    Sequential Patterns / Time Series – mining functions to
    address forecasting and modeling seasonal or periodic fluctuations in data.

    Transformations interface – data preparation is a key
    aspect of any data mining solution. A separate JSR for transformations is
    likely warranted. Having a close integration with such a JSR and addressing
    transformations in the next version has high priority.

    Ensemble models – define composite models structured
    with logic, e.g., boosting and bagging approaches.

    Apply for Association – augment specification to enable
    prediction based on association rules.

    Text Mining – enable mining of unstructured text data
    both by explicit feature extraction and the accepting of text attributes as
    model predictors

    Model Comparison – introduce ability to compare
    multiple models according to various quality metrics, e.g., accuracy and lift
    for classification.

    Multi-record real-time scoring – enable scoring of
    multiple records in the record apply task as a performance optimization for

    Multi-target models – enable the specification of
    multiple targets for supervised models as a model performance and
    representation optimization.


    Early Access Reviews

    The preliminary draft of the specification is one that both
    the community and the public may review. Anyone with an Internet connection can
    read and comment on the draft. The expert group uses feedback from the review
    to revise and refine the draft. The following JSRs released early draft


    JSR-209 Advanced Graphics and User Interface Optional Package for the J2ME
    Platform (

    The primary goal for this JSR is to provide support for core
    graphics capabilities on the J2ME platform. It intends to migrate the core APIs
    for advanced graphics and user interface facilities from the J2SE platform to
    the J2ME platform. These facilities will include: Swing, Java 2D Graphics and
    Imaging, Image I/O, and Input Method Framework. This JSR does not intend to
    modify the existing API’s thereby making applications written to this subset of
    the graphics libraries fully upward compatible to J2SE.


    This JSR will be under review until 7th August 2004. To
    contribute, send an email to
    The specification is available for download at


    Enterprise Java Beans 3.0 (EJB 3.0) (

    This JSR is an extension to the earlier EJB 2.1
    specification ( aiming to improve the EJB
    architecture by reducing its complexity from the developer’s point of view. The
    JSR expects that metadata attribute annotations will play a large role in this simplification.
    The scope of the JSR is not limited to simplification through the use of
    metadata, however. It will consider a variety of other features that can
    promote ease-of-use. Aspects that will be considered include:


    Definition of the Java metadata attributes that can be
    used to annotate EJB applications. Such metadata will be also be targeted at
    reducing or eliminating the need for the bean developer to provide an EJB
    deployment descriptor. Use of metadata will further enable the generation of component
    and home interfaces for an EJB component from the enterprise bean class itself.

    Specification of programmatic defaults, including for
    metadata, to reduce the need for the developer to specify common, expected
    behaviors and requirements on the EJB container.

    Definition of utility classes to reduce the number of
    interfaces and/or callback methods that the bean developer must implement.

    Encapsulation of environmental dependencies and JNDI
    access through more convenient utility classes and/or factory patterns.

    Simplification of the stateless session bean type or
    the introduction of a simplified EJB component that more closely resembles a
    plain Java class.

    Enhancements to container-managed persistence and EJB
    QL to provide greater usability and to facilitate the development of frameworks
    based on container-managed persistence.

    Reduction of the requirements for usage of checked

    Enhancements to facilitate performance optimizations by
    EJB container vendors.

    Requests for other enhancements to the EJB architecture
    to be considered by the Expert Group


    This JSR will be under review until 30th July
    2004. To contribute, send an email to The specification
    is available for download at


    Java API for XML Data Binding (JAXB) 2.0 (

    JAXB 2.0 is a follow-on to JSR 31 Java XML Data Binding
    Specification building upon the architecture introduced in JAXB 1.0. JAXB 2.0
    proposes additional functionality while retaining ease of development as a key
    goal. In particular, this JSR intends to:


    Leverage JSR 14, JSR 201 and JSR 175 resulting in a
    better and simpler binding, thus making the application development easier. The
    use of the language extensions will be enabled using a compiler switch

    Address the XML to Java object binding requirements for
    JAX-RPC (JSR-101) enabling a tighter coupling and a primary implementation of
    JAXB and JAX-RPC

    Specify the mapping between Java objects to XML
    Schemas. This addresses scenarios where an application design begins with Java
    objects rather than an XML schema. One such example is an application that
    exports itself as a web service that communicates using SOAP and XML as a
    transport mechanism

    Enable serialization of Java objects to XML schemas and

    Investigate the implementation of a portable,
    standalone runtime for JAXB, schema evolution, partial object to XML binding
    and the integration of JSR Streaming API for XML) into JAXB architecture.


    This JSR will be under review until 23rd July
    2004. To contribute, send an email to The
    specification is available for download at


    Scripting Pages in Java Web Applications (

    There are a number of scripting languages that are being
    used today to generate dynamic content; notable examples include PHP,
    ECMAScript, Active Server Pages and others. Application developers using these
    technologies would like a standard mechanism to access information developed in
    the Java platform. This Specification will describe how to write portable Java
    classes that can be invoked from a page written in an scripting language,
    including details on security, resources and class loader contexts. The
    specification will cover both the case where the Java classes are instantiated
    in a Java Servlet container and the case of a Java VM. The specification may
    include a Java API that can be used, possibly through JNI, by a scripting
    language engine to access the desired Java objects. The specification will also
    describe how to package these scripting pages and Java classes, including how
    to bundle the scripting pages into a WAR file.


    The way Java objects are represented and accessed in a given
    scripting language is specific to that scripting language but we expect this
    specification to indicate some common requirements for these mappings. The
    specification will be grounded in some specific mappings, which may or not be
    included as part of the specification. The reference implementation will
    include support for interoperability with the PHP scripting language.


    This JSR will be under review until 1th August 2004. To
    contribute, send an email to
    The specification is available for download at


    Java API for XML-Based RPC (JAX-RPC) 2.0 (

    The JAX-Remote Procedure Call 2.0 specification extends the
    existing JAX-RPC 1.0 (JSR 101) specification with new features, including some
    or all of the following: direct support for JAXB 2.0-based data binding,
    support for the latest W3C and WS-I standards (e.g. SOAP 1.2, WSDL 1.2),
    standardized metadata for Java<->WSDL mapping, ease-of-development
    features, support for easier evolution of Web services, an improved handler
    framework, support for asynchronous RPC and non-HTTP transports.

    This JSR will be under review until 23rd July
    2004. To contribute, send an email to
    The specification is available for download at


    Mobile Internationalization API (

    This specification will provide a common API for the
    internationalization of MIDP applications, delivered and licensed as an
    optional package. It intends to provide the means to isolate localizable
    application resources from program source code and an API for accessing those
    resources at runtime, selecting the correct resources for the user’s/device’s
    locale. The specification will also define an API for supporting cultural
    conventions in applications such as formatting dates, times, numbers, and
    currencies, and sorting text strings correctly for the user’s locale.


    This JSR will be under review until 23rd July
    2004. To contribute, send an email to The
    specification is available for download at


    Java Data Objects 2.0 – An Extension to the JDO specification (

    The JDO API provides a database abstraction that permitted
    API access to datastores without detailed knowledge of the underlying datastore
    API. This specification builds on the original, adding the following features


    Relational Database Mapping: Different JDO
    implementations have slightly different mappings to relational databases and
    the mappings are not portable among vendors. This JSR will address a common
    mapping format to allow a higher degree of portability of applications.

    Disconnected operation: A primary use-case for JDO is
    in a middle tier of a multi-tier architecture. Rich clients (http clients
    running applets, web services clients, and ORB clients) may wish to extract a
    subset of values from the database in a structured (domain model) format, and
    update this information. Once updated, the information is sent back to a middle
    tier, where the changes are applied to the datastore. This JSR will address the
    APIs in the middle tier to facilitate this use-case.

    Broaden the range of implementations: Certain JDO 1.0
    specification restrictions reduce the acceptance of the API by potential JDO
    vendors. Limitations include a requirement for binary compatibility to the
    Reference Enhancement contract and a requirement that only classes, not
    interfaces, can be persistent. This JSR will address these limitations.

    Alignment with J2EE: While the JDO technology is
    suitable as a component in the J2EE architecture, certain services are required
    from the server that is not currently standardized. Part of this JSR will
    recommend standard APIs to provide these services. Part of this alignment will
    specify the portable behavior of transaction completion in the web and EJB

    Extensions to JDO queries: JDOQL provides a standard
    way to access persistent instances based on values and relationships, but is
    limited in what can be returned as the result. This JSR will extend the range
    of return values to include projected fields, collections of instances
    identified in navigational expressions, and aggregate data such as MIN, MAX,
    SUM, AVG, and COUNT. Additional methods will be defined to perform string
    manipulations in filters.

    Relationships: The JDO object model does not specify
    bidirectional or composition relationships among object classes. This JSR will
    consider issues regarding managed bidirectional relationships and composition
    relationships including cascade delete semantics.

    Maximize JDO backward compatibility: Many applications
    and deployments have significant investments in the JDO technology. Any
    improvements to the API will attempt to maintain backward compatibility to all
    previous JDO specifications.


    This JSR will be under review until 7th August
    2004. To contribute, send an email to The
    specification is available for download at


    JSR Community Draft approvals

    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. (


    JSR-113 Java Speech API 2.0 (

    This JSR extends the work of the 1.0 Java Speech API which
    allows developers to incorporate speech technology into user interfaces for
    their Java programming language applets and applications. This API specifies a
    cross-platform interface to support command and control recognizers, dictation
    systems, and speech synthesizers. Version 2.0 will extend Sun’s s pre-JCP work
    on JSAPI 1.0. JSAPI does not provide any speech functionality itself, but
    through a set of APIs and event interfaces, access to speech functionality
    provided by supporting speech vendors is accessible to the application.


    While JSAPI 1.0 is a great start, there are still some
    issues to be resolved. Candidate targets for JSAPI 2.0 include:


    A service provider interface (SPI) will act as
    middleware between the JSAPI Layer and the vendor-provided speech engine. This
    may be based on existing standards such as the SAPI 5.0 service provider API.

    The JSGF and JSML specs must track the W3C Voice
    Browser group’s grammar format and synthesis markup languages.

    Built in support for redirection of audio.

    Various threading issues (e.g., synchronization via
    event queues) and reentrancy issues require tighter specification.

    A modular architecture that supports a very small
    minimum configuration and future growth for the resources of a variety of
    platforms (e.g., desktop, server).

    Various other specification details require

    Future consideration for compatibility with telephony
    APIs (e.g., JTAPI or JAIN).


    Proposed Final Draft Specifications


    133: Java Memory Model and Thread Specification Revision

    This specification intends to revise Chapter 17 of
    "The Java Language Specification" and Chapter 8 of "The Java Virtual
    Machine Specification" by clarifying and further specifying the semantics
    of threads, locks, volatile variables and data races. 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.
    Several important issues, such as the interaction between synchronization and
    final fields, simply aren’t discussed in the existing 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 such as
    wait() and join(). It also expects to clarify programming constructs and
    concepts such as volatile and final variables, immutable objects and thread-
    and memory-related JVM functionality and APIs such as class initialization,
    asynchronous exceptions, finalizers, thread interrupts, and the sleep, wait,
    and join methods of class java.lang.Thread


    The specification is
    available at
    . To contribute, send email to


    176: J2SE 1.5 (Tiger) Release Contents (

    This JSR is to develop a specification for the feature and
    API set for the next feature release of Java 2 Standard Edition, code named
    "Tiger", targeted to ship Q3 CY 2004. Tiger is one of a series of
    feature releases to J2SE. The intention is to ship feature releases on a
    regular 18-month cycle, with each release including a combination of quality
    improvements and a small amount of new features.


    Various existing JSR API initiatives will be evaluated as
    potential candidates for Tiger. Amongst the possible candidates for evaluation


    JSR-003 Java Management Extensions (JMX) Specification (

    JSR-013 Decimal Arithmetic Enhancement (

    JSR-014 Add Generic Types to the Java Programming Language

    JSR-028 Java SASL Specification (

    JSR-114 JDBC Rowset Implementations (

    JSR-133 Java Memory Model and Thread Specification Revision

    JSR-163 Java Platform Profiling Architecture (

    JSR-166 Concurrency Utilities (

    JSR-174 Monitoring and Management Specification for the
    Java Virtual Machine (

    JSR-175 A Metadata Facility for the Java Programming
    Language (

    JSR-199 Java Compiler API (

    JSR-200 Network Transfer Format for Java Archives (

    JSR-201 Extending the Java Programming Language with
    Enumerations, Autoboxing, Enhanced for loops and Static Import (

    JSR-204 Unicode Supplementary Character Support (

    JSR-206 Java API for XML Processing (JAXP) 1.3 (


    The final specification for Tiger may not include all of
    these JSRs, and may include some JSRs not present on this list.


    The specification is
    available at
    To contribute, send an e-mail to
    jsr-176-comments at


    Network Transfer Format for Java Archives (

    This JSR will define a dense download format for Java class
    files. 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.


    The specification is
    available at
    To contribute, send an e-mail to
    jsr-200-comments at


    Server API for Mobile Services: Messaging – SAMS: Messaging (

    Mobile network services such as short message service (SMS)
    and multimedia message service (MMS) have gained tremendous popularity among
    users of mobile phones. Increasingly it is becoming necessary to provide J2EE
    and J2SE a standard, universal mechanism of compose, send and receive SMS and
    MMS messages as application developers add support for these technologies in
    their application servers or backend systems. The goal of this JSR is to
    provide API’s for Java applications on top of J2SE/J2EE to compose, send and
    receive short messages and multimedia messages.


    According to the proposal, the scope of this API will not
    limit itself to only SMS and MMS but rather provide a high level API to
    accessing messaging mobile services, thereby accounting for future mobile
    messaging applications. It intends to serve as an example for future Java API’s
    accessing mobile network services.


    There are currently JSR’s relating to support of SMS and
    MMS messaging on the mobile platform (J2ME), namely JSR 120 Wireless Messaging
    API: JSR 205 Wireless Messaging API 2.0: . The programming
    model for this JSR intends to be different from the above proposals. However it
    would be nice if there would a single standard interface to mobile network
    messaging across J2ME and J2SE/EE, rather than 2 distinct ones, at least API


    The specification is
    available at
    To contribute, send an e-mail to
    jsr-212-comments at


    JSR Final Ballot Approvals

    The final specifications were approved were approved via
    ballot voting by the Executive Committee members. (
    At this stage, the complete final specification is available for download along
    with documentation and reference implementations of the specification.


    73: Data Mining API (

    The Java community needs a standard way to create, store,
    access and maintain data and metadata supporting data mining models, data
    scoring, and data mining results serving J2EE-compliant application servers.
    Currently, there is no widely agreed upon, standard API for data mining. The
    JDMAPI specification will address the need for a pure Java API that supports
    the building of data mining models, the scoring of data using models, as well
    as the creation, storage, access and maintenance of data and metadata
    supporting data mining results, and select data transformations.


    The specification is available at


    Java OLAP Interface (JOLAP) (

    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, implementers 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


    The specification is available at


    JSR-177 Security and Trust Services API for J2ME (

    The intent of this JSR is to define a collection of APIs
    that provide security services to J2ME enabled devices. It will provide
    security mechanisms to support a wide variety of application-based services,
    such as access to corporate network, mobile commerce, and digital rights
    management. These services rely on the existence of a "Security
    Element" in the device for storage and execution of sensitive data and
    operations. This Security Element will provide secure storage to protect sensitive
    data, secure execution (such as cryptographic operations to support payment
    protocols, data integrity, and data confidentiality) and the ability to
    customize and enable secure features provided by the device. The most commonly
    implemented Security Element currently is a Smart card, which is widely
    deployed in wireless phones. This specification provides an access model that
    enables applications running on J2ME enabled devices to communicate with a
    smart card inserted in the device. This access model intends to provide a
    flexible mechanism to allow service and equipment providers to define secure


    The specification is available at


    JSR Final Release

    At this stage the final specification, Technology Compatibility
    Kit (TCK) and reference implementations are available for developers to use.


    Wireless Messaging API (

    The original JSR (JSR-120) dealing with wireless messaging
    was confined to Short Message Service (SMS), Unstructured Supplementary Service
    Data (USSD) and Cell Broadcast Service (CBS). All of these messaging
    technologies deal with text based messaging. SMS allows sending of text
    messages to another cell phone. USSD is similar to SMS but unlike SMS messages,
    which get saved if the cell phone is unavailable USSD messages are generated
    and consumed within a single session, while the cell phone is active. Finally
    CBS allows for broadcasting text messages to a set of cell phones within a
    geographical area.


    Text based messaging is widely prevalent today primarily due
    to the nature of deployed wireless networks. These mobile networks are referred
    to as 2G (2nd Generation) networks and allow transmission of data at speeds up
    to 14.4Kbs. Now as mobile network technologies have matured the deployment of
    3G (3rd Generation) networks has started taking place. 3G networks allow
    transmission of data at speed up to 2Mbps which makes these networks capable of
    transmitting not only text but also video and audio to wireless devices. 3G
    capable mobile handsets have also become widely available.


    Java already has support for text based messaging using SMS,
    USSD and CBS. This JSR intends to extend the existing wireless messaging API’s
    to support Multimedia Message Service (MMS), which would allow Java mobile
    applications to create, send and receive rich media messages containing text,
    graphics, animations, audio and video.


    The final specification is available at


    Rejected JSR

    The JCP Expert group for J2ME (
    rejected the following specification related to interfacing with a mobile
    device’s native management system. The reason for rejection was primarily
    inconsistent information as part of the specification request and potential
    overlap with existing JSRs.


    246 Device Management API (

    The purpose of this JSR is to enable J2ME applications to
    access device management implementations.



    What do you think of
    the JCP? What do you think of the current JSRs? Do you have any suggestions
    for this column? Feel free to write to me at jcpwatch at


  • Get the Free Newsletter!

    Subscribe to Developer Insider for top news, trends & analysis

    Latest Posts

    Related Stories