Discussions

News: Will a Component Market, or Rich Clients Emerge for Java?

  1. The failure of a component market to emerge for the Java community troubles some people. There are signs of progress in two approaches: that of Eclipse, and JSR 198. Mike Milinkovich or Eclipse, and Mike Burba of Compuware give their 2 cents on the issue.

    A couple of Mike Milinkovich's thoughts
    Q: Do you expect a standard to be adopted?

    Milinkovich: I believe that there already is a standard¬óthe OSGi-based plug-in model that is used in Eclipse. Eclipse provides a real implementation that exists, is open source, and is well-documented. At the current time, the JSR 198 team has not yet issued a public draft specification, so it is difficult for the open development community to evaluate the proposed technology because of the closed nature of their proceedings.

    The idea of "write a plug-in once, run it in every IDE" sounds appealing. However, one has to understand that this is a comprehensive problem. Interesting IDE plug-ins are deep. That is, they seamlessly integrate into the IDE and add interesting new functionality.

    Consider a UML modeling tool that can update the diagram when the source in the code editor changes. To do so requires more than an API to add an action to a menu. What is needed is an API to the abstract syntax tree of the edited source. This requires us to standardize many non-trivial APIs.

    Any spec that emerges from JSR 198 will clearly introduce a lot of new APIs. These APIs will need to be validated, and industry adoption will depend heavily on the success of the validation process. The Eclipse approach is different. APIs are specified, validated, and kept stable as part of an open development process.

    Q: Do you expect a market to emerge for UI and other IDE plug-ins as has happened with Visual Basic? If yes, when and how?

    Milinkovich: It already has. The Eclipse Foundation currently has more than 50 add-in provider members¬ócompanies that are developing pluggable technologies that interoperate with Eclipse. In addition, there is a vibrant open source community that has built up around Eclipse technology. The Eclipse market is robust and rapidly growing.
    A couple of Mike Burba's thoughts
    Q: Why do you think the JSR 198 is important?

    Burba: To expand on my comments in the panel, JSR 198 is important because it provides a common interface to the core IDE. A common API is important to plug-in vendors, because it greatly expands the reach of their value-added plug-ins. A good example of this working on the Microsoft side is the story of Compuware DevPartner Studio. The product was built by a startup, NuMega, and grew to become the largest Microsoft VS plug-in in the world (large enough to capture the attention of a larger company like Compuware and get acquired ;-) ). And we're not the plug-in for VS; there is a $500 million cottage industry that surrounds Microsoft's IDE. That kind of healthy ecosystem helps everyone: the IDE vendor, the plug-in vendor, and most importantly, the customers who are provided with a rich array of products to help them develop applications faster.

    Q: What will it take for 198 to be successful?

    Burba: Well, the JSR needs to be finalized, and we're confident that's going to happen in the near future. The expert group has made some good compromises in order to keep the JSR moving, such as focus on providing an API for about 70 percent of the common IDE functionality and making the JSR Swing/SWT agnostic. But obviously, it's also going to take the large IDE vendors to get on board and provide implementations. Based on our conversations, we think that's going to happen as well. You might see the open source IDEs such as Eclipse and NetBeans be the first to roll out implementations, and eventually the commercial IDEs will follow.
    Will a Component Market, or Rich Clients Emerge for Java?

    Threaded Messages (41)

  2. Swing is the problem[ Go to top ]

    "One reason Java has failed on the client side, while succeeding so tremendously on the server, is the lack of reusable components".

    No, the reason is Swing. Countless times I have seen Spring be defended fanatically and claims that if you only know how, you can write fast apps in Swing. As long as Java people and Sun adhere to that philosophy there will never be a Component or Rich Clients Market for Java.

    The Spring team are in the process of making a Rich Client framework in Swing. I hope that people will realize that when not even the Spring team can succeed with Swing, nobody can.

    Regards
    Rolf Tollerud
  3. P.S.[ Go to top ]

    Windows Foundation Classes for Java (WFC) is an excellent replacement!
  4. re: Swing is the problem[ Go to top ]

    I still find it highly amusing when people claim that Swing has failed. Java only succeeded on the server first, due to the fact that it was ideally suited to running server applications. The ability to migrate a Win2K/NT server application to UNIX/LINUX was a big deal with a corporate that I was working for.

    However, having since returned to a desktop app, I've found the client side of the Java community is starting to catch up with the server side. For good up to date info on what's going on in the client app world try checking out: ClientJava.

    Also if you are looking for component/application frameworks check out:
    - Spring-RCP framework
    - Pendulum, check out the CVS version as the binaries are out of date.
    - Swingwork

    The example apps with these should give you enough to go on. For look and feels, and general helper stuff, obviously you want to check out JGoodies, plus the SkinLF is a good concept.

    So before anyone else slates swing... check out the above and have a play with IntelliJ (arguably the best Swing app out there). Also, I'm not putting Swing ahead of Eclipse, I've just chosen to go the swing route, and I believe I've made the right decision.
  5. re: Swing is the problem[ Go to top ]

    I agree with you Stuart. The client-side commununity is quikcly catching up to the server side.

    We are using Swing for our in house claims management app. We rely primarily on the JDNC swing extenstions(from javadesktop.org) and the JIDE framework to layout our forms.

    I have never been a fan of WSYSIG editors, but JFormsDesigner made me change my mind. This tool (with JDNC and JIDE) has dramatically cut our development time and the complexity.

    I would say there is really no excuse anymore to not use Swing for client development.
  6. re: Swing is the problem[ Go to top ]

    Swing is the problem. Those who refuse to see this are in denial. And as usual, admission is the first step toward solving the problem. Yes, you can use it to make forms, and yes there are IDEs to help you, but the following are still true:

    1. Swing is slow. Everything is painted in a lightweight manner, often without hardware acceleration, and it's a drag. There is garbage collection involved in everything, too. When I worked with Swing in a non-trivial application where UI design was critical, slowness was the #1 customer complaint for the entire length of our failed effort. Much measurement was done, and it was clear that much of the slowness came from the UI.
    2. Swing looks crappy. When will it catch up with the Windows XP L&F (for free...)? Also lacks the power you need to make really nifty UIs, like those found in most media players.
    3. Developing nice UIs in Swing is difficult, in cases where it is not impossible. I can write it in VB.NET in half the time or less, add more flair, and have it run better, with cleaner looking code.
    4. Swing is a buggy hell. Not really a core technology issue, but it is a practical one. I've seen it all; memory leaks due to the lightweight cursor blinking thread not releasing references after a dispose() to one we are still facing, a UI that won't repaint most of the time on the latest Sun 1.4 JRE on Sun hardware running Sun's OS. Fortunately it works fine on the 1.3 JRE, but now we have to bundle two enormous VMs with our installer instead of one.

    That said, I'd rather write a better looking UI in VB.NET, accept the fact that I'll only be able to run it on 90% of clients (99% within the enterprise, 100% of the ones I'm targeting now), and use web services to integrate with the more powerful Java server side technology.

    Swing is the problem.
  7. re: Swing is the problem[ Go to top ]

    1. Swing is slow. Everything is painted in a lightweight manner, often without hardware acceleration, and it's a drag. There is garbage collection involved in everything, too. When I worked with Swing in a non-trivial application where UI design was critical, slowness was the #1 customer complaint for the entire length of our failed effort. Much measurement was done, and it was clear that much of the slowness came from the UI.

    We have a swing app that we use to manage bank operations, an insurance company, credit card processing, and a couple of other areas that need to share information. I have found that since the 1.4 jvm came out, speed really hasn't been an issue. In fact our client is very responsive and the users absolutely love it. Saying java is slow may have been true 5 years ago, but anymore I think its just a cop-out. If the clients you are developing are slow, maybe your developers or development process need to be re-evaluated.

    2. Swing looks crappy. When will it catch up with the Windows XP L&F (for free...)? Also lacks the power you need to make really nifty UIs, like those found in most media players.

    Its caught up now. Take a look at JGoodies. They offer many beautiful choices for L&F. Our apps look just like a VB.NET app running on XP. You'd probably be hard pressed to notice much difference.

    3. Developing nice UIs in Swing is difficult, in cases where it is not impossible. I can write it in VB.NET in half the time or less, add more flair, and have it run better, with cleaner looking code.

    Again, I say maybe you need to evaluate your developers. Do you have a bunch of VB developers without any java experience? I could see it taking a little bit to get up to speed in this case, but once you've done a little work with swing it seems quite straight forward and easy to me.

    4. Swing is a buggy hell. Not really a core technology issue, but it is a practical one. I've seen it all; memory leaks due to the lightweight cursor blinking thread not releasing references after a dispose() to one we are still facing, a UI that won't repaint most of the time on the latest Sun 1.4 JRE on Sun hardware running Sun's OS. Fortunately it works fine on the 1.3 JRE, but now we have to bundle two enormous VMs with our installer instead of one.That said, I'd rather write a better looking UI in VB.NET, accept the fact that I'll only be able to run it on 90% of clients (99% within the enterprise, 100% of the ones I'm targeting now), and use web services to integrate with the more powerful Java server side technology.Swing is the problem.

    I have run into an occasional glitch in java, but who's perfect. At least it doesn't take down the OS when something goes wrong. I personally haven't run into any sort of show stopper bugs with the vm through 1.3 or 1.4. I have run into some memory issues, but after looking around, I have always found it to be a coding error. Maybe I'm just lucky to have good running client-side as well as server-side apps in java. Maybe Intellij is a fluke, too. Don't tell Jetbrains. Actually, I'm really surprised to hear you complaining about performance and then stating you are going to use web services for all your communication to the server. To each their own I guess. I personally believe if clients are written properly in java, they are just as snappy, beautiful, and easy to maintain / write as anything else out there. I'm sure if you do a poor job in your coding with a VB.NET app, it isn't going to be responsive either. By the way, how did the VB.NET client perform on the Sun hardware running Sun's OS?
  8. re: Swing is the problem[ Go to top ]

    I personally believe if clients are written properly in java, they are just as snappy, beautiful, and easy to maintain / write as anything else out there.
    In Java - yes, in Swing - no. For me the whole idea of Swing is wrong. It tries to emulate native controls by simply drawing on a window context. This process does not take advantage of region optimization, message queueing, hardware acceleration, data exchange and drag-and-drop features which are already built into native controls. Window update is slow with lots of flickering.

    You say IntelliJ IDEA is a good Swing example? Right, IDEA is done very well, but there are things which they just could not optimize without hacking Swing code, so they did not. For example, the menus and dialog boxes are painted with default OS color, then repainted in IDEA color. It is even more funny if you use Windows machine and choose Windows L&F. The menus and dialogs are painted in Windows color by Windows, then repainted with some other color by Swing (or by IDEA?), then repainted with Windows color again, now by Swing. So, even such a polished application as IDEA has inherent Swing flaws. I don't know why they decided to use Swing for IDEA instead of SWT. I guess SWT was still in its infantry when they released first IDEA version so they did not have much choice.

    Swing widgets are not OS controls and therefore they do not look the same as controls and do not behave the same as controls. The simplest drag-and-drop operation which works with standard OS controls and which is supported by OS/window manager (and works with SWT app right out of the box) does not work with Swing without additional programming. The keystrokes sometimes work different, some key combinations produce wierd characters... So even with Windows L&F Swing application is absolutely not the same as an application with the native controls.

    So, I would have said that SWT is better, if it hadn't been for Avalon/XAML. SWT for Windows is based on Win32 API, which is officially claimed as deprecated for future Windows versions. So, unless SWT would be rewritten using WinFX, it would be deprecated as well. It will be supported for some time and at least it provides native features automatically. I can't say which is better, but Swing is definetely worse.
  9. why not just lie down and die?[ Go to top ]

    "So, I would have said that SWT is better, if it hadn't been for Avalon/XAML. SWT for Windows is based on Win32 API, which is officially claimed as deprecated for future Windows versions"

    Please, that is incredible long into the future. Even if Avalon/XAML really comes into play 2006 it will be 5-6 years before you can count on it to be in place, and who knows what SWT will be like by then?

    Java developers are the strangest community of all time. They have a solution that works now, Java SWT compiled with Excelsior which is the absolutely best and superior solution, better than .NET even. Still they bicker and fight among themselves. In that case there really is not any hope is it, why not just lie down and die? :)

    Regards
    Rolf Tollerud
    (Obi-Wan Kenobi, there is not any hope)
  10. re: Swing is the problem[ Go to top ]

    VB.NET ? Oh please !!.
    I think hat the crux of the matter is that many developers are desperately OO illiterate. Sadly Swing is pure OO and maybe painfully so. Its API is quite elaborate and many would find it complex. Hopefully, JNDC and other such initiatives will alleviate these issues.

    Having had a go at c# Windows Forms I must say i found it to be crude and inane. Actually it attempts to copy Swing's Layout model which would not be such a bad thing if it hadn't made such a hash of it. Win forms is faster than Swing but Swing is fast enough and can only improve (see Tiger enhancements). Considering Swing's vast extensibility, flexibility and unrivalled portability, its speed is definitely good enough.
  11. Swing is the problem[ Go to top ]

    There has been much progress made in the open source community with what we call "Swing Simplification". Much is being driven by the experience of those who build rich-client applications for a living and know what works and doesn't. The Spring Rich Client project (and our team of developers), as well as the Java Desktop Network Components (JDNC) initiative are two good and exciting examples. In addition, Karsten's Lentzsch's JGoodies libraries are fantastic.

    Scott Delap's "ClientJava" portal/blog is doing a lot to get the word out: it is possible to write well-layered, maintainable business applications quickly atop _standard_ J2SE Swing TODAY.

    Swing is a complete widget toolkit. It's powerful, performant, and standard. What's been missing for so long are higher-level abstractions that make the toolkit easier to use. What's been missing are fine-grained open source projects that fill gaps and drive innovation, and a smart glue framework to connect the pieces together (Spring shameless plug;-)). That really is changing now...
  12. Yes, Swing is the problem.

    People who has already developed SWT applications and eclipse plugins knows how easy is to do so.

    I would like to read more about "creating business application using eclipse SDK" and "using Eclipse as a container for business rich applications".
  13. With SWT you can compile to native[ Go to top ]

    And not to forget that with SWT you can compile your application to native with Excelsior and ship everything in a 3 MB file without Java runtime or any other VM.
  14. With SWT you can compile to native[ Go to top ]

    And not to forget that with SWT you can compile your application to native with Excelsior and ship everything in a 3 MB file without Java runtime or any other VM.
    Hi Rolf.

    While this is true, imho this isn't really feasible. In fact I did a tutorial on just this subject (was supposed to be a book chapter but came to late, so we decided to make it available as a separate download on our book homepage http://www.javapraxis.de - you can get it here http://www.java-praxis.de/pages/Kapitel8.zip - only available in GERMAN!!!)

    The reason I think this is that in order to ship a standalone compiled version of your product you have to generate a full list of all classes your product uses (in order to be able to include them). These lists are generated automatically while you click through your application. But beware: don't miss any important clicks or some essential classes won't be included and your application will crash. My last evaluation of JET is a bit dated, so maybe now it is better, but then the speed and memory consumption of natively compiled java weren't really better.

    And one last thing: Swing apps could be compiled to native code also if Sun would allow the partial redistribution of the JDK (one would only need a few dlls). But as long as this is not the case I don't expect to see many natively compiled Java apps.

    Cheers
    Michael
  15. Sorry little typo there.
    The first link should read like this: http://www.java-praxis.de

    P.S.: When will theserverside finally include a feature which allows you to edit your own postings? This shouldn't be a security issue.
  16. Hi Michael,

    When I try to download "Kapitel 8 SWT - PlattformÜbergreifend" I only get the Java example is it an error or what?
  17. Hi Michael,When I try to download "Kapitel 8 SWT - PlattformÜbergreifend" I only get the Java example is it an error or what?
    If you download the ZIP file and extract it you get readme.html which is the german language tutorial I mentioned above. The rest is the little sample application for the tutorial which I wrote (and support files).

    Cheers
    Michael
  18. With SWT you can compile to native[ Go to top ]

    "Swing apps could be compiled to native code also if Sun would allow the partial redistribution of the JDK (one would only need a few dlls)"

    That is true as I have pointed out earlier. But Sun don't allow it so what.. And as SWT is smaller it still would outperform Swing and the distribution would be smaller.

    "but then the speed and memory consumption of natively compiled java weren't really better"

    That is certainly not my impression. SWT is snappier even when not compiled and when compiled even more so.

    But the main thing is that the startuptime is so much better, better than C# even. Any property broker can tell you that location,location,location is all that counts in that business. Likewise, in a rich client app = startup,startup,startup.

    Regards
    Rolf Tollerud
  19. Argg Swing![ Go to top ]

    I personally argee that there is a problem with Swing and I wouldn't say that it is the "power" but rather the complexity of Swing. People say that you can do anything with Swing and I should trust them that it's true but for me that's not the case. Spending a couple of DAYS to make a table behave and look the way I want it is NOT COOL!

    It should be way easier to make these GUIS going, as easy as HTML+CSS+JavaScript!
  20. I read the same client, rich client platform, Swing vs SWT posts over and over again. They remind me of the current political commercials. Half arguments and half truths. What I would love to know is why the desktop development scene with Java is evaluated differently?

    1. "Web apps are so much easier than desktop development" ... The core interaction model with webapps is simplified so of course it is easier. You have a MVC pattern with a view technology that causes you to jump through hoops to get an acceptable interaction level. Before the entire web browser era users were used to having a rich client interaction level with their applications. I don't think using the browser as the client was a shift made because of a superior technology. It was a shift made because of because of deployment ease and the fact that most applications didn't and still don't need the bells and whistles a rich client platform can provide. Now we have a market that has come full circle. We have broadband and user demands of more interaction in some cases. You can't tell me that it is easier in these cases to create the type of application rich client users request with Javascript, CSS, and HTML. Swing, SWT, and other technologies were designed with this type of application in mind. Furthermore the reason people complain that "Swing or SWT is hard" is not that the api itself is hard. They simply now have to deal with things like sortable table columns, dynamically updating data, real time data validation across their application, etc. The requirements of a rich client application make the task harder not the technology. Their application scopes have changed. You can't just expect to fire up a wizard and have the application written for you. Why is the expectation at that level?

    2. I will agree that we need better reusable components and frameworks. However, why with the client market do we simply gripe about it and do nothing? People realized early on with Servlet and Jsp technologies that some sort of order was still missing. How many MVC frameworks are there? I see a new one on TSS every day it seems like. In the client space we just say SWT this or Swing that. Saying they are inadequate is like saying Jsp and Servlets do a horrible job of supporting web apps.
  21. This year's JavaOne message seemed all about expanding the base of Java developers from 2+ million to 10 million by making development easier. I couldn't be at the show in person, but I watched what content was available from afar over the web and followed what bloggers were saying. The executive summary seemed to be that Sun's answer to making development easier was the combination of JavaServer Faces plus the Studio Creator tool. It seemed exclusively JSF/Web-focused from what I could tell/see.

    While Microsoft carefully promotes both its Windows Forms stack for rich clients and "WebForms" (ASP.Net) stack for web applications, illustrating developer productivity via Visual Studio .NET, I was not getting the same "two-pronged" productivity message about Studio Creator from Sun (or other Java-camp vendors).

    Where was Studio Creator for Swing to parallel Studio Creator for JSF ?

    Where was the demo on stage that showed how -- whether you wanted "rich" or "reach" -- the Java platform had you covered for developer productivity and ease of use?

    My guess is that answer was, sadly, that there isn't a simpler approach to rich-client GUI building available (yet?) that's supported by a mass-market Java IDE's.

    I work every day with customers building Swing front ends for real-world business applications and most every one has developed some kind of custom layer to hide the Swing GUI-building task from the bulk of their in-house business developers. Some build the GUI at runtime based on simplified XML-based screen descriptions (that include simplified data binding info in them). Others have their internal technology team build "SmartPanels" that mere mortal developers can drive through some other kind of runtime metadata or properties they can set more easily. Virtually none of them is allowing/requiring their business developers to hand-design each Swing panel.

    Some of their "custom Swing screen design productivity layer" solutions have found JGoodies to be useful in their custom productivity layers for Swing, but to my knowledge none of them has built any kind of visual tools support for their simplified, custom screen-building approaches. The reality is that business developers spend the bulk of their time building an ungodly number of screens. There should be something better that's a standard part of the Java platform that all vendors can support with their visual tools...

    I'm hoping that the JDesktop Network Components are the start of Sun's paying attention to simplifying the building of rich-client apps for the Corporate/Business developer. I'm hoping that a declarative-databinding standard like JSR 227 can be coupled with JDNC components, and JGoodies Form Layout, and have a slick GUI Designer (something like what Karl Tauber's cooked up in JFormDesigner would be a good start) and ideally have standard ways to build the inevitable application "desktop shell" with menu and window and functional security management that I see every customer inventing for themselves when building Swing-based applications.

    I've mentioned as much to some folks on the Swing and J2SE teams at Sun in a mid-August chat we had with them as part of their requirements gathering for future J2SE versions that they do with various vendors.

    I know that when I travel and peek behind the desk at many businesses that I frequent, they sure are not all running web-based applications. Many of the apps that I see behind those desks look like they were built with Visual Basic, Delphi, or some rich-client approach. My experience is that it's not completely a web-based world out there, especially in the small-to-medium-sized business space.
  22. I work every day with customers building Swing front ends for real-world business applications and most every one has developed some kind of custom layer to hide the Swing GUI-building task from the bulk of their in-house business developers. Some build the GUI at runtime based on simplified XML-based screen descriptions (that include simplified data binding info in them). Others have their internal technology team build "SmartPanels" that mere mortal developers can drive through some other kind of runtime metadata or properties they can set more easily. Virtually none of them is allowing/requiring their business developers to hand-design each Swing panel.Some of their "custom Swing screen design productivity layer" solutions have found JGoodies to be useful in their custom productivity layers for Swing, but to my knowledge none of them has built any kind of visual tools support for their simplified, custom screen-building approaches. The reality is that business developers spend the bulk of their time building an ungodly number of screens. There should be something better that's a standard part of the Java platform that all vendors can support with their visual tools...
    I found this a really interesting point, matches some of what I've seen. From your comment, it sounds like these custom layers are being built to accommodate a skill set issue, i.e. Swing requires a more talented hand than most corporate IT shops have, so they wrap it so that others on their team can be productive. True?

    I'm seeing a lot of interest in our technology, because Nexaweb can provide both a rich client UI that is specified declaratively (XML), with the guts of the Components (client and server side event logic handled in Java).

    Do these corporate shops have any interest in hosting their applications within web browsers (lower deployment costs), or are they more interested in rich front-end for middle-tier logic at a lower development cost (lower skills barrier)?

    Scott Cranton
    Nexaweb Technologies
  23. you can't be massive with Java in the client because the JRE for running client apps had the following _issues_ for years:

    - you need to download a JRE in order to run it. a what?
    - it's a 17 mb mammoth. Oh, you have dial up, what a shame.
    - It takes several MBs of memory just to run.
    - slow, very very slow. Most of the time, Swing apps weren't user friendly.

    Stop thinking as a geek and try to role play a non technical ppl (yes, there is a world out there, a many of those ppl doesn't like computers at all, or just don't get it, or just don't want to learn what a java runtime is).

    Deploy inside your company is easier because you supply the JRE but you still have to overcome the FUD on java cilent apps, most of the time, backed by the vast amount of poor Swing apps.

    Unless you provide the JRE installed in your OS, or create a dependency on users to install it, with a one-JRE-for-all (VM sharing in 1.5 is welcome) so you can "install once ond forget forever".

    No, common ppl don't like to patch apps, don't like to execute comand line bats in order to launch their favorite app, they want association between applicacionts (have you ever seen a java appa taking benefits on another java app installed ?).

    So, Rich Client Application in java are a no go.

    Unfortunately :(

    Fernando Racca
    fracca at gmail dot com
  24. No, common ppl don't like to patch apps, don't like to execute comand line bats in order to launch their favorite app, they want association between applicacionts (have you ever seen a java appa taking benefits on another java app installed ?).So, Rich Client Application in java are a no go.
    I helped deliver a Swing application for realtors, many of whom don't know what a command line is. Our paying beta customers haven't made any of your complaints. ZeroG shrink wraps our application with such tight native integration and installation wizardry that it takes an experienced eye to tell that it's Java during the installation or after. Our customers don't know it's Java unless we mention it, and it isn't rewarding to raise this with naive users. Commanding the desktop with a bare JRE is straightforward, so your issues above seem more complicating than necessary.
  25. Ever heard of webstart ?[ Go to top ]

    It exist since 1.4, it has automatic update of VM, incremental update of your applications, on demand load of application modules, restricited sandbox security model ... so yes Java is ready for Richclients.

    The question is more on the GUI part IMHO.

    And MS does not have any solution to that, even XAML does not provide any real life solution to issues such as layout design and enforcing an ergonomic policy or decoupling UI zonning with UI theming.

    So the richclient battle is just about to begin ...
  26. I have been researching a lot lately and found some very interesting things that i'd like to share.

    Well, in my previous post, I was complaining about the problem with Rich Clients was the Java Runtime and the fact that Swing often is pretty slow (yes, Java 1.4 does a great effort, but still lacks ).

    Excelsior would be nice, ZeroG is usefull, but none of them could be used in open source development (and many other environments).

    Then this paper automagically came to me by a friend http://www.cs.umanitoba.ca/~eclipse/6-Compiling.pdf

    Basically it tells you how to compile Binary executables in Eclipse with MinGW and the SWT runtime DLLs.

    Once again, Eclipse was the answer.

    I think that Mike Milinkovich is right, if you are planing development of RCP, you should take a look at the eclipse platform, even more taking into consideration tools like the reporting project and the Visual Editor plugin (which is trully amazing).

    Fernando Racca
  27. There are a few Java UI component sets out there that have nearly the same functionality as Swing, but that are faster and run in web browsers. Some even run in the older versions of IE without the Java plug-in.

    These component sets are presently embedded in the Java Rich Client platforms supplied by companies like Altio, Asperon, Droplets and Nexaweb. In the case of Asperon the UI component set is called the KWT. The KWT could be made available separately if there is interest. Would this type of solution be useful to the Java community?
  28. NetBeans Form builder[ Go to top ]

    I don't disagree that Sun's emphasis has been on the web front, but they haven't completely left the Rich client by the wayside. NetBeans has long provided a nice tool for starting a Rich GUI. Certainly it is no VB, but it does provide a simple tool for creating a simple panel. I have used it at times when I needed something simple and quick. It has done the trick.
  29. Sun Looking to Expand JDNC Effort[ Go to top ]

    I noticed this job posting from Amy Fowler where she says "we're looking to expand the sun-backed
    engineering resources on JDNC".

    A good sign from Sun in this department for Rich Clients.
  30. Many factors other than swing[ Go to top ]

    There are certainly other factors than just swing being the problem... also, not all components have to be swing.

    Swing suffers from the same problem as everything else in the JDK, it's a half-implementation. By that I mean, and now I understand why, SUN implemented just the underlying core basics to make things flow. There are very few niceties in the JDK because the Java biz model doesn't allow for development on the same library scale as .NET.

    Although you can do anything in swing, you have to handle almost everything in it as well. It's overly complex day-to-day because there are no pre-built goodies like wizards, managed grids, managed trees, etc. Once you get used to it though, it's pretty nice, but the learning curve is kinda insane. With VisualBasic, I can get a simple app out with minimal reading in a few hours.

    I don't think it's so much as there's not a component market for swing. I don't think there's a market for swing period. Until swing becomes as widely used as apps built in windows, linux, and mac, then there will never be a componenet market for it because no one will be there to purchase components.

    It's somewhat of a shame too - it's write once, run anywhere, at least now it is. Hopfully the pushing of the JSR and a large varied desktop OS market will help change all this.
  31. Great thread the tide is moving[ Go to top ]

    Chaps, interesting post and well worth a reply.

    I have recently completed the development of an Eclipse Rich Client Platform application. It was to demonstrate the how to achieve disconnect Motor Quote Insurance quotes for Insurance sales teams. The RCP included an embedded Cloudscape (Apache Derby) database for holding local cached data. It also had a Quote Engine developed in Java with a WSIF interface. This allow a local or remote quote to executed. The real benifit of RCP is that you can define your own product branding and Intro pages, so you get About box, preferences,help all for free. .Net WinForms has some clever features but no way as advanced as the RCP environement.

    This prototype was developed along side the .Net C# WinForm solution, in comparable time and function. (10 days)

    The key was in the plugin and perspective designs, with more resulable plugins on the market this will increase the development speed. I would loved to have used an XForms to SWT processor for example.

    The other key is to remove any Eclipse branding before demoing. User cannot tell the difference between Eclispe RCP or .Net, so the issue then comes down to all the other issues, like application delivery version control etc. OGSi will help and other things like Java Web Start. Dont forget to get an old Windows NT box up and running with .Net it takes a 50mb download to get the .Net CLR up and running. So a 17mb JRE and 20mb RCP apps is not far off.

    Customers are getting fed up with trying to force Web technologies to do Rich client solutions. So the key is build your SOA with WebServices have an ESB holding it all together and use Web technologies for Web Channel and Eclipse RCP for Call Centre , Branch channels. It make sense :-)

    These comments are my own and not IBM's


    Thanks
    Matthew Perrins
    IBM Software Services for WebSphere
  32. Applications built on NetBeans[ Go to top ]

    Note also that companies (to name a few, Nokia, Compuware, BEA) and individuals have been building rich-client apps on top of NetBeans for years, and it represents a very mature framework for doing so - a list can be found here. The platform by itself is quite small and lightweight, and provides a huge number of services (window management, configuration management, menus/actions/shortcuts, plugin dependency enforcement, to name a few) and there are a huge number of additional modules that provide useful services on top of the platform, which can be leveraged.

    Also, Scott Delap wrote:
    >1. "Web apps are so much easier than desktop development" ... The core interaction model with<br> >webapps is simplified so of course it is easier.

    One of the often missed points in comparing web apps vs. client-side apps is the sheer number of entry points. Consider that concepts such as "call throughput" (I often see this term in papers on optimization) as a way to measure/optimize performance of an application. Simply due to the facts that, a., all interaction is not shuttled through a single entry point - an http port (one could, I suppose, compare the event queue with one, but the variety of messages, the possible orderings of those messages, and the response time required make it a poor analogy), and b. the response times required are vastly shorter, make it a quite different programming paradigm. Every listener is another entry point.

    But few applications optimally decompose into a page-based paradigm (compare the usability of iTunes with the usability of mp3.com). So I would say that, given that a., there are a lot of Java developers out there, and b., software like iTunes is proving that a rich client environment offers a competitive advantage, and c. the companies those Java developers work for need to compete, it seems inevitable that such a market will emerge.
  33. SWT as alternative, and we need more...[ Go to top ]

    SWing & AWT haven been proven a failure of desgin. It didn't realize quick response is a key feature of UI, with native library support.
    Eclipse now has its own rich-client framework( some my friend has developed small apps on it ) based upon SWT, I think its feel & performance is satisfacotry.
    But is Rich clent .vs. Thin client equals rich client vs. Browser? Many people mixed these two diff concepts.
    Browse is some kind of thin client, but it's not fully qualified. The internet upsurge has pushed the browser too far, which make Browser burdened too much tasks that it not intented to, and to fulfil these uncapable tasks, many tech like script, activeX control was mixed in it. All these lead the browser to a super hybrid Gorgon. So it's time to let the browser retired.
    Though a little too far from the topic, please excuse me for continuing :p
    As many people have expected, the representive of the new generation of thin client should be some kind of distributed compute unit, which has part of data & compute power of the server, it can do some work offline with snapshot data slice retrieved from most recently. The relationship will not be request&service, but be some kind of cooperative computing.
    I think Sun & IBM should promote the new generation thin-client spec( Along with M$, after all, many client still will run on windows ) before Browser derive more oaf.
  34. ?[ Go to top ]

    What are you speaking about? The browser is the ideal thin client.

    Regards
    Rolf Tollerud
    (the only normal and reasonable person left in the world)
  35. Web browser is outdated[ Go to top ]

    What are you speaking about? The browser is the ideal thin client.
    I think the problem with the current browser is that it is not being used for its initial purpose in many cases. Web browsing was created to read and navigate through documents, NOT FOR TRANSACTIONAL APPLICATIONS. Since its cration, a number of ill-engineered enhancements were made to it what has come out with an unmaintainable mesh for a serious transactional application.

    But this does not mean that the idea of a common client for all applications is not right. A NEW BROWSER GENERATION for transactional applications is the way to go. This issue is independent of the Java language. Some initiatives like XUL, JDNC (too much Java and swing oriented), the W3C XForms standard, DataMovil and others offer enough background for a big company to take this issue seriously and promote a shift at the enterprise desktops for transactional applications.

    Rafael Benito
    rbenito@satec.es
  36. Web browser is outdated[ Go to top ]

    But this does not mean that the idea of a common client for all applications is not right. A NEW BROWSER GENERATION for transactional applications is the way to go.
    May be it is time to start using GOOD OLD XWINDOW SERVER (that works on client side by the way)?
  37. Web browser is outdated[ Go to top ]

    well,XWindow maybe a good prototype. The new thin client could be designed as lightweight as web browser and as powerful as XWidnows.
    The web browser, as someone said, is only for read, not for transaction.No state infomation is stored or managed. If redesigned, things like SSO could be easily implemented.
    I think the next generation thin client will be more common and more integrated, other thing like mail client, IM client , etc. will be put into it to make it a more general-purposed clinet platform. M$ is perhaps already on his way(MSN Explore is a bit of like this).
  38. Web browser is outdated[ Go to top ]

    May be it is time to start using GOOD OLD XWINDOW SERVER (that works on client side by the way)?
    What makes Xwindows thin, by the way? AFAIK, it's API is very complex, a real nightmare, plus it is not OO. If by thin you mean "exported diplays", then you're likely going to take your servers down with a high number of simultaneous client processes.

    Regards,
    Henrique Steckelberg
  39. Web browser is outdated[ Go to top ]

    What makes Xwindows thin, by the way?
    Do you consider a browser to be a thin client? :) A ‘thin’ client requires a very thick engine to run on it. And IMO thickness of an engine is not a problem at all: personally I did not hear complaints about thickness of an OS for a long time (desktop oriented GNU Linux is almost as monstrous as Win). This is a price to pay for smaller applications which just use shared resources and libraries. As long as environment is stable and incrementally updatable it is fine with me.
    AFAIK, it's API is very complex, a real nightmare, plus it is not OO.
    The beauty of XWindow is that majority of developers does not have to deal with XW API directly: there are QT, Swing, and many others libraries. I consider this as a strength of the technology: we do not think in the exactly same way, therefore some developers like one API and others like another, it does not matter for a client. Consider GNU-Linux applications: they are written with using different UI libraries and all of them work locally and remotely.
    If by thin you mean "exported diplays", then you're likely going to take your servers down with a high number of simultaneous client processes.
    XW architecture is not VNC like: it is more efficient therefore exact number of clients is questionable.
    And I do not mean that XW should be adopted as is, it probably needs improvements. I am advocating here XW architecture and ideology.
  40. Xwindows is outdated[ Go to top ]

    Do you consider a browser to be a thin client? :) A ‘thin’ client requires a very thick engine to run on it. And IMO thickness of an engine is not a problem at all: personally I did not hear complaints about thickness of an OS for a long time (desktop oriented GNU Linux is almost as monstrous as Win). This is a price to pay for smaller applications which just use shared resources and libraries. As long as environment is stable and incrementally updatable it is fine with me.
    For me, a thin client is not just about size, but complexity too. It should be small and simple. The collateral effects (OS, Browser, runtime, etc.) usually aren't counted in the sum.
    The beauty of XWindow is that majority of developers does not have to deal with XW API directly: there are QT, Swing, and many others libraries. I consider this as a strength of the technology: we do not think in the exactly same way, therefore some developers like one API and others like another, it does not matter for a client. Consider GNU-Linux applications: they are written with using different UI libraries and all of them work locally and remotely.
    If XWindows were really a beauty, there wouldn't be a need for so many APIs on top of it in the first place. Take Motif, for example, if it wasn't for it, XWindows would be dead a long time ago, IMO.
    XW architecture is not VNC like: it is more efficient therefore exact number of clients is questionable. And I do not mean that XW should be adopted as is, it probably needs improvements. I am advocating here XW architecture and ideology.
    XW architecture is very much like VNC regarding where the actual application process runs: you have a server and a client, where the server is responsible of exporting the display to the client, but the actual application is running at the server, and there is one distinct application process for each connected client. Depending on the application's memory and CPU load, a high number of simultaneous clients can really take a big server down. I've worked with a complex CAD system in unix some time ago, and saw this happenning many times, when some users opened remote sessions on one server simultaneously, taking it to a halt. This kind of architecture does not scale at all.

    Regards,
    Henrique Steckelberg
  41. Well we all know that swing is slow GUI breaks down in java (et al), but I honestly think we need a huge GUI project in java where we are able to create a SET of API which can harness the GUI power of the native platform. SWT is a great attempt in this direction but still in its infancy, I see no other application except eclipse and WSAD. There needs to be a whole desktop revolution in the Java side. Its not enough if we write a nice GUI system we will have to develop cooler applications on it. The ultimate aim would be do some thing like a media player which is fully java based..the dream will become a reality.
  42. ... I see no other application except eclipse and WSAD. ...
    I have to admit that there are not many examples at the moment, but here are a few:

    Azureus - bittorrent client: http://azureus.sourceforge.net

    RSSOwl - RSS Reader: http://www.rssowl.org

    SQLCreator - SQL query / development tool: http://www.snefru.com

    I think you'll find Azureus and RSSOwl are open source. SQLCreator is not open source, but it is free to use. I am sure that there are many other standalone SWT applications that will appear over the coming months.