IBM VisualAge for Java for Linux

Locutus writes "IBM is said to announce at JavaOne that they are working on VisualAge for Java on Linux and are looking at a 4th quarter release date. This is a really amaizing development IDE for Java (editor could use some work though). Now if BlackDown can just get the JIT crank'n faster we will be styling. Here is the news article: VisualAge for Java on Linux "

Comments

This is a good thing.

[SoftwareJanitor]

Visual Age for Java is the preferred Java development tool where I work. This will be another great opportunity for me to advocate and use Linux at work.

Despite some people's opinions, Java is far from dead. Now that the hype has died down, businesses are switching to it for use as a primary enterprise development language. Applets aren't really even that important. We are using it more for Servelets and full fledged applications.

Contrary to what some people also say, write once, run anywhere is not that difficult. I've written Java apps that run fine on Solaris, NT and Linux.

Also in my experience Java performance is not that bad, especially when you consider that most uses of it are for things that would have otherwise been done in either (ick) Visual Basic or PowerBuilder (both of which are as slow or slower than Java for most things and neither offers anywhere near the cross-platform capability of Java). Sure, its no competitor in speed to C or C++, but how hard is it to write a complex (something that is over 50,000 lines of code, uses multithreading, a GUI, etc) C or C++ program that is multiplatform? I know from experience it isn't easy, it can be done, but it isn't easy and it isn't usually pretty. Multiple *nix variants and Linux are no problem, but it is no fun to make something run on standard platforms and also on Windows due to poor standards adherence in most Windows C/C++ compilers. Porting stuff to the Mac isn't much better because while the basics of the compilers there seems reasonably robust, their standard library implementations seem quite weak and the Toolbox works quite differently from Win32 SDK or the POSIX API.

All that being said, I wouldn't advocate Java for everything. I like and use C, C++ and Perl for lots of things also, but people who want to poo-pooh Java just because it isn't the latest thing just seem to me like they are deluded. I've seem to many things dismissed for dead too quickly while they slowly build acceptance for me to believe it that easily.

Re:The tools are cool - its Java that needs work

[Anonymous Coward]

Gosh, I haven't seen such idiotic claims in my entire life.

You comments are so wrong that I wonder if you really have been doing serious development. The only "slow" aspect of modern Java VMs is Swing/Java2D.

Are you even aware of how much Web development is done in Java or other VM based languages and NOT in C/C++?

Let's put it this way. My company has an server-side Java product that handles 10x the number of concurrent users than the nearest C++ competitor on the same hardware simply because of superior multithreaded design. Even the *JAVA WEB SERVER* can handle more concurrent connections than Apache, which poops out at around 120+ concurrent connections.


Second of all, Java is far from dead. Sheesh, almost all new development except in a few specialized areas is being done in Java.
Especially, most server-side code. Every new W3C standard is prototyped in Java first. John Carmack has written all his new Quake3 support tools in Java, etc. No one is going to seriously challenge traditional C/C++ office applications, because the market isn't worth it. Only in new areas of development do you see new languages being used.

Eiffel blows away C++ too, but no one has written a killer app in it. That doesn't mean there's someting wrong with it.


I don't know how many times I have to keep explaining this to the macho C morons, but scalability has *nothing* to do with raw CPU execution speed (which JITs handle quit well). Transforming polygons yes, rendering database results, no. Raw CPU is the lowest determiner of scalability. The CPU spends the vast majority of its time waiting on memory, bus, network and disk i/o.

If you want to be scalable, consume as little state and disk as possible.

C++ falls flat on its face for server-side programming. It takes 10x as long to do the same thing in Java/JSP, and you still end up having to track down null pointers and memory leaks. That's why eBay and Onsale have more downtime than scripting oriented sites, because scripting languages are VM based and handle automatic memory reclaimation and shield the programmer for GPFs. eBay died because of a C++ memory leak.

Perl is great for text processing (I've been programming perl for 5 years), but its lack of static type checking makes it poor for team based
projects. If you're the only coder, fine.
Perl is also slower than Java.


The fact of the matter is, for the forseeable future, server-side languages are going to be high level 4GLs and VM based languages, NOT C++.

C/C++ are a resource drain on any IT department. Why the fuck does an intranet app to process forms have to be coded in a bug-happy language like C++, when a VB, Tcl, Perl, Python, or Java programmer can do it quicker, with less resources.

C++ is an IT resource drain for most companies. Money down the hole on programmers who spend extra time on bug tracking bullshit.

Which is why 99.9% of all CGIs are written in ASP, Cold Fusion, Perl ,Python, Java, TCL, or PHP, and *NOT* C/C++.


You might claim VM's are a dumb idea, but the fact of the matter is, most of the code being written in the world is being written for VMs.
The number of lines of VB code alone would dwarf C++.


Did you ever think that maybe your application was slow because you don't know how to code in Java? jEdit is an emacs clone in Java that is lightning quick on my P166. However, there are plenty of similar Java editors that are dog slow.

Java doesn't automatically make an inefficient programmer more efficient.