Swing is a good choice, however, it will take you some time to detect all the features provided by the framework. I had to redesign my first Swing app several times to detect the complex contextes of the base classes. But this feature is not new for complex frameworks. -)
Swing and performance: It seems that Sun pushes its resources to the server-side because Swing based application eat still a lot of resources and the performance cannot be compared with native applications like Motif or Windows. There are several things which cannot be changed (i.e. stack architecture of Java, interpreting byte code), however, it seems that architectur specific things like the rendering of widgets could be improved. An example: If you have complex GUIs than it takes some time to update them. It seems that all widgets are rendered and not only those which have changed. To speed up the application I only can recommend to use the thread technology which is - of course - supported by Swing (i.e. -> Threads and Swing, http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html)). However, you must take care this aspect in your design. Swing based apps can run on the top of a browser using the plug-in provided by Sun. The installation is done automatically and the browser (IE/NS)delegates all Java things to the plug-in. It's a little bit ironic but NS has changed the life-cyle of an applet (NS 6.x)! franzR -----Ursprüngliche Nachricht----- Von: A mailing list for discussion about Sun Microsystem's Java Servlet API Technology. [mailto:[EMAIL PROTECTED]]Im Auftrag von Grace S. Aguilar Gesendet: Montag, 10. Juni 2002 04:52 An: [EMAIL PROTECTED] Betreff: Re: Servlets + Swing Hi again! Actually, the only thing clear about this system I'm designing is that it has complex forms for user input thus I opted to use Swing. On the other hand, one of the major issues is that, the system will be ran on a disk-less environment and that, multiple concurrent access is expected (issue on multi-threading). Would appreciate your comments specially on performance issues. Thanks again! -----Original Message----- From: A mailing list for discussion about Sun Microsystem's Java Servlet API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher K. St. John Sent: Saturday, June 08, 2002 12:17 AM To: [EMAIL PROTECTED] Subject: Re: Servlets + Swing "Grace S. Aguilar" wrote: > > I'm wondering, if I'd be using Servlets that would require the browser to be > downloaded followed by the loading of the applet. On the other hand, if I > opt to use RMI, I could be able to run the application with (using Java Web > Start) or w/out the browser. However, I read in one article that it takes > long time to perform remote method calls. > I think you may be mixing some different issues: 1) Which RPC mechanism you use to get your client talking to your server: raw HTTP, SOAP over HTTP, RMI, plain old sockets, etc. 2) Which user interface mechanism you use: pure Swing (a regular Java application), pure HTML (just a browser), or a Swing applet running inside an HTML browser. 3) How you implement your server logic: putting the logic right in the servlets, putting the logic inside the RMI method implementations, or putting the logic in beans (of one sort or another) that can be called from an RMI or servlet container. 4) Your deployment mechanism: Java Web Start, download an applet into a browser, etc. Many people choose the raw HTTP/pure HTML/code-right inside-the-servlets approach, but you are pretty much free to mix and match as you want. Another popular option is raw HTTP/pure HTML/servlets+EJB. Or you could do a SOAP/pure Swing/servlets implementation. You need to address each of the above three categories on their own merits. For instance, RMI over an unreliable transport like the public internet is risky, but RMI over a LAN is perfectly fine (and if anything is considerably faster than a bloated monster like SOAP) -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
