Discussions

News: JSR 193: Client Side Container Available for Review

  1. JSR 193, "Client Side Container", is available for review. JSR 193 provides a client side framework/container that abstracts J2SE and other API's while prviding services such as pooling, caching, lifecycle management, authentification, etc. The proposed container could be thought of as a sophisticated multi-applet container, which runs as usual java app.

    Check out JSR 193: Client Side Container.

    Hmmm.. I knew that one day I could put the domain www.theclientside.com to good use. :)
  2. This reminds me of another TSS user's comment some time ago (and I paraphrase) that the JSR process was starting to look like a dumping ground for failed API's. Not having seen Adam Bien's tool set, I've no idea how good it is, but it strikes me that something that promises should to abstract <i>J2SE</i> itself is going to be a fairly specialized productivity tool.

    Given that an implementation already exists, why not open up the source and let the community play with it, instead of going straight to the standardization stage?
  3. The link above does not give the page where review could be found. This is only JSR 193 page with only request information. Where is draft for review ?
  4. Donatas,

      This JSR has not entered spec review yet. The JSR itself is available for the public to review and send feedback or hate mail.

    Floyd
  5. I think a client side container is a really great idea. As everyone who's reading this knows, web and J2EE containers have proven to be a boon to productivity for server-side Java.
    It is my opinion that the client side has been neglected in favor of dynamic web applications. However, I do think there is a lot of momentum happening for an important trend: GUIs are coming back in style!

    SOAP may or may not become a B2B standard, but surely it is being used for remote procedure calls. And of course, there's always RMI and CORBA IIOP.

    I think such a container should be dynamically extensible. It appears to me that JMX and MBeans would be ideal for providing extensiblility with pluggable modules that can be added to and extend a container at runtime.




  6. In so far as a client-side container is concerned, I agree that such a thing would be very welcome. And, in fact, we already have one - in Eclipse.

    "I think such a container should be dynamically extensible... pluggable modules..."

    This accurately describes the Eclipse kernel.

    Its a pity that Eclipse requires JFace rather than Swing - but on the other hand, JFace looks a lot nicer than Swing for the same effort.

    -Nick
  7. Nick,

    I really like Eclipse but it is still possible to create good looking applications in Swing that have a similar kernel like architecture.

    JDBInsight has an OOUI framework that results in the console having very little domain specific code. The JDBInsight console views that world very simple - a single object which has descriptors that ties actions, properties, views, contexts, icons, renderers, and so on, together. This is described in XML but prior to build converted into Java state objects. The OOUI framework was created about many years ago when I had the beta of Swing 1.1 and has stood its ground on many projects (especially J2EE). Of course it has evolved somewhat.

    Regards,

    William Louth
    Product Architect of JDBInsight
    "J2EE tuning with Insight"
    www.jinspired.com

    "Attractive Things Work Better" - Donald A. Norman, Interactions, ACM

  8. >>"I really like Eclipse but it is still possible to create good looking applications in Swing that have a similar kernel like architecture. "

    Agreed. The thing is, is that such a client-side container, with widespread backing and support hasnt existed until Eclipse. Its the biggest project by far in this area - and it was designed to be plugin-oriented from the ground-up (unlike other efforts like Netbeans).

    You dont have to look far to find my views on JFace - I am no big fan. I prefer the MVC Swing programming model any day to WIN32/JFace (where the programmer has to write the necessary MVC frameworky stuff).

    However, as good a programming model as it is, you do have to put in an unreasonable amount of effort to get a Swing app to look any good and behave anything like a Windows app. Its obviously possible (see Weblogic Workshop or IntelliJ) but its a question of how much work it is -and how much work it need be. There is definitely no shortage of very crappy Swing UI's. Even Netbeans, which is often held up as a shining example of Swing, is a pants UI, IMO.

    Its the balance of how much work to make it maintainable (JFace) vs how much work to make it look nice (Swing). Eclipse tips the balance in favour of Jface because there is considerably more in the platform (hence less to write).

    -Nick
  9. With all due respect, I think that you are missing the point. From what I can tell, jsr 193 addresses many issues that are prevalent in deploying/developing swing based applications either as plain vanilla apps or via webstart. Some of the apis which have moved to the core distribution in 1.4, specifically webstart, provide abstracted services for file persistence, etc., but what is missing and what hopefully jsr 193 at least starts the conversation on, is a higher level of abstraction for some commonly needed services on a rich swing client, way above the abstractions in the swing api, such as thread/object pooling, service lookups, etc. Developing panels and frames doesn't seem to be the issue from what I can tell, but more like what event handlers to based upon swing events. Avalon/Phoenix is a nice framework that addresses some of these issues and I have toyed with the idea of using it on a front end client.
    What jsr 193 addresses, I think, are some holes in the j2se for front end clients that some other frameworks (dare I mention .Not? ) already have filled.

    Jin
  10. What is the point of the word 'vanilla'? As I read technical articles I constantly have to substitute it back from geek slang to the meaning - 'standard'. Does it have any value as a technical word, especially after 'plain'?


  11. What the h*** is "vanilla" ?
  12. From vanilla.com: "Vanilla is the only edible fruit of the orchid family, the largest family of flowering plants in the world."

    Vanilla is used to flavour food. A typical use is in flavouring ice cream. Vanilla ice cream is the most common, basic flavour you can get, ie stock standard. The trouble starts when everybody uses it liberally to describe 'flavours' of webservers, or in sentences like:
    "From what I can tell, jsr 193 addresses many issues that are prevalent in deploying/developing swing based applications either as plain vanilla apps or via webstart."

    --what is the point? Does jsr193 also address issues found in neopolitan apps or chocolate ripple apps? To be honest, I think I am most disturbed by the description of computer hardware and software as something tasty and edible. It is not!


  13. Hm, I did not look at the specification and I will not do so until it gains some more ground. At the moment this looks very strange to me: An abstracted container on top of a resource hungry virtual machine that in its own right uses a huge amount of memory and delivers a very large set of APIs (and developers freedom for that matter).

    So what types of resources is the client side container going to manage? The things that are mentioned are pooling, caching, lifecycle management and authentication. This sounds very vague, since the services mentioned are all there in one way or the other. However I find it tempting to make swing a bit more easy to use (and performant) with object pooling etc.

    But the services mentioned are more services for the application. Do we really need this? Guidance is not a bad thing, but it is something that puts huge constraints on the developers and that are a nuisance if done in an inadequate matter. This sort of reminds me of the generated application blueprints that came with a number of IDEs. Since none ever came even near to impress me, I wonder if we may expect a lot more from this standardization effort.

    Anyway, time will tell...in the meantime, why not try a nice
    GUI framework for JSPs available at http://www.iternum.com/i3test ;-)