IBM claims VAJ and WebSphere more integrated than ever


News: IBM claims VAJ and WebSphere more integrated than ever

  1. IBM claims VAJ and WebSphere more integrated than ever (4 messages)

    IBM has written an article promoting some new integration points between VisualAge for Java v3.5 and WebSphere. I am curious to hear reactions from the community who have used these new features.

    Click here for the article.
  2. Well, as someone who has been using 3.5 for two months now, I have to say that the product isn't really there yet. There are several good things - which I won't mention here because they are not good enough to outweigh the problems with VAJ:

    - performance of the WTE is totally unacceptable. We're using 700 mhz machines with 256MB and it takes the WTE 10 minutes to start up. During that time, the cpu monitor shows 100% utilization. Once it does start, all applications run slowly (the cpu often is at 100% utilization) and crashes frequently.

    - implementation of some of the "wizards" is incomplete. I strongly recommend against using the VAJ provided tools for generating entity beans from a database schema. Once you walk down this road there's really no turning back. Our project is experiencing a lot of instability in its data model requiring us to update our entity beans frequently. Unfortunately, you can't get away with generating just one. Because of the nature of the "wizard" you must regenerate all the beans in your EJB Group. We have 30 entity beans, it generally takes 1 hour for the wizard to to its work.

    - entity beans require the Persistence Builder framework (an IBM proprietary set of classes).

    - beans running within the WTE can not call out to beans in a WAS production environment.

    - beans deployed in on WTE server instance can not call beans deployed in another WTE server instance (on the same machine, in the same VAJ session)

    I'll cut off here to avoid letting this post spiral into a flame. However, I do suggest that you look at the vajava newsgroup under the what do you think of VAJ thread. There's lots of intersting commentary there.

  3. I'm not sure if integrated isn't a more politically correct way to say proprietary when it comes to IBM development tools.

    Our group began a new project with WebSphere AE 3.02 and upgraded to 3.5 but finally had to drop the tool altogether after running into much of the same problems that the first post alluded to.

    I also don't want to start a flame here as Vaj has many strengths but it's too slow, too proprietary and too far behind 1.3 to be a serious contender to BEA/JRun/EJBoss/etc.

    As an aside I have to say that I was also seriously disappointed with the lackluster support/lack of technical knowledge that our onsite IBM 'experts' provided us. But there are so many patches and workarounds to the product that it's probably not their fault that they can't keep current.

  4. I spent the last three months mainly working with VAJ3.5 and WAS3.5 (WebSphere Advanced Server), dealing mostly with EJB (CMP entity) and Servlets, but only with limited JSP. (we are not in the UI phase of the project yet)

    I would mainly talk about VAJ3.5 concentrating on its J2EE support in this writeup.

    (Note: As we know, IBM is not an endorser of J2EE, although it's an understatement to say it has been playing significant roles in its inception and evolution. Here I use J2EE as a synonym for EJB/Servlet/JSP.)

    1. Don't get surprised to see favorable reviews of the tool. But don't get surprised to hear negative comments from serious enterprise developers either. Mainly on stability and (development) performance.

    2. You would probably be impressed with the features (esp related to J2EE), but you would get frustrated when you get into some serious development. The tools is slow and unstable.

    Read on for some details.

    I am impressed with the features that are packaged into VAJ3.5. Most of them works. Here is a brief rundown.

    Java 2 support is probably one of the most looked-for's and it's finally in place in VAJ 3.5. I know, as exciting as it is, it's after Sun's shipment of J2SE 1.3 in May. So, be aware it is a generation away and there's no sign that IBM's approach will be much different in the future.

    EJB support is 1.0+, as IBM puts it. It supports 1.0 but has more. It also comes with the object association support as a technical preview. (It should work with not just WebSphere). And it works nicely, MOST OF THE TIME. I've ran into bugs that cost me several hours each. Be open minded when you use that. Again, if you are looking for the latest spec, such as likeliness of EJB 2.0 support, look elsewhere.

    Servlet 2.1 and JSP 1.0. If you want Servlet2.2 and JSP1.1, IBM provides an alternative - there is an Apache Tomcat Test Environment (3.1) which you can plug into VAJ.

    WTE - WebSphere Test Environment. Probably the flagship feature of VAJ today. It's a trimmed down version of WebSphere server and it runs inside VAJ's virtual machine, so developer can test all of their code inside Visual Age. You have the advantage of simplicity of development, independency of testing among team members, and above all, debugging capability of your server-side code.

    EJB Test Server and Client. You can test your EJB inside VAJ. You need to first start the Persistence Naming Server in WTE. Then run your EJB as a Server and there is a nice EJB client program which lets you test your beans without the need of writing extra testing stubs.

    VAJ 3.5 will work nicely for your HelloWorld program. But when you start serious development, you will start hitting problems.

    1. VAJ is very unstable. It can lock up, or crash. Although, it claims to support Windows98 (the WTE in 3.0.2 only supports NT), it is almost unusable for me. I then switched to Windows 2000. Things looked good for a while, then I was still experiencing annoying freezes and crashes.

    2. Memory leaks, or as IBM specifies, the Work Space growth problem. At a high level, you use VAJ 3.5 (especially the WTE) for a while, VAJ will use more and more of your RAM. After a clean installation, my Task Manager says 120M RAM are in use. After a couple weeks, my Task Manager says 220M RAM. So we have to reinstall VAJ every once in a while. The defect has been identified, but no solid fix date yet.

    3. WTE is very buggy. Sometime, you just experience partial crash or full blowout (of VAJ), sometime, your code that should code does not. Very time consuming.

    4. WTE is very slow. Code generation is very slow. Testing is very slow... Of course it depends on the scale of your project. (We only have 8 CMP entity beans.) Plus the unstability, it makes the development a challenge. Think twice if you want to pick this right now for a project with a tight schedule, or budget in significant amount of coding/testing time accordingly.

    5. EJB client is a nice tool, but it only works with WTE. Using it to test against the real WebSphere is not feasible, at least for now.

    I just gave your some of the main problems. But the list goes on...

    We were relatively happy when we had just 1 or 2 beans. As the number of beans go up, we started to experience the problems more often and things turned out into untolerable rather than annoying. So we finally gave up on using the WTE and had to deploy Servlet/EJB on the actual WebSphere server to do testing. But then debugging became a problem. (We haven't tried the distributed debugger.) It's still a workable development environment, but the main selling point of VAJ stays dormant. That's grievious.

    I've looked at VAJ's fix patch plan. Patch 1 and 2 do not address problems I have run into. There is a long list of bugs that they are currently working on. Also, problem reporting to support is not very effective. They demand test case which costs time to build.

    I have limited experience of other tools in J2EE development. And I know for many, IBM is the choice regardless. Advice: You are better off if your project is of smaller scale, or is proof of concept/prototype in nature. Do put people with experience in your project. And look out for assistance. And be prepared for adopting the tool/technology with some patience. Exercise the best practices to have prototyping and phased approach, while crossing the finger that IBM will produce the fixes in overwhelming pace and promote the maturity of the tool. Also hoping Sun and the rest of the Java world would not be effective in creating new specs. :)
  5. VAJ is full of bugs. It makes me wonder if the VAJ development team has some serious competence issues. At the very least, it's easy to conclude that their management is reckless at best and incompetent at worst. Can you imagine a more effective way of damaging VAJ's reputation?
    here is a sampling of all the issues:

    Can you believe it. You thought VA Java 3.5 was slow, now with Fix Pack 2, things are even slower.

    The one thing we have found is the the JSP compilation process have slowed down by about 50% or more. On our 733MHz 256MB machine, JSP compilation is just a dog's lunch. Also, the compilation process can sometimes cause VA Java to freeze and take up 100% CPU.

    This code doesnt compile with VA 3.5 patch 2 :
    class C {
         static class Inner1 extends C {
         static class InnerA extends C {
         static class Inner2 extends Inner1 {

    it gives me the compile-error:
    "Superclass creates a cycle in the class hierarchy: C$Inner1"

    I didnt invent this code on my own - I just found it
    while importing Xerces 1.2.2 (and 1.2.3).

    this code compiles ok. with JDK 1.2.2 and JDK 1.3.

    It seems VAJ 3.02 is better than 3.5 Unlike hobby programmers like myself, professional developers would feel
    really bad about this VAJ3.5 situation since many have invested VAJ time and codes, and I don't think they can move back to 3.02 once repository is converted to 3.5
    Linux users would feel even worse becasue it is not even certain when they get 3.5, and how reliable it would be.

    I installed patch 2 for VAJ 3.5 (PRO) hoping that the External Version Control stuff would be fixed. In the patch 2 notes under external version control, I found the note (6) "Poor performance when performing function 'Add to Version Control' with a large number of files (> 100)" as a problem that was fixed.

    I tried to to add files from version control (about 200) and the ide kept churning away for 20 minutes and my machine froze and I had to kill the ide maunally. On restarting the ide, I don't find a single file in the ide! So what did it do for 20 minutes?

    Also, the code formatter is still broken. Looks like Patch 2 doesn't really fix much.

    Then I had exported jar file from VAJ.Then I tried to sign it using jdk1.2.2 jarsigner toll.It failed reporting an error saying:
    "jarsigner: unable to sign jar: invalid entry compresssed size (expected 509 but got 507 bytes)"
    After that I exported files in directory, made a jar using jar tool. After that signing works OK?????

    One of the biggest problems with VAJ 3.5 has been the export problem. For any development team not using the Repository, having clean concise code after an export is
    crucial if not downright fundamental.Therefore, how is it that the biggest problem which was to be addressed in
    this patch is still not fixed, when it was supposed to be. Its not that hard to check to see if it works, export
    and load the code in Notepad. It seems IBM should have beta'd the patch too.

    When marking code as deprecated it seems to be random as to whether the methods which refer to this code are flagged with warning markers. A lot (most) of the time they don't show up.

    I installed Tomcat in Visual Age (from the IBM site).
    I added a folder to the Project Resources and had to wait 1/2 hour whilst VAge 'released' every file in the resources directory. I tried pressing cancel but all that did was to disable the cancel button -it continued releasing.

    It seems impossible to write an agent in Domino that consists of several classes.Writing an agent consisting of one (1) class works fine but that sort of defeats
    the whole idea of java. When writing with several classes the "calls" to other classes does not work. The classloader cant find the class, probably because the package name
    is included in the call and all classes are in reality stored in the database not in the file system. It sure looks like a bug or a compatibility problem.

    VisualAge 3.5 patch 2 locks more Corba classes than VA3.5.
    I am using the professional version of VA and need OrbixWeb 3.2 in it. An example of the locked classes are: org.omg.CORBA.portable.ObjectImpl
    and org.omg.CORBA.Object which are not compatible with the same classes from OrbixWeb. (What happens is that the generated classes have errors in them because the OrbixWeb class doesnt define Object>>_get_Interface_def for example).