I've just started programming with Java, so might appear as silly question, but I was not able to find simple answer on the internet. This is "big" question which I have to answer before getting too deep into development, so you can help me to save a lot of time on trying different approaches.
I am currently creating a website using Java. Important feature of this website would be realized through separate Java thread (like daemon) which must be run in background for as long as the user is on the website. At the sametime, website applets must have means of communication with this thread.
I see three potential solutions to this:
Create traditional multipage website with stand-alone java applets in each separate page. I am not sure if it is possible, the following questions arise:
is it possible for java thread created by java applet to continue execution after user navigated to another webpage (on the same website)? I assume that yes.
is it possible for newly launched java applet to communicate with java thread already running in background? (I've seen part of documentation covering communication between java applets through JavaScript, not sure that this can be used in my case. Any other options?)
Create single-page website, with one single java applet, responsible for all navigation and rendering all pages. This solves the problem with background daemon, which becomes easy to implement and communicate with, as part of single applet, but raises one more questions:
I know that applet can modify current webpage. Is it feasible to use this feature to simulate navigation between different pages?
Create Java Webstart application, basically by taking the single java applet from p.2 and converting it into stand alone application.
I want the whole thing to have a look and feel of website, so I would prefer option 3 over option 2 and option 1 over option 2.
Thank you for any thoughts you share.
UPDATE:
Does anybody know answers specifically to the two questions under p1? If it is possible to work with java threads the way described?
Now I would most probably opt for making a Java Webstart Application. This should be the least painful way.
UPDATE 2:
I finally decided to work on single java applet, which can be easily converted to JWS application if needed. Nature of my project is that I need to make impression of working with website, that's why I am putting additional efforts to make it appear as a website. For knowledgeable people it will be obvious, that it is more like a local application.
Solution I chose has following benefits in my situation:
- easily convertable from JWS application to Java applet and back.
- no problems with running background thread and communicating with it.
- more reliable security (meaning that I don't need to use any mechanisms to pass over session ids from one applet to the other)
Contras:
- if size gets large, start up will be slow - I hope to avoid this.
- Security issues - I tried signing the applet and it helped a lot.
- Work of navigation buttons in browser (back and forth) - I hope to be able to replicated it in applet. Think applet should be able to catch this event.
Java thread [...] which must be run in background for as long as the user is on the website
If the thread being forked is to preserve state while the client is logged in then I would use a database, memory cache, or some other persistance layer to hold the client session state. This is a much more typical model. You can also have multiple frontends that share session information across the network.
If you are not talking to a browser then creating a stand-alone web application may be the best choice. You can still use HTTP as your transfer protocol in which case I'd recommend using a Java web implementation like Jetty. This would involve significantly less technology and complexity.
If you need to implement web pages, I would certainly use proper frontend models and technology. You should separate your pages into multiple applets -- or multiple controllers/views in the MVC model. Using the applets should be fine. They (or the controllers) should call a centralized service which starts, communicates with, and stops the background threads depending on the information flow.
I would also certainly have another background thread running to time out your client threads in case a client never returns. Your worker threads could just exit after a certain amount of waiting.
Hope this helps.
is it possible for java thread created by java applet to continue execution after user navigated to another webpage (on the same website)? I assume that yes.
Yes. Threads that are forked will continue to run until they terminate or (if daemon) the process terminates.
is it possible for newly launched java applet to communicate with java thread already running in background?
Sure. What they need is some mechanism to be able to share data. For example, your background thread service could keep a Map of the thread objects with the key being some sort of client-id. Whenever a thread wanted to talk to it's background thread then it could call the service to lookup the thread by id. Something like:
BackgroundStream thread = threadService.getThread(clientId);
thread.callMethod(...);
If there was some sort of synchronous question/response then you'd need to have a condition variable or something. Read up on Java threads for more information.
There's an architecture used in Website applications in Java, it's called a Model-View-Controller. Frameworks such as Java Server Faces (Standard on Java EE 5 and higher), Struts (1.x or 2.x), Spring, Apache Wicket, etc. were designed to create web applications using MVC model. The question is, would you prefer the component-based architecture of the framework (such as JSF) or not (which you shouldn't be worried about at this moment)
Applets is defnitely a bad choice as applets are downloaded to client side. Some browsers don't support Applets especially in mobile web browsers and its difficult to apply security settings to untrusted applets, plus you may not know if the client has blocked the applet or not.
Applets are a bad choice because of 2 reasons:
1) First, they are executed on client's browser and not on server. Therefore you cannot perform any backend processing(Business logic or fetching data from server database) using applets.
2) Applets are very buggy and have security issues. That's why applets are out of fashion these days.
Now coming to how you can create website using java technology, for that you need to start understand Java Server Side programming. Start learning about Java Servlets and Java Server Pages. To put it in simple terms, they are java programs which are executed on a web-server or application server.
then start reading about Java Enterprise Edition.
refer this tutorial for Java Enterprise Edition
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I currently run a website on LAMP, I am currently in the process of refactoring my code from normal php to Zend framework with Doctrine. I am happy with setup but often find function not found errors on live site cause I have renamed function. Which is frustrating as most of time is wasted is patching these errors.
So I have decided to switch from php to java as the code gets compiled, so just error will not go to live site. With java netbeans will work better.
But as I have not been in touch to j2ee for many years. What is the best replacement for my above setup in java?
Option 1. Jsf 2 with Hibernate
Option 2. Seam
Option 3. Spring
Option 4. Struts with Hibernate
My server has 24 gig ram and 2 core i7 processor and ssd drive on raid 0
Will my server handle the same amount of visitors if java was used without any performance issues?
I like the way I can update my site without losing live sessions(logged-in users). Can I do the same in Java? from my experience each update to site will redeploy the App which resets all the Active Sessions.
I love to consider .Net but from what I have read on most forums, no one recommends it?
Kind regards
Zerone
You problem is not switching to Java from PHP your problem is an good test coverage via unit and in particular with integration tests. From what you wrote the best thing might be to take a look at Selenium and to automate testing as most as possible. You need a complete infrastructure to deploy to a test system and run integration tests on it (Selenium) and after that you can say everything is ok.
Java will perform better, but switching to Java seems like overkill for this situation. That said, I would recommend something based on Spring and Hibernate. Spring can be a real godsend for configuring just about anything in Java and Hibernate is similar to Doctrine.
Apache Tapestry would make a good presentation toolkit for your site. It's a great templating library that is cleaner than JSP.
Java has a large variety of solutions to the same problem. Currently, the mainline Java solution to presenting items on the web is Java Server Faces.
Older (which doesn't always mean worse) solutions include Struts, Apache Tapestry, (parts of) Spring, etc. These solutions benefit from maturity, having an established following, etc. Basically they are good solutions because people already know the points where they fail, and already know how to work around them. The new solutions attempt to remove these pain points, and thus suffer from new pain points. Think of it as not noticing your headache until after you fix your broken arm.
Java will perform much better because the code that delivers the web pages is already in memory, so it avoids a number of items that take time (process spawning, disk access, webserver to language engine communications, etc). There are other PHP solutions which also attempt to solve similar problems using similar techniques; however, PHP has a different coding background and style. For example, Java doesn't need to discard any state between web page requests, something that PHP does (and often uses a number of libraries and workarounds to mitigate).
My recommendation is to use Java, but realize that a direct port will incur a lot of unnecessary expense. Choose a web facing toolkit (JavaServerFaces is the newest and part of the Java EE standard), and start off by porting the static portions of the HTML web pages. Organize your requests by scope (how long the side effect of the request should persist), and use the Servlet standard to store the artifacts generated by the request in the appropriate application, session, request, etc scope.
On the database side of things, there are many standards and solutions to pick from too. Personally, as you don't have a lot of legacy concerns, I would go with JPA. While it is not really a 100% complete solution, it will push you to use an interface which can be replaced by better implementations over time, without the need to recode your application. By stating it isn't 100% complete, I mean that you need to select a JPA provider as the default provider probably won't meet your real-world production needs. That said, the default provider should sustain development oriented work, and JPA's standards should protect you from unexpected differences when you run the code against different environments.
Whether you wish to fully restructure you code into a Java EE multi-tier architecture, of if you just want to embed a large Servlet (server faces is a type of servlet solution) that does everything is more of a function of how much you wish to architect your code. It is not a porting problem. That said, the biggest benefits of a typical Java solution over a typical PHP solution is that the Java architecture is designed to work faster and provide more features out-of-the-box. If you intend to do a port with no rearchitecting, you might be better off just finding out the bottlenecks in the PHP code and fixing them.
if you dont use ajax, i prefer 4 (struts + hibernate):
jsf needs an little bit of expiriences on such heavy load (getter-methods must be fast and so on).
if you use ajax, i prefer an combination of 3 and 1
regards
peter
I recently used a Java Web Start application. I launched it from my web browser using an embedded jnlp link in the page I was viewing. The application was downloaded, launched and worked just fine. It had access to my local file-system and remembered my preferences between restarting it.
What I want to know is why are Java Web Start applications not a more popular delivery format for complex applications on the web? Why do developers often spend considerable time & energy replicating desktop functionality in html/javascript when the power of a desktop application could be delivered more easily using Java & Java Web Start?
I know that in some corporate environments, e.g banking, they are relatively popular ways of delivering complex trading applications to clients, but why are they not pervasive across the web as a whole?
(For the sake of discussion let's assume a world where: download sources are "trusted" & applications are "signed" (i.e. no security concerns), download speeds are fast (load time is quick) and developers know Java (in the numbers they know html/js/php)).
I think the reason is not security nor startup time of the app. Let's understand what's behind the scene before we find out the root cause.
Java Control Panel has settings that allow users to use the default browser's proxy settings or to override them. In other words, infrastructure teams are able to customize the Windows or OS installation images to have JVM pre-installed with enterprise proxy settings. So I believe this is not an issue at all.
Java Web Start actually caches all apps with customizable settings in Java Control Panel. Once the app is cached, the app is "installed" just like other apps. Although first time execution may be slow, the second time will be fast due to JVM's smart memory allocation technique. So start up time could be an issue but a lot of web sites (even enterprise internal) are now migrated to portal. A web portal normally contains lots of unused libraries for development purposes due to the fact that the portal itself does not anticipate what kinds of portlets are built and deployed on a specific page. Therefore, downloading a single portal page could consume up to MBs and complete a page in more than 5 seconds; this is only one page and caching helps up to 30% but there are still lots of HTML/Javascript/CSS components required to download every time. With this, I am sure Java Web Start is an advantage here.
Java Web Start does not download again if it is cached as long as the server copy is NOT upgraded. Therefore, if, e.g. a project management software like MS Project, is completed using SmartClient (similar to JWS), the information exchange between the client and server would be purely data without presentation like browser's full page refresh. Even with the help of Ajax, it doesn't eliminate full page download entirely. Besides, a lot of companies consider Ajax to be immature and unsecured still. That is why Ajax is a hot topic in the circles of developers but not within enterprise software yet. With that in mind, JWS apps definitely have more advantages such as how JWS apps are deployed and executed in sandboxes, signed, and have much more interactive GUI.
Other advantages include faster development (easier to debug in code and performance), responsive user interface (does not require Comet Servers to provide PUSH functionality), and executing faster (for sure because client computers renders GUI without translation like HTML/Javascript/CSS, and less data processing).
After all these, I haven't touched the question yet, why JWS is not so famous?
My opinion is that it is the same as Brian Knoblauch's comment, it's without awareness.
IT folks are too attracted by the hype of Web Technologies, Ajax PUSH, GWT, and all those buzz words make them bias towards the fun of using different technologies or to resolve technical challenges instead of what's really working for the clients.
Take a look at Citrix. I think Citrix is actually a great idea. Citrix allows you to build your own app farms behind the scene. There are tons of upgrade and implementation strategies you can go for without impact to client experience. Citrix deployment is extremely easy, stable and secure. Enterprises are still using it. However, I think JWS is even better than Citrix. The idea of JWS is to run apps on client machines instead of hosting tons of server farms where client machines are capable of running these apps themselves. This saves a company a lot of money!!! With JWS, development team can still build business logic and data on server side. However, without the web processing unit and let the client computers do the rendering process, it greatly reduces the amount of network consumption and server processing power.
Another example of why JWS is an amazing idea is Blackberry MDS. Blackberry apps are actually Java apps translated from Javascript. With BB's MDS studio, you use the GUI tool to build BB app GUI, coding GUI logic in Javascript. Then apps are then translated and deployed on a BES server. Then the BES server will distribute these apps to BB. On each BB, it runs a thin Java App with GUI rendering and networking capability only. Whenever the app requires data, it communicates with the BES through web services to consume services from other servers. Isn't this just JWS BB version? It's been extremely successful.
Finally I think JWS is not popular because of how Sun advertises it. BB never advertises how good their BB Java apps are, they believe clients won't even care what is it. BB advertises the benefits of using MDS to develop apps: Fast, Cost Saving, Business Return.
Just my, a bit long, 2 cents... :)
A major roadblock for Java Webstart is probably that you still need to have a JVM installed before it can even attempt to download and start your application. Everyone has a browser. Not everyone has a JVM.
Edit:
I've since acquired some hands-on webstart experience and can now add these two points:
The Deployment Toolkit script and the modularized JVM released somewhere around Java 1.6u10 make the JVM requirement less problematic since it can automatically download a JVM and the API core and start the program wile downloading the rest.
Web Start is seriously buggy. Even among the Java 1.6 releases there was one which downloaded the entire app every time, and another which downloaded it and then failed with an obscure error message. All in all, I cannot really recommend relying on such a fragile system.
I think it's mostly due to a lack of awareness. It works very well. Quite seamless. App only downloads if it's the first time, there's been an upgrade, or if the end-user has cleared the cache. Great way to deploy full-blown desktop apps that user won't have to worry about manually upgrading!
The problem with Webstart is, that you actually have to 'start' something which isn't at all that fast even with a fast connection, while with a webapp you enter the URL and the app is there.
Also a lot of things can go wrong with webstart. Maybe the intended user doesn't have the privileges needed, or the proxy of webstart is configured wrong, or something went wrong with jre dependencies or there is simply no java installed in the first place. So for the average john doe in the internet it is not at all pleasent.
In controlled environments like a company it is a good and easy solution in many cases.
I've worked on a JWS-deployed application for a few years over a user base of a few thousands and its automatic upgrades are actually a huge pain.
On every update for some reason dozens of users get "stuck in the middle". All you get is the "class not found" exception (if you're lucky), or uninformative "unable to launch" from JWS before it even gets to your code. Looks like the update is half-downloaded. Or, in other words, it does not download and apply the update atomically AND has poor caching so that relaunching the app from the same URL does not fix anything.
There's no way to resolve it other than clearing JWS cache or providing a different URL (e.g. append ?dummyparam=jwssucks at the end). Even I as a developer hit it sometimes and don't see a way around.
When it works, it works. But too often it doesn't, and then it's a huge pain for you and your helpdesk. I would not recommend it for enterprise or mission-critical use.
There is a very big issue namely that it doesn't allow for "start the program instantly and THEN check for and download any updates in the background" deployments, which is what the defacto behaviour of applications are converging to.
I consider this personally so big an annoyance that we are actively looking for another technology which provides that.
From these posts it looks like when using Web start, it is important to make a good care about the server. The "huge pain" of downloading application on every startup may be caused by incorrect time stamp delivered from the server. Here not the application but the server must be configured to use caching properly and not just to disable it. About buggy start, I am not that much sure, but it seems to me that this also may be caused by unreliable connection.
Important advantage of Web start is that it works nicely with OpenJDK under Linux. Clients of some happy developers use Windows only but my clients do not.
HTML and JavaScript, mentioned in the initial question, are lighter approaches that work fine with smaller tasks like animated buttons or even interactive tables. Java niche seems around much more complex tasks.
Java Web Start is kind a successor of Java Applets, and applets got burned around the new millenium.
But, I still think Java Applets are way better than GWT or Javascript hell.
Java Web Start vs Embedded Java Applet
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm at the beginning/middle of a project that we chose to implement using GWT. Has anyone encountered any major pitfalls in using GWT (and GWT-EXT) that were unable to be overcome? How about from a performance perspective?
A couple things that we've seen/heard already include:
Google not being able to index content
CSS and styling in general seems to be a bit flaky
Looking for any additional feedback on these items as well. Thanks!
I'll start by saying that I'm a massive GWT fan, but yes there are many pitfalls, but most if not all we were able to overcome:
Problem: Long compile times, as your project grows so does the amount of time it takes to compile it. I've heard of reports of 20 minute compiles, but mine are on average about 1 minute.
Solution: Split your code into separate modules, and tell ant to only build it when it's changed. Also while developing, you can massively speed up compile times by only building for one browser. You can do this by putting this into your .gwt.xml file:
<set-property name="user.agent" value="gecko1_8" />
Where gecko1_8 is Firefox 2+, ie6 is IE, etc.
Problem: Hosted mode is very slow (on OS X at least) and does not come close to matching the 'live' changes you get when you edit things like JSPs or Rails pages and hit refresh in your browser.
Solution: You can give the hosted mode more memory (I generally got for 512M) but it's still slow, I've found once you get good enough with GWT you stop using this. You make a large chunk of changes, then compile for just one browser (generally 20s worth of compile) and then just hit refresh in your browser.
Update: With GWT 2.0+ this is no longer an issue, because you use the new 'Development Mode'. It basically means you can run code directly in your browser of choice, so no loss of speed, plus you can firebug/inspect it, etc.
http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM
Problem: GWT code is java, and has a different mentality to laying out a HTML page, which makes taking a HTML design and turning it into GWT harder
Solution: Again you get used to this, but unfortunately converting a HTML design to a GWT design is always going to be slower than doing something like converting a HTML design to a JSP page.
Problem: GWT takes a bit of getting your head around, and is not yet mainstream. Meaning that most developers that join your team or maintain your code will have to learn it from scratch
Solution: It remains to be seen if GWT will take off, but if you're a company in control of who you hire, then you can always choose people that either know GWT or want to learn it.
Problem: GWT is a sledgehammer compared to something like jquery or just plain javascript. It takes a lot more setup to get it happening than just including a JS file.
Solution: Use libraries like jquery for smaller, simple tasks that are suited to those. Use GWT when you want to build something truly complex in AJAX, or where you need to pass your data back and forth via the RPC mechanism.
Problem: Sometimes in order to populate your GWT page, you need to make a server call when the page first loads. It can be annoying for the user to sit there and watch a loading symbol while you fetch the data you need.
Solution: In the case of a JSP page, your page was already rendered by the server before becoming HTML, so you can actually make all your GWT calls then, and pre-load them onto the page, for an instant load. See here for details:
Speed up Page Loading by pre-serializing your GWT calls
I've never had any problems CSS styling my widgets, out of the box, custom or otherwise, so I don't know what you mean by that being a pitfall?
As for performance, I've always found that once compiled GWT code is fast, and AJAX calls are nearly always smaller than doing a whole page refresh, but that's not really unique to GWT, though the native RPC packets that you get if you use a JAVA back end are pretty compact.
We have been working with gwt for almost 2 years. We have learned a lot of lessons. Here is what we think:
Dont use third party widget libraries especially gwt-ext. It will kill your debugging, development and runtime performance. If you have questions about how this happens, contact me directly.
Use gwt to only fill in the dynamic parts of your apps. So if you have some complex user interactions with lots of fields. However, don't use the panels that come with it. Take your existing stock designer supplied pages. Carve out the areas that will contain the controls for your app. Attach these controls to the page within onModuleLoad(). This way you can use the standard pages from your designer and also do all the styling outside the gwt.
Don't build the entire app as one standard page that then dynamically builds all the pieces. If you do what I suggest in item 2, this won't happen anyway. If you build everything dynamically you will kill performance and consume huge amounts of memory for medium to large apps. Also, if you do what I am suggesting, the back button will work great, so will search engine indexing etc.
The other commenters also had some good suggestions. The rule of thumb i use is to create pages like you were doing a standard web page. Then carve out the pieces that need to be dynamic. Replace them with elements that have id's and then use RootPanel.get( id ).add( widget ) to fill those areas in.
Pitfalls that we've run into:
While you can get a lot of mileage from using something like GWT EXT, any time you use this sort of thin veneer on top of a JavaScript library, you lose the ability to debug. More than once I've bashed my head on the desk because I cannot inspect (inside my IntelliJ debugger) what's happening in the GWT EXT table class... All you can see is that it's a JavaScriptObject. This makes it quite difficult to figure out what's gone wrong...
Not having someone on your team who knows CSS. From my experience, it didn't matter that the person wasn't expert...it's enough that he has some good working knowledge, and knows the right terms to google when necessary.
Debugging across browsers. Keep an eye on Out of Process Hosted Mode[1][2][3], hopefully coming in GWT 1.6... For now, you just have to get things good with hosted mode, then use the "Compile/Browse" button, where you can play with other browsers. For me, working on Windows, this means I can view my work in FireFox, and use FireBug to help tweak and make things better.
IE6. It's amazing how different IE 6 will render things. I've taken the approach of applying a style to the outermost "viewport" according to the browser so that I can have CSS rules like:
.my-style { /* stuff that works most everywhere */ }
.msie6 .my-style { /* "override" so that styles work on IE 6 */ }
Finally, make sure you use an editor that helps you. I use IntelliJ -- it's got lots of GWT smarts. E.g., If I try to use a class that isn't handled by the JRE emulation, it lets me know; if I specify a style for a widget, and I haven't defined that style yet, the code gets the little red squiggly... Or, when looking at the CSS, it will tell me when I've specified conflicting attributes in a single rule. (I haven't tried it yet, but I understand that version 8 has even better GWT support, like keeping the "local" and "async" RPC interfaces and implementations in sync.)
GWT 2.0, which is supposed to come out sometime in the next few months, solves a lot of the issues discussed.
Create layouts using an html/xml like syntax
Dynamic Script Loading - only the essential JS will be downloaded initially. The rest will be downloaded as needed
In-Browser Hosted Mode - This might take care of the hosted mode speed issues discussed, among other benefits
"Compiler Optimizations" - Faster compilation, hopefully
GWT 2.0 Preview Video at Google I/O
Not "unable to be overcome" but a bit of a pain for something basic.
Date handling:
GWT uses the deprecated java.util.Date which can lead to unexpected behaviour when dealing with dates on the client side. java.util.Calendar is not supported by GWT. More info here.
Related problem examples:
GWT java.util.Date serialization bug
Get Date details (day, month, year) in GWT
Client side time zone support in GWT
I'll add some points to the ones already mentioned:
Databinding/validation. GWT doesn't have a databinding/validation support out of the box, although there are some projects on this area starting to emerge. You'll find yourself writing alot of this:
TextField fname, faddress;
...
fname.setText(person.getName());
faddress.setText(person.getAddress());
...
Lazy loading. Since gwt is on the client side, lazy loading is really not an option. You'll have to design your RPCs and Domain Objects carefully in order to
send all your object data that is needed
avoid eager fetching all of your data
You'll have also to make sure that you will not send proxies/non serializable objects. hibernate4gwt can help you with these points.
UI design. It is harder to visualize an UI in java (Panels, Buttons, etc) than in html.
History support. GWT does not ship with a History subsystem, nor does it ship with any subsystem for nice urls or statefull bookmarking. You'll have to roll your own (although it has support for History tokens, which is a start). This happens with all AJAX toolkits AFAIK.
IMHO, GWT is missing a framework that has out of the box support for all of the issues mentioned on this 'thread'.
I'm working on a project right now that uses EXT GWT (GXT) not to be confused with GWT EXT. There is a difference, EXT GWT is the one that is actually produced by the company that wrote ExtJS the javascript library. GWT EXT is a GWT wrapper around the ExtJS library. GXT is native GWT.
Anyways, GXT is still somewhat immature and lacks a solid community that I feel GWT EXT has. However, the future is with GXT, as it's native GWT and actually developed by the company that made ExtJS. GWT EXT is somewhat crippled as the license changed on the ExtJS library, thus slowing the development of GWT EXT.
Overall, I think GWT/GXT is a good solution for developing a web application. I actually quite like hosted mode for development, it makes things quick and easy. You also get the benefit of being able to debug your code as well. Unit testings with JUnit is pretty solid as well. I haven't yet seen a great JavaScript unit testing framework that I felt was mature enough for testing an enterprise application.
For more information on GWT EXT:
http://gwt-ext.com/
For more information on EXT GWT (GXT):
http://extjs.com/products/gxt/
No major pitfalls that I haven't been able to overcome easily. Use hosted mode heavily.
As you are using GWT-ext you will almost never need to touch CSS yourself unless you want to tweak the out of the box look.
My recommendation is to use a GWT "native" widget over a library one where they are close in features.
Re search engine indexing: yes the site will not have navigable URLs normally (unless you are only adding widgets to elements of a regular web site). You can do history back/forward functionality though.
I used GWT and GWT-ext together on a project a while ago. I found the experience quite smooth as web development goes, but my advice would be this:
Don't mix GWT native widgets with EXT widgets. It's confusing as hell, since usually the names are the same (GWT.Button or GWText.Button?)
One thing that happened to me that really made the code more complex than I'd like, was that I wanted a Panel that was
a) dynamically updatable
b) cascadable
GWT native panels are dynamic, Ext panels are cascadable. Solution? A GWT.VerticalPanel wrapping a GWTExt Panel... Chaos. :)
But hey, it works. ;)
I second the comment from ykagano, the biggest disadvantage is losing the V in MVC. Although you can separate the true ui class from the rest of your client side code, you cannot easily use an HTML page generated by a graphic/web designer. This means you need a developer to translate HTML into java.
Get a wysiwyg ui editor, it will save you lots of time. I use GWTDesigner.
The biggest upside of GWT is being able to forget about cross browser issues. Its not 100% but takes almost all that pain away. Combined with the benefit of hosted mode debugging (as opposed to Firebug which is excellent but not the same as a java debugger) it gives the developer a huge advantage in generating complex ajax apps.
Oh and its fast at runtime, especially if you use a gzip filter.
Slightly off-topic, but the #gwt channel on irc is very helpful, in-case you have a persistent problem.
GWT is pretty straight-forward and intuitive.
Especially with the release of UIBinder to allow GWT widgets to be laid out in XML and then coded-behind in Java.
So if you have used other Ajax or Flash design tools, or Silverlight, etc, GWT is very easy to learn.
The major hurdle, if not pitfall, is GWT RPC. The very reason you wish to use GWT is because of GWT async RPC. Otherwise, why not just rely on css to format your page?
GWT RPC is that element that allows your server to refresh data on your server without having to refresh the page. This is an absolute requirement for pages such as stock performance monitoring (or the current national and public debt of the US or the number of unborn babies aborted worldwide by the second).
GWT RPC takes some effort to understand but given a few hours, it should come all clear.
Above that, after putting in some effort to learn GWT RPC, you finally discover that you cannot use JSPs as the service component for RPC, unless ... I have an 8 part (I think) series on my blog on how to use JSP as the GWT RPC servicer. However, since you had not asked for answers but just issues, I shall desist from advertising my blog.
So. I very much believe that the worst roadblocks/pitfalls to using GWT is finding out how to properly deploy GWT async RPC and how to enable it to use JSP servicers.
We've had a very hard time marrying our GWT codebase with HTML web templates that we got from a web designer (static HTML pages with specific div ids that we wanted GWT to manage). At least back when we used it, we couldn't get GWT to integrate with parts of our website that were not coded in GWT. We had it working eventually, but it was a big hack.
The Async interface you have to write for each service interface looks like something that could have been automatically generated by the GWT compiler.
Compile times become long for large projects
But for a large Javascript project it's the best choice
GWT 2.4 has fixed many of the aforementioned issues and a great widget library is just coming out of Beta (Ext GWT 3.0.4 a.k.a. GXT), which is written completely in GWT, not a wrapper of a JS lib.
Remaining pain:
Lack of CSS3 selector support, you can use "literal()" in some cases to get around it.
Lack of support for CSS3 and modern browser events like transitionEnd.
Lack of Java Calendar class support (many years later).
Lack of JUnit4 support (5 years and counting).
Lack of clear road map and release schedule from Google GWT team.
Regarding GWT 2.4, Use Firefox when debugging GWT, it alot more faster then using chrome.
And if you'll using only firefox, consider putting this line in your project.gwt.xml file
<set-property name="user.agent" value="gecko1_8" />
Also, If you're using eclipse, then add the following under arguments -> VM arguments:
-Xmx512m -XX:MaxPermSize=1024m -XX:PermSize=1024m
You can divide your server and client, and use the following under arguments -> Program arguments:
-codeServerPort 9997 -startupUrl http://yourserver/project -noserver
Also, to prevent refreshing your server on each change, use JRebel
http://zeroturnaround.com/blog/how-to-rock-out-with-jrebel-and-google-web-toolkit-gwt/
And here's a live demo
http://www.youtube.com/watch?feature=player_embedded&v=4JGGFCzspaY
One major pitfall is that sometimes you need to explicitly assign an id to what ultimately becomes an HTML element to be able to use certain CSS styles. For instance: a GWT TabPanel will only do :hover over tabBarItems when the tabBar of the tabPanel has been assigned an id and you specify a :hover on that elementId.
I wrote about some other disadvantages of GWT elsewhere, but they are already covered by rustyshelfs answer :).
I have done a lot of work on GWT recently, and this is wht i have to say:
CSS styling is tricky only sometimes, use IE developer tool in IE and firebug in Firefox to figure out what exactly is happening and you will get a clear idea of what css needs to be changed
You can use tricks to get google to index it. A very famous site is http://examples.roughian.com/ check its ratings at google. A far less famous site is www.salvin.in (couldnt resist to mention that), i optimised it to words: salvin home page (search google for these three words)
I do not know much about GWT-EXT, But i too am of the belief that there is no need to include Third party libraries.
Best of luck on your decision :)
GWT does Browser Sniffing instead of Feature Detection and your application will not work on some browsers (specially new ones)
Here are some references of the problem:
google-web-toolkit Issue 2938: RFE: improve the user.agent property-provider to cope for userAgent string "masking"
Iceweasel no longer supported? - Google Docs Help
GWT implementations for every browser
Here are some references to Feature Detection:
Browser Detecting (and what to do Instead)
Feature Detection: State of the Art Browser Scripting
Browser Feature Detection
Extracted from Comparison of JavaScript frameworks - Wikipedia
The GWT team make a lot of great improvements in to last year releasing GWT 2.7. One major weakness of GWT was that compilation takes to much time in GWT 2.6 and below. This is now gone GWT has not incremental compile which is super fast and compiles only the changes.
GWT 2.7 now has (Source):
Incremental builds now just seconds
More compact, more accurate SourceMaps
GSS support
JSInterop
Great JavaScript Performance
Smaller Code Size
The best way to get reliable facts are from the gwt survey. One of the biggest issues with GWT has always been a long compile time. Fortunately, it's improving very quickly so it won't be a significant issue in the near future. Another pitfall is that GWT is dramatically more complicated because Java is a more complicated language that resists bad coders every step of the way. In addition, compiling adds a layer. For example, js interop requires a little boilerplate. The fundamental issue is that GWT wasn't designed to be simple. It was designed from the ground up for extremely complicated web apps and the entire community consistently prioritizes, performance, code quality, architecture etcetera over easy coding.
Remember that you can use js in GWT at any point so if you are struggling with GWT consider using js. At the end of the day GWT is js so you can do anything in GWT that you can in js. In fact, most GWT projects use js. The problem is that GWT is drastically more complicated. Nevertheless, it's sometimes worth the extra complexity.
It's worth noting that GWT 3.0 will bring massive improvements.
Re-using RPC service objects.
It causes race conditions with symptoms that look like the app hanging.
Pitfalls I ran into
1. Different behaviour in superdev mode. E.g. Someclass.class.getName() works absolutely fine in Superdev mode and returns the fully qualified name of the class. In productive mode this does not work.
addWidget(widget) will call widget's removefromparent()
GWT is a technology masterpiece. It unites client and server programming making it one coherent application - the way software was written before "layering", and the way it should be written. It eliminates different skills sets, miscommunication between team members, and generally the whole Web Design phase: both the artistic and programming. And it is the closest you'd get to mobile e.g. Android development. In fact GWT was designed to generate different native UIs, not just HTML. Though it requires enormous discipline to ensure such decoupling - to keep your inner layers presentation-agnostic.
The first mistake you should avoid, which took me four years to realize, is using third-party extensions like EXT-GWT aka GXT and SmartGWT. It is very tempting to start using their pretty desktopish widgets instead of investing in your own styling, but I cannot tell how many problems I had with SmartGWT until I finally got fed up. In short it freezes the core GWT feature set at the certain (pretty outdated) level and then builds on top of it. Also keep in mind, that chiseled desktop look and feel looks silly nowadays, not to mention the sluggish performance, tons of bugs, and compatibility features - especially on mobile devices. You want to stay as close to the native browser controls, as possible i.e. dropdowns rendered as native <select> elements, not some custom-painted controls.
Thanks to mobile trends the whole UX is becoming simpler and flatter, so you don't need to do much to style a sharp-looking application. Though if you want "3D" look, there are also gradients. CSS3 made everything easy, and GWT wraps it an elegant object-oriented manner unlike the raw CSS. So don't be discouraged by looking at rather ugly barebones controls in the GWT Showcase. The GWT team intentionally didn't offer any styling, because it it the developer's job.
The rest is pretty much conventional browser programming in strongly typed Java with beautiful concise APIs. But of course never forgetting your code runs inside the browser, so all of the calls are asynchronous e.g. you cannot call GWT-RPC methods in a loop (to populate some list), but need to recursively chain them if you ever come to to this situation.
There are some self-proclaimed "anti-patterns" like don't use GWT-RPC. It's been good to me so far: for 10 years. Simplicity is key. I wouldn't think even a second to sacrifice some marginal performance for code elegance and maintainability. besides this is not where your bottlenecks would be - in the database. Of course mind how much data you are sending to the client.
And if you cannot find or style the existing gadget - read rich HTML5 element set, you can always wrap a third-party one. I did it with a popular jQuery FullCalendar. Not rocket science at all. Everything else like Google Maps and Google Charts has semi-official GWT wrappers.
GWT is perfect. The only reason it doesn't get enough love is because early Internet adopters who still influence the industry didn't come from Computer Science and object-oriented languages to appreciate them. They have either artistic (Photoshop/WordPress) or network (Perl/Python) background.