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. (http://jcp.org/en/participation/committee)
JSR-247 Data Mining 2.0
(http://jcp.org/en/jsr/detail?id=247)
This JSR intends to extend the earlier version of the Java
Data Mining API, JDM 1.0 JSR-73 (http://jcp.org/en/jsr/detail?id=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
applications.
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
specifications
JSR-209 Advanced Graphics and User Interface Optional Package for the J2ME
Platform (http://jcp.org/en/jsr/detail?id=209)
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 jsr209-review-comments@jcp.org.
The specification is available for download at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=pbp_agui-1.0-edr-spec-jdoc-oth-JSpec&SiteId=JCP&TransactionId=noreg
JSR-220
Enterprise Java Beans 3.0 (EJB 3.0) (http://jcp.org/en/jsr/detail?id=222)
This JSR is an extension to the earlier EJB 2.1
specification (http://jcp.org/en/jsr/detail?id=153) 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
exceptions.
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 ejb3-feedback@sun.com. The specification
is available for download at http://java.sun.com/products/ejb/docs.html
JSR-222
Java API for XML Data Binding (JAXB) 2.0 (http://jcp.org/en/jsr/detail?id=222)
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
vice-versa
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 spec-comments@jsr222.dev.java.net. The
specification is available for download at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=jaxb-2_0-edr-spec-oth-JSpec&SiteId=JCP&TransactionId=noreg
JSR-223
Scripting Pages in Java Web Applications (http://jcp.org/en/jsr/detail?id=223)
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 jsr-223-comments@jcp.org.
The specification is available for download at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=java_scripting-1_0-edr-spec-oth-JSPEC&SiteId=JCP&TransactionId=noreg
JSR-224
Java API for XML-Based RPC (JAX-RPC) 2.0 (http://jcp.org/en/jsr/detail?id=224)
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 jsr-223-comments@jcp.org.
The specification is available for download at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=jaxrpc-2.0-edr-spec-oth-JSpec&SiteId=JCP&TransactionId=noreg
JSR-238
Mobile Internationalization API (http://jcp.org/en/jsr/detail?id=238)
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 jsr-238-comments@jcp.org. The
specification is available for download at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=j2me_i18n-0.4-edr-oth-JSpec&SiteId=JCP&TransactionId=noreg
JSR-243
Java Data Objects 2.0 – An Extension to the JDO specification (http://jcp.org/en/jsr/detail?id=243)
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
containers.
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 jsr-243-comments@jcp.org. The
specification is available for download at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=jdo-20-edr-oth-JSpec&SiteId=JCP&TransactionId=noreg
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. (http://jcp.org/en/participation/committee)
JSR-113 Java Speech API 2.0 (http://jcp.org/en/jsr/detail?id=113)
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
clarification.
Future consideration for compatibility with telephony
APIs (e.g., JTAPI or JAIN).
Proposed Final Draft Specifications
JSR
133: Java Memory Model and Thread Specification Revision
(http://jcp.org/en/jsr/detail?id=133)
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 http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=memory_model-1.0-pfd2-spec-oth-JSpec&SiteId=JSC&TransactionId=noreg
. To contribute, send email to jsr-133-comments@jcp.org
JSR
176: J2SE 1.5 (Tiger) Release Contents (http://jcp.org/en/jsr/detail?id=234)
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
are:
JSR-003 Java Management Extensions (JMX) Specification (http://jcp.org/en/jsr/detail?id=3)
JSR-013 Decimal Arithmetic Enhancement (http://jcp.org/en/jsr/detail?id=13)
JSR-014 Add Generic Types to the Java Programming Language
(http://jcp.org/en/jsr/detail?id=14)
JSR-028 Java SASL Specification (http://jcp.org/en/jsr/detail?id=28)
JSR-114 JDBC Rowset Implementations (http://jcp.org/en/jsr/detail?id=114)
JSR-133 Java Memory Model and Thread Specification Revision
(http://jcp.org/en/jsr/detail?id=133)
JSR-163 Java Platform Profiling Architecture (http://jcp.org/en/jsr/detail?id=163)
JSR-166 Concurrency Utilities (http://jcp.org/en/jsr/detail?id=166)
JSR-174 Monitoring and Management Specification for the
Java Virtual Machine (http://jcp.org/en/jsr/detail?id=174)
JSR-175 A Metadata Facility for the Java Programming
Language (http://jcp.org/en/jsr/detail?id=175)
JSR-199 Java Compiler API (http://jcp.org/en/jsr/detail?id=199)
JSR-200 Network Transfer Format for Java Archives (http://jcp.org/en/jsr/detail?id=200)
JSR-201 Extending the Java Programming Language with
Enumerations, Autoboxing, Enhanced for loops and Static Import (http://jcp.org/en/jsr/detail?id=201)
JSR-204 Unicode Supplementary Character Support (http://jcp.org/en/jsr/detail?id=204)
JSR-206 Java API for XML Processing (JAXP) 1.3 (http://jcp.org/en/jsr/detail?id=206)
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 http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=j2se-1.5.0-pfd-spec-oth-JSpec&SiteId=JCP&TransactionId=noreg.
To contribute, send an e-mail to jsr-176-comments at jcp.org
JSR-200
Network Transfer Format for Java Archives (http://jcp.org/en/jsr/detail?id=200)
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 http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=network_transfer_format-1.0-pfd2-spec-oth-JSpec&SiteId=JCP&TransactionId=noreg.
To contribute, send an e-mail to jsr-200-comments at jcp.org
JSR-212
Server API for Mobile Services: Messaging – SAMS: Messaging (http://jcp.org/en/jsr/detail?id=212)
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: http://www.jcp.org/en/jsr/detail?id=120 JSR 205 Wireless Messaging API 2.0: http://www.jcp.org/en/jsr/detail?id=205 . 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
wise.
The specification is
available at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=sams_messaging-1.0-pfd-spec-oth-JSpec&SiteId=JCP&TransactionId=noreg.
To contribute, send an e-mail to jsr-212-comments at jcp.org
JSR Final Ballot Approvals
The final specifications were approved were approved via
ballot voting by the Executive Committee members. (http://jcp.org/en/participation/committee).
At this stage, the complete final specification is available for download along
with documentation and reference implementations of the specification.
JSR
73: Data Mining API (http://jcp.org/en/jsr/detail?id=73)
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 http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=dmapi-0.96-pfd-spec-oth-JSpec&SiteId=JCP&TransactionId=noreg.
JSR.69
Java OLAP Interface (JOLAP) (http://jcp.org/en/jsr/detail?id=69)
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
databases.
The specification is available at http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=7696-jolap-1.0-pfd-spec-oth-JSpec&SiteId=JCP&TransactionId=noreg.
JSR-177 Security and Trust Services API for J2ME (http://jcp.org/en/jsr/detail?id=177)
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 http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=j2me_satsa-1.0-pfd-oth-JSpec&SiteId=JCP&TransactionId=noreg.
JSR Final Release
At this stage the final specification, Technology Compatibility
Kit (TCK) and reference implementations are available for developers to use.
JSR-205
Wireless Messaging API (http://jcp.org/en/jsr/detail?id=205)
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 http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=wma_ext-102-fr-oth-JSpec&SiteId=JCP&TransactionId=noreg
Rejected JSR
The JCP Expert group for J2ME (http://jcp.org/en/participation/committee#ME)
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.
JSR
246 Device Management API (http://jcp.org/en/jsr/detail?id=246)
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 jcpwatch.org