Visual Age Java Gripes

ItKnowsWhatsBestForYou? (tm)

WARNING: Because of the WikiNow, the version of VisualAge people are griping about is unknown. It seems that at least half this page refers to very old versions of VisualAge. For instance, inner classes show up very nicely in my version of VisualAge [3.5 onwards], exactly as they appear to the Java virtual machine.

VisualAgeJavaTips contains some useful hints on using this tool. VisualAge discusses it in general terms.

Here's a snapshot of one team's experience of it.

On the project I'm currently involved with, VAJ is mandated by the client (because they used to be a SmallTalk shop).

Only and exactly the team members who have extensive SmallTalk experience find the tool anything less than a colossal annoyance. An all too common sound in our office is the hand slapped on the desk followed by "f***ing visual age!"

The client also mandates RationalRose. Even with the big desktop machines we have (128 meg ram, very fast P2's) running both causes serious performance degradation: in this day and age I don't expect to be able to watch gui components get redrawn one at a time.

Agreed about the redraw. That said, some of the IDE's kick off multiple Java VM's to do anything interesting (i.e. compile or debug). --SteveFreeman

Team members now often refer to it as "Visual Bureaucracy", and to the Project/Package Owner/Developer/Group mechanism as the "Visual Bureaucracy Shuffle".

Maybe the client has things set up wrong, but ENVY seems to be a good versioning tool, but to have no concept of a configuration.

Agreed. I don't understand why they got to version 2 without configuration maps. --sf''

It took us weeks, weeks, with decades of university and commercial experience behind us to figure out how to safely version code. Inadvertent scratch editions, inadvertent branches (upon branches, upon branches...), too many open editions, no configurations!. Does any one using VAJ ever turn on the password protection? If so, how do they get anything done?

I worked with VisualAge in a group environment where almost everybody had a username and everybody knew all passwords; users were used to loosely identify ownership and you usually impersonated whoever created the module you were modifying. Still, I spent hours upon hours altering owners and switching users in order to assemble versions. I think the username system was designed with a cold, unfriendly, competitive team as the ideal users; the docs say people should try out changes in scratch editions and then convince the owners to apply them. --LorenzoGatti

VAJ has lots of cute features, but woefully inadequate documentation. We've been using it for six months, and are still hearing about things it does that we had no idea of.

IBM has done a dreadful job of educating people about the tool, it's not something you can just pick up without someone on-site who understands it. There's still too much folklore for which IBM presumably sells consulting. That said, if you know the lore and the process it's supposed to support (which probably doesn't include UML), it's very powerful. --sf

The best IDE's I've used in the past combined together tools, VAJ locks you out. Would you be more productive with vi? EMACS? ed? notepad!? Tough luck. Want to do some refactorings? Maybe you like to do these with a TrivialPerlScript. Tough.

The extent to which the IDE is closed, compared to SmallTalk is understandable but very frustrating. It negates many of the advantages of an image-based environment. --sf

Would you like the syntax mark-up reflected in the hard copy? Tougher still.

We are working on a distributed app. We need to manipulate CORBA IDL and its generated code. Oh my god no, the horror of it!

Java is not SmallTalk. Java and its associated tools (e.g. ORB code generators) work in terms of compilation units.

In rare situations, this is quite important as the order in which static blocks gets run depends on its position in the file. --sf

The way VAJ deals with class paths is a nightmare.

