Visual Age Java

Now IBMīs donīt support anyway the VAJ.
VisualAgeJava was IBM's first Java product. The brand is now (July, 2002) retired.
VisualAge for Java 4.0 has been released. Minimal changes between this and v3.5. It will apparently be the final version of VisualAge for Java, at which point IBM will move on to the WebSphere Studio Workbench... http://www7.software.ibm.com/vad.nsf/Data/Document2020?openDocument&p=1&BCT=1

Here's hoping they don't butcher it too much...

see http://www.eclipse.org for its replacement (See also EclipseIde)

From reading the IBM news groups, the "new improved" java:

As nearly as I can tell, this means that IBM has intentionally killed the attributes that, for better or worse, differentiated VisualAgeJava from the rest of the bloatware out there. JavaIsDead.

IBM VisualAge for Java product.

from the source: http://www-3.ibm.com/software/ad/vajava/

[I have tried to refactor, please move non java content to: VisualAge.]

It's beginning to spawn the following offspring:

Man, I have not seen that much hype since...well, the last time I saw a car commercial on television.

Can anyone explain how this might actually be useful? Is there something that their IDE provides that I can't live without.

-- BillTrost

I suppose IBM should really respond, but in their absence...

IBM seems not to have done much of an education job with VisualAge for Java as it's based on a SmalltalkLanguage approach, rather than the usual file-based (i.e. C++ or Pascal) approach. This means keeping everything you need live in a system image on your desktop. Obviously this takes a lot of steam (I find it runs OK in 64MB RAM on a P200), but it provides a much more dynamic environment. You can edit code in the middle of a debug session and just keep going. Similarly, the cross-referencing works pretty well.

The other thing it brings is serious configuration management, with version control down to the individual method--Each save of a method is kept as an edition and you can navigate around the editions. Again this sounds weird until you've tried it for a while and it gives you a lot of confidence to just type and sort out the mess later. This really works best in teams where you can keep going without worrying about stepping on each other.

Probably the best way to learn it would be to use SmalltalkLanguage with Envy for a while and then transfer back -- at which point you start whining about the inconsistencies in the language.

Concerning pricing, I believe that all the VisualAge products are pretty reasonable now until you go "Enterprise" (i.e. server repository plus various goodies). At that point it gets really expensive, but you're serious developers, right? ;-) --SteveFreeman

The IBM web site offers: I've just tried the entry edition for a little while. It's an interesting concept, but bloody slow even on a machine that's usually pretty good for Java work. (It didn't crash, but did freeze for over 15s at times.) Ubiquitous version control and a Smalltalk-like workspace are nice: programming by drawing arrows I'm not so sure. I think I'd basically rather have an environment where the code is readable than a tool that covers up ugly code. -- MartinPool

I'm using VisualAge now for nearly two years, before that I used VisualCafe. In my opinion, VisualAge is a lot more than a simple code editor (see what Steve wrote above). Particularly code navigation is very easy. If you have a project with a few hundred classes, you start to like the search functionality of VisualAge. --PeterGassmann

There are a number of other things you can do which non-SmallTalk programmers don't think to try. Recently when working with some friends, I had the chance to do some PairProgramming and made their eyes pop out with some of the features. I will start a separate page for VisualAgeJavaTips -- TimMackinnon

IBM appear to have produced a Java2 version of the VisualAgeJavaThree Enterprise Edition (instead of the earlier non-edition-specific preview version). It's still not fully supported, but at least it now exists. And about time too. Allegedly you can run it alongside the JDK1.1 version on the same workstation, and against the same Envy repository to help your migration. You have to have purchased Enterprise edition to get it though. --RichardEmerson

Many of the VisualAge related pages mention Smalltalk. Q: does anyone know if IBM VisualAge is based on a Smalltalk system? My impression was that VisualAge's big contribution was using a relational database to manage all of the code. Perhaps some Smalltalk systems do this, but I have seen more than a few Smalltalk systems that use idiosyncratic data structures to manage their code. I.e. it is possible to write poor databases in Smalltalk, just as in any other language.

Similarly, some Wiki comments say that VisualAge is nonextensible, and/or difficult to use with standard UNIX tools such as grep. Q: if there is an underlying relational database, does the VisualAge user have access to it? Can you write SQL queries over your code?

