Extending Java / RAD Support with NetBeans

In This Posting, I wrote that Java / RAD – ie Swing – Support could be added to the free version of Eclipse.

Well as a follow-up, I just wanted to mention that the Window Builder that this procedure installed, is not extensible. This can be quite limiting.

Instead, a better approach might be to install “Net Beans”, even under Linux. This IDE will support OpenJDK 7. We do need to make sure though, that we do not only have the JRE package installed, but also the JDK (development) package. It is a bit harder to set up than the other one, but has as advantage a Component Palette which is extensible.

After installing Net Beans, the thing to do is to add some sort of standard, built-in Swing component, thereby making the Component Palette visible in the IDE. We have our Swing Designer at that point. Then, under Linux, it is possible to add the Jar File ‘/usr/share/java/swingx.jar‘ to Net Beans, by way of ‘Tools -> Libraries (Global Libraries)’. Then, we can right-click on the Project and click on ‘Properties -> Libraries’, and add the newly-defined Library to the Project.

Next, we can right-click on the component palette, and open the Palette Manager, from which we first create a new Component Category. It will be empty. Then, still within the Palette Manager, we can add components at will From the newly defined Library. It will ask us which Category to add them to, and presumably we would add them to the Category we just created.

And at that point we will see, that we not only have components such as “JPanel”, but that we potentially have a large number of components, whose names begin with “JX”, such as “JXPanel” …


I never really knew, that Net Beans was so powerful, yet free. However, Net Beans is not open source, and to install it, we need to run their SH File as ‘root’. This could present a daunting leap of trust for some people. Also, even though this setup script wants to be run in root mode, it will also need to display a graphical wizard. This requirement has led to a common but minor error message with many users. And so, in user mode, we need to give the command ‘xhost +‘ first, so that the root-mode process can access our X-server, and then after we have installed Net Beans, back in user mode, we give the command ‘xhost -‘ again.

Continue reading Extending Java / RAD Support with NetBeans

Getting Java / RAD support within the Open version of Eclipse

One type of question which some of my friends will ask me from time to time, is ‘Whether I am aware of any good IDEs these days’. This question arises from the knowledge, that writing source code just with a text editor, is not much fun, the fact that IDEs exist which enhance the programming experience, and finally, the memory from our distant past, of the fact that there exist IDEs which implement a kind of ‘RAD’ – a Rational Application Development – or a Rapid Application Development platform. This can sometimes conjure up pleasant memories of the days when Sun Microsystems was still in control of Java.

And so I have taken a minor step to explore this subject only today, and come to the following observations.

Java / RAD in the old days, was already based on ‘Swing’. And Swing is a set of Java packages, which keep two things in sync: A code view, and a design view of our project. It was Swing which would update the code view, if we made changes graphically to our design view, and vice-versa.

Having understood that, the next thing people who use Linux might do – as I did – would be to install a number of Java Swing libraries from our package manager, and then to hope that we have what it takes to start building Java / RAD projects, the way we used to do it with ‘JBuilder’. JBuilder was a proprietary, paid-for IDE, which back in the days of ‘Borland Inprise’, possessed the components in a bundled way, not just to be an IDE, but to be an IDE with RAD capabilities.

But inevitably, we run into an impasse. Under Linux and entirely with Open Source software, we are likely to be using “Eclipse” as our IDE, and a version of it, which does not recognize that we have Swing packages installed – in our shared, non-proprietary Java folders. I do know that paid-for versions of Eclipse exist, which again bundle Java / RAD capabilities, but we might want to obtain those, without having to pay much money. So what can be done?

The answer that suits some use of Eclipse, lies in the fact that with any Linux Eclipse install, there exists a user-space install of extensions, similarly to how the Windows flavor of Eclipse, also has such a built-in mechanism to install extensions to this IDE itself. We find that in the Help menu, there is an entry named “Install New Software”. From there, we can specify a URL to download packages from, and we can extend, or possibly confuse, our Eclipse setup. But what we install from here under Linux does not ever use ‘root’, and thus only exists in our user / home directories.

There is a relevant URL which I just learned about, from which we can tell Eclipse to install extensions to itself:


And when we have typed in the URL, we can see a set of components available, which include 3 Swing components, plus the critically-important “Window Builder”. This Window Builder is the Eclipse extension, that actually maintains the two views. After we have installed all the relevant packages – because we often tell this wizard to install all the dependencies as well – we need to restart Eclipse. We may first have to acknowledge having to install non-signed packages.

Once this is done, under the New Projects list, we will see as the last menu entry, “Other”, referring to a miscellany of non-standard project types. And when we open that view, we will finally get to see our Swing subsection of New objects that we can create.

Doing so opens a specialized wizard, and sets up our Java / RAD project, which will eventually have a code view and a design view.

Now, the logical question does arise, of whether it did any good, to install Swing packages via the Linux package manager. Doing so places them into shared folders using root privileges, folders that are not even specific to one Java compiler used. I have run into situations before, in which Java projects designed by other programmers did not initially recognize, that these shared Java libraries even existed. This has required some workarounds in my past.

Using Eclipse, the fact is that these packages will not show up in the graphical browsers /  wizards.

But I think that this is one reason, to install all 4 components offered by the URL above, to make certain object types visible in the IDE wizard. After one has created a basic project with the code and design views, I think the next thing to try, would be just to add the ‘import‘ statements to the code view, that are meant to pull in the Swing packages we think we need, and then to see, whether the design view renders them correctly.

Whether it does so or not, next depends on the separate question, of whether All Swing packages are in fact compatible with the Google Window Builder. And even though Swing should implement a standard interface, depending on what we are trying to do, the answer might still be ‘No’.

It would be necessary to link our project to the desired JAR File explicitly, in a way that states its location in the shared, root File System… In that case, we would click on the IDE Menu, “File -> Import”. And in the window which appears, instead of choosing “Plug-Ins And Fragments”, we could choose “General -> File System”… And under Linux we would choose the folder ‘/usr/share/java‘, so that in the subsequent view, we can select the required JAR Files, knowing that they will be copied.

Then, we would right-click on the project we want to build, and click on Properties, which opens another window, from which we would choose “Java Build Path -> Libraries” …


(Edit : ) It is entirely unproven, whether externally-supplied Swing libraries can be made to work properly, with Google Window Builder. What Google has done, is to name the Swing components of its Window Builder, as offering a ‘JPanel’, a ‘JFrame’, a ‘JApplet’ etc., so that the naming of classes will not interfere with generic Swing class names. Hence, if we were to try to use Swing classes provided by the Linux package manager as stated before, first of all those would have dependencies on one or more base libraries, also located in ‘/usr/share/java‘, which would not only require that the ‘import‘ declarations be put into our Java source file, but also that the libraries be listed after the libraries that already belong to Window Builder, within the link order defined in the ‘Java Build Path’.

The ultimate success we would want to see, would be that the Component Palette belonging to Window Builder, should offer us additional components, other than J-this or J-that. But the mere fact that the naming of classes has been separated, suggests the possibility that these external components will not be recognized by Window Builder at all.

One quick test a user could perform, would take into account the observation that Window Builder source code tends to import one specific package, such as ‘javax.swing.jframe‘. After we have appended the desired libraries to the Java Build Path, base library first, we could try to declare something that generic Swing projects frequently used:

import javax.swing.*;

This declaration should either work, or crash Window Builder.

(Answer : ) Doing so simply causes Window Builder to crash temporarily, until the offending declaration is removed from the code view. That is all.