JavaData & JavaJCP Watch: JDBC in the Palm of Your Hand

JCP Watch: JDBC in the Palm of Your Hand content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

JCP Watch:


Two JDBC related JSRs went final over the past few week.
The first deals with an optional package for the J2ME mobile Java platform
while the other introduces a long awaited Rowset specification for programmatic
iteration over tabular data. Further, public review specifications for Java 1.5
(J2SE, Tiger) and an approval to start work on defining J2EE 1.5 were also


New JSRs


JSR-245 JavaServer Pages 2.1 (

Java Server Pages are a set of API.s used to develop web
pages that contain small pieces of Java code. When a web server receives a
request for such a page, it calls a JSP engine to execute the Java code within
the page. This execution results in dynamic and personalized content. Currently
JSP 1.2 is the accepted and most recent standard. This JSR specifies the next
revision to the JSP specifications. Significant changes relate to ease of use
and development of JSP pages for non-technical resources (like web page
designers), The purpose of JSP 2.1 is to improve alignment with JavaServerFaces
(JSF) and enhance ease of development.


This JSR will be under public review until 24th
May 2004. To contribute, send an email to jsr-245-comments at


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


242: Digital Set Top Box Profile – "On Ramp to OCAP" (

The existing Java platforms are generally too large in
implementation size and too demanding in functionality to be used with the majority
of already-deployed cable television set top boxes in the United States and
elsewhere. There is a pressing market need to identify a Java platform that can
be used with less-capable digital cable set top boxes that are currently
deployed and will remain in the field for some time. The proposed specification
will define a common API for applications that can be used by all vendors
targeting the already-deployed digital cable set top box market. It will also
provide a clear path of upward compatibility for content to migrate from the
target low-end platform to OCAP (OpenCable Applications Platform,, the Java middleware platform of next-generation
North American cable set top boxes. OCAP is related to DVB-MHP (Multimedia Home
Platform,, the Java middleware of choice for next
generation interactive television (iTV) devices in Europe and elsewhere.


The goal of this specification is to create a platform that
is as forward compatible as possible with OCAP while still fitting on the most
resource constrained of the currently deployed cable television set top boxes
that are capable of running J2ME CLDC.


JSR 243: 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 are 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.



244: Java 2 Platform, Enterprise Edition 1.5 (J2EE 1.5) Specification

This JSR is to develop J2EE 1.5, the next release of the
JavaTM 2 Platform, Enterprise Edition, targeted to ship in the second half of


The major theme for the next version of J2EE is ease of
development. JSR-175 (A Metadata Facility for the Java Programming Language) is
the enabling facility for a new declarative style of programming that
significantly simplifies many programming tasks. J2EE must move quickly to take advantage of this capability and
deliver significant improvements to ease of development for J2EE developers.


The JSR proposes that:


    J2EE 1.5 will define the J2EE component model,
    deployment, packaging, and container requirements for J2EE components that use
    Java language annotations, as defined by J2EE component JSRs.

    J2EE 1.5 will further define the J2EE component model,
    deployment, packaging, and container requirements for J2EE components that
    provide or use web services.

    J2EE 1.5 may also provide minor enhancements to
    existing APIs and small additional APIs, provided they meet the time and
    resource constraints of this release.


    This JSR will not itself define any new APIs, rather it will
    enumerate APIs defined in other JSRs which include:


    J2EE 1.5 is the Enterprise Edition of version 1.5 of
    the Java platform, and thus will be built on J2SE 1.5.

    JSR-181 (Web Services Metadata for the Java Platform)

    JSR-220 (EJB 3.0)

    JSR-222 (JAXB 2.0)

    JSR-224 (JAX-RPC 2.0)

    JSR-127 (JavaServer Faces 1.0)

    JSR-52 (JSTL 1.1)


    Public Review

    The following JSRs were released for public review.


    JSR-161 JAIN ENUM API Specification

    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. ENUM is a Domain Name System (DNS)
    based protocol defined by the IETF in [RFC2916]. General DNS resolver APIs and
    implementations expose the low-level protocol of DNS and do not encapsulate the
    specialized processing required by ENUM. The JAIN ENUM API hides the
    complexities of DNS resolution and Dynamic DNS provisioning (DDNS) [RFC2163],
    while encapsulating the higher-level services of ENUM, including POSIX Regular
    Expression Handling, Resolution Service and Protocol Filtering, Security
    (DNSSEC) [RFC2535], Extended DNS Support (EDNS0) [RFC2671, etc. The JAIN ENUM
    API specification enables applications to query and provision ENUM entries
    (i.e. E.164 telephone numbers and their service-specific URIs) into an ENUM


    The public review of this specification ends on June 10th
    2004. To contribute, send email to jsr-161-comments at The review is
    available at


    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

    JSR-028 Java SASL Specification

    JSR-114 JDBC Rowset Implementations

    JSR-133 Java Memory Model and Thread Specification

    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

    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.


    This is the second update to the final draft. This JSR will
    be under public review until 10th June 2004. To contribute, send an
    email to jsr-176-comments at The review is available at


    JSR-234 Advanced Multimedia Supplements

    Java equipped terminals are evolving into general multimedia
    and entertainment platforms. Features like camera and radio which have
    traditionally belonged into different device categories are now integrated into
    same terminals. Increase in the processing power of modern mobile phones allow
    more sophisticated media processing capabilities. Displays will remain
    relatively small due physical limitations but rich aural experience can be
    achieved without adding the physical size of the terminals. The purpose of this
    API is to give access to multimedia functionality of the modern mobile
    terminals. Specifically, better support for camera and radio and access to
    advanced audio processing will be introduced but it.s possible to add other
    functionality as well.


    MMAPI (JSR-135) is the media package for J2ME/CLDC
    environment which introduces basic playback functionality for audio and video.
    It allows media players to be created for various sources including camera and
    radio but it does not offer any specific methods to control them.


    This specification will bring the following capabilities to
    the mobile terminals with J2ME/CLDC support:

    Access to camera specific controls like visual settings
    (brightness, contrast), flashlights, lighting modes and zooming.

    Access to radio and other channel/frequency based media
    sources including RDS (radio data system)

    Access to advanced audio processing capabilities like
    equalizer, audio effects, artificial reverberation and positional 3D audio.

    Media output direction. For example, the ability to
    choose whether the audio is played out from speaker of from headset.


    This JSR will be under public review until 24th
    May 2004. To contribute, send an email to jsr-234-comments at The
    review is available at

    181: Web Services Metadata for the Java Platform

    Java Language Metadata (JSR 175
    is a recently submitted JSR that provides a standard model for annotating Java
    code, of which Web Services Metadata for the Java Platform will be one
    application that provides an easy to use syntax for describing web services at
    the source-code level for the J2EE platform. The specification is intended to
    provide a syntax that is amenable to manipulation by tools. In principle this
    JSR will provide a decorator development pattern similar to what JSP.s are to
    Servlets. Developers would now be able to specify web services using metadata.
    This metadata will get processed by Web Service containers, J2EE app servers
    etc. to produce fully functional, provisionable, deployable and interoperable
    web service implementations.


    This JSR will be under public review until 10th
    June 2004. To contribute, send an email to jsr-181-comments at The
    review is available at


    Server API for Mobile Services: Messaging – SAMS: Messaging

    This JSR proposing to add API’s for Java applications on top
    of J2SE/J2EE to compose, send and receive short messages and multimedia
    messages has been approved. This JSR has been covered in a previous installment
    available at


    This JSR has been approved in it.s final review ballot. To
    contribute, send an email to jsr-181-comments at The review is
    available 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-211 Content Handler API (

    The purpose of this JSR is to define an optional package for
    an API and associated model permitting the invocation of J2ME Applications to
    handle actions on Uniform Resource Identifiers (URI) based on the MIME-type or
    scheme. For example, an application or suite of applications running on the
    J2ME platform can register itself to be invoked when a particular content type
    in encountered. This is similar to file associations within web browsers that
    invoke particular programs when certain types of data are encountered (.PDF
    files invoke Adobe Acrobat).


    Proposed Final Draft Specifications


    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
    To contribute, send email to jsr-73-comments at


    JSR-105 XML Digital Signature APIs (

    This JSR is to define a standard set of APIs for XML digital
    signatures services. The XML Digital Signature specification is defined by the
    W3C. XML Signatures can be applied to any digital content (data object),
    including XML. An XML Signature may be applied to the content of one or more
    resources. Enveloped or enveloping signatures are over data within the same XML
    document as the signature; detached signatures are over data external to the
    signature element. More specifically, the XML Digital Signature specification
    defines an XML signature element type and an XML signature application;
    conformance requirements for each are specified by way of schema definitions
    and prose respectively. The XML Digital Signature specification also includes
    other useful types that identify methods for referencing collections of
    resources, algorithms, and keying and management information.


    The specification is available at
    To contribute, send email to jsr-105-comments at


    JSR-163 Java Platform Profiling Architecture (

    Platform profiling is the ability to extract usage
    statistics of a running JVM. Metrics include memory usage, CPU usage, object
    references etc. There is an experimental interface – the Java Virtual Machine
    Profiling Interface (JVMPI) that suffers from a number of design flaws,
    scalability issues, sizeable overhead and imprecise profiling. The new
    profiling architecture intends to non-compatibly supercede JVMPI but provide
    similar yet enhanced functionality. These APIs will allow inter-operability of
    profiling and advanced garbage collection technologies. The APIs will allow
    reliable implementation on the widest range of virtual machines, part of which
    will be achieved by grouping functionality into optional sets. Queries for
    which optional capabilities are supported will be provided. The APIs will be
    targeted to provide a Java programming language model of execution, however,
    some aspects of the virtual machine, native and operating system models may be
    directly provided or provided via an extension mechanism. The APIs will
    accommodate implementations which can dynamically enable and disable profiling;
    and thus will allow implementations which have negligible performance impact
    when profiling is disabled. While profiling in the application development
    phase will be the primary goal of this specification, the design objectives for
    low performance overhead and data perturbation will also support profiling in
    the deployment phase.


    The specification is available at
    To contribute, send email to jsr-163-comments 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 operations.


    The specification is available at
    To contribute, send email to jsr-177-comments at


    JSR-226 Scalable 2D Vector Graphics API for J2ME

    This specification will define an optional package API for
    rendering scalable 2D vector graphics, including image files in W3C Scalable
    Vector Graphics (SVG) format. The API is targeted for J2ME platform, with
    primary emphasis on MIDP. The main use cases for this API are map
    visualization, scalable icons, and other advanced graphics applications. The
    API is targeted at CLDC class devices that typically have very little
    processing power and memory, and no hardware support for 2D graphics or
    floating point arithmetic. The API shall allow utilization of native 2D
    graphics features of the device when applicable. The API will have the ability
    to load and render external 2D vector images, stored in the W3C SVG Tiny format
    and the capability to render 2D images that are scalable to different display resolutions
    and aspect ratios.


    The specification is available at
    To contribute, send email to jsr-226-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.


    JSR-205 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.


    You may download the final specification from


    JSR-86 Enterprise Media Beans

    EMB provides a framework to integrate rich media data such
    as audio, video or image into applications based on EJB Entity Beans within the
    J2EE application development model. It provides a common view on rich media
    from an application model point of view. EMB abstracts over underlying
    transport and rendering mechanisms (e.g. the various stream server
    implementations), caching and replication throughout the network. It ensures
    referential integrity and hides the underlying persistency method for rich
    media (file, binary large object, user defined data types, etc.) from the
    application model. EMB enforces a common security model for rich media, and
    ensure transactional behavior for operations like media insertion, remove or
    move. It standardizes the integration of en-de-transcoding mechanisms into the
    application model.


    You may download the final specification from


    JSR Final Release

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


    JSR-114 JDBC Rowset Implementations (

    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 final specification is available at
    and the reference implementation is available at


    JSR 169: JDBC Optional Package for CDC/Foundation Profile

    The proposed specification will define a JDBC Optional
    Package for Java 2 Micro Edition (J2ME), Connected Device Configuration (CDC)
    Foundation Profile. This optional package will contain equivalent functionality
    to the java.sql package provided in Java 2 Standard Edition (J2SE). The
    functionality required should be adjusted to take into account the limitations
    of CDC in terms of size, functionality and removal of deprecated APIs. The JDBC
    Optional Package for CDC would provide a strict subset of the functionality
    available in J2SE.


    The final specification is available at
    and the reference implementation is available at



    JDBC Specification:

    JDBC Rowset tutorial:

    An Introduction to the Java 1.5 (Tiger) release:

    JSR-175 A Metadata Facility for the Java:

    Java Server Faces homepage and reference implementation:

    Java Servlet Technology:

    Connected, Limited Device Configuration (CLDC):

    Starting point for all things related to the Java 2
    Enterprise Edition Platform:

    The Wireless Messaging API implementation (JSR-120):

    Wireless Messaging API 2.0:

    SVG specification:

    Mobile SVG Profiles:

    The Java Advanced Intelligent Network (JAIN) API.s:

    Java TV API:

    OpenCable Application Platform 1.0:

    OnRamp to OCAP 0.7.2,,

    JSR-12 Java Data Objects (JDO)

    JSR-14 Java Generics will be used as an alternative to
    certain JDO metadata

    JSR-175 Metadata Facility will be used as an alternative to
    certain JDO metadata



    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 apu at


  • Get the Free Newsletter!

    Subscribe to Developer Insider for top news, trends & analysis

    Latest Posts

    Related Stories