Why VisualAge for Java
Introduction
So IBM has come out with yet another Integrated Development Environment for Java. What's the big deal, you say? It's not only a great set of tools for developing Java applications, it's an entirely different way of thinking about Java.
What is an Integrated Development Environment?
An Integrated Development Environment (IDE for short) is a collection of tools that allow you to do many common development tasks with a common interface. Most program development tasks involve
- editing source code
- compiling source code to create executable applications
- executing applications
- debugging applications.
Before the arrival of IDEs, you would go to your favorite editor (vi, emacs, notepad) and create a file containing your source code. After finishing your edits, you would open up a console window and type some obscure compile command. If you get compilation errors, you would look at the line number mentioned in the message, switch back to your editor, find the line and correct the error. When you finally succeed in your compilation attempts, you go back to your console window and type a command to execute your application. If available, you might use a debugger to walk through execution of your application.
The problem was that each of the tools in this process has a different interface. To develop your application, you would need to
- learn how to use your editor
- learn how to use your debugger
- learn all the command-line options to the compiler
- buy a voice-recognition program because all the typing gave you tendonitis.
IDEs tied all these tools together in one nice package with a common interface. Tasks like browsing source code would be performed in exactly the same way whether you were editing code or debugging it. Command-line parameters were replaced by graphical interfaces to select options. One key press or mouse click could save, compile and execute your application.
Ok, IDEs are Cool, but I've Already Got One...
The current breed of IDEs all have one thing in common: they are file-based. All development is assumed to take place by editing an artificial structure known as a file. Files have absolutely no relation to any programming construct. So why do we have them? They simply provide a container in which to store your source code. A more natural way to edit source code would be based on the programming language constructs themselves.
Files are what every programmer has learned to use; it's a paradigm ("That's just the way things are done! Period!") that can be very difficult to set aside. Simply because everyone is used to using files for development, all tools use them as the base of any programming project. This causes several problems:
- the relationship between the language constructs and the files containing them is unclear, and often meaningless
- extra data can hide in a file (for example, multiple classes could be defined in a single file)
- determining relationships between language constructs is more difficult: you must parse all files to find all the relationships, and this can be painfully slow
- placement of files in certain directories sometimes works it way into the language definition. (For example, Java forces files containing classes that belong to a certain package to reside in a directory named after that package.)
- relationships between language constructs stored in different files must be maintained or specified by the user (using makefile, for example)
By rethinking the concept of what you edit to create a program, many development tasks become significantly easier. VisualAge for Java provides just this sort of paradigm shift ("teaching an old dog a new way to do an old trick").
A Repository
Instead of storing Java language constructs in a file, VisualAge stores them in a database call the repository. The repository stores information about
- Projects (an artificial construct that allows convenient grouping for a set of packages, classes and interfaces during development)
- Packages
- Classes
- Interfaces
- Methods
- Variables
- Visual Design
- Runtime parameters
- Compilation Options
This has several advantages to a file-based scheme:
- Relationships between language constructs are stored in the database and
can be quickly retrieved:
- You can easily find references to or the declaration of any language construct
- Compilation can be performed incrementally, as the data base allows VisualAge to know exactly what language constructs are affected by an edit
- Programmers can concentrate on what they are editing instead of figuring out which file to edit and where the construct in question exists in that file
- A list of unresolved problems is maintained, like an automatically-generated to-do list
- Errors in a saved construct (or changes that would cause errors in other constructs) immediately update the "unresolved problems" list, showing where one error affects other constructs
- Version control information can be saved for methods not just files. This provides a finer granularity of source management than previously available.
The "trick" is getting used to working directly with language constructs...
How Does This Make My Life Easier?
Once you adjust to programming language constructs such as classes instead of files, VisualAge really starts to improve your productivity.
For example, one thing that you've probably done several times is add a parameter to a method. If you're lucky, you'll remember every place where that method was called and can go and change the calls to add the method. But usually there will be several calls that you forget, and won't catch them until you re-compile. Even worse, there may be many applications that you don't recompile for quite some time, and by that time you may forget about the changed parameter.
In VisualAge, you add the parameter to the method and save that method. VisualAge searches through its database to find all other constructs that depend on that method (from other methods that invoke it to classes that implement an interface it was defined it) and recompile those constructs. Every location that is affected is flagged with a little red "X" to indicate a problem, giving you a visual to-do list of changes to be made. (The list of all unresolved problems is also available so you can see every problem spot, whether it is in your application or not.)
This is especially effective when adding or changing a constructor parameter. If you are using a hierarchy view while editing, all subclasses that invoke the superclass constructor are flagged with a red "X", helping to keep track of all the constructor call changes that are necessary.
Incremental compilation is automatic upon saving a method, class or interface. This ensures that you don't forget to compile anything affected by a change, and immediately informs you of any problems.
VisualAge provides automatic version control, making sure you can always go back to a working version of your code. VisualAge keeps track of the current version every time your save a method, class or interface, and you can explicitly checkpoint a method, class/interface, package or entire project with a version number/name. You can try a different approach in your code at any time by simply telling VisualAge to version your code. If the new approach doesn't prove fruitful, you can back out the changes easily. (This is especially nice if you only want to back out changes on a few methods, but want to keep changes in some other methods -- you can revert to previous versions of whichever constructs you desire!)
These are just a few of the benefits of VisualAge, thanks to its repository.
What Features Does VisualAge for Java Provide?
Other features in VisualAge for Java make it a top-notch IDE! As you might expect, VisualAge for Java provides an editor and debugger, and setting breakpoints is as simple as double-clicking the mouse. Errors detected during compilation are linked to the source code, so you can jump right to the problem and correct it. Compilation error information is kept in the repository, and all errors in any source construct can be displayed via an "unresolved problems" view.
VisualAge provides a myriad of ways to view your code. Some of the ways you can browse your code:
- a master view that contains all projects, packages, classes, interfaces and methods in a single tree
- a view of all code within a project
- a view of all code within a package
- a view of all code stored in the repository and each version available
Many of these views also allow you to view an inheritance hierarchy of your code, and even easily override methods just by editing a superclass method. (See VisualAge Tips and Tricks for a method of doing this.) This is great because you have a choice of finding which type of browser is most comfortable for you, rather than forcing yourself into a single project-manager browser like most IDEs provide.
VisualAge for Java provides a GUI-builder called the "Visual Composition Editor" (VCE). The VCE goes beyond a traditional GUI builder. Where most only allow you to design graphical interfaces, the VCE allows you to connect non-visual JavaBeans in the same manner you would connect visual JavaBeans. You can now have seamless integration of business-logic code and user-interface code, connecting them based on event processing.
The VCE is the most advanced bean interaction editor I've ever seen. One of its major strengths is that when you set up a connection between beans, the connection remains visible. Most GUI builders simply generate the connection code, leaving you to edit the connection code yourself if you want to change it. The VCE keeps all connection information, so you can change the source or target of a connection, the parameters to that connection, or even change the order of connections from a common source bean. You truly can visually maintain your application's event processing.
VisualAge for Java makes JavaBean development so easy you won't even know you're writing beans! JavaBeans aren't terribly complex to start with, but the tedium of writing all your BeanInfo classes and writing accessor method after accessor method can get tiresome very fast. VisualAge provides tools to assist bean development. Composing a bean is as simple as adding other beans as subcomponents, selecting which properties of which sub beans will be visible in the overall bean, and adding new properties, events and methods via the BeanInfo editor. And because the generated code complies with the JavaBeans spec, you can use your beans in any JavaBean-enabled development environment!
Conclusion
I've touched on only some of the reasons why VisualAge for Java is the best Java development environment available. VisualAge for Java provides all the tools you'll need to easily write Java applications, applets and JavaBeans.
To try it for yourself, surf to IBM's VisualAge for Java Home. You can download a free "Entry Level" version, which is exactly the same as the "Professional" version with the exception that you can only work on 100 classes at once. The professional version is available through several retailers, mail-order and internet-order sites. (I recommend surfing to http://www.shopper.com to find the best price.)
VisualAge for Java 2.0 has just been released! This version provides many updates and enhancements to v1.0.
If you are a subscriber to the VisualAge Developer Domain, you can download the professional version free from that site. (NOTE: If you had subscribed to the WebRunner subscription, your ID has been transferred to VisualAge Developer Domain!)