I must disagree here: For example with NetBeans you can subclass a JPanel and make it whatever you want, like an interface for whatever you have (like a database record, a file...). Then you can write "custom creation code", create your component directly or through a factory which also links it to the data it has to generate values from, and still drag it around in your visual builder, and set properties like size, colour... And then you can even make that JPanel to require a ComboBox or whatever else palaced into it, so it'll use that as a prototype to create the custom ones!
Back a while with Delphi I used to think like you, but that GUI builder was crap, and all of them is.
Good for you, to each his own.
It's also a good thing to be able to start Java without knowing how to create JFrames, and learn it on the way. But it's best to learn how to create JFrame, learn how your GUI handles it, and learn how each one is intended be customized, since the point of every OO framework is to be customized.
Maybe, but I still find it best to learn it manually
first so you
know what it is the code those GUI Builders make
does.
When you have to put a lot of simple components onto a form, it's inevitable to produce rigid and repetitive code, just because it's data hardcoded into program code, and GUI editors are in place exactly to help you modify that rigid and repetitive code that I don't like to touch by hand.
No, manually you can make methods that for the placements so that the only thing "repetitive" is the calling of the method. Also, I have never seen a GUI Builder use GridBagLayout, which is what I prefer as it gives you maximum control over the layout without 20 different layers of layout managers which is what most GUI Builders I've seen do.
You don't need even one line of program to define how a form looks, just think about serialized forms. Long ago Delphi's GUI builder was written so it manipulated a serialized form, which was exactly this kind of hard to modify. Now I think NetBeans finally get it right, and I find it easy to modify.
Yes you do. Whether you build it or a GUI Builder builds it the code is
still there, of course. And it is still nearly impossible to get a GUI Builder to create a
good action event that triggers more than a simple one-off action.
For the original question:
NetBeans is official and easy to install, Eclypse is old and has more plugins and supporters.
The main thing is that you have to use a GUI builder, and start using it as early as you can, to be expert in it as early as you can, because your work and the time it takes will be compared to those who are. And if you really learn how your GUI works, it'll include creating components by hand, and writing components yourself.
"Official"? There is no "official" IDE. Sun provides links to NetBeans because it "endorses" it, but that does not make it "official". There are no "official" IDE's. If there where it would come as a standard part of the JDK, rather than as an optional, bundled product. And the "time" to become an expert has
nothing to do with how quickly you can build rigid GUI's. Gui's are the
smallest part of any language. The hardest part of a GUI is getting actions to perform properly without "freezing" the GUI (i.e. without the action taking place on the Event Thread) and the GUI builders, normally, do not help much with this.
And I really dislike the statement about making the component "look" like the data without the qualifying statements of making sure that you are not tying your data and actions to the GUI. You
do realise that your GUI code, your action code, and your data model should be completely independent of each other, right? That statement made it sound (whether you intended it that way or not) as if you are going to mixing all that code, which would make it extreemly difficult to change GUIs later (I.E. from a Swing to Web GUI for example) or to simply allow, from the very beginning, for multiple possible GUI's for the application.
Offline 
Marked 