-- AndyGlew

It's a proprietary repository written by ObjectTechnologyInternational (now owned by IBM). The first Java implementation was built over their well-established Smalltalk implementation, although I believe they're slowly migrating it away. You can talk to the repository via the Tools API which, unfortunately, is much less open in the Java version. --SteveFreeman---- Unless IBM has done some serious rewriting of EnvyDeveloper in the last year or two (which I doubt), AndyGlew is mistaken when he writes that "the entire source code lives in a relational database, integrated with a language parser".

Instead, the repository is a big file, managed (carefully) by a combination of a very highly optimized accessing monitor (EMSRV), and client-side modules that interact with it using a protocol and objects defined in Smalltalk.

The repository is therefore a passive and carefully managed ObjectStore, which is then integrated into the client user environment as a collection of atomically-loaded classes and instances. This ObjectStore is managed as a WriteOnce? datastore that appears, from some perspectives, to exhibit behavior like a relational database (transactions, atomic operations, robust error recovery, etc). To my knowledge, it is not now has never been implemented using an RDB.

The integration with the language compiler is done in the image, not the repository. Smalltalk has always had this model, and IBM adopted it for VisualAgeJava. Thus, the second major contribution of VisualAgeJava is the implementation (with a few ugly wrinkles and creases) of a CausallyReflective? Java environment.

ObjectTechnologyInternational, now owned by IBM, created EnvyDeveloper in Smalltalk more than ten years ago. EnvyDeveloper was the defacto standard for corporate Smalltalk development. The capabilities and full functionality of EnvyDeveloper are staggering, and both IBM and OTI have always understated them. For example, developers within OTI routinely connected to it using multiple Smalltalk environments on multiple hardware platforms, all sharing a common codebase with a granularity to the method level (yes, the grain size, even in Java, is at the method level).

The VisualAgeJava VirtualMachine is the same virtual machine as the VisualAgeSmalltalk VirtualMachine. The VisualAgeJava environment was created by developers who shared a repository and code with the VisualAgeSmalltalk environment. Thus, the two environments are intimately connected at very fundamental levels.

The VisualAgeJava IDE is written in Smalltalk, not Java. Because Smalltalk and Java share the same VirtualMachine, they can run in the same environment. The reason it cannot be extended is that IBM has chosen not share the Smalltalk source for the VisualAgeJava IDE. In order to extend the environment, one would need both VisualAgeSmalltalk and VisualAgeJava; the VisualAgeJava environment runs inside the VisualAgeSmalltalk environment. The process of extending the IDE without breaking it is sufficiently tedious that IBM has chosen not encourage it (the support implications are nightmarish).

The VisualAgeJava IDE is written in Smalltalk, instead of Java, because Java (as it exists today) lacks sufficient richness in its metastructure to support the runtime magic that such an IDE demands. For example, the Java environment lacks classes that correspond to the Smalltalk entities like Behavior, Metaclass, Class, CompiledMethod?, BlockContext?, and MethodContext?. Java simultaneously captures the semantics that are expressed by these classes in the syntax, instead of the environment, so that it is impossible to integrate Smalltalk-style behavior without changing the language.

Someday, this is likely to change (Java approximately reflects the semantics of Smalltalk-78, a generation prior to the Smalltalk-80 that we now take for granted). Until then, the approach taken by IBM remains (in my opinion) compelling.

-- TomStambaugh

