Discussions

News: WebCream 6.0 released - AJAX for Swing applications

  1. WebCream provides a natural migration path for Swing applications by providing automatic conversion to AJAX. Virtually without modifications the existing Swing based front end can be deployed as a thin client. Our product supports every standard Swing component by providing an AJAX version that runs in the browser. What's new in 6.0 * AJAX functionality for component rendering and asynchronous communication with the server * Revamped rendering algorithm that now produces strictly complient HTML (bye-bye quirks mode) * Client-side sorting of JTable * Client-side filtering of JTable * Client-side splitter that actively resizes components in the browser * Client side validation via Validatable interface * Automatic resizing of maximized JFrame when the browser window is resized * Disable all components on submit and reenable them on focus gain * Support JFileChooser with SAVE_DIALOG option via file download * Built-in WYSIWIG Editor with spell checking and HTML formatting * Improved directory structure for scripts and stylesheets * Custom stylesheet for clean customization * Proper support for internal frames (all frames should be rendered, user should be able to click on frame header to switch to it) * Titled borders now use tag * keepAlive configuration parameter to keep server session alive by pinging the server as long as the browser window is open * notifyBeforeExpiration configuration parameter to display a notification in the browser allowing the user to prevent the session from expiring Our product supports most standard Swing component by providing an AJAX version that runs in the browser. Take a look at our demos to see how WebCream renders tables, trees, tabbed panes and dialogs. It’s a technology that has made our clients hugely successful because they were able to convert their Java Swing applications to AJAX websites in just a few days or weeks. The big advantage is that using WebCream relieves the developer from having to learn HTML, JavaScript and AJAX. http://www.creamtec.com/webcream/demos.html

    Threaded Messages (22)

  2. Looking at WebCream SwingSet demo I've got impression like migration of Swing applications won't be that easy specially in cases when: - Application uses some custom painting - Have some client side logic May be for very basic app can be migrated, but I have doubts about serious swing applications. To have a realistic sample try to make port of NetBeans for instance :) So the statement "convert their Java Swing applications to AJAX websites in just a few days or weeks" is quite slippery. So, think twice before migrating to WebCream. Max
  3. Maxim, Of course there are some limitations and it's not going to work for all applications. But there thousands of database driven applications written in Swing that do you regular tasks - data entry, search, display and navigation. Companies spent years developing them in Swing and WebCream has been very successful and migrating them. To answer your points more specifically: - Only few components of few applications use custom painting. WebCream has SnapshotRenderer that supports ANY custom painted component by converting it to an image and emulating mouse clicks. You can also write a custom renderer if you want to provide an AJAX counterpart. - Client side logic is not really a problem because WebCream emulates actions. It will be a problem if the application reacts to mouse movements but again, a large number (probably most) of the applications do not. - NetBeans - why would anybody want to migrate an IDE into the browser?:-) The whole point behind our product is to give companies who have invested into Swing front end an ability to deploy as AJAX. It should work well for many applications and would not work well for some. The best approach is to download the product and try it on your application.
  4. Looks most interesting, I'll definitely try it on a Swing app or two but I think most I'm involved in either extend Swing in incompatible (to WebCream) ways or use 3rd party stuff such as JIDE and JGoodies that are deeply coupled to Swing. Interesting timing as I'll looking into GWT to build a rich client but basically simple webapp. The ability to webstart and webhost (if thats the right word) the same app is neat. Basic type stuff I guess should work out fine. I'll see if I can find one to test it out on...
    NetBeans - why would anybody want to migrate an IDE into the browser?:-)
    Well there is this http://www.tibco.com/devnet/gi :-) Regards, Colin. http://hermesjms.com
  5. As long as yours or 3rd party components extend Swing components they should work. But the father you get away from the original functionality the higher is the probability that things won't work out of the box. You can of course write a custom renderer to fix things that don't work and the contribute it to the product. Or hire our professional services to do it for you:-) I think if I having a Swing/WebStart version of the application is not important, I would go with native AJAX framework such as GWT. But if you already have a Swing UI or want WebStart version for ultimate user experience then our product is definitely worth giving a try.
  6. Alex, Please, don't think that I consider that WebCream does not make sense at all. I just wanted to highlight potential problems because in your post you talk only about positive stuff of your product. I used Netbeans because it is one of the mostly recognized Swing applications and it is real example of what is impossible with WebCream. Alternatively you can try to migrate any business application based on NetBeans RCP which I suppose also far from trivial task. I could probably admit that for limited set of applications this approach could work. At the same time I suppose that such "migratable" applications should be quite poor in their client UI functionality that it is a question for me why they initially were not created using Web technologies :) Also I've found on your site a comparison of technologies: http://www.creamtec.com/webcream/ and it may be quite interesting how other product vendors do similar comparisons e.g. see this one: http://www.canoo.com/ulc/ (see "Compare UltraLightClient to:") Each vendor pushes comparison list which is more advantageous for his product hiding those points which are disadvantageous :)
  7. Maxim, I think we are in agreement here. Companies were choosing Swing not just for the ability to write complex custom graphical interfaces, but also for development productivity, immediate feedback to the user and a well-written set of UI components. Some applications such as NetBeans go well beyond the standard set of Swing components. Others stay with the standard set that they enhance with a few custom components. WebCream is not a good solution for applications with a lot of custom and 3rd party components. It is a very viable solution for applications that are built mostly with standard set of Swing components and fit well with request-response model. We have clients who have spent years building applications with hundreds of tables, forms, search screens and business logic. They happened to choose Swing which at the time was a viable solution to writing browser-based or desktop applications. Today AJAX client is a much more accepted choice, but from a business perspective they don't want to loose the investment they have already made. It's a lot cheaper to use WebCream and tweak the application if needed, then it is to rewrite the whole UI. As far as highlighting advantages over disadvantages, well, it's only natural to do that, isn't it?:-) We do mention limitations in our FAQ page and there is a list of supported components.
  8. We've actually used WebCream for our application and it worked amazingly well. We did have to spend about a month writing custom renderers and tweaking things here and there to make them work with WebCream/HTML. But the end result was awesome and it's hard to believe that it could actually work the way it does. Our app has a lot of logic and screens but they are mostly form based. But I can definitely see that it is not possible to migrate 100% of applications simply because HTML is still more limited then Swing and it's not possible to capture all logic correctly.
  9. Licensing scheme broken?[ Go to top ]

    1. You say that "open source license" costs $50,000. You do not say which open source license the 50k gives, but AFAIK a strict requirement of all real (approved) open sources licenses is that the licensee must be able to redistribute the software. As such, if i had faith in your software, i could pay 50k and then 100% legally give your software away for free to all other companies. 2. You also say that you grant open source projects an Apache 2.0 license. Again just AFAIK, but Apache 2.0 license does give very liberal rights to redistribute the software. If you have already given any open source projects the software under Apache 2.0 license they are free to redistribute it to anybody, including pure-commercial companies, which could had been your paying customers otherwise. This seems like a good example why using professional assistance in intellectual property rights management is critical -- a license ****-up can ruin entire business. /Henri Karapuu
  10. Licensing[ Go to top ]

    Henri, thanks for good points. I'll try to answer what we are trying to achieve with dual licensing. 1. Our open source license for commercial applications allows for redistribution with the client product but in binary form. The license is proprietary and it prohibits from publishing the source code to the public. We give open source commercial license to simplify the adoption of the product and to allow the customers to contribute the code back to the product. 2. I think you have a point there and I think the license that should be in place there is GPL. The goal here is to allow open source projects to leverage our code base and to encourage code contribution from non-commercial user base.
  11. Re: Licensing[ Go to top ]

    1. Our open source license for commercial applications allows for redistribution with the client product but in binary form. The license is proprietary and it prohibits from publishing the source code to the public.
    Then, it is not open source license. You should probably call it just "source code license", to avoid confusion.
    2. I think you have a point there and I think the license that should be in place there is GPL. The goal here is to allow open source projects to leverage our code base and to encourage code contribution from non-commercial user base.
    If you'd grant GPL license for an open source project then that project could give your software to companies, and the companies would be legally free to use the software in-house in commercial projects. Moreover, they would NOT be required to give their source code away, as long as they don't distribute their software outside the company. /Henri Karapuu
  12. WebCream!! really? did we skip Web4Play?
  13. What's wrong with applets?[ Go to top ]

    Swing applications can run in a browser as an applet. What is the added value of having the same application in Ajax? Werner.
  14. Re: What's wrong with applets?[ Go to top ]

    Swing applications can run in a browser as an applet. What is the added value of having the same application in Ajax?

    Werner.
    Are you serious? Hmmmmm. I don't see any emoticons so maybe you are.
  15. Re: What's wrong with applets?[ Go to top ]

    Swing applications can run in a browser as an applet. What is the added value of having the same application in Ajax?

    Werner.

    Are you serious? Hmmmmm. I don't see any emoticons so maybe you are.
    We need to sell new AJAX components, frameworks, IDEs, test tools, debuggers and justify building that 1 000 000 $ client for the customer. Don't stop the business by suggesting any old and easy technology. Frankly, I think there was something wrong with applets. Yeah, the browsers supported only Java 1.0. Hmm... Tomi
  16. Re: What's wrong with applets?[ Go to top ]

    OK, here is emoticon:-))) Personally, I think the concept behind apples was great and in theory they would have made the development of dynamic web pages much easier (compiled code, common UI framework and the same language as the server side). In practice you will be hard pressed to find a web site that uses applets today. We can argue about the reasons (Microsoft's decision to not support Java in the browser, Sun's inability to build a JVM that would start fast enough and appeal to end user like Flash etc) but the bottom line is that the web is not built on Java. It's built at least today with AJAX. Arguments aside, with our product we try to give people who invested into Swing an option to deploy or migrate their applications to AJAX model. Nothing stops you from deploying the same app as an applet or via WebStart.
  17. Re: What's wrong with applets?[ Go to top ]

    In practice you will be hard pressed to find a web site that uses applets today.
    Doesn't yahoo games use applets? I can name a few others if needed. BTW: WebCream and Creamtec are really terrible names. Do you realize that there are some connotations to the word 'cream' that you probably don't want associated to your company? Some people are likely to be too embarrassed to suggest using your products.
  18. Re: What's wrong with applets?[ Go to top ]

    In practice you will be hard pressed to find a web site that uses applets today.


    Doesn't yahoo games use applets? I can name a few others if needed.

    BTW: WebCream and Creamtec are really terrible names. Do you realize that there are some connotations to the word 'cream' that you probably don't want associated to your company? Some people are likely to be too embarrassed to suggest using your products.
    I can too. If anyone is into sports at all - NASCAR, Yahoo Sports ... .
  19. Re: What's wrong with applets?[ Go to top ]

    Well, there are a few sites with applets of course. But it is a tiny percentage and is nothing compared to what was expected in the 90s when applets were touted as the future of the web. Sites like Yahoo Mail, Google Maps, Yahoo Finance, Amazon and lots of others that are very dynamic were expected to be built as applets. HTML is a static markup and productivity in writing JavaScript for complex sites is still not comparable to Java. Last but not least, the momentum seems to be clearly with AJAX.
  20. Re: What's wrong with applets?[ Go to top ]

    Well, there are a few sites with applets of course. But it is a tiny percentage and is nothing compared to what was expected in the 90s when applets were touted as the future of the web. Sites like Yahoo Mail, Google Maps, Yahoo Finance, Amazon and lots of others that are very dynamic were expected to be built as applets. HTML is a static markup and productivity in writing JavaScript for complex sites is still not comparable to Java. Last but not least, the momentum seems to be clearly with AJAX.
    Well we can get into long discussions about why applets never took off but here's the short version: Java 1.1 sucked and MS trapped applets in it for a long time. Now applets are actually becoming viable as Java has matured. But AJAX is a pretty sweet technology. It's not as rich as applets but it's (generally) more lightweight a lot better than plain old HTML. Not everyone needs a full-blown fat client anyway.
  21. Re: What's wrong with applets?[ Go to top ]

    AJAX.

    Arguments aside, with our product we try to give people who invested into Swing an option to deploy or migrate their applications to AJAX model. Nothing stops you from deploying the same app as an applet or via WebStart.
    Exactly. It is all about flexibility. And Development vs Delivery. I would rather develop an application in Swing (or SWT). But sometimes the proper JVM is not and will not be available on the client. And being able to delivery it via AJAX will make it available and, as much as is possible in the browser, function like a "desktop" application.
  22. Re: What's wrong with applets?[ Go to top ]

    As far as names go, they were given by geeks who were thinking about Java as a coffee and not the "other" connotations. But during the course of the years we've heard plenty of comments like yours and they are justified:-) In the next version we are giving in and renaming the product to AjaxSwing - so you can recommend it under this name.
  23. Re: What's wrong with applets?[ Go to top ]

    As far as names go, they were given by geeks who were thinking about Java as a coffee and not the "other" connotations. But during the course of the years we've heard plenty of comments like yours and they are justified:-) In the next version we are giving in and renaming the product to AjaxSwing - so you can recommend it under this name.
    I think this is a wise choice. And I'm not offended or anything. I'm really just pointing it out because things like this can hold you back. I remember someone complaining once that they couldn't get management to consider 'bouncy castle' because the name didn't sound serious. Whether they should or not, names matter.