Chapter 14. Understanding the NetBeans APIs
You would think that in writing an IDE the first priority would be an editor—this is a thing that edits files, right? Then you write code for compilation, execution, and so on, and you have an IDE. This is a fine design for a small application. But what happens when you want to, say, integrate source code management with the tool? You find you have to rewrite a lot of your file access code. What about integrating access to databases? You’ll need some way to make connections, browse databases, and so on. And interestingly, you’ll find a lot of the user-interface code you’re writing (select an object representing the database, get some information from it, present it), looks an awful lot like the code you’re writing for browsing files...which looks like the code for managing user settings, and so on. Your codebase is growing rapidly (and getting less maintainable in the process), and a lot of it is code to do very similar things.
The team that created NetBeans went through this, as NetBeans 2.0 evolved. As a result, if you are building an application on top of the NetBeans core, you get to benefit from their experience. You can start writing your application with all the problems they encountered already solved for you.
Design Philosophy of NetBeans
NetBeans solves problems
like those above through very heavy
use of abstractions. For example, when you interact with a file, you
will be using a
FileObject, not an instance of