Now IBMīs donīt support anyway the VAJ.
was IBM's first Java product. The brand is now (July, 2002) retired.
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.
- Does not support incremental compilation
- Does not allow changing code from the debugger/inspector (see above)
- Uses a file-based paradigm (Envy is gone)
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.
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
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:
- Entry Edition (500-class limit, etc): no charge
- Pro Edition USD 299 (apparently now free with VADD membership; can someone verify this?)
- Enterprise Edition (concurrent development, etc) USD 2999
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
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
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
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?
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?
, 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.
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
; 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).
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?
, 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.
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:
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?
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.
(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.
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
- None that I've heard of and I monitor this pretty carefully. I'd expect Macs would follow a full Linux port but don't hold your breath for that.
- Yes, I know, IBM trumpets Linux support but that's their suits talking. Yes, I know, VisualAge3.2 runs on Linux. That's where I use it. Mid-level IBM suits nixed making VisualAge 3.5 (with JDK 2.x support) on Linux. The newsgroup promptly went dark on any news as to when full Linux support would be available after announcing it would be available early this year. I'm still bitter for buying a VADD subjection for Linux based on the understanding that I'd be getting first-class Linux support. Silly me. Never again. Linux and/or Mac users: beware of IBM suits.
- That said, I've managed to cope with VisualAge's JDK1.1.8 limitations by exporting source and doing my production builds with Jikes. See http://virtualschool.edu/wap and http://virtualschool.edu/mybank for further details. --BradCox
See also discussion in VisualLanguage