Whats the best Java GUI Builder??

[Archenemie]

Im looking for the "best" GUI builder for java.

I use Eclipse to write my scripts, and i would appreciate you guys telling me your favourite GUI Builder and the reasons why.

Thanks

[masijade]

Manual. Gives full control with no "bolierplate", repetitive, rigid code.

But that's not what you're looking for is it? I dislike all "Gui builders", as they all produce rigid, reptitive code that is hard to modify correctly, and is not always that effecient when any action to be performed is more than popping up a dialog.

[javaAddict]

Manual. Gives full control with no "bolierplate", repetitive, rigid code.

But that's not what you're looking for is it? I dislike all "Gui builders", as they all produce rigid, reptitive code that is hard to modify correctly, and is not always that effecient when any action to be performed is more than popping up a dialog.

I agree. I prefer to write my own gui.

Surely I also use a Gui Builder but just to quickly declare and place the elements.

But most of the times I do them on my own.
It is hard to use a gui builder to create dynamically a list of buttons or a ComboBox whose values are generated by some other function.

It is better to learn how to create JFrames on your own and not depend on a builder. Especially for actionListeners. The code that they generate is not easy to follow and you won't learn how they work and called.

[Archenemie]

So basically use JFrame...

Will do.

[jbennet]

NetBeans, nice easy visual-studio-like interface. But generates ugly code. Writing your own is best in the long run, but for RAD, netbeans is good.

[MoZo1]

I agree. I prefer to write my own gui.

Surely I also use a Gui Builder but just to quickly declare and place the elements.

But most of the times I do them on my own.
It is hard to use a gui builder to create dynamically a list of buttons or a ComboBox whose values are generated by some other function.

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.

It is better to learn how to create JFrames on your own and not depend on a builder. Especially for actionListeners. The code that they generate is not easy to follow and you won't learn how they work and called.

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.

Manual. Gives full control with no "bolierplate", repetitive, rigid code.

But that's not what you're looking for is it? I dislike all "Gui builders", as they all produce rigid, reptitive code that is hard to modify correctly, and is not always that effecient when any action to be performed is more than popping up a dialog.

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.
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.

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.

[masijade]

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.

[java..]

jframebuilder.exe

[MoZo1]

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.

Generalizing things that you can repeat places constraints on your design. It depends on how much you (or your customer) want to customize a form. Also you loose the advantage of property editor interfaces like colour picker, table editor... again because you didn't separated data from code, you've lost the editors for the data.
GridBagLayout should be supported, but this doesn't mean that the concept of GUI builders are wrong.

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.

The code is there without any switch or loop or arithmetic, which I call data. You could replace the whole thing with a call to unserialize.
This is not the case of course if you need a variable number of combobox or whatever, but then you can encapsulate the whole stuff within a JPanel.
GUI builders are there to deal with rigid repetitive code like one-off actions, not to write good events. If you can write good events, and you only need some one-off actions, you sure won't like writing those by hand.

"Official"? There is no "official" IDE. 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.

Sun's Java tutorial often assumes you use NetBeans. If it's official or endorsed, it's my mistake, I'm not pro at these.
GUI is the smallest part of the language or a big application, but a lot of application requires a GUI, even the smallest ones, where the GUI part consumes very large part of the time if you write it by hand. RAD and GUI editors are in place to produce large number of smaller applications fast.
And of course a GUI builder won't make a thread for you, because every GUI related tasks should also run in the Event Thread. If you want something to run in another thread, that's completely your concern.

Web GUI for example

And also when I write a web interface, I won't create it by hand, but make it with an appropriate editor, and use JSP.

[masijade]

And of course you use JSP/Servlet, That, of course, does not invalidate the argument. And you completely missed the point about methods. And building a GUI by hand, when done properly, as I said, does not produce rigid and repetitive code, unless you code in the same way as the GUI Builders. And, as I said, I have never seen a GUI builder that lets you choose what layout you wish to use. That would cause too many variations in the way the GUI builder must react, and, as I said, I have never seen one that uses GridBagLayout, so a complex GUI will winf up using about 5 times as much heap space as necessary. It is not something that is fatal, usually, and not someting that you always, or even usually need to be concerned with, but sometimes you do.

I have no problem with people using them. Exactly the opposite. But, especially for the beginner it is very important to start building them manually. It is important to know how to do it yourself, or you will never be able to diagnose problems that even just might be caused by that. And you will be completely lost if you need to make even just a minor change to it and do not have your builder to use, or, in the framework of the project, are not allowed to use it, which happens more often than you may think.

I also see no argument in support their abilities to facilitate good actions.

I also have no idea what you mean with "switch or loop or arithmetic". If the GUI was built properly there is absolutely no need for any kind of that stuff, and being "rid of a GUI" is simply no longer including that code in the project, when done properly so that the application itself is not at all involved in the GUI code, as I said earlier.

[Ezzaral]

Netbeans does allow you to work in GridBagLayout (or several others) from the designer if you set it yourself. It defaults to GroupLayout though, which is hideous to read.

[masijade]

Then I'm impressed, they've gotten better.

[BestJewSinceJC]

For what it's worth I agree with Masijade (about learning to code GUIs by hand first, then moving on to builders if you want to). Doing so was very helpful to me and it made it a lot easier to use the GUI builder as well. If you jump into the GUI builder without knowing a lot of things first, you will end up confused and unable to modify key sections of the GUI builder's code to get it to do what you want.

[P00dle]

I agree with Masijade, learning to code them by hand first is the best. I did.
Then I spent a year doing other things than gui's, and didn't remember anything when I came back. Netbeans was an enormous help.

[Archenemie]

Im tempted to mark this as solved, but ive kind of started WW III with the original question, and im afraid that if i mark it as solved, im going to get knifed in my sleep :(

[masijade]

No. It's a simple discussion of personal opinions/views of the pros and cons of varying approachs.

If your question is solved, go ahead and mark it as solved, that won't stop people from being able to post in it.

[Archenemie]

I was only kidding anyway, but ive decided to start building them from scratch.

:)

[dotxyteam]

Reflection-based GUI creation and customization (no code or few code) may be an option for you. See the ReflectionUI project.