Swing Design in Netbeans; Coding in Eclipse

Eclipse is a very popular IDE for java development. However, it does not come with a good "built-in" plugin for Swing UI design (Even eclipse itself is developed in SWT instead of Swing). It's said that eclipse 3.7 indigo comes with a UI designer "WindowBuilder". However, I haven't tried it yet.

Netbeans is also a popular java IDE. The good thing of Netbeans is that it comes with a better support of Swing UI design and development.Basically, with netbeans, you don't need to write a line of code while you can still design a decent looking UI in Swing.

Here comes a problem: what about taking advantage of the easy design facility in Netbeans while still coding the business logic in Eclipse as the majority code is developed using Eclipse?

Coping/synchronizing java files back and forth between Eclipse and Netbeans is obviously not a good idea.

• Changing the Netbeans generated code in Eclipse could break the Swing designer in Netbeans.
• Mixing the business logic with the generated code implies that Netbeans has to be aware of these additional dependencies so it can work.

The following tip helps to avoid this two-way copying/syncing mentioned above.

Basically, the principle is to use Netbeans only to design the base of the UI, it does not need to know the business logic: Then a class is created in eclipse to extend the generated UI base class. All the business logic are coded in the extended class, leaving the Netbeans generated java classes and resources untouched in Eclipse.

A few things need to be done to make this principle work:

Allow the extended class to access the java component fields generated in Netbeans. By default, Netbeans generates Swing component fields with a "private" modifier. This can be modified however.The following figure shows how you can change the modifier from private to protected: Select the root form in the Navigator Panel; then in the Properties Panel, change the variables modifier from private to protected or whatever suits you.

Create the event handling methods for the extended class to implement. Netbeans can automatically generate the event handling stub methods. However, these methods are private methods. manually changing them to protected seems not a good idea. What I prefer to do is to create an unimplemented protected method to be called in the Netbeans generated method. This method then can be implemented in the extended class with the real business logic. The code will look like the following: