Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 193: Client Side Container (CSC)

Stage Access Start Finish
Withdrawn   14 Oct, 2002  
JSR Review Ballot View results 01 Oct, 2002 14 Oct, 2002
Status: Withdrawn
Reason: Having noticed the many questions/concerns about this specification proposal, the submitter decided to withdraw the request.
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0

This would have described a client-side container architecture, providing common client infrastructure, for developing API-neutral clients (Swing, AWT, Command Line). The access to J2EE-components would be fully abstracted and encapsulated.

Please direct comments on this JSR to the Spec Lead(s)

Specification Leads
  Adam Bien Bien, Adam
Expert Group
  Bien, Adam    

This JSR has been Withdrawn
Reason: Having noticed the many questions/concerns about this specification proposal, the submitter decided to withdraw the request.

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Original Summary: This spec describes a client side container architecture, which provides the common client infrastructure like: logging, security, internationalization, configuration, lifecycle management etc. It provides an architecture for developing API neutral clients (Swing, AWT, Command Line). The access to J2EE-components will be also fully abstracted and encapsulated.

Section 1. Identification

Submitting Member: Adam Bien

Name of Contact Person: Adam Bien

E-Mail Address:

Telephone Number: +49 89 909 69004

Fax Number: +49 89 909 69027

Specification Lead: Adam Bien

E-Mail Address:

Telephone Number: +49 89 909 69004

Fax Number: +49 89 909 69027

Initial Expert Group Membership:

Adam Bien

Supporting this JSR:

No official supporters

Section 2: Request

2.1 Please describe the proposed Specification:

Client Side Container (CSC) simplifies the development of clientside applications (also invisible ones like e.g. searchengines) and abstracts the common api's like Webstart, JAAS It abstracts the J2SE API's and provides a common framework for applications on the client.
Every application is able to communicate with another. This mechanism is very similar to JMS (and could be build with it), Also services like pooling, caching, activating, deactivating (lifecycle-service) will be provided by the framework.Common things like authentification or authorization will be simplified. Generally could this specification be compared with a high-sophisticated, multi-applet container, which runs as usual java-application.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

J2SE Desktop, personal, embedded, card (could be used also on the server - but we have already J2EE), residential gateways

2.3 What need of the Java community will be addressed by the proposed specification?

All J2SE-APIs are really low level. What the community needs is an abstraction layer and architecture guideline to develop clientside applications. This not addressed by existing specifications, because all what we have are the API's or drivers. CSC is a platform upon this APIs. With CSC the development time could be really shortened and also unexperienced developers were able to develop an application on it. So we get the same benefits, as with J2EE but on the clientside. Also the problems how to access J2EE-componets are solved by my CSC, because the access to the business-tier could be fully abstracted.

2.4 Why isn't this need met by existing specifications?

Other API's provide just special, independent services. This API provides common architecture with some best practises for java-apps.

In my last projects, every time we have to build a common infrastructure for the clients. Otherwise we were extremely tight coupled to existing APIs and the developers had to learn the full blown APIs.

2.5 Please give a short description of the underlying technology or technologies:

The idea is to provide a common framework for client side applications. Especially the communication,configuration,lifecycle-management between the applications will be managed by the framework. My testapplication runs on J2SE 1.4.X without any additional API's or libraries.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)


2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?


2.8 Are there any security issues that cannot be addressed by the current security model?

Common frameworks like JAAS etc. coult be plugged as a "SPI" into my model. All isues can be addressed.

2.9 Are there any internationalization or localization issues?

Yes. Every application is able to use the "internationalization service" which uses the i18n components for now. Every I18N-API could be plugged into "my" framework.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No existing specs will be deprecated.

2.11 Please describe the anticipated schedule for the development of this specification.

I think in a year this spec should be "ready to deploy".

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

EMail:, face-to-face meetings, tele con mtgs, chat rooms,conferences (JavaONE).

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

Existing Framework with (was implementing by me)

- SPI-implementation (the "Reference Implementation" already exists, because it is my "testdriver")
- Docs
- UML - Documentation

I will publish or submit this documents after this JSR was approved.

My book (Enterprise Java Frameworks, Adam Bien, Addison Wesley was only published in german language) describes a similar (serverside) architecture.

3.2 Explanation of how these items might be used as a starting point for the work.

We could use the RI and already existing API as a starting point of our work. The already existing source code, UML-diagrams are only an initial point.
The architecture should be improved to be more general.

Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR. (my homepage).
As a freelancer I have contracted for several companies in Germany/Europe (Allianz, BMW, VW, O2, Sun Microsystems, etc.) as an architect, developer, trainer and coach. I wrote several books, articles about this topic. I was encouraged to submit this request by BMW, conference attendees etc.

In the last Swing-Project (I think the biggest in Germany or Europe - about 500 panels) we had big problems with "memory leaks", logging, configuration etc. The idea for this api was born. I think with this JSR our project could be earlier in production and the migration from JDK 1.1 to JDK 1.2 and JDK 1.3 could be simplified. Further not so skilled developers would gain a general architecture for developing clienside java applications.

This specification is really lightweight, so it is possible to run it on mobile (or micro) clients.