The version we have [2.0 on NT] is flaky. People have learned to version their code many time a day in order to be able to recover from crashes. Is that really what version control should be about? (you don't want to know how big our repository gets between compactings).

I don't understand this. While we've had a few problems, I'm generally up for a week at a time. One bug to watch is that if you put 2 breakpoints into a method and then change it, you'll break the workspace. That's the only dangerous thing I know of --sf

The searcher is unreliable, weak, and is presented as if it understands Java source semantics (as its SmallTalk ancestor would), but in fact it doesn't have a clue.

Is there an IDE that's much better at this? I miss grep and its derivatives, and the NT ports don't quite seem to cut it. --sf
My favorite IDE is called Unix! --DW

The apparent state of the workspace can be very different from its true state. Large workspaces can be very unstable. I am told an Accenture team disintegrated with permanent damage the repository of a large project because they inadvertently hit the size limit. Do that with CVS if you can.

: "I am told..."? The size limit is 16G. That's right, sixteen gigabytes. How does even a "large project" contain 16G of code? I strongly suspect that either a) you were "told" incorrectly, b) you heard an urban legend or c) you heard of a development process so badly mucked up that no respository would survive.
: The repository posts multiple warnings when the size limit is approached, the process for cloning repositories is spelled out clearly, and any project that has that much code can and should surely be divided into smaller pieces and spread among multiple repositories. 16G of unpartitioned java! What a nightmare. --TomStambaugh

It doesn't understand inner classes.

Single level undo.

Having to step into a compound statement.

Visibility filtering ignores "package", just gives you public or everything.

The confusion between saving and compiling makes TestDrivenProgramming harder than it needs to be.

OK, now that you've gotten that out of your system :)

(1) What do you mean by "It doesn't understand inner classes?" I write inner classes in VAJ every day.

Inner classes appear in the browser in an odd way, and they often don't export properly--and even when they do, there are many spurious error messages generated.

(2) What do you mean by "the confusion between saving and compiling makes TestDrivenProgramming harder than it needs to be". I use JavaUnit and VAJ in a TestDrivenProgramming way every day as well and I have no problems. Could you elaborate on this?

We do all these things too. All of us who have used this technique outside of VAJ find that the eager compilation of code gets in the way.

Can you elaborate on how "eager compilation of code gets in the way."?

Seconded, I don't understand the problem. You don't have to get all the code compiled to be able to run. --sf

Also, are you using the IDL feature of VAJ? It does allow you to work simultaneously with IDL and Java in the same workspace...

Yes. We hate it. Not only is it difficult to set up, but every so often the IDL's "disappear" mysteriously

P.S. Searching is MUCH better in the next version...

KyleBrown

I just started using VAJ. I have been in the habit of organizing my code in one directory ("java") and my tests in a separate directory ("jtest"), and having both directories on the CLASSPATH -- thereby keeping tests and code separate, but still having tests live in the same package as the code they test.

You can't do this in VAJ, and that makes me sad.

--BrettNeumeier

VisualAgeJavaThree is far and away the best Java IDE if you ThinkInObjects? at all. But here's my gripe: Why oh why can I only store my source code in the repository?? What about all the other myriad types of file that need to be tracked, versioned and shared amongst my team members?? This half-and-half approach is mad. --RichardEmerson

I was doing great at secretly introducing XP to my client, but they've thrown a spanner in the works by introducing VisualAge:

The code suppos... I mean repository seems to want every package to be owned by someone, and only lets that someone mess with it. Unless I figure out how to work around it, this totally ruins CollectiveCodeOwnership.
printStackTrace does not print line numbers. The line numbers are essential for interpreting the stack trace of a failed test. Without line numbers, unit tests will become much harder to write or interpret, and that threatens everything.

Have you tried turning off the JIT? First thing I thought of, but how? I'm sure it'll be obvious once I know how, but it isn't obvious yet...

So far, it's looking to me like a very XP unfriendly tool. --WayneConrad

Have you looked at the VisualAgeJavaRefactoringBrowser feature request? That might be the feature to make VisualAge worth the pain.

One trick with ownership is to run everyone as the same user. We put initials in the version names instead. Another option is to develop as yourself but to release using a special identity. Switching workspace owner helps to avoid mistakes (whoops, didn't mean to release that) and adjust mindset. Unfortunately, unlike VisualAgeSmalltalk, you can't write yourself a button to make it easy to change role. Otherwise, we find the workspace cross referencing and fine-grained merging really useful for refactoring. We're doing some other things in SourceSafe and locking out files is a real pain. Also, the dynamic environment really helps when you want to AskTheCode. --SteveFreeman

I'm glad there's a workaround, clumsy though it is. I'll suggest that on Monday. Since I'm doing guerilla XP, it's important that they don't figure out why I'm asking for it <grin>.

Thanks for your answers to my gripes. It's still an XP unfriendly tool, but it sounds like I can workaround its worst parts. --WayneConrad

You're welcome, but we'll have to disagree on this one ;-). --sf

Update: Have more experience with VAJ now. Lost the fight to have everyone develop as the same owner, so now we're all doing the "Visual Bureaucracy Shuffle". Still haven't found a way to turn off JIT so that I can see line numbers in JUnit stack traces. Hoo hah.

I get the feeling that this is a way to make all developers equally unproductive, so that the command-line guy in the next cubacle can no longer make you look bad. --WayneConrad

Sorry, but why do you need to see the line numbers? We always set it to catch assertion exceptions and the debugger just pops you right into the stack. VAJ has very strong opinions about the world. You have to buy the story or, as you say, it'll get in the way -- or go with the tool let it help you. After VAJ, I find it very frustrating not being able to do things like fix code on the fly and keep going, or excecute arbitrary code all over the place, or get _all_ the references to a feature. --sf

Sorry Wayne, I don't understand your problem. I find the "Visual Bureacracy Shuffle" of VA compellingly more attractive than the corresponding nightmare of logins, labels, protections, masks, private and public branches, views, vobs, paths, static and and dynamic views, etc., etc. etc., that comes with the corresponding ClearCase functionality. Try this on your competing alternative: in the middle of a tense debug/code session, pull the plug on your development machine. I'll pull the plug on mine. Then let's see who comes back to useful work first. In VA, your work is *always* in the repository, and is *always* recoverable.

Secondly, why on earth do you use *line numbers* in JUnit? I use the debugger to set a breakpoint in the failing test, and start there. I suspect that with only a little more effort, I could put conditional breakpoints in the test case code and have it automagically pop a debugger. Trust the force, Wayne. --TomStambaugh

The "pulling the plug" part of VA is neat, but not a big concern for me. How often does that really happen? But is that really why the VAJ repository works the way it does? I get the impression that the immediate-save part of it is necessary to support VAJ's model of group development.

It happens, in essence, each time you inadvertently do something that confuses the interpreter. Also, each time "systems" takes down the network for backup or maintenance in the middle of a session. Also each time the DBA down the hall clogs your network connection with a 200G network transfer.

As for "why", I have the distinct impression that we are looking in opposite directions through the same pair of binoculars. I would describe "VAJ's model of group development" as the happy outcome of the "immediate-save part of it". The concept of a persistent "image" that saves everything, including all prior changes, is a fundamental aspect of Smalltalk. It is therefore a fundamental aspect of ObjectOrientedProgramming. Yes, it is a *major* mind-shift from other styles, and it has very little to do with language syntax (although C++ demonstrated that appropriately baroque syntax can make OOP much more tedious). The original Smalltalk-80 environment included a "RemoteString" class, used for keeping source code in the external filesystem. Every change was written to the filesystem on every change. The original contribution of Envy was to allow a group to share a single source, instead of replicating them. -- TomStambaugh

The bit about ClearCase is interesting -- sounds like ClearCase is no better -- but I'm not comparing VA to ClearCase. Remember, I'm the resident troglodyte that doesn't care to use Big Bang Tools. My environment of choice for Java development is JDK/bash/emacs/make. For versioning I've been using RCS. All of these tools suck, but they suck in an adequate way. Despite their serious deficiencies, they fit my brain well, and I am very productive with them. However, I have no doubt that you are also very productive using your tools. Different brains need different tool sets.

ClearCase is no "Big Bang" tool, it is an overgrown RCS. Thus, you can freely substitute "RCS" for "ClearCase" in my argument. In your case, I would compare the "Visual Bureacracy Shuffle" to the time you spend frobbing makefiles, environment variables, shellscripts, emacs macros, symbolic links, directory structure refactoring, and so on and so forth. Perhaps you have developed your own personal style (most of us have), but I suspect that if you are part of a team of, say, 15 developers, then I suspect your team has its own dance that you do instead of the "Visual Bureacracy Shuffle". -- TomStambaugh

I am chewing on this bit of making the debugger stop on certain exceptions. I'll let you know what it tastes like.

WayneConrad (aka "Thog")

It is funny how all this discussion seems makes this development environment seem to outdated, both VisualAge and ClearCase way of versioning have lost the battle against SubVersion, MercurialVersionControl and GitVersionControl...

There is no way to create package level documentation (with JavaDoc) which seems a pity since one can write comments at the package level which could be included. --ChanningWalton

Several things that seemed more to be requests for advice than gripes were moved to VisualAgeJavaAdvice -- DavidSaff