There is a Jolt award for VisualAge for Java (new reference!!: http://www.sdmagazine.com/products/2000/06/r2.shtml), but the comment says the following:

"...Unfortunately, VisualAge is a victim of its own comprehensiveness. It requires all source code to be kept inside its repository, not on the file system. This Borg-like aspect of the programming environment effectively locks the developer into using VisualAge for all aspects of the project; in short, it doesn?t play nicely with other tools."

This isn't quite true. VisualAge's import/export facilities provide comprehensive support for imporint and exporting to filesystem files. My only complaint is that resource files are not dealt with as comprehsnviely as java source and binary files.

If you agree with the Pragmatic Programming "PowerOfPlainText", the previous statement seems to have a point when it comes to external tool integration. Can someone enlighten me?

--ErnestoGuisado

In a recent email to CliffordAdams, I wrote: 

 > At first I really disliked the "image" model, but I can 
 > appreciate some of its power.  


 I'm the other way around. I loved the image model first
 but I am slowly getting to hate it as my images get 
 corrupted over and over again or when I need to do a
 full grep, or macroed editing or something supposedly simple.


 There's one lesson I've learnt over the past year: use simple, 
 open formats and data stores so people can easily write or
 use pre-existing tools to manipulate them. Flat text files are
 better than complicated B-Tree images.


 I've been thinking about this. There's no good reason why
 you can't have all the benefits of an image and still dump to
 flat files. The bloody IDE has a fuzzy parser in it, doesn't it?
 If it does syntax colouring or code completion, it does. Use 
 that to create the abstract syntax tree which you can then
 use to manipulate the code at a higher level.
[...] 

 >	Another thing I like is that practically all of the code is available
 >for practical changing in an image.  In languages like Java, it's generally
 >impractical to change core libraries


 There's no reason you can't do that with a file based system
 if you had access to the source code and the ability to rebuild
 the system files.
-- SunirShah (my opinions are my own and not those of my employer)
I'm the other way around. I loved the image model first but I am slowly getting to hate it as my images get corrupted over and over again or when I need to do a full grep, or macroed editing or something supposedly simple.

I find it easy enough to select (from the WorkBench?) the projects that I want to do the full grep or macro'd editing on, export them to a temporary directory, do whatever I want to them, and them import them. I find that I need to do this relatively infrequently, and so I don't mind the export/import overhead.

I've been thinking about this. There's no good reason why you can't have all the benefits of an image and still dump to flat files. The bloody IDE has a fuzzy parser in it, doesn't it? If it does syntax colouring or code completion, it does. Use that to create the abstract syntax tree which you can then use to manipulate the code at a higher level.

I think the difference between "image" and "flat file" is itself a reflection of a more fundamental distinction, one that is even more pronounced in Smalltalk. VisualAge (both Smalltalk and Java) intentionally strives to create an environment that is object-oriented "all the way down". The "image" is an implementation detail of how this is accomplished -- it is certainly possible to "dump to flat files" while preserving this illusion, but I suspect that doing so would only reveal more about the difference.

Even if flat files were there, the idea of "macro editing" or doing a "full grep" assumes a model where there are "source files" (always streams of ascii characters) that are "compiled", from beginning to end, and that result in an "application". It is this model, itself, that VisualAge (both Java and Smalltalk) turns inside-out. Instead, the idea is that the environment is stable, solid, persistent, robust, and distributed -- and the "source code" is a rendering of some aspect of this environment, often created on demand in order to communicate with an external tool or service. Why bother to archive the "source code" of a class or package definition when the class or package object *itself* is preserved in a transaction-controlled persistent store? In VisualAge, even if the image or the "source files" are corrupted, the environment is not, and hence the image or source files can be recreated.

Often when I think I need a "full grep", I realize that I can instead change the representation of the object itself. For example, what I'm *really* doing is changing the signature of a particular method for all its senders and implementors. If I can change the representation of the method itself (for example, if the environment maintains a call-graph), I don't need to do the "grep", I can merely change the method object itself (and let the environment update the call-graph).

At some level, I think this really gets at the fundamental obstacle that has always blocked developers from grokking Smalltalk (I think something analogous happens in Lisp as well): it is a *fundamentally* different paradigm. I think the investment and business communities have always wanted to "paper-over" this difference, first with CeePlusPlus and then with the JavaLanguage. I think our industry is learning, the hard way, that this difference cannot be obscured -- any tool that reveals enough of the power of being "object oriented" to cross the threshold of compelling usability ultimately lets the genie out of the bottle.

Such an environment (any of the Smalltalks or VisualAgeJava) isn't "backwards compatible". It isn't "evolutionary". It doesn't "play nicely with other tools". It is fundamentally *different* -- for better or worse.

--TomStambaugh
Are there any plans to port VisualAge to the Mac ? --ChanningWalton

I think that we have a greater chance of Eclipse being ported to the MacOsx, lets hope so. -- ChanningWalton

See also discussion in VisualLanguage -- JeffMantei
CategorySoftwareTool
EditText of this page (last edited April 12, 2006)
FindPage by searching (or browse LikePages or take a VisualTour)