|
The last time I tried to install VAJ was version 3.0.2. The installation twice halted the system (NT Server 4.0, SP6a), which is very rare under NT (couldn't kill the running processes). A previous install of a version 3.0 did actually get itself off the ground, but even with the latest service packs installed it was not usable (it regularly stopped responding, and I lost the source code I was testing with). Unfortunately, these issues are not related to usability, such as a NoClassDefFound, which would have been resolvable. My installation machines have all been at least PIII 733 mHz machines with at least 256mb memory loaded with NT 4.0 at the latest service pack level. My preference would be to stick with IBM, and I would prefer also to use an IDE, but I'm hesitant to spend more money to upgrade to a later version of VAJ which I have no confidence can even install successfully, and this is one specific area which needs work. Based on my experiences, I am surprised to hear that anyone is successfully using VAJ, so maybe I will consider upgrading to 3.5, and the Linux availability for VAJ provides an additional compelling reason to try it again. One usability concern I've had with VAJ, and one which is echoed in the article "Linux-Friendly VisualAge for Java" linked directly from IBM's VAJ Info page (http://www-4.ibm.com/software/ad/vajava/about/v35/vaj35platforms.html), is that source code is not stored in the file system, but rather within VAJ's repository, so data corruption (or even intended behaviour of the product) can alter/damage/destroy your source code. Here's an excerpt: *** But woe to you if you need to incorporate an outside technology into your development process. The only way to expose your project to the outside world is by exporting either source code or bytecode. If you can't already see the train wreck ahead, let me provide a simple example which immediately confronted me. The project I am currently working on is stored in a remote CVS repository. If I want to use VisualAge on my project, I have to import the entire thing into the VisualAge repository. When I'm finished making my changes, I need to export the entire project (or, if I've kept track of which classes I've modified, I can just export those) back to the file system. When the code is exported, all the original formatting, warts and all, is reworked to conform to the VisualAge formatting specifications. Unfortunately, this tends to confuse diff to no end, rendering the merge- and change-history capabilities of CVS/RCS completely useless. My response to IBM vis-à-vis the wisdom of the repository approach would be an invocation of the Hippocratic oath: First do no harm. If a feature is not useful, you should be able to ignore it. It should never stand in the way of using the entire product. *** Has anyone had any problems with this model? Thanks, Shawn ----- Original Message ----- From: "Joe Pluta" <joepluta@PlutaBrothers.com> To: <JAVA400-L@midrange.com> Sent: Monday, June 18, 2001 1:26 PM Subject: RE: VAJAVA vs CODE/400 > VAJ 3.5 Patch 2 is very reliable and robust. For me, it's far easier, > especially at jar file packaging and deployment, than command line > techniques. Each person has their own style, but I haven't had a single > problem with VAJ as an editor in quite some time. Anybody who has a > specific problem with VAJ, please post it and let's see what we can do to > address it. > > Joe Pluta > Moderator > > P.S. Please do not turn this into an IBM vs. Microsoft discussion, or even a > "my IDE is better than your IDE" argument. If there is a specific area > where one IDE is better than another, feel free to post details. By far, > though, the best discussions are "how-to": if you have a problem, please > post it and we'll see if we can answer it. > > > > -----Original Message----- > > From: owner-java400-l@midrange.com > > [mailto:owner-java400-l@midrange.com]On Behalf Of Shawn Church > > Sent: Monday, June 18, 2001 10:28 AM > > To: JAVA400-L@midrange.com > > Subject: Re: VAJAVA vs CODE/400 > > > > > > I gave up on VAJava a long time ago; it really isn't very good despite all > > the hype. I have installed various versions of VAJava 4 or 5 > > times over the > > past 3 years, along with any available fix packs, but I rarely have gotten > > it to work reliably, and I am not comfortable it will not dump all my work > > when it crashes. JBuilder is better (not as fancy, but more > > reliable), but > > I am much more productive with a good text editor such as UltraEdit. > > > > The Java language however should not be blamed for shortcomings in IDEs. > > Java will be around for a long time to come, and it is a very powerful, > > easily-learned language (OO concepts are probably more difficult for many > > people to get a handle on than the language itself). > > > > I have gone back to using a decent editor and compiling and deploying from > > the command line, at least until a better IDE comes along. > > > > As far as VB is concerned, most Microsoft products are excellent, and many > > of the slams are misdirected at applications rather than the Windows > > operating system itself, which more arguably deserves criticism. Visual > > Studio is certainly more advanced than any of the Java IDEs I have used. > > > > Shawn > > +--- > | This is the JAVA/400 Mailing List! > | To submit a new message, send your mail to JAVA400-L@midrange.com. > | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. > | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. > | Questions should be directed to the list owner: joe@zappie.net > +--- > +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.