Printed: Jan 21, 2025
From: http://www.jcp.org/en/jsr/detail?id=107
|
| Specification Leads | |||
| Joseph Fialli | Oracle | ||
| Gregory Robert Luck | Luck, Gregory Robert | ||
| Brian Oliver | Oracle | ||
| Cameron Purdy | Oracle | ||
 |
|||
| Expert Group | |||
| Apache Software Foundation : Jon Stevens |
Chang, Bongjae | Cotton III, Ben D. : Ben D. Cotton III |
|
| Fujitsu Limited : Toshio Takeda |
Gardner, Ryan : Ryan Gardner |
Goldman Sachs & Co. : William Newport |
|
| Hazelcast : Christoph Engelbert |
Hewlett-Packard : Greg Pavlik |
Hightower, Richard : Richard Hightower |
|
| IBM : Brian Martin |
IBM : Gabe Montero |
Gregory Robert Luck | |
| Millidge, Stephen : Stephen Millidge |
Mossakowski, David : David Mossakowski |
Oracle : Yannis Cosmadopoulos |
|
| Oracle : Joseph Fialli |
Oracle : Brian Oliver |
Oracle : Andy Piper |
|
| Oracle : Cameron Purdy |
Red Hat : Pete Muir |
Red Hat : Galder Zamarreno |
|
| Seovic, Aleksandar : Aleksandar Seovic |
Software AG : Chris Dennis |
TmaxSoft, Inc. : chang paek |
|
|
|||
| Contributors | |||
| headissue : Jens Wilke |
|||
List of JCACHE compatible implementations
The following updates have been made to the original proposal on the dates shown.
2019.02.01:
The Maintenance Leads moved the JSR to JCP 2.11.
2017.10.20:
Joe Fialli has taken over as Maintenance Lead for Oracle.
Name: Joe Fialli
e-mail address: joe.fialli
telephone number: +1 781-442-0795
2013.03.05:
The RI will be available for commercial use under the CDDL 1.1 open source license, the GPLv2 with Classpath Exception open source license, or this RI license.
The RI will be available for non-commercial use under the CDDL 1.1 open source license, the GPLv2 with Classpath Exception open source license, or this RI license.
The TCK will be available for commercial use under this TCK license.
As required by the Java Specification Participation Agreement (JSPA), the TCK will be licensed at no charge without support to qualified not-for-profit. The Compatibility Testing Scholarship Program will verify such qualification. Support may also be provided at no charge with approval of the scholarship board. For more information, please refer to:
http://www.oracle.com/technetwork/java/index-137188.html
There are two channels for feedback. First is via the JSR 107 forum. Secondly is via raising issues in the Issue Tracker.
New nominations will be distributed to the Expert Group via jsr107@googlegroups.com, and details of Expert Group nominations will be provided to the public via the forum of the mailing list, which is also the EG communication archive.
https://github.com/jsr107/jsr107spec/issues
For specification documentation: https://docs.google.com/document/d/1YZ-lrH6nW871Vd9Z34Og_EqbX_kxxJi55UrSn4yL2Ak/edit?hl=en_US
For source code: https://github.com/jsr107
2012.10.23:
Final Specification license
Final RI license
Final TCK license
2012.04.20:
Specification Leads: Brian Oliver (Oracle), Cameron Purdy (Oracle), Greg Luck
E-Mail Addresses: brian.oliver
Telephone Numbers: +1 781 640 6842, +1 781 442 0145, +61 7 3368 2122
Fax Numbers: -, -, -
2011.07.25:
Yannis Cosmadopoulos was added as co-Spec Lead.
2011.05.04:
The Specification Lead and Expert Group changed the JSR to JCP version 2.7.
2007.05.15:
Greg Luck became co-Spec Lead.
2003.12.19:
Cameron Purdy took over as Specification Lead.
Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Submitting Member:Oracle Corporation
Name of Contact Person: David Clay, Oracle Corporation
E-Mail Address: david.clay@oracle.com
Telephone Number: 503-525-8025
Fax Number: 503-276-2400
Specification Lead: Jerry Bortvedt
E-Mail Address: gerald.bortvedt@oracle.com
Telephone Number: 503-525-8023
Fax Number: 503-276-2400
Note that the above information has been updated from this original proposal.
Initial Expert Group Membership:
(Please provide company or organization names. Note that expert group
members must have signed the JSPA.)
Jerry Bortvedt, Oracle Corporation
Jun Wang, Oracle Corporation
Section 2: Request
Caching is a tried and true method for dramatically speeding up applications. Applications often use temporary data which are expensive to create, but have a lifetime over which they can be reused. For example, a servlet might create a web page from data obtained from multiple databases, network connections, and expensive computations; the sets of data might be reusable over the same or different periods of time.
The JCACHE specification standardizes in process caching of Java objects in a way that allows an efficient implementation, and removes from the programmer the burden of implementing cache expiration, mutual exclusion, spooling, and cache consistency.
Objects whose type is not known until runtime can be cached, but only those which implement the serializable interface can be spooled.
Can be used on any Java platform. Particularly useful on server platforms, such as a servlet container.
What need of the Java community will be addressed by the proposed specification? The primary goal of JCACHE is to allow developers to write as little code as possible to solve a very common problem.
There are no existing specifications which deal with automatic creation and refresh of temporary, in-process data shared across threads.
JNDI provides an interface for looking up objects by name, and an interface (the SPI) which could be used for a caching implementation. However, the application would be required to check expiration of retrieved objects after each look up, and sychronize creation and binding of a new object. Per object cache attributes (e.g., expiration time) would require introduction of an additional level of indirection: the application would look up a cache handle and use one of its methods to access the associated object.
java.util.Hashtable provides a way of looking up cached objects by name, but has no way to materialize objects in the cache without application enforcement of expiration and mutual exclusion. The granularity of Hashtable locking is the whole table, which affects application scalability when multiple threads access the HashTable. HashTable also has no underlying spooling capability.
JavaSpaces and Enity Enterprise Java Beans deal with caching of persistent, transactional data. Cached data do not always come from data stores; they may be the result of an expensive computation or a remote procedure call. Also, these interfaces do not deal with efficient handling of expiration and refresh of cached data.
Enterprise Java Beans are designed primarily for remote access to objects. Although an in-process implementation of EJB is possible, the application code would still have to make all of the additional calls required for remote object access. EJB's must be pre-defined by the application, and do not have any concept of shared access or expiration.
javax.servlet.http.HttpSession allows named objects of arbitrary type to be cached, but does not have the concept of sharing, invalidation, per object expiration, automatic loading, or spooling.
An application begins by creating a cache name space and associating a cache loader with it. The cache loader is application code which materializes application objects to be cached. Following this simple initialization, concurrent threads may retrieve objects from the cache. If the object does not exist or has expired, the cache loader is invoked. When the cache meets it memory limit, its replacement policy decides which objects should be spooled to disk and when.
An application may optionally associate a set of attributes with a name space or with individual cached objects. Examples of attributes are time to live, expiration date, and whether an object can be spooled.
Applications may also explicitly create, replace, remove, or invalidate objects in the cache. Using a cache event listener, the application may interpose before cache actions whether invoked by the cache system or explicitly by the application.
Changes to the cached objects may be sychronized across multiple JVM's on multiple hosts. However, the application designer must carefully weigh the advantages of the performance cost against the functionality gain.
javax.util.jcache in j2ee (although it could be useful in j2se)
No.
No.
No.
No.
| 4 weeks after JSR approval. | Release preliminary specification, including API |
| + 2 weeks | Comments on first draft due |
| + 2 weeks | 2nd draft released |
| + 1 week | Comments on 2nd draft due |
| + 1 week | 3rd draft released (if necessary) |
| + 1 week | Comments on 3rd draft due (if necessary) |
| + 1 week | Participant draft released |
Note that this JSR has been updated since this original proposal.
Section 3: Contributions
Functional Specification for Object Caching Service for Java (OCS4J), 2.0
Basic functionality is described. However, the documented API excludes spooling and includes extraneous functionality such as pooling which would probably not be included in JCACHE.
Section 4: Additional Information (Optional)
This section contains any additional information that the submitting Member wishes to include in the JSR. The Oracle Java caching system has been in use internally in Oracle products for about 2 years. It has proved to be popular among developers.
