I am building an Eclipse RCP application that will eventually have section for NASA Worldwind AWT component. I will be using the SWT_AWT bridge to get the worldwind component embedded in an RCP application. I am trying to decide whether I should write other components using SWT, or use Swing all the way and embed everything using SWT_AWT bridge. The latter would allow me to use Swing, but not sure what the performance implications are?
If you are going to write an RCP application then it is best to stick to the native concepts and use SWT.
When you are going to write everything in Swing then there will be a performance penalty. How much, as always, depends on the hardware you are using. With todays hardware, assuming NASA has the funds, it would not be all that relevant.
What would be more relevant is the difference in UI. SWT renders with native widgets, Swing does not.
A good read is this article on the Swing in RCP [1]
[1] http://www.eclipse.org/articles/Article-Swing-SWT-Integration/
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
My company is planning on developing a brand new web front-end application.
Some background:
It must "sizzle" i.e. a nice marketable look and feel.
Our development team has no Java experience, with limited experience in Silverlight, Javascript, JQuery or CSS.
Time to market is a factor.
We need to stream large amounts of data from an Oracle database.
It must support 500 - 1000 concurrent users
It will be hosted internally behind a firewall.
We need mapping (geo-spatial) capabilities.
Someone has recommended using GWT instead of Silverlight or Traditional technologies(Javascript, jquery, CSS etc.).
I am not sure if this is the right way to go? A lot of the GWT news is from 2007/2008. It makes me think that this technology is old and maybe dying.
If you had a choice would you choose GWT?
unfortunately two of your statements are mutually exclusive in this context:
Our development team has no Java experience
Time to market is a factor
I'm a Java programmer who has picked up GWT over the last year or so. It's immensely effective being able to write direct to the browser using a compiled language & mature development tools. I can fly through web-development faster than ever before (using ASP, JSP, ExtJS ...).
But, as the other commenters have said: if you've no Java experience you're going to find it a real challenge picking up both technologies (Java & GWT) in a short time. If you do manage to make it to market in a reasonable time I could only imagine the code base would be in very poor condition (since you'd be learning as you go) - which would be a very poor foundation for your organisation's shiny new venture.
There again, you don't have a 'lot' of skills in the other related skills you listed either.
I suspect there's a more effective solution. As some wise old goat project manager said:
I have three variables to delivering your project: time, cost and quality. Pick any two
In your situation, if the organisation wants a quality product in a short time, it's the cost factor that must compensate - your organisation should buy in some interim GWT expertise to give you a sound software architecture and to mentor your team for the next few months. After that you'll be ready to take the reigns, inheriting a quality codebase by 'standing on the shoulders of giants'.
As others have said, GWT definitely is not a dying project. Quite the contrary actually as there are now more than 20 regular contributors from within Google (versus a semi-dozen back in 2008). Wave (despite being discontinued as a Google service, it's still alive as an Apache Foundation project), Orkut, AdWords, Google Moderator and the new (still beta) Google Groups are made with GWT; and parts of Google Buzz and a few other projects at Google are built with it too.
Now as to your choice:
Silverlight is a dying technology. Microsoft made it clear that it now invests in "HTML5": http://www.zdnet.com/blog/microsoft/microsoft-our-strategy-with-silverlight-has-shifted/7834
GWT is mostly a client-side toolkit, but it comes with "high productivity" tools for client-server communications (GWT-RPC and RequestFactory for end-to-end protocols, AutoBeans for easy JSON serialization). With UiBinder, you can easily put to use your web designer skills.
if you're comfortable with JS, then go for it, but then you'd have to choose the "right toolkit" (jQuery? Google Closure?). Otherwise (which seems to be the case), it really depends how much "ajaxy" you need/want to be. I'm a strong believer in "one-page apps", but YMMV, or you can have specific constraints that rule it out. In any case, you'd have to choose a server-side technology.
So, depending on your needs/wants and skills, I'd choose GWT or "some JS toolkit". In any case, you'll have full control over the look and feel (unless you choose one of the bloated players: ExtJS/ExtGWT, SmartGWT or similar; you'll probably have a shorter time-to-market with these, but you'll pay it later, in terms of performance, integration with other toolkits, and look-and-feel).
In the light of what you're saying about your skills, I would definitely recommend GWT (despite your lack of experience with Java); because lack of experience with JavaScript is far worse than lack of experience with Java (you're talking about a "large application", so it's really important to start building things right and/or have tools to help refactoring, which you'll have with Java).
#ianmayo replied while I was writing the above, and I can only second what he said!
GWT is definitely not old or dying! A lot of Google's own applications are developed using GWT. You can download the GBST case study and learn how the global financial company uses GWT to improve productivity and create a rich user experience. You have to know that when you use GWT you automatically use javascript, html, etc. You create a your gwt application in java, but when you compile it gwt creates a folder with html files, javascript code, css, etc...
I definitely recommend it!
In order not to mislead readers with above seemingly unanimous answers, keep objective view in respected stackoverflow, following review expressed exact experiences I had with using GWT. Whether GWT is dying depends on how many new apps will adopt it,Google trend can tell (gwt trend).
Excerpt from https://softwareengineering.stackexchange.com/questions/38441/when-not-to-use-google-web-toolkit
>
I am both good and bad to answer this question - good, in that I've actually used it before, and bad, in that I was quite experienced with HTML/CSS/JavaScript prior to working with GWT. This left me maddened by using GWT in a way that other Java developers who don't really know DHTML may not have been.
GWT does what it says - it abstracts JavaScript and to some degree HTML into Java. To many developers, this sounds brilliant. However, we know, as Jeff Atwood puts it, all abstractions are failed abstractions (worth a read if considering GWT). With GWT, this specifically introduces the following problems:
Using HTML in GWT sucks.
As I said it, to some degree, even abstracts away HTML. It sounds good to a Java developer. But it's not. HTML is a document markup format. If you wanted to create Java objects to define a document, you would not use document markup elements. It is maddeningly verbose. It is also not controlled enough. In HTML there is essentially one way to write
<p>Hello how are <b>you</b>?</p>
In GWT, you have 3 child nodes (text, B, text) attached to a P node. You can either create the P first, or create the child nodes first. One of the child nodes might be the return result of a function. After a few months of development with many developers, trying to decipher what your HTML document looks like by tracing your GWT code is a headache-inducing process.
In the end, the team decided that maybe using HTMLPanel for all HTML was the right way to go. Now, you've lost many of GWT's advantages of having elements readily available to Java code to bind easily for data.
Using CSS in GWT sucks.
By attachment to HTML abstraction, this means that the way you have to use CSS is also different. It might have improved since I last used GWT (about 9 months ago), but at the time, CSS support was a mess. Because of the way GWT makes you create HTML, you often have levels of nodes that you didn't know were injected (any CSS dev knows how this can dramatically affect rendering). There were too many ways to embed or link CSS, resulting in a confusing mess of namespaces. On top of that you had the sprite support, which again sounds nice, but actually mutated your CSS and we had problems with it writing properties which we then had to explicitly overwrite later, or in some cases, thwarted our attempts to match our hand-coded CSS and having to just redesign it in ways that GWT didn't screw it up.
Union of problems, intersection of benefits
Any languages is going to have it's own set of problems and benefits. Whether you use it is a weighted formula based on those. When you have an abstraction, what you get is a union of all the problems, and an intersection of the benefits. JavaScript has it's problems, and is commonly derided among server-side engineers, but it also has quite a few features that are helpful for rapid web development. Think closures, syntax shorthand, ad-hoc objects, all of the stuff done by Jquery (like DOM querying by CSS selector). Now forget about using it in GWT!
Separation of concerns
We all know that as the size of a project grows, having good separation of concerns is critical. One of the most important is the separation between display and processing. GWT made this really hard. Probably not impossible, but the team I was on never came up with a good solution, and even when we thought we had, we always had one leaking into the other.
Desktop != Web
As #Berin Loritsch posted in the comments, the model or mindset GWT is built for is living applications, where a program has a living display tightly coupled with a processing engine. This sounds good because that's what so many feel the web is lacking. But there are two problems: A) The web is built on HTTP and this is inherently different. As I mentioned above, the technologies built on HTTP - HTML, CSS, even resource-loading and caching (images, etc.), have been built for that platform. B) Java developers who have been working on the web do not easily switch to this desktop-application mindset. Architecture in this world is an entirely different discipline. Flex developers would probably be more suited to GWT than Java web developers.
In conclusion...
GWT is capable of producing quick-and-dirty AJAX applications quite easily using just Java. If quick-and-dirty doesn't sound like what you want, don't use it. The company I was working for was a company that cared a lot about the end product, and it's sense of polish, both visual and interactive, to the user. For us front-end developers, this meant that we needed to control HTML, CSS, and JavaScript in ways that made using GWT like trying to play the piano with boxing gloves on
First of all , GWT is not dying technology, its usage increases, and its latest version is 2.2. I am using GWT for 2 years, since version 1.6. Its improvements since them is quite amazing.
Since GWT is client side technology, it does have only positive effects of your application scaliblity feature. Because server side web technologies such as jsf, struts, wicket are server resource consumers, but gwt does not need any server resource to render user interface..
But there is problem for your team. Because your team has no java experience, it would be quite difficult to adapt yourself two new technologies java and gwt.. If you have time to learn , I would strongly suggest GWT.
It takes approx 1 year to become proficient in GWT. Using GWT pays off if you develop an application as sophisticated as MicrosoftOffice or PhotoShop. It makes no sense to use GWT for small and relatively simple apps, IMHO. GWT is a time killing framework indeed, and you have to have very strong reasons to use it. I think that 99% of web apps don't need GWT.
GWT is not dying framework, but time killing framework. It has security issue. You can do easily CSRF(Cross site request forgery) request to the GWT applications. Also Java and Javascript are totally different languages, you can't translate easily. For your productivity avoid GWT.
I would like to start a new project which will make extensive use of plugins. I know that both Eclipse and Netbeans have their respective Rich Client Platforms, both with their respective strengths and weaknesses.
I would like some comments on which the Stack Overflow community prefers.
Also, and most importantly, how easy it is with the respective platforms to write plugins for already existing applications. For example, if I finish my application, and would like to enable 3rd parties to extend it with their own plugins, how does each of these platforms provide functionality for this? Would they need my source to do it, or do these platforms provide plugin APIs towards which 3rd parties can code?
I would like some comments on which the Stack Overflow community prefers.
I lean my preference to Eclipse RCP, mostly because I still think that the IDE itself is the best right now. Eclipse RCP is also more mature, and has more books and documentations on the web. Netbeans RCP is slightly behind with only three books I can find on Amazon.com regarding the platform.
I'm also very eager to see the platform growing with its e4 projects which will simplify a lot of things (from dependency injection to UI customization)
Also, and most importantly, how easy it is with the respective platforms to write plugins for already existing applications. For example, if I finish my application, and would like to enable 3rd parties to extend it with their own plugins, how does each of these platforms provide functionality for this? Would they need my source to do it, or do these platforms provide plugin APIs towards which 3rd parties can code?
I can imagine that the answer for this question will not really be satisfying while both platform are designed to be extensible. They are pretty equals in this department.
The most important thing is to design your application to also be extensible. That is, providing extension points. You don't have to provide source code for that but you can document the extension points. Also, in case you need to provide interfaces, you can just provide the javadoc without the real source.
I repeat my point, designing application using RCP doesn't mean your application will automatically be extensible. You have to also design your application to be so. This won't come easily as you learn the platform for the first time but you will eventually learn about it from experience.
(Note: I'm not speaking for the community here ;) )
The two major differences between Netbeans and Eclipse RCP are:
OSGi (Netbeans 6.9 is only beginning to support it): it is designed to support extensions
Swing vs. SWT (can you app benefit from the native look supported by SWT)
Another factor, as you can read in this blog post is RAP (Rich Ajax Platform), which could help deploy your app on many platform based on one source code. But that may not concern you.
The maven integration is quite good from both side (see the Netbeans-RCP-Maven Hello World article), but the Maven3-Tycho integration is primarily developed on Eclipse.
Again, you might not need those new maven features (or you could use other build management system entirely, like Ivy or Graddle)
Consider if your plugins does really need such complex architecture as eclipse RCP or NetBeans provide. Plugins for RCP or NetBeans can be only created by Java Developers with strong RCP/NetBeans experience. Be aware that you can do (very easy) RCP application that is not pluggable at all. In some cases is better to write your own, maybe less flexible but more friendly way to attach new plugins. You can even do some wizards for them.
I'm a largely self-taught front-end developer only just making the transition into back-end development in order to be able to say yes to more projects.
I've found eclipse to be my favourite text editor for javascript and php, but I'm conscious that it (and other IDEs) have a whole load of features which I don't know how to use, or why I should want to use them.
I'd really appreciate some pointers on why using such-and-such a feature of an IDE helps you work more efficiently, write better code etc..., and maybe some links to useful sources of information.
Cheers
edit - I'm already converted to using ftp features and code explorer/function lists
You may find eclipse tips such as these interesting. But if your objective is to "write better code" then I think you need to look elsewhere. Understand the language you are using better, understand design patterns and the reasons whey people apply them, study testing techniques. There's so much else to spend your time on. Truly working smarter is the objective.
I would always advise learning what goes on behind the IDE and then using the IDE.
Get familiar with:
Build/Distribution processes (Like Make and others)
How compilation works, what are the component processes
How the IDE is generating things like autocomplete (scanning headers/source)
version control, get familiar with it on the command-line. It will mean you can deal with issues/requirements not filled by the IDE.
Once you know what goes on behind the scenes for the language/environment you are programming in ... the IDE is a bit mundane, just a modular text-editor on steroids.
Good luck
Maybe this is obvious, but in my opinion class/function/variable name refactoring is among the most essential features of any IDE. Constant refactoring is one of the secrets of making good code.
That's a bit of a difficult question to answer since most modern IDEs offer such a wide range of features. From a general standpoint, I'd become familiar with hot key combinations for repetitive tasks (saving, building, code folding, etc.) and how to install/enable/disable add-ons and plug-ins. That will make you more efficient.
As Aiden mentions, knowing how to to a build from the command line/compilation in general will be useful as well as version control systems. Get familiar with GIT and Subversion.
The IDE will not make you write better code. For that, you're going to need practice and some time spent reading/listening to podcasts. Read Robert Martin's "Clean Code" for starters.
Additionally, spend the time to learn proper TDD and the toolset(s) available for your IDE.
I am about to start on a college project (a web application) and I have never used a full-fledged IDE such as Eclipse.
Turbo C/C++, Visual Basic 6,Java Basic, a bit of SQL, ASP, etc is the sort of exposure I have.
What things should I keep in mind before starting my project using Eclipse? Are the tools mentioned appropriate for the project?(If not please give a detailed answer)
Designing - UML (Rational Rose)
Language - Google Web Toolkit
Server - Google App Engine
IDE - Eclipse
Version Control - Subversion or Mercurial?
I would definitely recommend Googling first. There are a number of tutorials regarding Eclipse as it is a very popular IDE. A quick Google search of my own brought up all these results: developing web applications in eclipse
As for other things to consider, if you are developing a web application, you'll need:
web server (Tomcat is a popular one)
possibly a database (MySQL is an open source, easy to use DB)
language (I'm assuming you're going with Java since you are using Eclipse)
Of course, you'll also need to consider how you hook everything together and what technologies you want to use to do that. (Hibernate, Spring, etc) Eclipse itself has a ton of plugins to help bring together all these various aspects.
That list from Wikipedia is a good and comprehensive list, but if you are learning or developing on your own machine, you may not necessarily need all of that.
Hope that helps.
Since it is a web application, then start with the looks of it.
First, layout a template of how your pages should look, that is what users see. If it does not look good, the users will think the application (in its entirety) is also not good (it does not matter if the code behind the view is perfect; it will just make a first bad impression).
Start with that and be consistent with the design in all your pages. SiteMesh is a nice tool to dissociate the looks of the page from the functionality you put in it.
Then think what the application will do and what it will use:
you have a database? (use something like MySQL). With what are you going to access it? (IBatis is nice; Hibernate I think is a bit heavy weight for a first project)
you need a server: Tomcat is easy to use;
are you going for a simple Servlet/JSP approach or you want to use a framework (look at Spring or Struts);
try to find the good ways of writing the application, look at service layers, DAO pattern, DTO, MVC. Also, you must understand how HTTP works.
A lot more could be said.
Ah.. and also use a source repository. It’s a must (even if you work alone on this project).
Eclipse can handle all of these tools, but then so can Netbeans.
For your first project with GWT you should read through this tutorial:
http://code.google.com/webtoolkit/tutorials/1.6/gettingstarted.html
If you don't know Java then you will have some learning to do, and unlike Visual Studio your UI won't be just drag and drop, so it will be a bit harder than you are used to.
Subversion is fine, it is a nice source control, and any IDE will work with it.
Depending on your project would determine if GWT is the best choice though.
I expect UML may be overkill, and if you were following an agile methodology you wouldn't use it.
Your best bet is to get the UI done first, just have it appear as you want, and have some fake results, until you are happy with the look and feel.
Then, start to do the wiring to whatever you need on the backend.
Don't mean to be harping on you, but is Eclipse a must? For myself, in the beginning NetBeans turned out to be a really painless introduction to getting a web project up a running fast. I believe in the beginning one will spend a lot less time fighting the IDE with NetBeans.
A lot of the items from your bullet list NB makes super easy to ramp up as well. Just my $0.2