Page 2 of 3
FB has some logistical problems with regard to its development, as do most GNU projects. For example, although the FB team maintains a GNUish atmosphere of flexibility, the developers are all volunteers -- so they work on FB when they can, and not according to a production schedule. As a consequence, the development of FB has been a slow process, and FB has never had an official release date.
Petkov began working on Version 07 of FB after he finished another IDE-development project using Delphi/Pascal. He had written a Pascal compiler that produced Java-like bytecode that is interpreted. As with Java, the code used a stack machine and was therefore not designed for a specific platform. Although the development of FB required completely different coding and instructions, Petkov used his IDE-development experience as a template for the GNU project.
During the process of designing and programming the various components of FB, Petkov had to learn some of the basics of Java development -- including the purpose and structure of a bean, serializing some objects, working with interfaces, and the benefits of a garbage collector.
Despite FB's importance to the Java development and free software communities, not all Java developers are convinced that IDEs are a good thing in general. Carl Muckenhoupt, a former EarthWeb developer who now does consulting work for the company, outlines the problems with IDEs.
Limited choice of development apps
First, Muckenhoupt explains, an IDE limits a programmer's choice of development applications. For example, someone who prefers
to use emacs as the source code editor -- and has developed a custom emacs configuration over a long period of time -- can't
take advantage of it when using an IDE. Muckenhoupt feels that the editors in IDEs are generally inferior to a custom-designed
one -- so a substitution of the IDE's built-in tools may take developers several steps back in convenience and usability.
FB is constructed from JavaBeans -- so, theoretically, it should be easy to swap in an alternate editor bean. Even if this works, a programmer must choose from Java-based editors, and unfortunately these are neither the best nor the most popular editors.
Single process problems
Second, an IDE often runs as a single process. Because of this, any individual component (such as the debugger) that crashes
creates a chain-reaction and crashes the entire application. This can be disruptive and even destructive if a programmer has
five or six files open at the time -- not an uncommon situation for a large Java project. The programmer is then forced to
reopen all of the files following the crash of a single component.
Fortunately, FB does not have this problem. When Run or Debug is selected, it starts a project as a separate process -- so each project can be terminated without crashing the entire application.
Problems peculiar to IDEs
Third, IDEs present particular problems to development teams. IDEs typically have their own built-in project management systems,
which means that if several developers are working on a project, they must either all use the same IDE, which limits the choice
of tools for all the programmers, or set up the same project files, which is redundant. In addition, it's difficult to start
or stop using a particular IDE in mid-development, which is not a problem with non-IDE programming tools.